Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Dick Hardt
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,

RE: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Recordon, David
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

No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Recordon, David
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

Re: No New DB Field Requirement? (WAS: RE: Questions about IIW Identifier Recycling Table)

2007-06-08 Thread Johnny Bufu
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

RE: Questions about IIW Identifier Recycling Table

2007-06-08 Thread Recordon, David
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

Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Recordon, David
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. insert big company needs a way to give 'TheBestUsernameEver' to a new user if it has not been used in some

Re: Questions about IIW Identifier Recycling Table

2007-06-08 Thread Josh Hoyt
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

RE: The CanonicalID Approach

2007-06-08 Thread Recordon, David
Hey Johnny, My understanding, though don't have the appropriate spec reference, is that the process would be: 1) User enters http://daveman692.livejournal.com 2) RP fetches Yadis doc for http://daveman692.livejournal.com 3) RP sees CanonicalID of

RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Recordon, David
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
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

Re: The CanonicalID Approach

2007-06-08 Thread Johnny Bufu
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

Re: Questions about IIW Identifier Recycling Table

2007-06-08 Thread Josh Hoyt
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Johannes Ernst
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)

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Johannes Ernst
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
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

Re: The CanonicalID Approach

2007-06-08 Thread Martin Atkins
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

RE: The CanonicalID Approach

2007-06-08 Thread Recordon, David
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Johannes Ernst
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

RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Drummond Reed
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
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.

Re: The CanonicalID Approach

2007-06-08 Thread Johnny Bufu
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Johannes Ernst
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread David Fuelling
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. insert big company needs a way to

RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Drummond Reed
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.

RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Recordon, David
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,

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
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

RE: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Drummond Reed
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Dick Hardt
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread David Fuelling
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

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-08 Thread Johannes Ernst
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,