Re: Do We Agree on the Problem We're Trying to Solve?
Re-reading what I wrote, I realize that what I said makes no sense
after the first sentence. Thanks, Drummond, for keeping me honest.
There was a point I was trying to make which I botched, and which is
also unimportant in this thread. So never mind ... ;-) Sorry.
On Jun 8, 2007, at 16:16, Drummond Reed wrote:
>
>>> Dick Hardt wrote:
>>>
>>> Canonical IDs do not solve B.
>>
>> I would agree with that one.
>>
>> Obviously the XRI architecture assumption ("not as radically
>> decentralized as OpenID") makes that less of a problem in an XRI
>> context. Of course, some would say that that assumption is a problem
>> in itself.
>
> Where was it asserted that XRI architecture is "not as radically
> decentralized as OpenID"? Fen made the point yesterday that XRI
> architecture
> is *less* centralized that DNS. The choice of identifier
> authorities under
> URL architecture is DNS registries or IP addresses. XRI architecture
> supports both of those and adds two more: XRI registries and p2p
> authorities. So it's getting less centralized, not more.
>
> Due to the influence of OpenID and other URL-centric technologies,
> in the
> XRI 3.0 discussions already under way, the TC is looking at
> formalizing XRI
> resolution of HTTP and HTTPS URIs (URLs) and Handles. Wouldn't it
> be cool
> for OpenID libraries be able to simply call a resolver to do XRDS
> resolution
> of any OpenID identifier (URL or XRI), Canonical ID verification
> (URL or
> XRI), and OpenID service endpoint selection all in one function?
>
> =Drummond
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
Assuming I understand things correctly, it seems like what we're calling a canonical URL in this thread is really a pseudo-canonical URL since a given OpenID's XRDS doc is what specifies the Canonical ID. 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 so, then It seems like there's almost a (in a good way) circular reference going on, since at certain points in time, what we're calling the "Canonical URL" is the unchanging/stable/authoritative URL, while at other times, the actual OpenID is the authoritative/unchanging/stable URL. In this setup, I a given person has to control 2 URL's at the same time in order to assert ownership of a given OpenID, making it difficult to lose your Identity if you lose only a single domain. In this respect, each URL provides a safeguard against the loss of the other URL. On 6/8/07, Dick Hardt <[EMAIL PROTECTED]> wrote: You are still trusting one registry. Of course it is your choice, but you have a single point of failure. Do you think they will still be around in 50 years? On 8-Jun-07, at 4:20 PM, Recordon, David wrote: > I don't see how it requires a centralized registry, if I choose to > trust > that LiveJournal, or some ugly URL from AOL, etc will never go away > then > that is my choice. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dick Hardt > Sent: Friday, June 08, 2007 4:08 PM > To: Drummond Reed > Cc: specs@openid.net > Subject: Re: Do We Agree on the Problem We're Trying to Solve? > > > On 8-Jun-07, at 4:00 PM, Drummond Reed wrote: > >> Drummond Reed wrote: Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. >>> >>> Dick Hardt wrote: >>> >>> The persistent URL or XRI *is* a master directory. What do you do >>> when the persistent identifier is compromised, goes out of >>> business ... >>> >>> That is problem B. >>> >>> Canonical IDs do not solve B. >> >> I completely agree that B is a hard problem. However Canonical IDs >> solve B >> if the identifier authority for the Canonical ID follows business and >> operational practices intended to solve B. > > And I think there is a solution that does not require a single, > central registry. > > One of the other issues with the registry is it is challenging to > provide directed identities. > > -- Dick > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ 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
>> http://openid.aol.com/daveman692 - reassignable >> http://openid.aol.com/daveman692#1234 - persistent >> >> If an XRDS for the reassignable identifier asserts the persistent >> identifier >> as a Canonical ID, a second round trip is not required because the >> client >> can verify that http://openid.aol.com/ is authoritative for both >> daveman692 >> and daveman692#1234. > >Johnny Bufu wrote: > >Because in the case of URLs delegation is decoupled from the >identifiers, I don't think that verifying only the authority part >will suffice. > >I could have the XRDS at: > > http://openid.aol.com/johnny692 > >assert the cannonical ID: > > http://openid.aol.com/daveman692#1234 > >.. but have http://openid.aol.com/johnny692 delegate to my own OP >running in my basement, which is configured to issue assertions with >the above canonical id. Checking only the authority section would >render such assertions valid. > >Unless I'm missing something, I believe we should mandate a stricter >verification, on the full URL without the fragment. (Whoever controls >the URL without the fragment, also controls the URL with any fragments.) Good point. I agree. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
You are still trusting one registry. Of course it is your choice, but you have a single point of failure. Do you think they will still be around in 50 years? On 8-Jun-07, at 4:20 PM, Recordon, David wrote: > I don't see how it requires a centralized registry, if I choose to > trust > that LiveJournal, or some ugly URL from AOL, etc will never go away > then > that is my choice. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dick Hardt > Sent: Friday, June 08, 2007 4:08 PM > To: Drummond Reed > Cc: specs@openid.net > Subject: Re: Do We Agree on the Problem We're Trying to Solve? > > > On 8-Jun-07, at 4:00 PM, Drummond Reed wrote: > >> Drummond Reed wrote: Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. >>> >>> Dick Hardt wrote: >>> >>> The persistent URL or XRI *is* a master directory. What do you do >>> when the persistent identifier is compromised, goes out of >>> business ... >>> >>> That is problem B. >>> >>> Canonical IDs do not solve B. >> >> I completely agree that B is a hard problem. However Canonical IDs >> solve B >> if the identifier authority for the Canonical ID follows business and >> operational practices intended to solve B. > > And I think there is a solution that does not require a single, > central registry. > > One of the other issues with the registry is it is challenging to > provide directed identities. > > -- Dick > > ___ > 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: Do We Agree on the Problem We're Trying to Solve?
On 8-Jun-07, at 4:21 PM, Drummond Reed wrote: > Dick Hardt wrote: The persistent URL or XRI *is* a master directory. What do you do when the persistent identifier is compromised, goes out of business ... That is problem B. Canonical IDs do not solve B. >>> >>> I completely agree that B is a hard problem. However Canonical IDs >>> solve B >>> if the identifier authority for the Canonical ID follows business >>> and >>> operational practices intended to solve B. >> >> And I think there is a solution that does not require a single, >> central registry. > > Agreed. However XRI as a language for identifier interoperability is a > superset of the portion of XRI that enables native XRI registries, > thus XRI > Canonical ID architecture can be used with any registry providing > persistent, verifiable identifiers (XRIs, URLs, Handles, URNs, etc.) > >> One of the other issues with the registry is it is challenging to >> provide directed identities. > > Agreed that it is challenging for *global* registries to provide > directed > identities. You'd want to drop down one or more levels of delegation. Still one point of failure from a specific users point of view. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
>>> Dick Hardt wrote: >>> >>> The persistent URL or XRI *is* a master directory. What do you do >>> when the persistent identifier is compromised, goes out of >>> business ... >>> >>> That is problem B. >>> >>> Canonical IDs do not solve B. >> >> I completely agree that B is a hard problem. However Canonical IDs >> solve B >> if the identifier authority for the Canonical ID follows business and >> operational practices intended to solve B. > >And I think there is a solution that does not require a single, >central registry. Agreed. However XRI as a language for identifier interoperability is a superset of the portion of XRI that enables native XRI registries, thus XRI Canonical ID architecture can be used with any registry providing persistent, verifiable identifiers (XRIs, URLs, Handles, URNs, etc.) >One of the other issues with the registry is it is challenging to >provide directed identities. Agreed that it is challenging for *global* registries to provide directed identities. You'd want to drop down one or more levels of delegation. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
I don't see how it requires a centralized registry, if I choose to trust that LiveJournal, or some ugly URL from AOL, etc will never go away then that is my choice. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, June 08, 2007 4:08 PM To: Drummond Reed Cc: specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? On 8-Jun-07, at 4:00 PM, Drummond Reed wrote: > >>> Drummond Reed wrote: >>> >>> Multiple, redundant identifiers is what canonical ID mapping >>> provides. It >>> doesn't require a master directory; it's as distributed as OpenID >>> itself, >>> i.e., it simply provides a way to map a reassignable URL or XRI to a >>> persistent URL or XRI. >> >> Dick Hardt wrote: >> >> The persistent URL or XRI *is* a master directory. What do you do >> when the persistent identifier is compromised, goes out of >> business ... >> >> That is problem B. >> >> Canonical IDs do not solve B. > > I completely agree that B is a hard problem. However Canonical IDs > solve B > if the identifier authority for the Canonical ID follows business and > operational practices intended to solve B. And I think there is a solution that does not require a single, central registry. One of the other issues with the registry is it is challenging to provide directed identities. -- Dick ___ 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: Do We Agree on the Problem We're Trying to Solve?
>> Dick Hardt wrote:
>>
>> Canonical IDs do not solve B.
>
>I would agree with that one.
>
>Obviously the XRI architecture assumption ("not as radically
>decentralized as OpenID") makes that less of a problem in an XRI
>context. Of course, some would say that that assumption is a problem
>in itself.
Where was it asserted that XRI architecture is "not as radically
decentralized as OpenID"? Fen made the point yesterday that XRI architecture
is *less* centralized that DNS. The choice of identifier authorities under
URL architecture is DNS registries or IP addresses. XRI architecture
supports both of those and adds two more: XRI registries and p2p
authorities. So it's getting less centralized, not more.
Due to the influence of OpenID and other URL-centric technologies, in the
XRI 3.0 discussions already under way, the TC is looking at formalizing XRI
resolution of HTTP and HTTPS URIs (URLs) and Handles. Wouldn't it be cool
for OpenID libraries be able to simply call a resolver to do XRDS resolution
of any OpenID identifier (URL or XRI), Canonical ID verification (URL or
XRI), and OpenID service endpoint selection all in one function?
=Drummond
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
On 8-Jun-07, at 3:04 PM, Drummond Reed wrote: > http://openid.aol.com/daveman692 - reassignable > http://openid.aol.com/daveman692#1234 - persistent > > If an XRDS for the reassignable identifier asserts the persistent > identifier > as a Canonical ID, a second round trip is not required because the > client > can verify that http://openid.aol.com/ is authoritative for both > daveman692 > and daveman692#1234. Because in the case of URLs delegation is decoupled from the identifiers, I don't think that verifying only the authority part will suffice. I could have the XRDS at: http://openid.aol.com/johnny692 assert the cannonical ID: http://openid.aol.com/daveman692#1234 .. but have http://openid.aol.com/johnny692 delegate to my own OP running in my basement, which is configured to issue assertions with the above canonical id. Checking only the authority section would render such assertions valid. Unless I'm missing something, I believe we should mandate a stricter verification, on the full URL without the fragment. (Whoever controls the URL without the fragment, also controls the URL with any fragments.) Johnny ___ 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 8-Jun-07, at 4:00 PM, Drummond Reed wrote: > >>> Drummond Reed wrote: >>> >>> Multiple, redundant identifiers is what canonical ID mapping >>> provides. It >>> doesn't require a master directory; it's as distributed as OpenID >>> itself, >>> i.e., it simply provides a way to map a reassignable URL or XRI to a >>> persistent URL or XRI. >> >> Dick Hardt wrote: >> >> The persistent URL or XRI *is* a master directory. What do you do >> when the persistent identifier is compromised, goes out of >> business ... >> >> That is problem B. >> >> Canonical IDs do not solve B. > > I completely agree that B is a hard problem. However Canonical IDs > solve B > if the identifier authority for the Canonical ID follows business and > operational practices intended to solve B. And I think there is a solution that does not require a single, central registry. One of the other issues with the registry is it is challenging to provide directed identities. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
>David Fuelling wrote: >Side Note: Can't an OP use canonical URL ID's today without adjusting the current 2.0 spec? It seems like the proposal is just a Yadis adjustment. Yes. That's exactly what we're proposing - adding Canonical ID verification rules to the discovery process. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
>> Drummond Reed wrote: >> >> Multiple, redundant identifiers is what canonical ID mapping >> provides. It >> doesn't require a master directory; it's as distributed as OpenID >> itself, >> i.e., it simply provides a way to map a reassignable URL or XRI to a >> persistent URL or XRI. > >Dick Hardt wrote: > >The persistent URL or XRI *is* a master directory. What do you do >when the persistent identifier is compromised, goes out of business ... > >That is problem B. > >Canonical IDs do not solve B. I completely agree that B is a hard problem. However Canonical IDs solve B if the identifier authority for the Canonical ID follows business and operational practices intended to solve B. For example -- and this is only one example, other identifier authorities that adopt these or similar practices to solve B -- XDI.org spent several years developing policies that ensure that as an identifier authority, the Canonical IDs (global i-numbers) assigned by the XDI.org global XRI registries follow these policies: 1) Global i-numbers and their registration policie are designed explicitly for persistent identifiers that are never reassigned and administered by an international public trust organization (XDI.org) for which this is the primary responsibility. 2) If the i-broker serving as the end-user's registrar goes out of business, the global i-number is not compromised because, like a DNS name, it is portable, i.e., the registrant can move it to another accredited i-broker. In other words, the concern about "going out of business" becomes a concern only about the entire infrastructure going out of business. 3) Strong authentication is used in i-broker-to-registry communications to ensure that only accredited and authoritative i-brokers make changes to global registrations, and accredited i-brokers compete under market conditions to offer the best and most flexible means of authenticating registrants, thereby minimizing the risk of a registrant losing control of their global i-number. 4) Every global i-number registration also enables the registrant to register private contact data with an independent third-party trustee (their contact data custodian) to provide an independent third-party channel for authentication. For reference, see the XDI.org Global Services Specifications site at http://gss.xdi.org. It's not a perfect solution, but I would argue (my well-known bias aside) that it's a practical one. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
Wrt to the problems we're trying to solve, I think that we should define a (C) (which is similar to (A), yet instigated by the user and doesn't trigger an RP recycle) and a (D). In summary: A) Identifier recycling normally in large user-base deployments. i.e. needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. C) If I change my OP (i.e., I start using an OpenId with a different URL), I should still be able to use all of my existing RP accounts with my new OP, and prevent my old OP from making assertions for me moving forward. D) Publicly displayed OpenID's should be distinguishable from one owner to the next. IMHO, Canonical ID's seem to solve (A), (B - to some degree - the canonical URL might get lost, but this could be mitigated), and (C), whereas Fragments solve (A) and (D), so why not use both? Plus, (B) can be solved via AX using private tokens that only an OP, the User, and an RP know (see my previous post, but make the tokens private). Side Note: Can't an OP use canonical URL ID's today without adjusting the current 2.0 spec? It seems like the proposal is just a Yadis adjustment. David On 6/8/07, Recordon, David <[EMAIL PROTECTED]> wrote: I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ 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 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. > >Josh Hoyt wrote: > >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? Good example of why you need Canonical ID verification, thus why the XRI TC is adding that function to XRI Resolution. However for some reassignable/persistent identifier pairs there is an optimization that eliminates the need for an extra round trip. The principle is identical to OpenID realm authorization (http://openid.net/specs/openid-authentication-2_0-11.html#realms), which is simply if the client can verify that the same provider is authoritative for both the reassignable and persistent identifier, then an extra round-trip for discovery is not required. A good example is fragments. To use Johnny's example: http://openid.aol.com/daveman692 - reassignable http://openid.aol.com/daveman692#1234 - persistent If an XRDS for the reassignable identifier asserts the persistent identifier as a Canonical ID, a second round trip is not required because the client can verify that http://openid.aol.com/ is authoritative for both daveman692 and daveman692#1234. XRI architecture simply generalizes this approach to any level of delegation. XRI authorities at any level can assert both reassignable i-names and persistent i-numbers that are also distinguished syntactically (i-numbers -- all begin with !). So for example, following is is one of my i-names and my i-number: =drummond - reassignable i-name =!F83.62B1.44F.2813 - persistent i-number An XRDS discovered from resolving "=drummond" asserts my i-number as my Canonical ID, and an XRI resolver can verify that = is authoritative for both "drummond" and "!F83.62B1.44F.2813" without doing an extra round trip. Thus they are "verified synonyms". This works for my delegates as well. For example: =drummond*gardner - reassignable i-name =!F83.62B1.44F.2813!4 - persistent i-number In the first iteration of XRI resolution, an XRI resolver verifies that =drummond and =!F83.62B1.44F.2813 are synonyms as above. In the second interation, it verifies that =drummond*gardner and =!F83.62B1.44F.2813!4 are synonyms. In neither case is an extra round trip needed. This optimization does not work for either URLs or XRIs when the reassignable and persistent identifiers come from different authorities. In other words, both of the following pairs of identifiers... http:// http://www.davidrecordon.com - reassignable http://openid.aol.com/daveman692#1234 - persistent @cordance*drummond - reassignable i-name =!F83.62B1.44F.2813!4 - persistent i-number ...would require an extra roundtrip at least the first time this identifier pair needs to be verified as synonyms (there are optimizations for subsequent verifications). =Drummond ___ 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 Jun 8, 2007, at 14:41, Dick Hardt wrote:
Canonical IDs do not solve B.
I would agree with that one.
Obviously the XRI architecture assumption ("not as radically
decentralized as OpenID") makes that less of a problem in an XRI
context. Of course, some would say that that assumption is a problem
in itself.
Johannes Ernst
NetMesh Inc.
<><>
http://netmesh.info/jernst
___
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
Re: Do We Agree on the Problem We're Trying to Solve?
On 8-Jun-07, at 2:29 PM, Drummond Reed wrote: > Multiple, redundant identifiers is what canonical ID mapping > provides. It > doesn't require a master directory; it's as distributed as OpenID > itself, > i.e., it simply provides a way to map a reassignable URL or XRI to a > persistent URL or XRI. The persistent URL or XRI *is* a master directory. What do you do when the persistent identifier is compromised, goes out of business ... That is problem B. Canonical IDs do not solve B. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Do We Agree on the Problem We're Trying to Solve?
Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. Given the right practices, it solves both A and B. The cost can be, as Josh points out, an extra round trip on discovery. However this can be avoided for certain pairs of the reassignable and persistent identifiers. See my next reply to Josh's message. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, June 08, 2007 12:33 PM To: Johannes Ernst Cc: specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? Multiple, redundant identifiers solves B without requiring a master directory. On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote: > Such as? > > On Jun 8, 2007, at 10:55, Dick Hardt wrote: > >> There are ways to solve B that don't really solve A. >> >> In fact, I think the only way to solve B that does not require a >> master directory is orthogonal to solving A. >> >> -- Dick >> >> On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: >> >>> I would suggest that any solution to B is also very likely a >>> solution to A. >>> >>> Anybody disagree? >>> >>> If so, I'd suggest that we should either solve A and B at the same >>> time, or not at all. >>> >>> >>> >>> On Jun 8, 2007, at 10:42, Dick Hardt wrote: >>> At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: > I'm not sure if we all think we're trying to solve the same > problem. > The two problems that have been discussed are: > A) Identifier recycling normally in large user-base deployments. > i.e. > needs a way to give 'TheBestUsernameEver' > to a > new > user if it has not been used in some period of time. > B) Losing control of your own domain name whether that be via > someone > stealing it or just that you don't want to have to pay for it > forever. > > Have we made a decision as to if we're looking for a solution to > solve > both of these problems, only A, or only B? > > --David > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs >>> >>> >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > ___ 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 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. > >Johnny Bufu wrote: > >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?) The second editor's draft of XRI Resolution 2.0 Working Draft 11 was posted Wed night at: Http://www.oasis-open.org/committees/download.php/24286/xri-resolution-v2.0- wd-11-ed-02.doc However, there was so much discussion around specifying Canonical ID verification for URLs that we didn't update that section (11) yet, instead we just put in commments saying it was under discussion. We then agreed on the XRI TC telecon last Thursday to hold a special telecon about it on Monday at 1PM PT. I'll send details to the list. >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 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). =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The CanonicalID Approach
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? 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?
And then vote by majority? Be safer the more distinct OpenIDs you own and make globally correlatable? While I don't particularly like this approach (and I understand you are not proposing it to solve B), come to think of it, I would think this would also address A -- no worse than what it does for B. On Jun 8, 2007, at 12:33, Dick Hardt wrote: > Multiple, redundant identifiers solves B without requiring a master > directory. > > On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote: > >> Such as? >> >> On Jun 8, 2007, at 10:55, Dick Hardt wrote: >> >>> There are ways to solve B that don't really solve A. >>> >>> In fact, I think the only way to solve B that does not require a >>> master directory is orthogonal to solving A. >>> >>> -- Dick >>> >>> On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: >>> I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: > At IIW we[1] decided we wanted to solve (A) and that (B) would be > nice to solve, but we were ok to wait for a future version to > resolve, as when we discussed (B), resolving looked much harder > then > it seemed at first. > > I'm not certain of where we are now. > > -- Dick > > [1] those present when we met about how to solve recycling ... > > On 8-Jun-07, at 10:35 AM, Recordon, David wrote: > >> I'm not sure if we all think we're trying to solve the same >> problem. >> The two problems that have been discussed are: >> A) Identifier recycling normally in large user-base deployments. >> i.e. >> needs a way to give 'TheBestUsernameEver' >> to a >> new >> user if it has not been used in some period of time. >> B) Losing control of your own domain name whether that be via >> someone >> stealing it or just that you don't want to have to pay for it >> forever. >> >> Have we made a decision as to if we're looking for a solution to >> solve >> both of these problems, only A, or only B? >> >> --David >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs >>> >>> ___ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >> >> > > ___ > 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
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 "" 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
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 "" 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: Do We Agree on the Problem We're Trying to Solve?
Multiple, redundant identifiers solves B without requiring a master directory. On 8-Jun-07, at 11:06 AM, Johannes Ernst wrote: > Such as? > > On Jun 8, 2007, at 10:55, Dick Hardt wrote: > >> There are ways to solve B that don't really solve A. >> >> In fact, I think the only way to solve B that does not require a >> master directory is orthogonal to solving A. >> >> -- Dick >> >> On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: >> >>> I would suggest that any solution to B is also very likely a >>> solution to A. >>> >>> Anybody disagree? >>> >>> If so, I'd suggest that we should either solve A and B at the same >>> time, or not at all. >>> >>> >>> >>> On Jun 8, 2007, at 10:42, Dick Hardt wrote: >>> At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: > I'm not sure if we all think we're trying to solve the same > problem. > The two problems that have been discussed are: > A) Identifier recycling normally in large user-base deployments. > i.e. > needs a way to give 'TheBestUsernameEver' > to a > new > user if it has not been used in some period of time. > B) Losing control of your own domain name whether that be via > someone > stealing it or just that you don't want to have to pay for it > forever. > > Have we made a decision as to if we're looking for a solution to > solve > both of these problems, only A, or only B? > > --David > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs >>> >>> >> >> ___ >> 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: Do We Agree on the Problem We're Trying to Solve?
Such as? On Jun 8, 2007, at 10:55, Dick Hardt wrote: > There are ways to solve B that don't really solve A. > > In fact, I think the only way to solve B that does not require a > master directory is orthogonal to solving A. > > -- Dick > > On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: > >> I would suggest that any solution to B is also very likely a >> solution to A. >> >> Anybody disagree? >> >> If so, I'd suggest that we should either solve A and B at the same >> time, or not at all. >> >> >> >> On Jun 8, 2007, at 10:42, Dick Hardt wrote: >> >>> At IIW we[1] decided we wanted to solve (A) and that (B) would be >>> nice to solve, but we were ok to wait for a future version to >>> resolve, as when we discussed (B), resolving looked much harder then >>> it seemed at first. >>> >>> I'm not certain of where we are now. >>> >>> -- Dick >>> >>> [1] those present when we met about how to solve recycling ... >>> >>> On 8-Jun-07, at 10:35 AM, Recordon, David wrote: >>> I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs >>> >>> ___ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >> >> > > ___ > 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: Do We Agree on the Problem We're Trying to Solve?
> I'm not sure if we all think we're trying to solve the same problem. > The two problems that have been discussed are: > A) Identifier recycling normally in large user-base deployments. i.e. > needs a way to give 'TheBestUsernameEver' to a new > user if it has not been used in some period of time. > B) Losing control of your own domain name whether that be via someone > stealing it or just that you don't want to have to pay for it forever. Perhaps y'all know all this and I should just continue to listen, but what I see above are observations about practices, not problem descriptions. Seems like the problems are that (1) user wants some properties to hold even in situations A and B, or (2) that relying parties want some properties to hold in those situations. What are the desired properties? Probably something like: RPs want policies/profiles/etc that applied to old user of identifier not to apply to new user of identifier. ? - RL "Bob" ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
There are ways to solve B that don't really solve A. In fact, I think the only way to solve B that does not require a master directory is orthogonal to solving A. -- Dick On 8-Jun-07, at 10:49 AM, Johannes Ernst wrote: > I would suggest that any solution to B is also very likely a > solution to A. > > Anybody disagree? > > If so, I'd suggest that we should either solve A and B at the same > time, or not at all. > > > > On Jun 8, 2007, at 10:42, Dick Hardt wrote: > >> At IIW we[1] decided we wanted to solve (A) and that (B) would be >> nice to solve, but we were ok to wait for a future version to >> resolve, as when we discussed (B), resolving looked much harder then >> it seemed at first. >> >> I'm not certain of where we are now. >> >> -- Dick >> >> [1] those present when we met about how to solve recycling ... >> >> On 8-Jun-07, at 10:35 AM, Recordon, David wrote: >> >>> I'm not sure if we all think we're trying to solve the same problem. >>> The two problems that have been discussed are: >>> A) Identifier recycling normally in large user-base deployments. >>> i.e. >>> needs a way to give 'TheBestUsernameEver' to a >>> new >>> user if it has not been used in some period of time. >>> B) Losing control of your own domain name whether that be via >>> someone >>> stealing it or just that you don't want to have to pay for it >>> forever. >>> >>> Have we made a decision as to if we're looking for a solution to >>> solve >>> both of these problems, only A, or only B? >>> >>> --David >>> ___ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >>> >>> >> >> ___ >> 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: Do We Agree on the Problem We're Trying to Solve?
On Jun 8, 2007, at 10:50, Johannes Ernst wrote: > I would suggest that any solution to B is also very likely a solution > to A. I would agree with that statement. --David -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:50 AM To: Dick Hardt Cc: Recordon, David; specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: > At IIW we[1] decided we wanted to solve (A) and that (B) would be > nice to solve, but we were ok to wait for a future version to > resolve, as when we discussed (B), resolving looked much harder then > it seemed at first. > > I'm not certain of where we are now. > > -- Dick > > [1] those present when we met about how to solve recycling ... > > On 8-Jun-07, at 10:35 AM, Recordon, David wrote: > >> I'm not sure if we all think we're trying to solve the same problem. >> The two problems that have been discussed are: >> A) Identifier recycling normally in large user-base deployments. >> i.e. >> needs a way to give 'TheBestUsernameEver' to a >> new >> user if it has not been used in some period of time. >> B) Losing control of your own domain name whether that be via someone >> stealing it or just that you don't want to have to pay for it >> forever. >> >> Have we made a decision as to if we're looking for a solution to >> solve >> both of these problems, only A, or only B? >> >> --David >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> > > ___ > 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: Do We Agree on the Problem We're Trying to Solve?
I would suggest that any solution to B is also very likely a solution to A. Anybody disagree? If so, I'd suggest that we should either solve A and B at the same time, or not at all. On Jun 8, 2007, at 10:42, Dick Hardt wrote: > At IIW we[1] decided we wanted to solve (A) and that (B) would be > nice to solve, but we were ok to wait for a future version to > resolve, as when we discussed (B), resolving looked much harder then > it seemed at first. > > I'm not certain of where we are now. > > -- Dick > > [1] those present when we met about how to solve recycling ... > > On 8-Jun-07, at 10:35 AM, Recordon, David wrote: > >> I'm not sure if we all think we're trying to solve the same problem. >> The two problems that have been discussed are: >> A) Identifier recycling normally in large user-base deployments. >> i.e. >> needs a way to give 'TheBestUsernameEver' to a >> new >> user if it has not been used in some period of time. >> B) Losing control of your own domain name whether that be via someone >> stealing it or just that you don't want to have to pay for it >> forever. >> >> Have we made a decision as to if we're looking for a solution to >> solve >> both of these problems, only A, or only B? >> >> --David >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> > > ___ > 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
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 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 of http://www.livejournal.com/userinfo.bml?userid=1356357 is itself 5) RP sees 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
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 "" 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. 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?
At IIW we[1] decided we wanted to solve (A) and that (B) would be nice to solve, but we were ok to wait for a future version to resolve, as when we discussed (B), resolving looked much harder then it seemed at first. I'm not certain of where we are now. -- Dick [1] those present when we met about how to solve recycling ... On 8-Jun-07, at 10:35 AM, Recordon, David wrote: > I'm not sure if we all think we're trying to solve the same problem. > The two problems that have been discussed are: > A) Identifier recycling normally in large user-base deployments. i.e. > needs a way to give 'TheBestUsernameEver' to a > new > user if it has not been used in some period of time. > B) Losing control of your own domain name whether that be via someone > stealing it or just that you don't want to have to pay for it forever. > > Have we made a decision as to if we're looking for a solution to solve > both of these problems, only A, or only B? > > --David > ___ > 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
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: Questions about IIW Identifier Recycling Table
On 6/8/07, Recordon, David <[EMAIL PROTECTED]> wrote: > The difference I see is that the current secrets can be renegotiated. > If we're working with non-public fragments then they cannot be. If > we're working with public fragments, then I'm less concerned. I understand your concern, but I don't share it. There will be times that secrets are lost, but I think that the benefit of protecting users from identifier loss is more important than the cost of requiring a reliable provider. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Do We Agree on the Problem We're Trying to Solve?
I'm not sure if we all think we're trying to solve the same problem. The two problems that have been discussed are: A) Identifier recycling normally in large user-base deployments. i.e. needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some period of time. B) Losing control of your own domain name whether that be via someone stealing it or just that you don't want to have to pay for it forever. Have we made a decision as to if we're looking for a solution to solve both of these problems, only A, or only B? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Questions about IIW Identifier Recycling Table
The difference I see is that the current secrets can be renegotiated. If we're working with non-public fragments then they cannot be. If we're working with public fragments, then I'm less concerned. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, June 08, 2007 10:29 AM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Questions about IIW Identifier Recycling Table On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote: If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party and the provider already need to store secrets. Josh ___ 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: Questions about IIW Identifier Recycling Table
On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote: > > I'm not sure I understand what's "public" about this. If I understand > > it correctly, from the relying party's perspective, the user's account > > is keyed off of the pair of the identifier and the token. This sounds > > like URL + private token in that table. Am I missing something? > > Maybe I don't understand the difference between private and public tokens. > My proposal used private information to create a public token that can be > sent via AX (thus the hybrid term). Am I understanding the difference > between private/public tokens incorrectly? I think I see how we're using the term differently. The token only protects your identifier if the relying party does not ever display it. If the relying party did display it, anyone who gained control of your identifier in the future could just send that (reusable) token along with an assertion in order to gain access to a relying party. Since the relying party needs to keep the token secret, I was calling it "private." It's shared between the provider, the user, and the relying party, but it's secret from anyone else. I think it's also important to note that the transport mechanism for the token (using attribute exchange, as an extra field or as a fragment) is independent from whether the token should be shared. I think using attribute exchange for this core feature is a non-starter, since it would create a dependency on the attribute exchange in the authentication spec. > > This approach was rejected at IIW because: > > > > 1. An extra database field is required (whether or not the data is > > transmitted using attribute exchange) > > If the AX database schema is architected properly, then the addition of a > new AX attribute should not necessitate a new database column. If this were > the case, then AX would not really be feasible (how would an RP deal with a > new AX attribute?). If you have an existing application and you are adding OpenID support, in order to support the token, you would have to alter your schema. When creating a new application, it's not a big deal. I also expect that few relying parties will support *arbitrary* attributes, since the relying party will not be asking for attributes that do not have specialized uses anyway. Perhaps this deserves clarification on the wiki page. > > 2. There is no obvious way to tell if a user is the same user across > > sites (The identifier contains a secret portion) > > Good point. Although, let's assume that RP's display fragment-enabled > OpenID's in the following manner, which overcomes the "Fragments are Ugly" > problem: > http://me.example.com#1234";>http://me.example.com > > Users will not be able to easily distinguish that the OpenID is owned by a > different user without hovering over the URL in their browser. That said, > computers will be able to, since the actual HREF is what counts, I assume. > Has this been discussed wrt to fragments. There has been some discussion about it. It's a tough issue, and it's one of the reasons that I asked the (surprisingly controversial) question about whether we can just add the token to some part of the URL, if it's going to be publicly available anyway. If it's a visible part of the URL, both users and software agents will be able to tell the difference between identifiers. In the discussions that we have had about this issue so far, we have concentrated on a user gaining access (either on purpose or accidentally) to resources that were controlled by the previous owner of their identifier. For example, a user could sign in to a photo sharing site and see someone else's photos. A related issue is that of a third party mistaking resources controlled by the previous owner of a URL as being controlled by the current owner. For example, a potential employer does a search for the user's identifier and finds photos of some illegal activity, without the uniquifying token as a visible part of the URL. > > 3. Concern about depending on a secret for a user to be able to sign > > in to a site (David's Wordpress issue) > > I think DR had a problem with anything that could be lost, thereby > preventing access to an RP. Both Fragments and Tokens seem to suffer from > this problem, since in the Fragment scheme, if I or my OP forgets what my > fragment was, I won't be able to login to an RP without recycling my account > (or forcing an account recovery procedure). > > Seems like the odds of my OP losing my fragment information are pretty slim. > Identically, the odds of my OP losing my recycling_password are pretty > slim, too. What's more, If *I* lose my recycling password, why should I > care? Only the OP needs to deal with it, and perhaps the OP can just show > me that password in an account settings page when I login(?) If the token is publically viewable, then losing it is not an issue. I do not share David's concern about depending on a secret, since both the relying party a
Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
It is more complex having to use two fields to uniquely identify a user in a DB then one. DB queries are more complex and there is more opportunity for the developer to make mistakes. Given a goal of OpenID is to be simple, one field is better then two. -- Dick On 8-Jun-07, at 10:14 AM, Johnny Bufu wrote: > > On 8-Jun-07, at 10:02 AM, Recordon, David wrote: > >> I'm confused as to why a RP having to not create a new DB field is a >> requirement when looking to solve this problem. RP's implementations >> already need to change to upgrade from 1.1 to 2.0 and this has never >> been a requirement in the past. It certainly is nice that storage >> changes wouldn't be needed, but I don't see it as something that >> should >> be a requirement. > > My feeling was that, all other things being equal, some bits of code > (stripping the fragment for display purposes) which ideally would go > into the library, were preferred to requiring a schema change (to > store the separate token) for the RPs. Not a requirement, but a > strong preference. > > > Johnny > > ___ > 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: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
I agree that all things equal, it is reasonable to look at. I think a lot of this in terms of where stripping versus identifier storage happen depends a lot on the library and application. In Rails for example the library manages the store for associations and nonces, and the application has to modify a table to store the identifier. In the stripping case, you'd then have to create a method in your application for when you call User.identifier which strips the fragment. In the second field case, you'd then have two fields in your database to work with, also from the application level. So just not sure if there really is more or less complexity from this standpoint between the two approaches. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 10:15 AM To: Recordon, David Cc: specs@openid.net Subject: Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table) On 8-Jun-07, at 10:02 AM, Recordon, David wrote: > I'm confused as to why a RP having to not create a new DB field is a > requirement when looking to solve this problem. RP's implementations > already need to change to upgrade from 1.1 to 2.0 and this has never > been a requirement in the past. It certainly is nice that storage > changes wouldn't be needed, but I don't see it as something that > should > be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
On 8-Jun-07, at 10:02 AM, Recordon, David wrote: > I'm confused as to why a RP having to not create a new DB field is a > requirement when looking to solve this problem. RP's implementations > already need to change to upgrade from 1.1 to 2.0 and this has never > been a requirement in the past. It certainly is nice that storage > changes wouldn't be needed, but I don't see it as something that > should > be a requirement. My feeling was that, all other things being equal, some bits of code (stripping the fragment for display purposes) which ideally would go into the library, were preferred to requiring a schema change (to store the separate token) for the RPs. Not a requirement, but a strong preference. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)
I'm confused as to why a RP having to not create a new DB field is a requirement when looking to solve this problem. RP's implementations already need to change to upgrade from 1.1 to 2.0 and this has never been a requirement in the past. It certainly is nice that storage changes wouldn't be needed, but I don't see it as something that should be a requirement. Can someone shed some light on this for me? Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, June 07, 2007 5:03 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: Questions about IIW Identifier Recycling Table On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote: > Over the last few days I've been thinking about your Identifier Recycling > proposal[2], in addition to other proposals (Tokens, etc). Assuming I > understand things correctly, it seems as if a hybrid of the public/private > token approach would seem to garner the most checks, per the IIW grid. Not > sure if my idea is technically correct or not, so please let me know if what > I'm proposing falls short anywhere. Here goes I'm not sure I understand what's "public" about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
