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

[Drummond Reed]

Shade, here's the nut of the problem: directed identity in OpenID
Authentication 2.0 means nothing more than:

"The user logging in to your site is not asserting the URI they have typed
in; instead the OP will tell you the URI for the user."

Then _any_ URI then returned from the OP *is* then the "user's URI". For
example, I could enter "myopenid.com" when logging into an RP, have the RP
discover the myopenid.com directed identity service there, and then instruct
myopenid.com to return xri://=!F83.62B1.44F.2813 as my URI (which is the XRI
i-number for my i-names =drummond and =drummond.reed).

So the RP would end up exactly the same identifier an RP would dicover if I
logged in as =drummond. 

That's the way directed identity is designed to work. It's not necessarily
about anonymity -- it's about letting the user choose their URI at the OP
rather than typing it into the RP.

So net net is I don't think there's any way to ascertain a "real" URI even
if there was such a thing. It can and should be the user's choice what URIs
he/she shares with what sites. If a site has a particular reason to know
that a user has shared a particular URI with another particular site, that's
different -- and the OpenID protocol could be used to prove that. But I
don't think that's what you're asking.

=Drummond 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of SitG Admin
> Sent: Friday, September 05, 2008 1:48 PM
> To: specs@openid.net
> Subject: RE: "This is user's URI" for Assertion Quality Extension
> 
> None of them were assumed by me; I don't consider the use-case to
> rely on any of them.
> 
> 1) A directed identity URI creates a situation where the RP *doesn't
> know* whether it is a "real URI" or not. (This assumption has been
> hypothetically mitigated by an idea that occurred to me during this
> discussion, of performing discovery on the asserted URI as normal and
> looking for any OpenID headers.)
> 
> 2) There are other reasons for using Directed Identity (such as being
> able to give all users the same URL to use instead of asking them to
> figure out what a URL would look like with their username substituted
> for the example text), reasons that have nothing to do with privacy.
> RP's may, at their discretion, encourage use of Directed Identity
> (adoption of the feature, where offered at the site hosting user's
> URI) by treating those who *don't* use it (when available) as
> second-class citizens! Or just ignore (not even request, really) this
> information completely. Like any of the other quality assertion
> strings (biometrics, phone), it's not there because ALL the Relying
> Parties MUST use it, but because *some* of us *may* want to. Whether
> a RP discriminates and whether it's for or against is not dictated by
> this proposal.
> 
> 3) Do you know what the web will look like if no user ever employs
> the same URI at more than one site? The same walled gardens we have
> right now, that's what. One account per site. OpenID doesn't provide
> Identity in any meaningful way (and certainly not Open) if we don't
> see users employing at least one URI on at least two sites. Providing
> the means to detect when they're using a unique URI over the long
> term, so they can at least be educated about the implications (if not
> encouraged to practice a consistent URI), does not strike me as a bad
> thing.
> 
> -Shade
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

To clarify what I wrote before:
>User: "I want to be known anonymously."
>RP: "I don't like that, use a real URI."
>User: "I don't have to."
>RP: "You don't have to use my site either."
>
>I only see a problem with it if the user thinks they ought to be
>entitled to use whatever services they please while remaining
>anonymous.

There's nothing wrong with remaining anonymous - it's the general 
idea of a user's right to use a service under whatever conditions 
they care to dictate, overriding the service *provider's* right to 
refuse service if they don't find those conditions acceptable. If we, 
as users or fellow service providers, think a RP's case for treating 
anonymous logins in certain ways that differ from other logins, isn't 
acceptable, we can boycott that RP and engage in other "free market" 
activities (such as starting up a competing site that provides the 
same services but with less discrimination). It's also possible to 
avoid putting anything in the specs that could make such things 
easier, but if we follow that route, we'd be trying to engineer human 
values instead of address them as people always have. Looking at 
what's already possible (allied companies whitelisting one another's 
OP's, etcetera), it's plain to me that the specs were written to 
create useful functionality instead of engineer discrimination out of 
the equation. I presume we still have ways to address discrimination 
without making it impossible in the code?

-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

