"This is user's URI" for Assertion Quality Extension

SitG Admin sysadmin at shadowsinthegarden.com
Fri Sep 5 16:53:47 UTC 2008


I've quoted your entire message below my reply since you appear to 
have sent your message to me directly and not to the list ;)

>How would the OP know if the user it's authenticating is a member at the RP?

Not a member at the RP, a member at the OP (or any site the OP is a 
proper authority for).

>Also, couldn't the RP keep track of the op_local value with the 
>claimed_id to help reduce clutter in the RP db?

I'm not clear what you're suggesting here. I did consider a different 
table for each 2nd-level domain to organize the database by so a 
zillion users from one site didn't make things worse for the rest, 
but decided against it because users would come from all over the 
place if they followed the spirit of OpenID (specifically: 
decentralization). Using a different table but still having a zillion 
entries (one per OP-Local at a single site the OP was vouching for) 
when it's possible to give all those users the same account (just one 
in the database) is wasteful and inefficient.

>Yes, the OP can hand out a totally random identifier each time the 
>user logs in, but that isn't the spirit of directed identity.

That's the impression I've gained from Yahoo!'s implementation ;)

I expect other OP's to improve upon the example set (nonsensical 
strings of alphabetical characters) in future, whether "random" and 
"anonymous" was Yahoo's intent or not.

>The "spirit" is for the OP to create a unique identifier for the 
>relationship of user:OP:RP and maintain that relationship across 
>time.

Ahh, okay, now I get it. You said "*each time* the user logs in", not 
just each time at a new RP.

I'm not concerned about one-time-only accounts. (If that were the 
case, it'd all be handled in session once someone authenticated with 
OpenID at all, and they'd never *have* an account. Come to think of 
it, that's how I was handling it in the first place.) I'm concerned 
about short-term "relationship across time" accounts that were only 
ever intended to maintain their relationship across a *very short* 
period of time.

There are other reasons for proposing this, of course, but the 
preceding explanation focuses on "new anonymous OpenID each session" 
versus "new anonymous OpenID for each user:OP:RP relationship".

>So I can see a use case for an RP to know the "real" identifier for 
>"linking" data for the user at the RP with other data by that user 
>"across the web". This seems to me to be the benefit to put before 
>the user.

Not just identity correlation, but more granular identity - I've only 
been able to think of 3 distinctions all sites have, but one of those 
(learned from Sun's implementation) is "I am a member of Sun but you 
don't know who." Is this the only variation of OpenID services that 
any company will ever come up with? I'm thinking here of membership 
levels, such as "This employee is technical support, this employee is 
sales." and "This employee works at an entry-level position, this 
employee is a manager." - all of which may be better suited to AX 
with the OP not letting its users set their own attributes, and since 
many sites either wouldn't use the granularity or wouldn't need it, 
there's not much reason here for sticking it in the Assertion Quality 
spec. But we could start out with the 3 distinctions known, and add 
others only if they became appropriate.

Hmm . . . the RP could process a URI to extract OP-Local and create 
one account for the entire site (*if* it knew that the user's account 
with that OP was "anonymous"). Here's the challenge: in cases of 
sub-domains, what's the site? Is there a meaningful difference 
between tech.site.com and sales.site.com?

-Shade

At 8:17 AM -0400 9/5/08, George Fletcher wrote:
>SitG Admin wrote:
>>>  What's the use-case?
>>>
>>
>>  If the RP doesn't care about distinguishing between users that 
>>have accounts at a site but identify themselves as such 
>>anonymously, it can reclassify them as "users that have accounts at 
>>a site", consolidating what could be a large number of identities 
>>into a single account. (This is largely a convenience for the 
>>Relying Parties, reducing database clutter but perhaps the 
>>performance hit wouldn't be noticed anyway?)
>>
>How would the OP know if the user it's authenticating is a member at 
>the RP? It's not required to keep that information? I suppose OPs 
>could keep track of all the RP's they've sent a particular OpenID 
>to... but it might not be trivial for the OP to extract that 
>information and make a determination that a particular OpenID falls 
>into the classifications you've listed.
>
>Also, couldn't the RP keep track of the op_local value with the 
>claimed_id to help reduce clutter in the RP db? This would help with 
>user entered claimed_id's. Of course in directed identity there is 
>only one identifier, but that shouldn't change on a regular basis 
>for the same user.
>
>Yes, the OP can hand out a totally random identifier each time the 
>user logs in, but that isn't the spirit of directed identity. The 
>"spirit" is for the OP to create a unique identifier for the 
>relationship of user:OP:RP and maintain that relationship across 
>time.
>>  RP's may want to discriminate between users that use a "real" URI 
>>and those that only use OpenID anonymously, just as users may want 
>>to experiment with new sites using a unique (randomly generated) 
>>URI that can't be associated with their accounts elsewhere, and 
>>then use their main URI if they decide they like the RP's services. 
>>(I'm hoping that others here will volunteer their own specific 
>>use-cases or what they *could* do with such information were it 
>>asserted by an OP.)
>>
>So I can see a use case for an RP to know the "real" identifier for 
>"linking" data for the user at the RP with other data by that user 
>"across the web". This seems to me to be the benefit to put before 
>the user. "If you use a correlatable OpenID at our site, then we can 
>provide you these additional benefits (e.g. automatically find 
>people that know you that also use this site)".
>
>Note that it's possible to provide these same benefits without using 
>correlatable identifiers, but it requires a service that knows the 
>mapping.
>>  One form of discrimination could be encouraging users to have a 
>>"real" URI by giving them more features - reward them for adapting 
>>to the Web 2.0 model and using their OpenID around the web. Another 
>>could be swifter expiration of new accounts under the presumption 
>>that new users who use an anonymous URI are just experimenting with 
>>the service (this would be both a performance convenience for RP's 
>>as described above, and a complement of the encouragement more 
>>immediately above, instead *dis*-couraging users from using an 
>>anonymous URI for long-term use). (Since a user could still create 
>>multiple accounts on one or more sites and use each of them as a 
>>"real" URI; such discrimination wouldn't reduce the user's ability 
>>to compartmentalize their identity and maintain privacy.)
>>
>>  -Shade
>>  _______________________________________________
>>  specs mailing list
>>  specs at openid.net
>>  http://openid.net/mailman/listinfo/specs
>>
>>
>
>--
>Chief Architect                   AIM:  gffletch
>Identity Services                 Work: george.fletcher at corp.aol.com
>AOL LLC                           Home: gffletch at aol.com
>Mobile: +1-703-462-3494
>Office: +1-703-265-2544           Blog: http://practicalid.blogspot.com



More information about the specs mailing list