[OpenID] Secure attribute transmission

[Andrew Arnott]

Very good point, Nate.  I hadn't considered #2.  Although one might argue
that once spyware is on the computer, all confidentiality bets are off
period anyway.

On Sun, Aug 3, 2008 at 3:10 PM, Nate Klingenstein <ndk at internet2.edu> wrote:

> 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! :)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080803/a17aa7b5/attachment-0002.htm>