"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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
> Of SitG Admin
> Sent: Friday, September 05, 2008 1:48 PM
> To: specs at 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 at openid.net
> http://openid.net/mailman/listinfo/specs