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, 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)

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 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


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 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


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 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: 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 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


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 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

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 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


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
http://www.livejournal.com/userinfo.bml?userid=1356357
3) RP fetches Yadis doc for
http://www.livejournal.com/userinfo.bml?userid=1356357
4) RP sees CanonicalID of
http://www.livejournal.com/userinfo.bml?userid=1356357 is itself
5) RP sees Ref of http://daveman692.livejournal.com and thus has
verified that the pointer goes in both directions

Will have to ask Drummond his thoughts on how fragments would be used,
since this morning it isn't clear to me.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 08, 2007 10:42 AM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: The CanonicalID Approach

Hi David,

On 7-Jun-07, at 6:31 PM, Recordon, David wrote:

 You could also, don't shudder too hard Dick :), use an i-number
 as your persistent identifier via this method though on the flip-side
 could also use a fragment if that is the approach someone would  
 like to
 take.

 The nice thing is that this method is extremely flexible in terms of
 what you use as your persistent identifier in different cases.

The question (that we will need to specify or have a clear pointer  
to) is how the canonical ID verification is done. (BTW: Was this  
section updated on Wed in the XRI draft?)

Your HTTP URL canonical ID example is straight-forward and simple. Do  
you have an example of how it would work with fragments, say:

http://openid.aol.com/daveman692 - reassignable
http://openid.aol.com/daveman692#1234 - persistent


Thanks,
Johnny


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: 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
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.
 insert big company 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?

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 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.
 insert big company 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?

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 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.
 insert big company 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

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 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

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 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:
 a href= http://me.example.com#1234;http://me.example.com/a

 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 and the provider already need to store secrets.

I think 

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) 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.
 insert big company 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?

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 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.
 insert big company 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?

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 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.
 insert big company 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: 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 same sort of process using the Ref/ tag in my
 various XRDS files.
 
 -1 on requiring a whole extra round of discovery for every sign in. If
 you can come up with a way to verify that (a) the identifier in
 question points to the canonical ID and (b) the canonical ID has the
 appropriate information in it without doing twice the discovery, I'd
 like to hear it.
 

I figure that you could potentially use the same mechanism as delegation 
to avoid the extra discovery iteration.

The problem, as with delegation, is that you need to duplicate the 
endpoint URL in the source identifier's XRDS document. The canonical 
identifier must also support OpenID, which I believe is something they 
were trying to avoid.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: The CanonicalID Approach

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 Atkins
Sent: Friday, June 08, 2007 1:42 PM
Cc: specs@openid.net
Subject: Re: The CanonicalID Approach

Josh Hoyt wrote:
 On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote:
 What I'd like to markup is that my three reassignable identifiers so
 that they all use my LiveJournal userid URL as the persistent
 identifier.  It should be noted that also marking them as synonyms to
 each other follows the same sort of process using the Ref/ tag in
my
 various XRDS files.
 
 -1 on requiring a whole extra round of discovery for every sign in. If
 you can come up with a way to verify that (a) the identifier in
 question points to the canonical ID and (b) the canonical ID has the
 appropriate information in it without doing twice the discovery, I'd
 like to hear it.
 

I figure that you could potentially use the same mechanism as delegation

to avoid the extra discovery iteration.

The problem, as with delegation, is that you need to duplicate the 
endpoint URL in the source identifier's XRDS document. The canonical 
identifier must also support OpenID, which I believe is something they 
were trying to avoid.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: 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 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.
 insert big company 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?

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 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.
 insert big company 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?

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.

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: 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 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?

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 problem  
in itself.






Johannes Ernst
NetMesh Inc.


inline: openid-relying-party-authenticated.gifinline: lid.gif
 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?

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 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.
insert big company 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?

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.

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?

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, 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?

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 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?

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 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?

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 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?

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 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?

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, 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