* Sara Hopkins <[log in to unmask]> [2012-10-08 15:52]:
> Please note that the UK federation recommends that you do not push
> attributes with the authentication assertion for SAML1.1 because
> they cannot be encrypted; you thus have to push them in the clear.
>
> As to whether the data is personal or not; there may be different
> definitions of this according to country.

You'd potentially expose yourself suggesting otherwise, so the
conservative official recommendation is clear and all well.
I was just saying that an institution could look at the risks involved
and still decice to push attributes.

The risk of some unauthorized person with full access (!) to your
computer (!) and webbrowser -- while you're have an active SSO session
with your IdP -- also getting access to your ePSA values
([log in to unmask]; [log in to unmask]) from a SAML-assertion seems
like a small price to pay, IMHO, when you gain added resilience in
your IdP deployment for free (otherwise).
For the most common services (publishers) there will be no personal
identifiable data involved (if only ePSA or ePE with the
common-lib-terms value are released) and much of the information that
would be available to the unauthorized person can possibly be deduced
from the misused computer itself.

More realistically, people grabbing SAML-assertions from someone
else's webbrowser while logging in to SAML1-only entities (that
usually means disabling JavaScript in the webbroser first) and then
base64-decoding the content might find more lucrative ways to misuse
someone else's WebSSO session or comuter (with all its files and
emails on it!). The SAML assertion in transit is not a relevant target
in such a scenario, IMHO.

So the risk of exposing data from the SAML assertion to the HTTP User
Agent /for use with SAML1-only publishers/ is vastly overstated, in my
very personal opinion.
(Has there been a single report of such an incident in the history of
SAML-based WebSSO? That of course might be due to the fact that
institutions either don't push attributes in the clear or use SAML2
and encrypt: No way of knowing if the threat is exaggerated or the
consistently applied mitigation so effective.)

Of course it's easier to say "No risk is better than a very very very
low risk with potentially negligible or no damages". That just comes
with a price for the institution in operational complexity and the
costs associated with that (at least once you need resilience and
higher availability).

And all that is of course meaningless unless you know that pushing
attributes would actually help achiving that goal. Some SPs might not
stop issuing SOAP queries even if an attribute assertion was included
with the initial authentication assertion.
-peter