None of them were assumed by me; I don't consider the use-case to 
rely on any of them.

1) A directed identity URI creates a situation where the RP *doesn't 
know* whether it is a "real URI" or not. (This assumption has been 
hypothetically mitigated by an idea that occurred to me during this 
discussion, of performing discovery on the asserted URI as normal and 
looking for any OpenID headers.)

2) There are other reasons for using Directed Identity (such as being 
able to give all users the same URL to use instead of asking them to 
figure out what a URL would look like with their username substituted 
for the example text), reasons that have nothing to do with privacy. 
RP's may, at their discretion, encourage use of Directed Identity 
(adoption of the feature, where offered at the site hosting user's 
URI) by treating those who *don't* use it (when available) as 
second-class citizens! Or just ignore (not even request, really) this 
information completely. Like any of the other quality assertion 
strings (biometrics, phone), it's not there because ALL the Relying 
Parties MUST use it, but because *some* of us *may* want to. Whether 
a RP discriminates and whether it's for or against is not dictated by 
this proposal.

3) Do you know what the web will look like if no user ever employs 
the same URI at more than one site? The same walled gardens we have 
right now, that's what. One account per site. OpenID doesn't provide 
Identity in any meaningful way (and certainly not Open) if we don't 
see users employing at least one URI on at least two sites. Providing 
the means to detect when they're using a unique URI over the long 
term, so they can at least be educated about the implications (if not 
encouraged to practice a consistent URI), does not strike me as a bad 
thing.

-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

>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.

I'm speculating here about the future development path Directed 
Identity will take - I don't see this supported by the current specs. 
The flow I'm imagining is,

1) User enters "www.myOP.com".
2) RP looks for an XRDS file at www.myOP.com, finds it, and parses it 
for a service type URI saying "I'm an OP Identifier, not a user 
identity".
3) RP does its thing (I've read the spec but I'm still not clear on 
exactly how this happens) and obtains a URI of 
"www.someothersite.com".
4) Since "www.someothersite.com" isn't the same as "www.myOP.com", RP 
checks for OpenID headers at the URI claimed (or maybe it checks for 
an XRDS document at that host, again, not clear on how this part is 
working).

Hmm . . . come to think of it, would looking for OpenID headers at 
the URI claimed through Directed Identity work?

>If the user choses to use an "opaque" identifier, that's the user's 
>choice and I don't think it should be circumvented.

How could this circumvent their choice?

User: "I want to be known anonymously."
RP: "I don't like that, use a real URI."
User: "I don't have to."
RP: "You don't have to use my site either."

I only see a problem with it if the user thinks they ought to be 
entitled to use whatever services they please while remaining 
anonymous. Again, there's nothing to stop the user from creating an 
account at one of the many sites now offering OpenID, and only ever 
use that URI for one RP.

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

I worded that badly . . . I meant that Yahoo seems to be handing out 
a totally random identifier, not that it would be changed every time 
the user logged in.

>Do you have a use case for the "short-term 'relationship across 
>time'" accounts?

Indeed! Giving potential users a tour/demo of the service. Let them 
explore customization (which would not be possible if they were 
"sharing" an account with other users from their OP) anonymously, 
then upgrade to a "real URI" account for long-term use.

>Even in the 3 distinctions you've identified, could they be handled 
>by AX? That seems to me to be the natural fit.

Yes, and (as Paul pointed out) with AQU deprecated in favour of PAPE, 
which doesn't appear to fit this at all (whereas it seemed close 
enough to AQU), this should probably be handled by AX (and AX is 
already extensible without having to modify the existing spec).

>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.

Unless it's an identifier for "a member of this site" (such as Sun 
offers). Think stores that offer discounts to students at a local 
university or employees of a company it deals with, without having to 
know exactly who those students/employees are.

So, if the OP-Local says "employee.store.com", that's one thing; but 
if you start seeing "employee.sales.store.com" and 
"employee.support.store.com", you start wondering if maybe tech 
support is outsourced and you should care about "*.store.com" or 
"*.sales.store.com" versus "*.support.store.com".

-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Nat]

