"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