Requiring Pseudonymous Identifier

[John Bradley]

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.

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 <jbradley at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090517/251f0c4c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1722 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090517/251f0c4c/attachment-0002.bin>