Obvious use case would be that psudonimous user wanting to be  
recognized as the same person as the previous visit but not willing to  
give up his privacy. Thisbis a classic use case in both XRI and Liberty.

[EMAIL PROTECTED] via iPhone

On 2008/09/05, at 16:09, Martin Atkins <[EMAIL PROTECTED]> wrote:

> SitG Admin wrote:
>> http://openid.net/specs/openid-assertion-quality- 
>> extension-1_0-03.html
>> > >
>> I'd like to see the 4th draft of this include a "URI level"
>> authentication property.
>>
>> I'd like to know whether the OP is asserting that the user "is a  
>> member
>> of Site", "is this specific user *at* Site", or "is a member of  
>> Site and
>> we've generated this unique Directed Identity for them that won't  
>> reveal
>> their userID at Site but will allow you, the RP, to distinguish  
>> between
>> this anonymous Site user and other anonymous Site users".
>>
>
> What's the use-case?
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Nat]

Come in to PAPE WG! We are a bit lonely right now :-) IMHO, identity  
assurance is THE THING you need for the RP adoption, and it is  
important enough for many more people to get involved on the discussion.


[EMAIL PROTECTED] via iPhone

On 2008/09/05, at 11:19, SitG Admin <[EMAIL PROTECTED]>  
wrote:



http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
I'd like to see the 4th draft of this include a "URI level"  
authentication property.


I'd like to know whether the OP is asserting that the user "is a  
member of Site", "is this specific user *at* Site", or "is a member  
of Site and we've generated this unique Directed Identity for them  
that won't reveal their userID at Site but will allow you, the RP,  
to distinguish between this anonymous Site user and other anonymous  
Site users".


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[George Fletcher]

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 identi

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

[Drummond Reed]

Shade, your use case seems to have three built-in assumptions:

1) A directed identity URI is not a "real" URI.

2) Users who want to use a directed identity URI are second-class users of a
site vs. those who do not.

3) The goal of OpenID is to get users to use a single URI at all sites.

I would submit that all three are false:

1) A directed identity URI is as valid a URI as any other URI for the user.
It can be used to discover other services or exchange attributes or anything
else a non-directed identity URI can do.

2) The fact that a directed identity URI helps preserve the user's privacy
should in no way be construed that they should be a second-class citizen of
a site.

3) I've had people tell me that without directed identity being added in
OpenID 2.0, OpenID was so privacy-unfriendly that adoption would hit a wall.


So in short, rather than directed identity URIs being treated as
second-class, there is every reason for a privacy-protecting site not to
discriminate against them at all.

=Drummond 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of SitG Admin
> Sent: Friday, September 05, 2008 1:15 AM
> To: Martin Atkins
> Cc: specs@openid.net
> Subject: Re: "This is user's URI" for Assertion Quality Extension
> 
> >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?)
> 
> 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.)
> 
> 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@openid.net
> http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

>All of your use-cases here seem to be to do with the RP somehow 
>discriminating against users that have a flag set.

There's a new use-case type in my reply to Paul Madsen.

By the way, I'm concerned about your phrasing there. By saying that 
the RP "discriminates *against*" such users, it implies that the only 
difference users will see is a negative. This is most definitely NOT 
the case, since less database clutter will result in faster lookup 
times for ALL users (though, again, I do not know if such speed 
differences would be discernible by anyone in real-time).

>With that in mind, what's the incentive for the OP to actually set the flag?

What service would it provide to their users?

Apart from the new use-case referenced above, it's a way for the OP 
to ensure that RP's treat the real OpenID's *as* real. I suppose I 
could detect Directed Identity and say "Please don't do this, enter 
your actual URI instead.", but then the user *can't* use an anonymous 
ID (without at least one more click if I let them resume as usual), 
and if they've become accustomed to Directed Identity (or never 
learned how to enter their URI!), it'll interrupt the flow for them. 
(Kind of like the situation we have now, where users gleefully charge 
out to use their OpenID's and then say "Hey wait, where's my login 
screen for OpenID?" because there aren't many sites which "support 
OpenID" but trust anyone else's OP.) This would only be a reactive 
measure, though, for RP's refusing to treat Directed Identity as a 
*real* Identity.

How much of the "RP's trusting OP's" issue is a reluctance to embrace 
the web 2.0 model of user-centric identity? Could the OP offer its 
users "increased acceptance at [such] RP's" by marketing to those 
RP's that an "anonymous" URI marks a unique user:OP:RP relationship 
that identifies the user as one of that site's human assets (not an 
entity unto themselves) and merely provides a way of distinguishing 
them from other human assets currently held by the site?

