Generalized solution to OpenID recycling (was RE: The WordPress User Problem)

2007-06-05 Thread =drummond.reed
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

RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread =drummond.reed
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

RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread =drummond.reed
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

RE: Specifying identifier recycling

2007-06-05 Thread =drummond.reed
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

Writeup of XRDS Canonical ID verification for URLs and XRIs

2007-06-13 Thread =drummond.reed
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

RE: OpenID Provider Authentication Policy Extension

2007-06-22 Thread =drummond.reed
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?