Great work, David. +1 to Han's comments -- they are good points. Coming up with a better semantic identifier for the phishing-resistant policy isn't easy but I like his point that it really comes down to the definition that no shared secret is available to a third party. Perhaps non-shared-secret?
Dick Hardt wrote: Just to clarify, I do *not* propose we add support for multiple identifiers in OpenID 2.0 -- but hope that this discussion sheds light that there are other ways of solving the problem besides having a permanent directory of identifiers aka the i-names/i-numbers
David Recordon wrote: snip of explanation of problems with fragment solution to OpenID recycling I don't want to say that I have the answers here, since I don't think I do. I do however see the following possible solutions: 1) The core specification only talks about fragments in relation to
Josh Hoyt wrote: The fragment is not secret. It is not protecting your OpenID. You should be able to get the fragment from any relying party that you visited. You might choose to use a fragment if you have acquired a recycled identifier, but you can choose the fragment. It protects *nothing* if
=drummond.reed wrote: As Martin has pointed out, the purpose of the CanonicalID element in XRDS is to support reassignable-to-persistent identifier mapping. Although this is a native function of XRI resolution (because XRI architecture was explicitly designed to address the reassignable
David, just want to reinforce that the CanonicalID element in XRDS has always been defined as containing anyURI, so it's been there to support mapping of any reassignable identifier to any persistent identifier (or, technically, any canonical identifier, even if not persistent, though persistence
For posterity, here's how I'd summarize this thread about using public keys as persistent identifiers: 1) Yes, a public key could be used as an identifier, and could serve as a persistent identifier if it was not reassignable. 2) The issue of it becoming invalid as a credential if the private