"This is user's URI" for Assertion Quality Extension
George Fletcher
gffletch at aol.com
Fri Sep 5 19:24:20 UTC 2008
SitG Admin wrote:
> 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 ;)
oops... sorry
>
>> 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).
So in some cases, an OP is "a proper authority" for multiple SPs but
that isn't in any way required. If the OP asserts an OpendID, then that
OP is authoritative for that OpenID. If the user choses to use an
"opaque" identifier, that's the user's choice and I don't think it
should be circumvented.
>
>> 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.
Per the 2.0 spec...
OP-Local Identifier:
An alternate Identifier for an end user that is local to a
particular OP and thus not necessarily under the end user's control.
also.. the OP-Local identifier may be specified in the positive response
from the OP
openid.identity
Value: (optional) The OP-Local Identifier
Note: OpenID Providers MAY assist the end user in selecting the
Claimed and OP-Local Identifiers about which the assertion is made. The
openid.identity field MAY be omitted if an extension is in use that
makes the response meaningful without it (see openid.claimed_id above).
So I was thinking that the RP could use openid.identity value as a way
to track slight variations in the claimed_id based on what the OP
returns. This probably wouldn't work for all OP's but could help cut
down on the clutter.
>
>> 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.
Actually, Yahoo generates one and only one random string for the user's
OpenID and never changes it (at least that was their initial
implementation). I'm sure Allen will correct me if I'm wrong:)
However, the intent of the "directed identity" feature is that an OP
would generate a unique string for the user for each RP they logged in
to. This ensures that the RP's can't correlate information about the
user without the user's consent. This is a key privacy feature of the
2.0 spec, but one not realized much (yet) in practice.
>
>> 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.
>
Sorry for causing confusion. Generating a unique OpenID at each login is
possible with OpenID but not implemented in any OpenID Provider that I
know of. So the behavior I would expect would be the unique user:OP:RP
identifier.
> 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".
Do you have a use case for the "short-term 'relationship across time'"
accounts? I can see value in a verified identity token (see my blog,
http://practicalid.blogspot.com) but if the concern is "cleaning up
inactive accounts", could that be handled in the TOS such that an
account that is inactive for n months is automatically removed? This
would allow you to keep your databases fairly clean.
Maybe I missed the point.
>
>> 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.
Even in the 3 distinctions you've identified, could they be handled by
AX? That seems to me to be the natural fit. Even in the case of what SUN
did, I think AX would be better suited rather than the implicit
statement that SUN made.
>
> 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?
I'm confused by the relationship between OP-Local and the "entire site".
The OP-Local identifier is the OP's identifier for the user (if it's
provided). However, it's still an identifier for the individual. I
suppose you could associate it with this OP is authoritative for this
OpenID but I think that's about as much as can be assumed.
Thanks,
George
>
> -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
>>>
>>>
More information about the specs
mailing list