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