<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">So is it fair to characterize the use case delivering a attribute to a RP that the RP can trust because it knows or the issuer can prove it's authoritative for the attribute in some way, while leaking the minimal amount of information to 3rd parties.<div><br></div><div>I don't know that the privacy goal can be met without a client side identity selector of some sort.</div><div>(this problem is solved in info-card that is why it has a selector)</div><div><br></div><div>The best thing would be for the RP to guide the user to select the correct endpoint OP endpoint for that assertion and perform a identity less openID transaction to get the attribute/claim from the OP. If the user uses the same auth OP for the attribute OP the auth OP learns that the user has a relationsip with that attribute provider anyway, but at least they don't see the value of the attribute.</div><div><br></div><div>If you are going to pass the token through the users Authentication OP there are questions of end to end encryption that need to be addressed. The token issuer would need the cert of the RP etc.</div><div><br></div><div>This has been well thought out in SAML and WS-Fed/Infocard. If there is a particular use case that needs solving I am OK with that, but lets not reinvent the wheel for a third time just for something to do.</div><div><br></div><div>The original design goal of openID was to provide correlation and disclosure for blogging. Trying to retool it into something with perfect privacy will take work.</div><div><br></div><div>This is a hybrid service where a RP can ask for a claim from a 3rd party and have it encrypted end to end. It uses information-cards hosted at the OP.</div><div><a href="https://higgins.eclipse.org/cloud-selector-test/">https://higgins.eclipse.org/cloud-selector-test/</a></div><div>ttp://wiki.eclipse.org/Cloud_Selector</div><div><br></div><div>Have a look at this and let me know if it solves part of the use case.</div><div><br></div><div>Once a User is logged in an identity less openenID request could be make and the user has the ability to direct via the card metaphor what issuer will generate the token.</div><div><br></div><div>John Bradley</div><div> </div><div><div><div>On 16-May-09, at 10:42 PM, Andrew Arnott wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Sounds like a great idea to mock up for a demo.<br><br>On Saturday, May 16, 2009, John Bradley <<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>> wrote:<br><blockquote type="cite">There is nothing that would stop an RP from performing discovery on some group URI to discover a OP Endpoint.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Once the RP has the endpoint they can do an identity-less request to the OP for the session that is currently logged in.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The OP returns what is the openID equivalent of a bearer token in that it is about whoever presents it as it lacks a "Subject"/claimed_id.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This would require some work to get right but is far better than overloading the identifier.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">John Bradley<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 15-May-09, at 3:55 PM, SitG Admin wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Keeping it identity-less also allows the assertion to come from a 3rd party.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The group may be the only one that can say I belong to it. They may have the openID's of there members and make membership assertions on there behalf without being a full IDP. That could be done with AX or oAuth for transferring the attributes.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">How about a restricted-access "group" (community, whatever an OP calls it) where members must have been approved? If the school doesn't want to run its own IDP, it can host an XRD file showing the URI's for Groups (Communities) on various 3rd-party sites that it has investigated and found to be run by those who will be responsible (cue internal policy decisions, here), so it declares them (groups, not sites) authoritative.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">From then on, if RP's want to know that a user is a student at that school, they check the school's XRD file, then say "Okay, you can prove membership in this group on Facebook, that group on LiveJournal, or some other group at MySpace."<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This kind of "delegation" brings us back to using those URI's, though. Then again . . . if the user's OP *is* that same site they are a member of some Group on, couldn't something be done there? (If the user is employing delegation as known to the spec, it seems unlikely that the Group page would be available for that user to control the OpenID headers of.)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Shade<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br>-- <br>--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the<br>death your right to say it." - S. G. Tallentyre<br></div></blockquote></div><br></div></body></html>