"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