-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

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?)
> 
> 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.)
> 
> 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.)
> 

All of your use-cases here seem to be to do with the RP somehow 
discriminating against users that have a flag set. With that in mind, 
what's the incentive for the OP to actually set the flag?





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

>Hi Shade, AQE has long ago been deprecated in favour of PAPE

Hmm . . . looks like PAPE is more of *how* the user was authenticated 
than the *quality* of their authentication (the latter seemed 
appropriate for what quality of identity the RP should take the OP as 
asserting).

Looking at the specs list to find a more suitable spec to propose 
this for, I notice that AQE isn't even on it. It may be worth 
mentioning that I looked at AQE because someone suggested it to me 
during a discussion on the general mailing list.

I can't see this going with anything (currently on the list) but 
Attribute Exchange, which is freely extensible, so there wouldn't be 
any need to change the spec for such assertions to happen.

Thinking of how I might be able to set up examples of this, another 
possible use-case just occurred to me:

"This is me with my coder hat on."
"This is me with my manager hat on."
"This is me with my sales hat on."
All of these would be set with AX to indicate, per specific login, in 
what capacity I was acting at that particular time. It might be set 
automatically by the software, looking at what department I was 
working in at the moment and whether I was on my lunch break ("This 
is me as a regular person.") to let the OP remain solely responsible 
for OpenID's (and let the user not have to use their personal 
OpenID's at the surveilled company) but signal when an employee was 
not representing the company, but acting only of their own accord. 
The company wouldn't need to assign a different OpenID to that 
employee just to reflect a different stature.

-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

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 spi

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

[Paul Madsen]

Hi Shade, AQE has long ago been deprecated in favour of PAPE

paul

SitG Admin wrote:
> http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 
> 
> I'd like to see the 4th draft of this include a "URI level" 
> authentication property.
>
> I'd like to know whether the OP is asserting that the user "is a 
> member of Site", "is this specific user *at* Site", or "is a member of 
> Site and we've generated this unique Directed Identity for them that 
> won't reveal their userID at Site but will allow you, the RP, to 
> distinguish between this anonymous Site user and other anonymous Site 
> users".
>
> -Shade
> 
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>   
> 
>
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 7.5.524 / Virus Database: 270.6.16/1651 - Release Date: 04/09/2008 
> 6:57 AM
>   

-- 
Paul Madsene:paulmadsen @ ntt-at.com
NTTp:613-482-0432
   m:613-282-8647
   aim:PaulMdsn5
   web:connectid.blogspot.com 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

>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?)

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.)

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@openid.net
http://openid.net/mailman/listinfo/specs

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

[Martin Atkins]

SitG Admin wrote:
> http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 
> 
> I'd like to see the 4th draft of this include a "URI level" 
> authentication property.
> 
> I'd like to know whether the OP is asserting that the user "is a member 
> of Site", "is this specific user *at* Site", or "is a member of Site and 
> we've generated this unique Directed Identity for them that won't reveal 
> their userID at Site but will allow you, the RP, to distinguish between 
> this anonymous Site user and other anonymous Site users".
> 

What's the use-case?

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[SitG Admin]

http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
I'd like to see the 4th draft of this include a "URI level" 
authentication property.


I'd like to know whether the OP is asserting that the user "is a 
member of Site", "is this specific user *at* Site", or "is a member 
of Site and we've generated this unique Directed Identity for them 
that won't reveal their userID at Site but will allow you, the RP, to 
distinguish between this anonymous Site user and other anonymous Site 
users".


-Shade___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs