[OpenID] Secure attribute transmission

[Nate Klingenstein]

Andrew,

I agree with you in general, but you might face resistance.

We've faced this issue in Shibboleth for a long time because SAML 1.1  
has no encryption of the payload.  As a result, we faced two  
choices.  We could ship nothing particularly valuable in the payload  
and do a back-channel call for attributes, which was generally via  
mutually authenticated TLS(we have to be careful whom we released  
student information to).  The alternative was to "push" the  
attributes through the browser without encryption.  There was TLS/SSL  
used on both legs of the journey.  Attribute push still encountered  
strong resistance for two reasons.

1)  The user can see all their attributes.  I don't consider this a  
significant problem, but a few minor use cases may require  
confidentiality between providers.
2)  The user's spyware -- and many users have plenty of it -- can see  
all the user's attributes too.  Harvesting attributes is trivially  
automated and fun for all ages.  This is, of course, a very large  
problem, and often ends discussions immediately.

#2 was sufficient for almost everyone to avoid attribute push,  
despite also having major problems with the setup of mutually  
authenticated TLS.  We now default to attribute push in SAML 2.0, but  
would probably have to revert back to the callback method.

Take care,
Nate.


On 3 Aug 2008, at 21:45, Andrew Arnott wrote:

> The openid.response_nonce won't be helpful here.  If your RP can  
> work only with HTTPS OP endpoints, and if your RP has an https://  
> return_to address, then you're already golden.  The authenticating  
> user will have the opportunity to see the information flash by in  
> transit, but no one else will, and presumably this information  
> isn't to be held private against the user himself! :)