Re: Do We Agree on the Problem We're Trying to Solve?
On 11-Jun-07, at 1:45 PM, Josh Hoyt wrote: > > 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. The multiple identifiers resolves problem B of losing control of an identifier, and would also enable identifier recycling. If you pull back and look at current mechanisms, many of them are multiple identifiers. If you forget your password, equivalent to losing control of an identifier, you can get a new one sent to your email address and you can change your password (identifier). If you don't have access to your email anymore, some sites ask you a number of "secret" questions, and if you have that information, then it is another "identifier". 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 mechanisms. -- 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?
Josh Hoyt wrote: > On 6/11/07, Martin Atkins <[EMAIL PROTECTED]> wrote: >> Presumably the recommendation would be to have several identifiers >> attached to a single account just as is recommended today. I would point >> most of my identifiers at one canonical identifier but retain one or >> more special "backup identifiers" that do not point at my "persistent" >> identifier so that I can reclaim my account if my persistent identifier >> goes away. > > Why bother with a canonical identifier if you're going to need > multiple identifiers attached to an account anyway? Why bother using OpenID if you need to have multiple identifiers attached to your account anyway? ___ 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, Martin Atkins <[EMAIL PROTECTED]> wrote: > Presumably the recommendation would be to have several identifiers > attached to a single account just as is recommended today. I would point > most of my identifiers at one canonical identifier but retain one or > more special "backup identifiers" that do not point at my "persistent" > identifier so that I can reclaim my account if my persistent identifier > goes away. Why bother with a canonical identifier if you're going to need multiple identifiers attached to an account anyway? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
Josh Hoyt 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. > Presumably the recommendation would be to have several identifiers attached to a single account just as is recommended today. I would point most of my identifiers at one canonical identifier but retain one or more special "backup identifiers" that do not point at my "persistent" identifier so that I can reclaim my account if my persistent identifier goes away. Changing the CanonicalID on a particular identifier won't work unless the new CanonicalID URL is also associated with your RP account(s). ___ 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
