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: 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
Re: The CanonicalID Approach
Josh Hoyt wrote: On 6/8/07, Martin Atkins [EMAIL PROTECTED] wrote: I figure that you could potentially use the same mechanism as delegation to avoid the extra discovery iteration. The problem, as with delegation, is that you need to duplicate the endpoint URL in the source identifier's XRDS document. The canonical identifier must also support OpenID, which I believe is something they were trying to avoid. I'm assuming that by saying it's like delegation, you mean that the canonical identifier is discovered from the entered identifier, and sent to the server, but discovery is never done. Let's say that you use http://mart-atkins.com/; as your identifier, with a canonical id of http://inconvenient.example.com/001; I can set up a URL http://impersonation.example.com/mart; that points to an OpenID provider that I control, and give it the same canonical ID, http://inconvenient.example.com/001;. Unless we make sure that the canonical ID is intended to be used with this OpenID server, I can sign in to your account anywhere, since the canonical ID is used as the database key. Were you thinking of a different mechanism? 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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The CanonicalID Approach
Hey Johnny, My understanding, though don't have the appropriate spec reference, is that the process would be: 1) User enters http://daveman692.livejournal.com 2) RP fetches Yadis doc for http://daveman692.livejournal.com 3) RP sees CanonicalID of http://www.livejournal.com/userinfo.bml?userid=1356357 3) RP fetches Yadis doc for http://www.livejournal.com/userinfo.bml?userid=1356357 4) RP sees CanonicalID of http://www.livejournal.com/userinfo.bml?userid=1356357 is itself 5) RP sees Ref of http://daveman692.livejournal.com and thus has verified that the pointer goes in both directions Will have to ask Drummond his thoughts on how fragments would be used, since this morning it isn't clear to me. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:42 AM To: Recordon, David Cc: specs@openid.net Subject: Re: The CanonicalID Approach Hi David, On 7-Jun-07, at 6:31 PM, Recordon, David wrote: You could also, don't shudder too hard Dick :), use an i-number as your persistent identifier via this method though on the flip-side could also use a fragment if that is the approach someone would like to take. The nice thing is that this method is extremely flexible in terms of what you use as your persistent identifier in different cases. The question (that we will need to specify or have a clear pointer to) is how the canonical ID verification is done. (BTW: Was this section updated on Wed in the XRI draft?) Your HTTP URL canonical ID example is straight-forward and simple. Do you have an example of how it would work with fragments, say: http://openid.aol.com/daveman692 - reassignable http://openid.aol.com/daveman692#1234 - persistent Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
Hi David, On 7-Jun-07, at 6:31 PM, Recordon, David wrote: You could also, don't shudder too hard Dick :), use an i-number as your persistent identifier via this method though on the flip-side could also use a fragment if that is the approach someone would like to take. The nice thing is that this method is extremely flexible in terms of what you use as your persistent identifier in different cases. The question (that we will need to specify or have a clear pointer to) is how the canonical ID verification is done. (BTW: Was this section updated on Wed in the XRI draft?) Your HTTP URL canonical ID example is straight-forward and simple. Do you have an example of how it would work with fragments, say: http://openid.aol.com/daveman692 - reassignable http://openid.aol.com/daveman692#1234 - persistent Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
Josh Hoyt wrote: On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote: What I'd like to markup is that my three reassignable identifiers so that they all use my LiveJournal userid URL as the persistent identifier. It should be noted that also marking them as synonyms to each other follows the same sort of process using the Ref/ tag in my various XRDS files. -1 on requiring a whole extra round of discovery for every sign in. If you can come up with a way to verify that (a) the identifier in question points to the canonical ID and (b) the canonical ID has the appropriate information in it without doing twice the discovery, I'd like to hear it. I figure that you could potentially use the same mechanism as delegation to avoid the extra discovery iteration. The problem, as with delegation, is that you need to duplicate the endpoint URL in the source identifier's XRDS document. The canonical identifier must also support OpenID, which I believe is something they were trying to avoid. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The CanonicalID Approach
Not really trying to avoid the canonical ID having an OpenID service listed, just figured not listing one would make the example simpler though as you point out you certainly can have one. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Friday, June 08, 2007 1:42 PM Cc: specs@openid.net Subject: Re: The CanonicalID Approach Josh Hoyt wrote: On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote: What I'd like to markup is that my three reassignable identifiers so that they all use my LiveJournal userid URL as the persistent identifier. It should be noted that also marking them as synonyms to each other follows the same sort of process using the Ref/ tag in my various XRDS files. -1 on requiring a whole extra round of discovery for every sign in. If you can come up with a way to verify that (a) the identifier in question points to the canonical ID and (b) the canonical ID has the appropriate information in it without doing twice the discovery, I'd like to hear it. I figure that you could potentially use the same mechanism as delegation to avoid the extra discovery iteration. The problem, as with delegation, is that you need to duplicate the endpoint URL in the source identifier's XRDS document. The canonical identifier must also support OpenID, which I believe is something they were trying to avoid. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
On 8-Jun-07, at 2:26 PM, Drummond Reed wrote: See my next message about this. It works identically to David's examples (just substitute these as reassignable and persistent identifiers) except it has the advantage that it does not require an extra round-trip for discovery/verification of the persistent identifier (the Canonical ID) because the client can verify from the identifiers themselves that the provider of the reassignable identifier (the first one) is authoritative for the persistent identifier (the second one). In essence, it would then be the same flow I detailed last week [1], would you agree? Specifically, the canonical id verification above is: c) Verification of discovered information against auth response fields: strip_fragment(openid.claimed_id) == discovered claimed id So the fragment approach would match Josh's request for no extra discovery [2]. Allowing for more general canonical IDs would require a more complex verification process. Johnny [1] http://openid.net/pipermail/specs/2007-May/001767.html [2] http://openid.net/pipermail/specs/2007-June/001851.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
The CanonicalID Approach
So sitting up here in Seattle with Drummond and we're chatting about the Canonical ID approach to the identifier recycling and losing problem. What I describe below is an example which shows four identifiers that I use daily, one of them being persistent and that I know will never be reassigned. http://daveman692.livejournal.com - reassignable http://www.livejournal.com/userinfo.bml?userid=1356357 - persistent http://www.davidrecordon.com - do I want to own it forever? http://openid.aol.com/daveman692 - reassignable What I'd like to markup is that my three reassignable identifiers so that they all use my LiveJournal userid URL as the persistent identifier. It should be noted that also marking them as synonyms to each other follows the same sort of process using the Ref/ tag in my various XRDS files. It should also be noted that the identifier you're using as your persistent identifier must allow you to add references back to your other identifiers. While this certainly is a specialized feature, we envision that OpenID Providers will create a persistence service both guaranteeing the URL will not be reassigned as well as providing means to add additional references. Many of the existing i-brokers already do this by using OpenID to prove you control the references that you're adding. You could also, don't shudder too hard Dick :), use an i-number as your persistent identifier via this method though on the flip-side could also use a fragment if that is the approach someone would like to take. The nice thing is that this method is extremely flexible in terms of what you use as your persistent identifier in different cases. I fully guarantee I haven't done a great job of explaining all of this, but hopefully the main point gets across. --David (and Drummond) http://daveman692.livejournal.com XRDS XRD Service URIhttp://www.livejournal.com/openid/server.bml/URI Typehttp://openid.net/signon/1.0/Type /Service CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID /XRD /XRDS http://www.davidrecordon.com XRDS XRD Service URIhttps://pip.verisignlabs.com/openid/server/URI Typehttp://specs.openid.net/auth/2.0/signon/Type LocalIDhttps://recordond.pip.verisignlabs.com/LocalID /Service CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID /XRD /XRDS http://openid.aol.com/daveman692 XRDS XRD Service URIhttps://api.screenname.aol.com/auth/openidServer/URI Typehttp://openid.net/signon/1.0/Type /Service CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID /XRD /XRDS http://www.livejournal.com/userinfo.bml?userid=1356357 XRDS XRD CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can onicalID Refhttp://www.davidrecordon.com/Ref Refhttp://daveman692.livejournal.com/Ref Refhttp://openid.aol.com/daveman692/Ref /XRD /XRDS ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
