<div dir="ltr">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.<br><br><div class="gmail_quote">On Sun, Aug 3, 2008 at 3:10 PM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Andrew,<br>
<br>
I agree with you in general, but you might face resistance.<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
#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.<br>
<br>
Take care,<br><font color="#888888">
Nate.</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
On 3 Aug 2008, at 21:45, Andrew Arnott wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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! :)<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>