Re: Do We Agree on the Problem We're Trying to Solve?
On 6/8/07, David Fuelling [EMAIL PROTECTED] wrote: If in 50 years, a given canonical URL domain goes away, then couldn't a given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? If I understand the way that David Recordon and Drummond are proposing that canonical identifiers work, this is not the case. The canonical identifier is the sole database key, and the URL that the user enters and everyone sees is reassignable and (to a certain extent) ephemeral. Control of the canonical identifier is necessary and sufficient to assert one's identity. If I understand Dick, he's proposing using multiple identifiers as a kind of multi-factor authentication, where the user has to present more than one credential in the form of identifiers to take an action. This is very similar to your interpretation of two URLs being necessary. It's an interesting idea, and it has a lot of nice properties, but it seems like a pretty big leap at this point. I think the biggest drawback is that the nice properties only really appear when each identifier is issued by a separate authority. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
On 6/9/07, Martin Atkins [EMAIL PROTECTED] wrote: I'm assuming that the RP authenticates http://inconvenient.example.com/001, not http://impersonation.example.com/mart. Just as with delegation, if I can successfully authenticate as the persistent identifier and the non-persistent identifier points at the persistent one, we can assume that http://impersonation.example.com/mart is me as well. If you agree that: 1. In order to authenticate as the persistent identifier, discovery must be done on the persistent identifier 2. In order to determine that the non-persistent identifier points at the persistent one, discovery must be done on the non-persistent identifier. then two discovery steps are necessary in order to use this scheme. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
On 6/11/07, Josh Hoyt [EMAIL PROTECTED] wrote: On 6/8/07, David Fuelling [EMAIL PROTECTED] wrote: If in 50 years, a given canonical URL domain goes away, then couldn't a given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? If I understand the way that David Recordon and Drummond are proposing that canonical identifiers work, this is not the case. The canonical identifier is the sole database key, and the URL that the user enters and everyone sees is reassignable and (to a certain extent) ephemeral. Control of the canonical identifier is necessary and sufficient to assert one's identity. Yes, I think that's what is intended. However, there doesn't appear to be any mechanism (aside from the proposal saying so) to enforce that the canonical identifier is the root key. Seems like somebody could arbitrarily switch their canonical id to a different canonical id, so long as the person doing the switching controls a regular OpenID and its XRDS file that specifies the canonical id. Am I missing something there? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
Josh Hoyt wrote: On 6/9/07, Martin Atkins [EMAIL PROTECTED] wrote: I'm assuming that the RP authenticates http://inconvenient.example.com/001, not http://impersonation.example.com/mart. Just as with delegation, if I can successfully authenticate as the persistent identifier and the non-persistent identifier points at the persistent one, we can assume that http://impersonation.example.com/mart is me as well. If you agree that: 1. In order to authenticate as the persistent identifier, discovery must be done on the persistent identifier 2. In order to determine that the non-persistent identifier points at the persistent one, discovery must be done on the non-persistent identifier. Right you are. The detail I was missing was that if, as in delegation, the non-persistent identifier is trusted to nominate a server endpoint for authentication, it becomes possible to lie about the server endpoint and claim any identifier. But can we guarantee that it is always exactly two discovery steps? If my CanonicalID points at an identifier which itself also has a CanonocalID, do we follow it recursively? I can't really think of any security flaws as a result of only following one level of CanonicalID, but it may be counter-intuitive for implementors. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
