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
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
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?
