I don't know that the privacy goal can be met without a client side identity selector of some sort.
(this problem is solved in info-card that is why it has a selector)
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.
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.
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.
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.
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.
https://higgins.eclipse.org/cloud-selector-test/ ttp://wiki.eclipse.org/Cloud_Selector Have a look at this and let me know if it solves part of the use case.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.
John Bradley On 16-May-09, at 10:42 PM, Andrew Arnott wrote:
Sounds like a great idea to mock up for a demo. On Saturday, May 16, 2009, John Bradley <jbrad...@mac.com> wrote:There is nothing that would stop an RP from performing discovery on some group URI to discover a OP Endpoint.Once the RP has the endpoint they can do an identity-less request to the OP for the session that is currently logged in.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.This would require some work to get right but is far better than overloading the identifier.John Bradley On 15-May-09, at 3:55 PM, SitG Admin wrote:Keeping it identity-less also allows the assertion to come from a 3rd party.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.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.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."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.)-Shade-- -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
