"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