RE: Specifying identifier recycling

[=drummond.reed]

For posterity, here's how I'd summarize this thread about using public keys
as persistent identifiers:

1) Yes, a public key could be used as an identifier, and could serve as a
persistent identifier if it was not reassignable.

2) The issue of it becoming invalid as a credential if the private key was
compromised is orthogonal to its use purely as an identifier, i.e., as
Johannes points out, if the private key was compromised, use of the public
key could revert to the role of serving purely as an identifier, and another
set of credentials (such as another public/private key pair) could be
assigned.

3) In this light, the primary drawbacks I see to public keys as identifiers
are:

a) They are typically much larger than other persistent identifiers
designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or
Handles as issued by CNRI).
b) I am not aware of a resolution protocol designed for them, with
the exception that I believe syntactially they could be used as XRI
i-numbers.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Tuesday, June 05, 2007 7:27 PM
To: =nat
Cc: 'OpenID specs list'
Subject: Re: Specifying identifier recycling

I think you are making an invalid analogy. What prevents you from  
setting up a "private key reset" function the same way you set up a  
"password reset" function, using an alternate credential? You allow  
for this for non-public-key credentials but not for others ...

But I don't want to perpetuate this thread given the general  
reluctance of the community to think about public key cryptography at  
this time ... I just want to go on record that I find the arguments  
made counter public keys on this thread non-persuasive and want to  
pick it back up when the community is ready to go there ... (note  
also that the security industry would not exist in the shape it does  
if we didn't have public key crypto, so that technology does  
contribute something somewhere ... perhaps also to OpenID?)

Just follow the following argument ... let's assume that the problem  
that started this thread
... can be solved by adding a number to the URL identifier (using a  
fragment syntax or an i-number or whatever other approaches were  
discussed)
... then it also can be solved by adding a large number instead of  
just any number
... then it also can be solved by adding a large number that could be  
a public key, which is nothing but a large number
... which, therefore, makes a public-key-based approach at least as  
powerful as a plain number

Just some stuff for thought ... ;-)

Cheers,



Johannes.


On Jun 5, 2007, at 17:58, =nat wrote:

> Hi.
>
> Ok. Now I see the heart of the topic :-)
>
> Fundamental difference is that you postulate that one cannot lose  
> one's
> credential including all the information that bears onto establish  
> one's
> identity while I do not postulate so.
>
> For example, one can loose one's password and reset it.
> You can loose your credit card and replace it.
> Doing so has not nullished your "identity". You still are yourself.
> Your identity itself and the attribute associated with it apart  
> from this
> particular lost credential data (whether it was a password or  
> credit card)
> stays intact.
>
> This picture changes dramatically when you use public key
> as your main identity address. If you lose your private key,
> that's the end of story. Your relationships with all the RPs are  
> ruined.
>
> That is why I believe that we should not be using this kind of  
> public key
> as the identification data for RPs.
>
> Also, mandating OPs to specify a unique opaque string as the
> identification data would be much simpler than requiring parties to
> do public key verification, I think :-)
>
> Having said that, I do agree that we should be completing 2.0 cycle
> quickly and making it SIMPLE!
>
> Nat
>
>
>> -Original Message-
>> From: Johannes Ernst [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, June 05, 2007 1:45 PM
>> To: =nat
>> Cc: 'OpenID specs list'
>> Subject: Re: Specifying identifier recycling
>>
>> I would postulate that if you want to be able to prove your
>> identity, you cannot allow your credential to be lost,
>> interpreting "credential" to be all the information that
>> bears onto establishing your identity. (saying it this way,
>> it is a tautology.)
>>
>> This is independent of whether anybody uses public keys, or
>> any other technology. So I very strongly suspect that while
>> it may be more apparent to you guys that the issue exists for
>> public key technology, it also exists for all other
>> app

Re: Specifying identifier recycling

[Johannes Ernst]

I think you are making an invalid analogy. What prevents you from  
setting up a "private key reset" function the same way you set up a  
"password reset" function, using an alternate credential? You allow  
for this for non-public-key credentials but not for others ...

But I don't want to perpetuate this thread given the general  
reluctance of the community to think about public key cryptography at  
this time ... I just want to go on record that I find the arguments  
made counter public keys on this thread non-persuasive and want to  
pick it back up when the community is ready to go there ... (note  
also that the security industry would not exist in the shape it does  
if we didn't have public key crypto, so that technology does  
contribute something somewhere ... perhaps also to OpenID?)

Just follow the following argument ... let's assume that the problem  
that started this thread
... can be solved by adding a number to the URL identifier (using a  
fragment syntax or an i-number or whatever other approaches were  
discussed)
... then it also can be solved by adding a large number instead of  
just any number
... then it also can be solved by adding a large number that could be  
a public key, which is nothing but a large number
... which, therefore, makes a public-key-based approach at least as  
powerful as a plain number

Just some stuff for thought ... ;-)

Cheers,



Johannes.


On Jun 5, 2007, at 17:58, =nat wrote:

> Hi.
>
> Ok. Now I see the heart of the topic :-)
>
> Fundamental difference is that you postulate that one cannot lose  
> one's
> credential including all the information that bears onto establish  
> one's
> identity while I do not postulate so.
>
> For example, one can loose one's password and reset it.
> You can loose your credit card and replace it.
> Doing so has not nullished your "identity". You still are yourself.
> Your identity itself and the attribute associated with it apart  
> from this
> particular lost credential data (whether it was a password or  
> credit card)
> stays intact.
>
> This picture changes dramatically when you use public key
> as your main identity address. If you lose your private key,
> that's the end of story. Your relationships with all the RPs are  
> ruined.
>
> That is why I believe that we should not be using this kind of  
> public key
> as the identification data for RPs.
>
> Also, mandating OPs to specify a unique opaque string as the
> identification data would be much simpler than requiring parties to
> do public key verification, I think :-)
>
> Having said that, I do agree that we should be completing 2.0 cycle
> quickly and making it SIMPLE!
>
> Nat
>
>
>> -Original Message-
>> From: Johannes Ernst [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, June 05, 2007 1:45 PM
>> To: =nat
>> Cc: 'OpenID specs list'
>> Subject: Re: Specifying identifier recycling
>>
>> I would postulate that if you want to be able to prove your
>> identity, you cannot allow your credential to be lost,
>> interpreting "credential" to be all the information that
>> bears onto establishing your identity. (saying it this way,
>> it is a tautology.)
>>
>> This is independent of whether anybody uses public keys, or
>> any other technology. So I very strongly suspect that while
>> it may be more apparent to you guys that the issue exists for
>> public key technology, it also exists for all other
>> approaches, whether we know them at this time or not!
>>
>> However, I can readily see that strong voices (that'd be you
>> guys ;-)) are not ready to adopt any kind of public key
>> technology into the OpenID family, never mind whether X or Y
>> wins this particular argument. So we don't need to continue
>> this thread.
>>
>> I continue to believe, however, as I have said before, that
>> we don't have enough of an agreement on the solution to be
>> able to standardize any of them at this time. (Personally, I
>> don't think we have agreement on the problems to be solved
>> either.) I'd much rather see our creative juices flowing on
>> the much larger problem of simplifying the OpenID Auth draft
>> in a manner that people say "this is much easier than 1.1"
>> instead of the opposite.
>>
>>
>> On Jun 3, 2007, at 23:11, =nat wrote:
>>
>>> Dick's concern is very valid, I think.
>>>
>>> I do not even want to think of the consequence of losing my
>> own main
>>> identity secret :-p
>>>
>>> =nat
>>>
>>>> -Original Message-
>&g

RE: Specifying identifier recycling

[=nat]

Hi. 

Ok. Now I see the heart of the topic :-)

Fundamental difference is that you postulate that one cannot lose one's 
credential including all the information that bears onto establish one's 
identity while I do not postulate so. 

For example, one can loose one's password and reset it. 
You can loose your credit card and replace it. 
Doing so has not nullished your "identity". You still are yourself. 
Your identity itself and the attribute associated with it apart from this 
particular lost credential data (whether it was a password or credit card) 
stays intact. 

This picture changes dramatically when you use public key 
as your main identity address. If you lose your private key, 
that's the end of story. Your relationships with all the RPs are ruined. 

That is why I believe that we should not be using this kind of public key 
as the identification data for RPs. 

Also, mandating OPs to specify a unique opaque string as the 
identification data would be much simpler than requiring parties to 
do public key verification, I think :-)

Having said that, I do agree that we should be completing 2.0 cycle 
quickly and making it SIMPLE!

Nat


> -Original Message-
> From: Johannes Ernst [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 05, 2007 1:45 PM
> To: =nat
> Cc: 'OpenID specs list'
> Subject: Re: Specifying identifier recycling
> 
> I would postulate that if you want to be able to prove your 
> identity, you cannot allow your credential to be lost, 
> interpreting "credential" to be all the information that 
> bears onto establishing your identity. (saying it this way, 
> it is a tautology.)
> 
> This is independent of whether anybody uses public keys, or 
> any other technology. So I very strongly suspect that while 
> it may be more apparent to you guys that the issue exists for 
> public key technology, it also exists for all other 
> approaches, whether we know them at this time or not!
> 
> However, I can readily see that strong voices (that'd be you 
> guys ;-)) are not ready to adopt any kind of public key 
> technology into the OpenID family, never mind whether X or Y 
> wins this particular argument. So we don't need to continue 
> this thread.
> 
> I continue to believe, however, as I have said before, that 
> we don't have enough of an agreement on the solution to be 
> able to standardize any of them at this time. (Personally, I 
> don't think we have agreement on the problems to be solved 
> either.) I'd much rather see our creative juices flowing on 
> the much larger problem of simplifying the OpenID Auth draft 
> in a manner that people say "this is much easier than 1.1" 
> instead of the opposite.
> 
> 
> On Jun 3, 2007, at 23:11, =nat wrote:
> 
> > Dick's concern is very valid, I think.
> >
> > I do not even want to think of the consequence of losing my 
> own main 
> > identity secret :-p
> >
> > =nat
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> >> Sent: Sunday, June 03, 2007 8:24 PM
> >> To: Johannes Ernst
> >> Cc: OpenID specs list
> >> Subject: Re: Specifying identifier recycling
> >>
> >> There is a huge difference between the OP/RP shared secret 
> and using 
> >> a shared secret as an identifier.
> >>
> >> The secret between the OP and RP has a mechanism for it to be 
> >> recycled. If it happens to be lost, then the pair can set up a new 
> >> secret.
> >>
> >> If the user's secret is lost, then that identifier and any 
> accounts 
> >> that it was used for are lost.
> >>
> >> -- 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: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Recordon, David]

At that point I'd be concerned as to solving the "big OP issue" while
not solving the "lost domain issue" when some of the proposals could
possible solve both.  This largely focuses around using an XRI-style
canonical id, whether that be an i-number or just another "ugly" URL
which points back at the pretty one.  I know I need to write this up
more...

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 05, 2007 3:18 PM
To: Recordon, David
Cc: Josh Hoyt; Johannes Ernst; OpenID specs list
Subject: Re: The "WordPress" User Problem (WAS: RE: Specifying
identifier recycling)

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
> The relying parties SHOULD make the fragment available to software 
> agents, at least, so that it's possible to compare identifiers across 
> sites. If the fragment is never available, then there is confusion 
> about which user of an identifier is responsible for content that has 
> been posted. One use case where software agents having access to the 
> fragment is particularly important is if the identifier is used for 
> access control, and the access control list is retrieved from off-site

> (e.g. from a social networking site).
>
> The implementation that seems most sane is for places that display the

> identifier for human reading look like:
>
> http://josh.example.com/#this-is-intended-for-machine-
> consumption"
>  >http://josh.example.com/
>
> so that the software agent would see the fragment, but the user 
> wouldn't have to.

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

> I thought the fragment was to be secret so that for the case of using 
> a personal domain you don't have to own joshhoyt.com forever.  Rather 
> as long as your fragments are secret, someone else can buy 
> joshhoyt.com and not be you.  If this is no longer a requirement then 
> it certainly changes the game, though also doesn't solve one of the 
> other aspects of identifier recycling.

I thought so too, but I believe Josh is right - the "lost domain"  
cell with an X in it (for URL + public fragment) supports Josh's
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually simpler
to address just the identifier recycling for big OPs, where loosing the
domain is not an issue.


Johnny

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
> The relying parties SHOULD make the fragment available to software
> agents, at least, so that it's possible to compare identifiers across
> sites. If the fragment is never available, then there is confusion
> about which user of an identifier is responsible for content that has
> been posted. One use case where software agents having access to the
> fragment is particularly important is if the identifier is used for
> access control, and the access control list is retrieved from off-site
> (e.g. from a social networking site).
>
> The implementation that seems most sane is for places that display the
> identifier for human reading look like:
>
> http://josh.example.com/#this-is-intended-for-machine- 
> consumption"
>  >http://josh.example.com/
>
> so that the software agent would see the fragment, but the user
> wouldn't have to.

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

> I thought the fragment was to be secret so that for the case of  
> using a
> personal domain you don't have to own joshhoyt.com forever.  Rather as
> long as your fragments are secret, someone else can buy  
> joshhoyt.com and
> not be you.  If this is no longer a requirement then it certainly
> changes the game, though also doesn't solve one of the other  
> aspects of
> identifier recycling.

I thought so too, but I believe Josh is right - the "lost domain"  
cell with an X in it (for URL + public fragment) supports Josh's  
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually  
simpler to address just the identifier recycling for big OPs, where  
loosing the domain is not an issue.


Johnny

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

RE: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Recordon, David]

I thought the fragment was to be secret so that for the case of using a
personal domain you don't have to own joshhoyt.com forever.  Rather as
long as your fragments are secret, someone else can buy joshhoyt.com and
not be you.  If this is no longer a requirement then it certainly
changes the game, though also doesn't solve one of the other aspects of
identifier recycling.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh
Hoyt
Sent: Tuesday, June 05, 2007 11:58 AM
To: Johnny Bufu
Cc: Recordon, David; Johannes Ernst; OpenID specs list
Subject: Re: The "WordPress" User Problem (WAS: RE: Specifying
identifier recycling)

On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > The fragment is not secret. It is not "protecting" your OpenID. You 
> > should be able to get the fragment from any relying party that you 
> > visited.
>
> I believe David's point is that you cannot retrieve the fragment from 
> the RP if you have lost it and are no longer able to log into any RPs.

> (Unless there's an account recovery mechanism either on the RP or the 
> OP.) The RPs know it, but are not supposed to display / disclose it.

The relying parties SHOULD make the fragment available to software
agents, at least, so that it's possible to compare identifiers across
sites. If the fragment is never available, then there is confusion about
which user of an identifier is responsible for content that has been
posted. One use case where software agents having access to the fragment
is particularly important is if the identifier is used for access
control, and the access control list is retrieved from off-site (e.g.
from a social networking site).

The implementation that seems most sane is for places that display the
identifier for human reading look like:

 http://josh.example.com/#this-is-intended-for-machine-consumption";
  >http://josh.example.com/

so that the software agent would see the fragment, but the user wouldn't
have to.

Using this approach, the fragment is trivially available anywhere you
signed in.

There is also no reason that a relying party should hide the fragment if
a user asks for it. Since it is not sensitive information, it does not
require "account recovery."

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Josh Hoyt]

On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > The fragment is not secret. It is not "protecting" your OpenID. You
> > should be able to get the fragment from any relying party that you
> > visited.
>
> I believe David's point is that you cannot retrieve the fragment from
> the RP if you have lost it and are no longer able to log into any
> RPs. (Unless there's an account recovery mechanism either on the RP
> or the OP.) The RPs know it, but are not supposed to display /
> disclose it.

The relying parties SHOULD make the fragment available to software
agents, at least, so that it's possible to compare identifiers across
sites. If the fragment is never available, then there is confusion
about which user of an identifier is responsible for content that has
been posted. One use case where software agents having access to the
fragment is particularly important is if the identifier is used for
access control, and the access control list is retrieved from off-site
(e.g. from a social networking site).

The implementation that seems most sane is for places that display the
identifier for human reading look like:

 http://josh.example.com/#this-is-intended-for-machine-consumption";
  >http://josh.example.com/

so that the software agent would see the fragment, but the user
wouldn't have to.

Using this approach, the fragment is trivially available anywhere you signed in.

There is also no reason that a relying party should hide the fragment
if a user asks for it. Since it is not sensitive information, it does
not require "account recovery."

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 11:12 AM, Josh Hoyt wrote:

> On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
>> Imagine if I install WordPress (or insert other app here) on
>> https://davidrecordon.com and check the "Use fragments to protect my
>> OpenID" box.  A few months later I decide to remove WordPress, or an
>> upgrade blows away my OpenID extension data, or I'm using an  
>> extension
>> which stores the fragments in /tmp/ and they get blown away.  I  
>> now no
>> longer have access to my accounts on all the relying parties I've
>> visited.  Now what do I do?
>
> The fragment is not secret. It is not "protecting" your OpenID. You
> should be able to get the fragment from any relying party that you
> visited.

I believe David's point is that you cannot retrieve the fragment from  
the RP if you have lost it and are no longer able to log into any  
RPs. (Unless there's an account recovery mechanism either on the RP  
or the OP.) The RPs know it, but are not supposed to display /  
disclose it.

> You might choose to use a fragment if you have acquired a
> recycled identifier, but you can choose the fragment. It protects
> *nothing* if you control the base identifier (to the point that you
> can choose an OpenID provider).

Agreed - if you loose control over the URL, you can no longer use  
your old online identity.

However, the issue / feature this does address is "protect your RP  
accounts if you loose your identity". (The new owner of  
davidrecordon.com would not be able to sign into the old  
davidrecordon.com's digg account.)


Johnny

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Josh Hoyt]

On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Imagine if I install WordPress (or insert other app here) on
> https://davidrecordon.com and check the "Use fragments to protect my
> OpenID" box.  A few months later I decide to remove WordPress, or an
> upgrade blows away my OpenID extension data, or I'm using an extension
> which stores the fragments in /tmp/ and they get blown away.  I now no
> longer have access to my accounts on all the relying parties I've
> visited.  Now what do I do?

The fragment is not secret. It is not "protecting" your OpenID. You
should be able to get the fragment from any relying party that you
visited. You might choose to use a fragment if you have acquired a
recycled identifier, but you can choose the fragment. It protects
*nothing* if you control the base identifier (to the point that you
can choose an OpenID provider).

I'm not arguing for or against a particular approach here, but I think
your argument is flawed.

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 8:00 AM, Recordon, David wrote:

> I think the largest concern I have with fragments, or really any
> pair-wise shared secret which can't be renegotiated, is that while it
> solves issues for the large service providers it actually inhibits
> OpenID within the grassroots community.

This concern is definitely something new; I haven't seen it expressed  
before.

> Imagine if I install WordPress (or insert other app here) on
> https://davidrecordon.com and check the "Use fragments to protect my
> OpenID" box.  A few months later I decide to remove WordPress, or an
> upgrade blows away my OpenID extension data, or I'm using an extension
> which stores the fragments in /tmp/ and they get blown away.  I now no
> longer have access to my accounts on all the relying parties I've
> visited.  Now what do I do?

What do you do today, if you forget your slashdot password and  
slashdot didn't implement account recovery? Most (if not all) RPs  
today do implement account recovery - they don't want to loose users,  
and they know users make mistakes and forget passwords.

> We can't count on each RP implementing an account recovery mechanism;
> remember OpenID outsources account management so you can focus on
> building you application.  I can't call up my service provider and ask
> them to fix it, since well I was using my own provider.

You should call up your OP then.

> I could try to
> call up my webhost and see if they can restore from a backup, but I'd
> guess by the time I realize what that check box in my WordPress
> extension settings did there may not even be backups anymore.  In the
> end, I'd be extremely frustrated that OpenID didn't work for me   
> and I'd
> write a really obnoxious blog post about how much OpenID sucks.
>
> So while we solve one aspect of the recycling problem, we end up
> creating a larger problem from the opposite side of the equation.  I'm
> certainly not arguing that we shouldn't solve this problem, nor that
> participation from large providers isn't vital, but would hate to  
> see us
> create a problem for all of the people out there that have really  
> helped
> gain OpenID traction.
>
> I don't want to say that I have the answers here, since I don't  
> think I
> do.  I do however see the following possible solutions:
>
> 1) The core specification only talks about fragments in relation to
> Relying Parties, to the extent that they should be stripped from  
> display
> though used as a unique key.  We do however need to address how a RP
> should handle display and account management differences when a  
> fragment
> changes.  I'm guessing it is unreasonable to expect every instance of
> https://davidrecordon.com to be replaced with
> https://davidrecordon.com/#231hwqai21jb when the fragment changes (not
> to mention that the fragment *must* remain private between the OP  
> and RP
> to be effective).  An extension is then written describing fragment
> usage from the OP perspective with huge warnings about how it should
> only be used by large service providers who know what they're doing.

I believe it could work with REQUIREments in the core for RPs  
(discovery, verification), and OPTIONAL / extension for the OPs.  
Though the gained simplicity I think would be minimal. But if the  
other advantage is that OPs don't carelessly implement this feature  
without knowing what they are doing, then it may be better overall.

Totally agree with the warnings / raising awareness that identifier  
recycling is an advanced feature. I believe this is part of a more  
general problem: by being decentralized, OpenID gives power to  
everyone (anyone can be an OP); while being an RP is / should be  
simple, doing the OP job right is not.

> 2) We use a centralized "canonical id" approach like i-numbers.
> Basically somebody issues unique and never reassigned ids.
>
> 3) We use a distributed "canonical id" approach.  Providers issue an
> ugly non-reassignable URL which points at the pretty one and vice- 
> versa.
> Thus https://davidrecordon.com says its canonical is
> https://12jbd9210.pip.verisignlabs.com which in turn says it is
> https://davidrecordon.com.  We could even kill two birds with one  
> stone
> and use "" to do this and setup an easy way to create
> identifier equality.

> I think my preference is #3, though I'm sure it has its own issues.

Do you have a more detailed proposal on how this would work? I do see  
a couple important / possibly show-stopper issues here, but I haven't  
really explored this direction for a solution. If you have, I would  
definitely be interested to learn more.

However, I still believe #1 is our best bet, if we can focus our  
efforts to make it work in such a way to address your grassroots  
adoption concerns. #1 did have (and still has, I hope) the support of  
a good many people, and has a concrete and detailed proposal. If we  
agree that _some_ changes to the core are required, then #1 has also  
the time advantage.


> 4) W

The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Recordon, David]

I think the largest concern I have with fragments, or really any
pair-wise shared secret which can't be renegotiated, is that while it
solves issues for the large service providers it actually inhibits
OpenID within the grassroots community.

Imagine if I install WordPress (or insert other app here) on
https://davidrecordon.com and check the "Use fragments to protect my
OpenID" box.  A few months later I decide to remove WordPress, or an
upgrade blows away my OpenID extension data, or I'm using an extension
which stores the fragments in /tmp/ and they get blown away.  I now no
longer have access to my accounts on all the relying parties I've
visited.  Now what do I do?

We can't count on each RP implementing an account recovery mechanism;
remember OpenID outsources account management so you can focus on
building you application.  I can't call up my service provider and ask
them to fix it, since well I was using my own provider.  I could try to
call up my webhost and see if they can restore from a backup, but I'd
guess by the time I realize what that check box in my WordPress
extension settings did there may not even be backups anymore.  In the
end, I'd be extremely frustrated that OpenID didn't work for me  and I'd
write a really obnoxious blog post about how much OpenID sucks.

So while we solve one aspect of the recycling problem, we end up
creating a larger problem from the opposite side of the equation.  I'm
certainly not arguing that we shouldn't solve this problem, nor that
participation from large providers isn't vital, but would hate to see us
create a problem for all of the people out there that have really helped
gain OpenID traction.

I don't want to say that I have the answers here, since I don't think I
do.  I do however see the following possible solutions:
1) The core specification only talks about fragments in relation to
Relying Parties, to the extent that they should be stripped from display
though used as a unique key.  We do however need to address how a RP
should handle display and account management differences when a fragment
changes.  I'm guessing it is unreasonable to expect every instance of
https://davidrecordon.com to be replaced with
https://davidrecordon.com/#231hwqai21jb when the fragment changes (not
to mention that the fragment *must* remain private between the OP and RP
to be effective).  An extension is then written describing fragment
usage from the OP perspective with huge warnings about how it should
only be used by large service providers who know what they're doing.

2) We use a centralized "canonical id" approach like i-numbers.
Basically somebody issues unique and never reassigned ids.

3) We use a distributed "canonical id" approach.  Providers issue an
ugly non-reassignable URL which points at the pretty one and vice-versa.
Thus https://davidrecordon.com says its canonical is
https://12jbd9210.pip.verisignlabs.com which in turn says it is
https://davidrecordon.com.  We could even kill two birds with one stone
and use "" to do this and setup an easy way to create
identifier equality.

4) We use public/private key pairs, though this has the traditional
private key revocation issues.

I think my preference is #3, though I'm sure it has its own issues.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 03, 2007 6:35 PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recycling


On 3-Jun-07, at 1:46 AM, Recordon, David wrote:

> I thought at IIW we agreed that if we could come to quick consensus  
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it  
> would
> not...

Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on  
how to solve this issue. But the issue was deemed important enough to  
be one of the only two on the 2.0 agenda.

> As concerns with the fragment proposal have been raised, which had the
> most agreement at IIW, it seems we no longer have consensus.

I haven't seen many actually; checking this thread for what can count  
as concerns reveals only:
a) Josh's initial email
b) Johannes' +1 to not adopting a solution that doesn't actually work
c) David acknowledging the concerns

This doesn't seem to me to carry enough weight to veto the fragment  
proposal, especially when a) has been / can still be addressed, and  
the fragment proposal made sense to a dozen people at that meeting.

> As seen in
> this thread, there are a wide variety of opinions as to how to resolve
> this concern.  I thus think merely picking one for the sake of putting
> something into 2.0 would be misguided.

True, there have been a few (I definitely wouldn't call it a wide  
variety) possible solutions mentioned, but none very well defined,  
and none had th

Re: Specifying identifier recycling

[Johannes Ernst]

I would postulate that if you want to be able to prove your identity,  
you cannot allow your credential to be lost, interpreting  
"credential" to be all the information that bears onto establishing  
your identity. (saying it this way, it is a tautology.)

This is independent of whether anybody uses public keys, or any other  
technology. So I very strongly suspect that while it may be more  
apparent to you guys that the issue exists for public key technology,  
it also exists for all other approaches, whether we know them at this  
time or not!

However, I can readily see that strong voices (that'd be you  
guys ;-)) are not ready to adopt any kind of public key technology  
into the OpenID family, never mind whether X or Y wins this  
particular argument. So we don't need to continue this thread.

I continue to believe, however, as I have said before, that we don't  
have enough of an agreement on the solution to be able to standardize  
any of them at this time. (Personally, I don't think we have  
agreement on the problems to be solved either.) I'd much rather see  
our creative juices flowing on the much larger problem of simplifying  
the OpenID Auth draft in a manner that people say "this is much  
easier than 1.1" instead of the opposite.


On Jun 3, 2007, at 23:11, =nat wrote:

> Dick's concern is very valid, I think.
>
> I do not even want to think of the consequence of losing my own
> main identity secret :-p
>
> =nat
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
>> Sent: Sunday, June 03, 2007 8:24 PM
>> To: Johannes Ernst
>> Cc: OpenID specs list
>> Subject: Re: Specifying identifier recycling
>>
>> There is a huge difference between the OP/RP shared secret
>> and using a shared secret as an identifier.
>>
>> The secret between the OP and RP has a mechanism for it to be
>> recycled. If it happens to be lost, then the pair can set up
>> a new secret.
>>
>> If the user's secret is lost, then that identifier and any
>> accounts that it was used for are lost.
>>
>> -- 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: Specifying identifier recycling

[Dick Hardt]

On 4-Jun-07, at 7:51 AM, Granqvist, Hans wrote:

>> So I ask again - does anyone see any issues with the
>> fragments being used like this:
>>
>>  http://openid.net/pipermail/specs/2007-May/001767.html  
>>
>
> Seems reasonable in essence. But it adds complexity and
> removes some immediacy of URL identifiers-as-is.
>
> Do fragments need special handling just to handle id
> recycling risks?
>
> I'm probably missing some context, but can't the issuing OP
> make sure to issue unique IDs, like http://example.com/user1234
> instead of http://example.com/user#1234 ?

Just to clarify the issue:

Users like to have memorable usernames, and likely memorable OpenIDs.

So http://example.com/hans would be a desirable URL at example.com.  
For OPs with literally 100Ms of users, http://example.com/hans would  
be a coveted URL and if it is not being used, example.com would like  
to issue it to someone else.

I think the tradeoff of RPs understanding to strip fragments when  
displaying them is worth removing a barrier for very large OPs from  
joining OpenID.

-- Dick

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

RE: Specifying identifier recycling

[Granqvist, Hans]

> So I ask again - does anyone see any issues with the 
> fragments being used like this:
> 
>   http://openid.net/pipermail/specs/2007-May/001767.html  
> 

Seems reasonable in essence. But it adds complexity and
removes some immediacy of URL identifiers-as-is.

Do fragments need special handling just to handle id 
recycling risks?

I'm probably missing some context, but can't the issuing OP 
make sure to issue unique IDs, like http://example.com/user1234 
instead of http://example.com/user#1234 ?  

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

RE: Specifying identifier recycling

[=nat]

Hi. 

My comments in-line below: 

On Saturday, June 02, 2007 5:40 AM, Johannes Ernst wrote: 
> 
> On May 31, 2007, at 18:41, Nat Sakimura wrote:
> 
> > Public key idea is somewhat attractive to me, but there are some 
> > issues that comes up in my mind as well.
> 
> Bring them on ;-)
> 
> > 1) Storing many users' private key on the server in 
> decryptable format 
> > is not very safe.
> >
> > In your proposal, it looks like that OP is going to hold 
> the private 
> > key for each user in decryptable format. Considering that 
> most large 
> > scale privacy leakage happens at the server side, I have 
> got a feeling 
> > that such thing like private key in a shared location.
> 
> How would this be less safe than storing many shared secrets 
> (per OpenID Auth) in decryptable format, or clear-text (more 
> likely) on the server?

Well, we should not store any :-) We would not need them, do we? 
Just hashes would do. 

> Note that these private keys would not be general-purpose 
> private keys, but only for the specific purpose we are 
> discussing here.

Actually, by Dick's comment, I am now realizing what was making me 
uneasy. I feel (sort of) ok on storing one's special purpose secret key on
the 
server just like server-side wallet, but I want it to be replaceable without
impacting 
my identity. i.e., it is ok to use the key to sign a message, but not make
the 
pub-key my identifier. (Having said that, I am still not clear why we should
need 
this for just AuthN. OP sigining the response on authenticating the user
does 
not seem much different. Also, keeping one key in HSM and securely operating

is easier than having millions of keys...)

> 
> Also, I suspect that the use of these keys would be fairly 
> infrequent compared to other operations, so conceivably one 
> could add additional safeguards of various kinds if that was needed.
> 
> > 2) It may mean a high cost operation for OPs.
> >
> > If we do this, it makes OP operation very high cost because to make 
> > the service safe, it would require a lot of measures. (NRI is 
> > providing similar kind of service but it indeed is very high cost 
> > operation.)
> >
> > Nice thing about i-number is that it has no value like public key 
> > except for its resolvability. Even if it leaks, that's kind 
> of ok so 
> > operational risk is low.
> 
> This comparison does not work very well for me. However: I 
> don't know the details of how to avoid "impersonation" via 
> i-numbers (in case of key pairs, it would be "private key 
> leaks and is reused by attacker"  
> -- what would be the equivalent for i-numbers?), but I 
> suspect there are some measures that prevent attackers from 
> impersonation by using somebody else's i-number? If so, 
> aren't they similarly susceptible to attack?

In the scenario that OP signs a unique string (whether it is i-number or
something else), 
impersonization happens when OP's key is stolen. However, as Dick points
out, 
we have a way to re-setup the keys between OP and RP. In case of "user
private key 
as a part of identity" leaks, we do not have a very good way of replacing
it. (Well, 
we cannot, as if we could, this will contradict its purpose as counter id
recycling measure. 
Note, if it is not part of identity string and just used to sign something
with public key 
discovery protocol, that is ok.) ( I also would like to point out that OP's
key leaking is 
much easier to monitor and detect than user's. )

> 
> > Actually, these private key pain may be eased by IBE (Identity Based
> > Encryption) but I need some more time to contemplate on it.
> 
> I had somebody else mention this to me -- I wonder whether 
> anybody could put together an actual proposal.

After some thinking, I started to think that this might not be a good idea
after all. 

> 
> > 3) Since OPs has an access to the users' private key, they 
> > may recycle them as well.
> >
> > IMHO, recycling is operational problem as well as a technical one.
> > i-number from a certified i-broker is somewhat trustable on the 
> > account of no recycling because of this operational 
> > restriction. Could 
> > there be operational restriction similart to that for 
> > general OPs as well?
> 
> There could, and -- I suspect -- in the longer term there 
> probably will, but the whole point about a decentralized 
> system like OpenID is to keep the playing field level without 
> a central entity in the middle for the maximum length of time 
> and scope possible.

Well, I am not talking about a central authority kind of thing. 
Having a uniquely identifying filed (whether canonicalID or fragment) 
in the spec would suffice because this will imply that an OP that does not 
meet this operation practice is not OpenID spec compliant. 
Some OP may opt to elect a third party auditor to prove their parctice, 
while some other would not. Also, reputation service kind of thing would 
be nice. This is all de-centralized. No central authority would be required.


> 
> In any case,

RE: Specifying identifier recycling

[=nat]

Dick's concern is very valid, I think. 

I do not even want to think of the consequence of losing my own 
main identity secret :-p

=nat

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> Sent: Sunday, June 03, 2007 8:24 PM
> To: Johannes Ernst
> Cc: OpenID specs list
> Subject: Re: Specifying identifier recycling
> 
> There is a huge difference between the OP/RP shared secret 
> and using a shared secret as an identifier.
> 
> The secret between the OP and RP has a mechanism for it to be 
> recycled. If it happens to be lost, then the pair can set up 
> a new secret.
> 
> If the user's secret is lost, then that identifier and any 
> accounts that it was used for are lost.
> 
> -- Dick
> 

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

RE: Specifying identifier recycling

[Drummond Reed]

>> Johnny Bufu wrote:
>> 
>> We did look at this (with Drummond) in December. The bottom line is  
>> that it can't be done easily - a mechanism similar to XRI's canonical  
>> ID verification would have to be employed, to confirm that the i- 
>> number actually 'belongs' to the URL on which discovery was  
>> initiated. (Otherwise anyone could put any i-number in their URL- 
>> based XRDS files.)
>> 
>Martin Atkins wrote:
>
>Indeed, CanonicalID verification would be necessary, but it's already 
>necessary if you want to accept XRI-based logins anyway.
>
>Last time we were talking about this CanonicalID verification for XRI 
>was not yet specified. Is it now specified somewhere?

Martin, it's been specified in draft form since last October on the XRI TC
wiki at:

http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification

The content there was moved week before last into the first editor's draft
of XRI Resolution 2.0 Working Draft 11 at:


http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0-
wd-11-ed-01.doc

The new Canonical ID Verification section is #11. Note that the verification
rules currently only cover if the XRDS is discovered from an XRI. In the
second editor's draft, due this Wednesday, we will add rules for
verification if the XRDS is discovered from a URL.

=Drummond 

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

Re: Specifying identifier recycling

[Johnny Bufu]

On 3-Jun-07, at 1:46 AM, Recordon, David wrote:

> I thought at IIW we agreed that if we could come to quick consensus  
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it  
> would
> not...

Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on  
how to solve this issue. But the issue was deemed important enough to  
be one of the only two on the 2.0 agenda.

> As concerns with the fragment proposal have been raised, which had the
> most agreement at IIW, it seems we no longer have consensus.

I haven't seen many actually; checking this thread for what can count  
as concerns reveals only:
a) Josh's initial email
b) Johannes' +1 to not adopting a solution that doesn't actually work
c) David acknowledging the concerns

This doesn't seem to me to carry enough weight to veto the fragment  
proposal, especially when a) has been / can still be addressed, and  
the fragment proposal made sense to a dozen people at that meeting.

> As seen in
> this thread, there are a wide variety of opinions as to how to resolve
> this concern.  I thus think merely picking one for the sake of putting
> something into 2.0 would be misguided.

True, there have been a few (I definitely wouldn't call it a wide  
variety) possible solutions mentioned, but none very well defined,  
and none had the support of 10+ people like the fragment did.

I have argued that it will have to be core (whether 2.0 or 3.0). I  
guess we should ask ourselves then if we really want this addressed  
in 2.0, and if yes then try to make it work.


So I ask again - does anyone see any issues with the fragments being  
used like this:

http://openid.net/pipermail/specs/2007-May/001767.html  

If not, I have a hard time understanding where exactly the consensus  
was lost.


Johnny

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

Re: Specifying identifier recycling

[Dick Hardt]

On 3-Jun-07, at 10:46 AM, Recordon, David wrote:

> I thought at IIW we agreed that if we could come to quick consensus  
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it  
> would
> not...

That is what we agreed to in Josh's meeting. Then we had a meeting  
the next day and we had consensus from a pretty good sized group that  
included ALL the spec authors.

>
> As concerns with the fragment proposal have been raised, which had the
> most agreement at IIW, it seems we no longer have consensus.  As  
> seen in
> this thread, there are a wide variety of opinions as to how to resolve
> this concern.  I thus think merely picking one for the sake of putting
> something into 2.0 would be misguided.

I'm not clear what the issues with the fragment are. Josh's issue  
does not make sense as the user does not really know they have a  
fragment in their identifier.

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

Re: Specifying identifier recycling

[Dick Hardt]

There is a huge difference between the OP/RP shared secret and using  
a shared secret as an identifier.

The secret between the OP and RP has a mechanism for it to be  
recycled. If it happens to be lost, then the pair can set up a new  
secret.

If the user's secret is lost, then that identifier and any accounts  
that it was used for are lost.

-- Dick

On 31-May-07, at 7:30 AM, Johannes Ernst wrote:

> If we cannot assume that nobody manages to obtain a secret they
> should not have gotten in the first place, then OpenID as it stands
> is rather useless as we cannot trust its  authentication scheme.
>
> Note that the surface through which the D-H shared secret can escape
> is about twice as large as the surface through which a private key
> can escape -- because an RP does not have access to the private key.
> In other words, if I was an attacker, I'd go after a lot of things
> first before I'd try to obtain a private key.
>
> Note also that public keys would make rather good i-numbers -- for
> those who would like to, they can ignore that they are public keys
> and do i-number-based verification only, because they are simply
> numbers. For those who don't care about i-numbers, they use their
> public key aspects. Win-win, perhaps?
>
> There is also the case -- which Stefan Brands would undoubtedly bring
> up if he was on this list -- that the IdP may be hostile, or may
> become hostile. (think of, say, a large OpenID provider going out of
> business, and being bought out by spammer.com -- or just the domain
> name whose registration lapsed) A scheme that is public key based is
> inherently more resilient towards this than one that is not. You
> certainly don't want to trust spammer.com to honor whatever
> conventions the previous owner of the domain put in place to
> disambiguate their users.
>
> --
>
> Overall, I'm not sure we are ready in this community to pick one
> alternative over another as "the standards". I have my views, (many)
> others have (many) others -- and I don't think that any of this has
> to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will
> be. This seems like a clean add-on.
>
>
>
> On May 30, 2007, at 22:01, Drummond Reed wrote:
>
>> Johannes:
>>
>> What about the point Dick posted earlier in this thread, that the
>> problem
>> with using a public key is if the private key gets compromised?
>> Persistent
>> identifiers need to persist independent of any attribute changing
>> or being
>> revoked.
>>
>> =Drummond
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf
>> Of Johannes Ernst
>> Sent: Wednesday, May 30, 2007 9:54 PM
>> To: OpenID specs list
>> Subject: Re: Specifying identifier recycling
>>
>>
>> On May 30, 2007, at 21:02, Johnny Bufu wrote:
>>
>>> ...The bottom line is
>>> that it can't be done easily - a mechanism similar to XRI's  
>>> canonical
>>> ID verification would have to be employed, to confirm that the i-
>>> number actually 'belongs' to the URL on which discovery was
>>> initiated. (Otherwise anyone could put any i-number in their URL-
>>> based XRDS files.)
>>
>> Public keys ... public keys ... with the added benefit that no
>> centralized or trusted verification service needs to be employed
>> whatsoever ...
>>
>>
>>
>>
>> Johannes Ernst
>> NetMesh Inc.
>>
>>
>>
>> ___
>> 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: Specifying identifier recycling

[Dick Hardt]

A little late to the conversation, but some comments inserted as I  
did not see them all in any other aspect of this thread ...

On 30-May-07, at 10:28 PM, Josh Hoyt wrote:

> Hello,
>
> I started writing up the use of fragment identifiers for URL-recycling
> for the OpenID 2.0 authentication spec, and I ran into some unforseen
> challenges. It's not obvious how a relying party should behave when a
> URL with a fragment is entered. How should the discovery process work?

The user does not use the fragment. If they do type it in, the RP can  
strip it.

> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?

Not sure there is an issue here. Can you elaborate?

>
> After thinking this over for a while, I'm no longer convinced that
> using URI fragments as the uniquifying value is the right
> approach. Looking at the available options, I think that the best
> approach might be to add a uniquifying value to some part of the URL,
> in a provider-specific manner. For instance:
>
>   I own . I delete my account, and so it
>   goes back in the pool of identifers. The next Josh who registers the
>   username "josh" at MyOpenID.com gets .
>
> Providers can also provide a redirect from the general form of the
> identifier to the current version of the identifier so that users do
> not need to remember or type the uniquified version. This is pretty
> much equivalent to the fragment scheme, except:
>
>   * It does not require spec changes (and is backwards-compatible!)
>
>   * The uniquifying component is user-visible

the user now has to enter something that is not as memorable -- there  
is little difference between http://josh.myopenid.com/1 and http:// 
josh1.myopenid.com/

Your approach does not solve the recycling problem.

>
> I'd like to hear opinions on whether this unique-URL solution is good
> enough to solve the problem. If you think it isn't, I'd like
> suggestions on how discovery and delegation should interact with
> fragments.
>
> Josh
>
>
> For reference, here's a comparison of the three different approaches
> to solving the identifier recycling problem:
>
> 1. Using a URI fragment with a uniquifying value:
>
>   * No database changes necessary on the RP (the RP can store the URL
> with the fragment as the identifier)
>
>   * Potential problems with initiation and discovery

The user types in the memorable part of the URI, and not the fragment.

>
>   * Potential problems with inconsistent behaviours on OpenID 1 sites

We discussed this at IIW and the consensus was that we would just  
have to get them to upgrade. Many of them will not allow the user to  
enter an i-name or OP currently anyway.

>
>   * Comparing identifiers is easy
>
>   * URLs that user see may be ugly or inconsistent across sites (if
> some relying parties do and others do not strip the fragment
> before display)
>
>   * There is no difference between different versions of a
> *user-displayed* identifier (users can't tell if a reference to a
> URL in the wild belongs to the current ownder of a URL or another
> user).
>
>
> 2. Adding an extra field with a uniquifying value:
>
>   * Database change required
>
>   * No change in initiation or discovery
>
>   * OpenID 1 sites will behave as they do now
>
>   * Identifier comparison is no longer obvious
>
>   * Display URLs are easy
>
>   * There is no difference between different versions of an identifier

ISSUE: The new user of the identifier will get access to the old  
user's account.

>
>
> 3. Just use different URLs:
>
>   * No database change required
>
>   * No change in initiation or discovery
>
>   * No implementation change at all (just a new best practice)
>
>   * Comparing identifiers is easy
>
>   * Display URLs are easy
>
>   * Users can tell the difference between an old and a new identifier


ISSUE: URIs are not being recycled


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

Re: Specifying identifier recycling

[Dick Hardt]

On 3-Jun-07, at 2:14 AM, Recordon, David wrote:

>> Overall, I'm not sure we are ready in this community to pick one
>> alternative over another as "the standards". I have my views,
>> (many) others have (many) others -- and I don't think that any
>> of this has to be in an Authentication 1.x (x>1) or 2.0 spec,
>> whatever it will be. This seems like a clean add-on.
>
> I also agree with Johannes here.  I'd like to see this written as an
> extension so that if the first approach doesn't work, the Auth spec
> itself doesn't have to be "reverted.  Rather we can finish 2.0 and try
> implementing different approaches before deciding on the final way to
> solve this problem.

I don't see how we can solve this problem as an extension as we need  
the RP to know that a memorable identifier has some extra info that  
makes it unique when reused. This is core to OpenID.

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

RE: Specifying identifier recycling

[Recordon, David]

I thought at IIW we agreed that if we could come to quick consensus on a
way to resolve the problem it would be a part of 2.0, otherwise it would
not...

As concerns with the fragment proposal have been raised, which had the
most agreement at IIW, it seems we no longer have consensus.  As seen in
this thread, there are a wide variety of opinions as to how to resolve
this concern.  I thus think merely picking one for the sake of putting
something into 2.0 would be misguided.

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 02, 2007 10:12 PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recycling


On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
> I'd like to see this written as an
> extension so that if the first approach doesn't work, the Auth spec
> itself doesn't have to be "reverted.  Rather we can finish 2.0 and try
> implementing different approaches before deciding on the final way to
> solve this problem.

I thought we had agreed at IIW (for good reason) to address this in  
2.0. Other than the actual solution not being 100% clear, has  
anything changed?

Arguments for not putting it into an extension:
- users of provider's X who employs 'identifier recycling extension'  
would not be able to log into RP Y who doesn't understand the extension
- it's likely that whatever solution we come up with affects the  
discovery / verification processes, in which case it couldn't be  
pushed to an extension (we're trying to patch something about the  
_identifier_ itself, which is the center of each openid transaction).


Also, I believe the fragment approach can actually work, as detailed  
here:

http://openid.net/pipermail/specs/2007-May/001767.html

I haven't seen any replies to this, so would appreciate if others  
would go through the proposed changes and see if they all makes sense  
of I've overlooked something.


Thanks,
Johnny

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

Re: Specifying identifier recycling

[Johannes Ernst]

I wasn't in that session (as far as I recall ;-)) so I don't know  
either what was agreed on, or who agreed, or for what reasons ... the  
thread so far does not look like it was a very stable agreement ;-)



On Jun 2, 2007, at 22:11, Johnny Bufu wrote:

>
> On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
>> I'd like to see this written as an
>> extension so that if the first approach doesn't work, the Auth spec
>> itself doesn't have to be "reverted.  Rather we can finish 2.0 and  
>> try
>> implementing different approaches before deciding on the final way to
>> solve this problem.
>
> I thought we had agreed at IIW (for good reason) to address this in  
> 2.0. Other than the actual solution not being 100% clear, has  
> anything changed?
>
> Arguments for not putting it into an extension:
> - users of provider's X who employs 'identifier recycling  
> extension' would not be able to log into RP Y who doesn't  
> understand the extension
> - it's likely that whatever solution we come up with affects the  
> discovery / verification processes, in which case it couldn't be  
> pushed to an extension (we're trying to patch something about the  
> _identifier_ itself, which is the center of each openid transaction).
>
>
> Also, I believe the fragment approach can actually work, as  
> detailed here:
>
>   http://openid.net/pipermail/specs/2007-May/001767.html
>
> I haven't seen any replies to this, so would appreciate if others  
> would go through the proposed changes and see if they all makes  
> sense of I've overlooked something.
>
>
> Thanks,
> Johnny

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

Re: Specifying identifier recycling

[Johnny Bufu]

On 2-Jun-07, at 5:14 PM, Recordon, David wrote:
> I'd like to see this written as an
> extension so that if the first approach doesn't work, the Auth spec
> itself doesn't have to be "reverted.  Rather we can finish 2.0 and try
> implementing different approaches before deciding on the final way to
> solve this problem.

I thought we had agreed at IIW (for good reason) to address this in  
2.0. Other than the actual solution not being 100% clear, has  
anything changed?

Arguments for not putting it into an extension:
- users of provider's X who employs 'identifier recycling extension'  
would not be able to log into RP Y who doesn't understand the extension
- it's likely that whatever solution we come up with affects the  
discovery / verification processes, in which case it couldn't be  
pushed to an extension (we're trying to patch something about the  
_identifier_ itself, which is the center of each openid transaction).


Also, I believe the fragment approach can actually work, as detailed  
here:

http://openid.net/pipermail/specs/2007-May/001767.html

I haven't seen any replies to this, so would appreciate if others  
would go through the proposed changes and see if they all makes sense  
of I've overlooked something.


Thanks,
Johnny

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

RE: Specifying identifier recycling

[Recordon, David]

> Overall, I'm not sure we are ready in this community to pick one
> alternative over another as "the standards". I have my views,
> (many) others have (many) others -- and I don't think that any
> of this has to be in an Authentication 1.x (x>1) or 2.0 spec,
> whatever it will be. This seems like a clean add-on.

I also agree with Johannes here.  I'd like to see this written as an
extension so that if the first approach doesn't work, the Auth spec
itself doesn't have to be "reverted.  Rather we can finish 2.0 and try
implementing different approaches before deciding on the final way to
solve this problem.

SREG shows how 1.1 can be extended, 2.0 clarifies this mechanism and
makes it more robust, let's take advantage of it especially given that
not all providers require this feature (whether via fragments or public
keys).

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Wednesday, May 30, 2007 10:30 PM
To: OpenID specs list
Subject: Re: Specifying identifier recycling

If we cannot assume that nobody manages to obtain a secret they  
should not have gotten in the first place, then OpenID as it stands  
is rather useless as we cannot trust its  authentication scheme.

Note that the surface through which the D-H shared secret can escape  
is about twice as large as the surface through which a private key  
can escape -- because an RP does not have access to the private key.  
In other words, if I was an attacker, I'd go after a lot of things  
first before I'd try to obtain a private key.

Note also that public keys would make rather good i-numbers -- for  
those who would like to, they can ignore that they are public keys  
and do i-number-based verification only, because they are simply  
numbers. For those who don't care about i-numbers, they use their  
public key aspects. Win-win, perhaps?

There is also the case -- which Stefan Brands would undoubtedly bring  
up if he was on this list -- that the IdP may be hostile, or may  
become hostile. (think of, say, a large OpenID provider going out of  
business, and being bought out by spammer.com -- or just the domain  
name whose registration lapsed) A scheme that is public key based is  
inherently more resilient towards this than one that is not. You  
certainly don't want to trust spammer.com to honor whatever  
conventions the previous owner of the domain put in place to  
disambiguate their users.

--

Overall, I'm not sure we are ready in this community to pick one  
alternative over another as "the standards". I have my views, (many)  
others have (many) others -- and I don't think that any of this has  
to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will  
be. This seems like a clean add-on.



On May 30, 2007, at 22:01, Drummond Reed wrote:

> Johannes:
>
> What about the point Dick posted earlier in this thread, that the  
> problem
> with using a public key is if the private key gets compromised?  
> Persistent
> identifiers need to persist independent of any attribute changing  
> or being
> revoked.
>
> =Drummond
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
> Behalf
> Of Johannes Ernst
> Sent: Wednesday, May 30, 2007 9:54 PM
> To: OpenID specs list
> Subject: Re: Specifying identifier recycling
>
>
> On May 30, 2007, at 21:02, Johnny Bufu wrote:
>
>> ...The bottom line is
>> that it can't be done easily - a mechanism similar to XRI's canonical
>> ID verification would have to be employed, to confirm that the i-
>> number actually 'belongs' to the URL on which discovery was
>> initiated. (Otherwise anyone could put any i-number in their URL-
>> based XRDS files.)
>
> Public keys ... public keys ... with the added benefit that no
> centralized or trusted verification service needs to be employed
> whatsoever ...
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
> ___
> 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: Specifying identifier recycling

[Recordon, David]

Would have to agree with what Johannes has said. :)

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Wednesday, May 30, 2007 1:53 PM
To: Josh Hoyt
Cc: OpenID specs list
Subject: Re: Specifying identifier recycling

On May 30, 2007, at 13:28, Josh Hoyt wrote:
> After thinking this over for a while, I'm no longer convinced that 
> using URI fragments as the uniquifying value is the right approach.

I agree with you. Our reasons may differ slightly, but the result is the
same.

I have no problem in not solving this problem this time around. I would
have a problem with adding a solution to the spec that turns out to not
be a solution after all. ;-)

Cheers,


Johannes.



Johannes Ernst
NetMesh Inc.


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

Re: Specifying identifier recycling

[Claus Färber]

Nat Sakimura schrieb:
> 1) Storing many users' private key on the server in decryptable format is
> not very safe. 
> 
> In your proposal, it looks like that OP is going to hold the private key for
> each user in decryptable format. Considering that most large scale privacy
> leakage happens at the server side, I have got a feeling that such thing
> like private key in a shared location.

If you can't trust your OP to keep your secrets secret, there's nothing 
you can do about that. Of course, you would not use a key that's valid 
as a key for anything else than OpenID.

It's also possible that the OP does not know the private key by using 
two key pairs:

. pers_secret, pers_public (the identity)
. temp_secret, temp_public

The OpenID Povider only has the following:

. pers_public
. temp_secret, temp_public
. cert = sign(temp_public, with_key=pers_secret)

The _real_ private key, pers_secret, is kept by the user. If the server 
is compromised (or becomes rouge, trying to steal the identity), the 
user can still take his identity elsewhere by signing the tmp2_public 
key of another server.

Claus

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

RE: Specifying identifier recycling

[Recordon, David]

Just for reference, this draft spec takes a look at key discovery for
OpenID URLs.
http://openid.net/specs/openid-service-key-discovery-1_0-01.html

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Johannes Ernst
Sent: Friday, June 01, 2007 1:40 PM
To: Nat Sakimura
Cc: 'OpenID specs list'
Subject: Re: Specifying identifier recycling


On May 31, 2007, at 18:41, Nat Sakimura wrote:

> Public key idea is somewhat attractive to me, but there are some  
> issues that
> comes up in my mind as well.

Bring them on ;-)

> 1) Storing many users' private key on the server in decryptable  
> format is
> not very safe.
>
> In your proposal, it looks like that OP is going to hold the  
> private key for
> each user in decryptable format. Considering that most large scale  
> privacy
> leakage happens at the server side, I have got a feeling that such  
> thing
> like private key in a shared location.

How would this be less safe than storing many shared secrets (per  
OpenID Auth) in decryptable format, or clear-text (more likely) on  
the server?

Note that these private keys would not be general-purpose private  
keys, but only for the specific purpose we are discussing here.

Also, I suspect that the use of these keys would be fairly infrequent  
compared to other operations, so conceivably one could add additional  
safeguards of various kinds if that was needed.

> 2) It may mean a high cost operation for OPs.
>
> If we do this, it makes OP operation very high cost because to make  
> the
> service safe, it would require a lot of measures. (NRI is providing  
> similar
> kind of service but it indeed is very high cost operation.)
>
> Nice thing about i-number is that it has no value like public key  
> except for
> its resolvability. Even if it leaks, that's kind of ok so  
> operational risk
> is low.

This comparison does not work very well for me. However: I don't know  
the details of how to avoid "impersonation" via i-numbers (in case of  
key pairs, it would be "private key leaks and is reused by attacker"  
-- what would be the equivalent for i-numbers?), but I suspect there  
are some measures that prevent attackers from impersonation by using  
somebody else's i-number? If so, aren't they similarly susceptible to  
attack?

> Actually, these private key pain may be eased by IBE (Identity Based
> Encryption) but I need some more time to contemplate on it.

I had somebody else mention this to me -- I wonder whether anybody  
could put together an actual proposal.

> 3) Since OPs has an access to the users' private key, they may  
> recycle them
> as well.
>
> IMHO, recycling is operational problem as well as a technical one.
> i-number from a certified i-broker is somewhat trustable on the  
> account of
> no recycling because of this operational restriction. Could there be
> operational restriction similart to that for general OPs as well?

There could, and -- I suspect -- in the longer term there probably  
will, but the whole point about a decentralized system like OpenID is  
to keep the playing field level without a central entity in the  
middle for the maximum length of time and scope possible.

In any case, I think we should use the approach to use  
(decentralized) technology to the maximum extent possible, and only  
add operational requirements when unavoidable. (And I know that many  
people on this list would scream bloody murder if anybody seriously  
proposed such a centralized requirement for OpenID usage ...)  
Personally I would feel we didn't think hard enough on this  
particular problem if the solution to this problem required us to use  
centralization of some kind.

>
> =nat
>
>
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst
>> Sent: Thursday, May 31, 2007 2:30 PM
>> To: OpenID specs list
>> Subject: Re: Specifying identifier recycling
>>
>> If we cannot assume that nobody manages to obtain a secret they
>> should not have gotten in the first place, then OpenID as it stands
>> is rather useless as we cannot trust its  authentication scheme.
>>
>> Note that the surface through which the D-H shared secret can escape
>> is about twice as large as the surface through which a private key
>> can escape -- because an RP does not have access to the private key.
>> In other words, if I was an attacker, I'd go after a lot of things
>> first before I'd try to obtain a private key.
>>
>> Note also that public keys would make rather good i-numbers -- for
>> those who would like to, they can ignore that they are public keys
>> and do i-number-based ver

Re: Specifying identifier recycling

[Johannes Ernst]

On May 31, 2007, at 18:41, Nat Sakimura wrote:

> Public key idea is somewhat attractive to me, but there are some  
> issues that
> comes up in my mind as well.

Bring them on ;-)

> 1) Storing many users' private key on the server in decryptable  
> format is
> not very safe.
>
> In your proposal, it looks like that OP is going to hold the  
> private key for
> each user in decryptable format. Considering that most large scale  
> privacy
> leakage happens at the server side, I have got a feeling that such  
> thing
> like private key in a shared location.

How would this be less safe than storing many shared secrets (per  
OpenID Auth) in decryptable format, or clear-text (more likely) on  
the server?

Note that these private keys would not be general-purpose private  
keys, but only for the specific purpose we are discussing here.

Also, I suspect that the use of these keys would be fairly infrequent  
compared to other operations, so conceivably one could add additional  
safeguards of various kinds if that was needed.

> 2) It may mean a high cost operation for OPs.
>
> If we do this, it makes OP operation very high cost because to make  
> the
> service safe, it would require a lot of measures. (NRI is providing  
> similar
> kind of service but it indeed is very high cost operation.)
>
> Nice thing about i-number is that it has no value like public key  
> except for
> its resolvability. Even if it leaks, that's kind of ok so  
> operational risk
> is low.

This comparison does not work very well for me. However: I don't know  
the details of how to avoid "impersonation" via i-numbers (in case of  
key pairs, it would be "private key leaks and is reused by attacker"  
-- what would be the equivalent for i-numbers?), but I suspect there  
are some measures that prevent attackers from impersonation by using  
somebody else's i-number? If so, aren't they similarly susceptible to  
attack?

> Actually, these private key pain may be eased by IBE (Identity Based
> Encryption) but I need some more time to contemplate on it.

I had somebody else mention this to me -- I wonder whether anybody  
could put together an actual proposal.

> 3) Since OPs has an access to the users' private key, they may  
> recycle them
> as well.
>
> IMHO, recycling is operational problem as well as a technical one.
> i-number from a certified i-broker is somewhat trustable on the  
> account of
> no recycling because of this operational restriction. Could there be
> operational restriction similart to that for general OPs as well?

There could, and -- I suspect -- in the longer term there probably  
will, but the whole point about a decentralized system like OpenID is  
to keep the playing field level without a central entity in the  
middle for the maximum length of time and scope possible.

In any case, I think we should use the approach to use  
(decentralized) technology to the maximum extent possible, and only  
add operational requirements when unavoidable. (And I know that many  
people on this list would scream bloody murder if anybody seriously  
proposed such a centralized requirement for OpenID usage ...)  
Personally I would feel we didn't think hard enough on this  
particular problem if the solution to this problem required us to use  
centralization of some kind.

>
> =nat
>
>
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst
>> Sent: Thursday, May 31, 2007 2:30 PM
>> To: OpenID specs list
>> Subject: Re: Specifying identifier recycling
>>
>> If we cannot assume that nobody manages to obtain a secret they
>> should not have gotten in the first place, then OpenID as it stands
>> is rather useless as we cannot trust its  authentication scheme.
>>
>> Note that the surface through which the D-H shared secret can escape
>> is about twice as large as the surface through which a private key
>> can escape -- because an RP does not have access to the private key.
>> In other words, if I was an attacker, I'd go after a lot of things
>> first before I'd try to obtain a private key.
>>
>> Note also that public keys would make rather good i-numbers -- for
>> those who would like to, they can ignore that they are public keys
>> and do i-number-based verification only, because they are simply
>> numbers. For those who don't care about i-numbers, they use their
>> public key aspects. Win-win, perhaps?
>>
>> There is also the case -- which Stefan Brands would
>> undoubtedly bring
>> up if he was on this list -- that the IdP may be hostile, or may
>> become hostile. (think of, say, a large

Re: Specifying identifier recycling

[Martin Atkins]

Johnny Bufu wrote:
> 
> We did look at this (with Drummond) in December. The bottom line is  
> that it can't be done easily - a mechanism similar to XRI's canonical  
> ID verification would have to be employed, to confirm that the i- 
> number actually 'belongs' to the URL on which discovery was  
> initiated. (Otherwise anyone could put any i-number in their URL- 
> based XRDS files.)
> 

Indeed, CanonicalID verification would be necessary, but it's already 
necessary if you want to accept XRI-based logins anyway.

Last time we were talking about this CanonicalID verification for XRI 
was not yet specified. Is it now specified somewhere?


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

RE: Specifying identifier recycling

[Nat Sakimura]

Public key idea is somewhat attractive to me, but there are some issues that
comes up in my mind as well. 

1) Storing many users' private key on the server in decryptable format is
not very safe. 

In your proposal, it looks like that OP is going to hold the private key for
each user in decryptable format. Considering that most large scale privacy
leakage happens at the server side, I have got a feeling that such thing
like private key in a shared location.

2) It may mean a high cost operation for OPs. 

If we do this, it makes OP operation very high cost because to make the
service safe, it would require a lot of measures. (NRI is providing similar
kind of service but it indeed is very high cost operation.) 

Nice thing about i-number is that it has no value like public key except for
its resolvability. Even if it leaks, that's kind of ok so operational risk
is low. 

Actually, these private key pain may be eased by IBE (Identity Based
Encryption) but I need some more time to contemplate on it. 

3) Since OPs has an access to the users' private key, they may recycle them
as well. 

IMHO, recycling is operational problem as well as a technical one. 
i-number from a certified i-broker is somewhat trustable on the account of
no recycling because of this operational restriction. Could there be
operational restriction similart to that for general OPs as well? 

=nat





> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst
> Sent: Thursday, May 31, 2007 2:30 PM
> To: OpenID specs list
> Subject: Re: Specifying identifier recycling
> 
> If we cannot assume that nobody manages to obtain a secret they  
> should not have gotten in the first place, then OpenID as it stands  
> is rather useless as we cannot trust its  authentication scheme.
> 
> Note that the surface through which the D-H shared secret can escape  
> is about twice as large as the surface through which a private key  
> can escape -- because an RP does not have access to the private key.  
> In other words, if I was an attacker, I'd go after a lot of things  
> first before I'd try to obtain a private key.
> 
> Note also that public keys would make rather good i-numbers -- for  
> those who would like to, they can ignore that they are public keys  
> and do i-number-based verification only, because they are simply  
> numbers. For those who don't care about i-numbers, they use their  
> public key aspects. Win-win, perhaps?
> 
> There is also the case -- which Stefan Brands would 
> undoubtedly bring  
> up if he was on this list -- that the IdP may be hostile, or may  
> become hostile. (think of, say, a large OpenID provider going out of  
> business, and being bought out by spammer.com -- or just the domain  
> name whose registration lapsed) A scheme that is public key based is  
> inherently more resilient towards this than one that is not. You  
> certainly don't want to trust spammer.com to honor whatever  
> conventions the previous owner of the domain put in place to  
> disambiguate their users.
> 
> --
> 
> Overall, I'm not sure we are ready in this community to pick one  
> alternative over another as "the standards". I have my views, (many)  
> others have (many) others -- and I don't think that any of this has  
> to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will  
> be. This seems like a clean add-on.
> 
> 
> 
> On May 30, 2007, at 22:01, Drummond Reed wrote:
> 
> > Johannes:
> >
> > What about the point Dick posted earlier in this thread, that the  
> > problem
> > with using a public key is if the private key gets compromised?  
> > Persistent
> > identifiers need to persist independent of any attribute changing  
> > or being
> > revoked.
> >
> > =Drummond
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On  
> > Behalf
> > Of Johannes Ernst
> > Sent: Wednesday, May 30, 2007 9:54 PM
> > To: OpenID specs list
> > Subject: Re: Specifying identifier recycling
> >
> >
> > On May 30, 2007, at 21:02, Johnny Bufu wrote:
> >
> >> ...The bottom line is
> >> that it can't be done easily - a mechanism similar to 
> XRI's canonical
> >> ID verification would have to be employed, to confirm that the i-
> >> number actually 'belongs' to the URL on which discovery was
> >> initiated. (Otherwise anyone could put any i-number in their URL-
> >> based XRDS files.)
> >
> > Public keys ... public keys ... with the added benefit that no
> > centralized or trusted verification service needs to be employe

Re: Specifying identifier recycling

[Johannes Ernst]

If we cannot assume that nobody manages to obtain a secret they  
should not have gotten in the first place, then OpenID as it stands  
is rather useless as we cannot trust its  authentication scheme.

Note that the surface through which the D-H shared secret can escape  
is about twice as large as the surface through which a private key  
can escape -- because an RP does not have access to the private key.  
In other words, if I was an attacker, I'd go after a lot of things  
first before I'd try to obtain a private key.

Note also that public keys would make rather good i-numbers -- for  
those who would like to, they can ignore that they are public keys  
and do i-number-based verification only, because they are simply  
numbers. For those who don't care about i-numbers, they use their  
public key aspects. Win-win, perhaps?

There is also the case -- which Stefan Brands would undoubtedly bring  
up if he was on this list -- that the IdP may be hostile, or may  
become hostile. (think of, say, a large OpenID provider going out of  
business, and being bought out by spammer.com -- or just the domain  
name whose registration lapsed) A scheme that is public key based is  
inherently more resilient towards this than one that is not. You  
certainly don't want to trust spammer.com to honor whatever  
conventions the previous owner of the domain put in place to  
disambiguate their users.

--

Overall, I'm not sure we are ready in this community to pick one  
alternative over another as "the standards". I have my views, (many)  
others have (many) others -- and I don't think that any of this has  
to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will  
be. This seems like a clean add-on.



On May 30, 2007, at 22:01, Drummond Reed wrote:

> Johannes:
>
> What about the point Dick posted earlier in this thread, that the  
> problem
> with using a public key is if the private key gets compromised?  
> Persistent
> identifiers need to persist independent of any attribute changing  
> or being
> revoked.
>
> =Drummond
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
> Behalf
> Of Johannes Ernst
> Sent: Wednesday, May 30, 2007 9:54 PM
> To: OpenID specs list
> Subject: Re: Specifying identifier recycling
>
>
> On May 30, 2007, at 21:02, Johnny Bufu wrote:
>
>> ...The bottom line is
>> that it can't be done easily - a mechanism similar to XRI's canonical
>> ID verification would have to be employed, to confirm that the i-
>> number actually 'belongs' to the URL on which discovery was
>> initiated. (Otherwise anyone could put any i-number in their URL-
>> based XRDS files.)
>
> Public keys ... public keys ... with the added benefit that no
> centralized or trusted verification service needs to be employed
> whatsoever ...
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
> ___
> 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: Specifying identifier recycling

[Drummond Reed]

Johannes:

What about the point Dick posted earlier in this thread, that the problem
with using a public key is if the private key gets compromised? Persistent
identifiers need to persist independent of any attribute changing or being
revoked.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Wednesday, May 30, 2007 9:54 PM
To: OpenID specs list
Subject: Re: Specifying identifier recycling


On May 30, 2007, at 21:02, Johnny Bufu wrote:

> ...The bottom line is
> that it can't be done easily - a mechanism similar to XRI's canonical
> ID verification would have to be employed, to confirm that the i-
> number actually 'belongs' to the URL on which discovery was
> initiated. (Otherwise anyone could put any i-number in their URL-
> based XRDS files.)

Public keys ... public keys ... with the added benefit that no  
centralized or trusted verification service needs to be employed  
whatsoever ...




Johannes Ernst
NetMesh Inc.



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

RE: Specifying identifier recycling

[Drummond Reed]

>>> John Panzer wrote:
>>>
>>> Has there been a discussion about an extension to map to/from i- 
>>> numbers
>>> via AX?  If there were a generic attribute you could stuff an i- 
>>> number
>>> or a hash of an internal ID in there to help solve the disambiguation
>>> problem.  Alternatively it'd be nice to have a way to ask when the
>>> account was created, if the OP is amenable.
>>>
>> Martin Atkins wrote
>>
>> If you're going to use i-numbers, then there's no reason at all not to
>> use the XRD CanonicalID element. The same mechanism that's used to map
>> i-names onto i-numbers can also be used to map URLs onto i-numbers, or
>> URLs onto other URLs.
>>
>> I'm sure Drummond can talk in more detail about this. We did  
>> discuss it
>> briefly at IIW, but once the majority had decided that the fragment
>> approach was the way to go we didn't get a chance to investigate this
>> further.
>
>Johnny Bufu wrote;
>
>We did look at this (with Drummond) in December. The bottom line is  
>that it can't be done easily - a mechanism similar to XRI's canonical  
>ID verification would have to be employed, to confirm that the i- 
>number actually 'belongs' to the URL on which discovery was  
>initiated. (Otherwise anyone could put any i-number in their URL- 
>based XRDS files.)

Johnny:

Martin, Gabe, and I discussed this at IIW, and the CanonicalID verification
process that's specified in the XRI Resolution 2.0 Working Draft 11
specification (of which the first editor's draft has now been posted - see
below) could be applied even if the XRDS was discovered via a URL.

To do this, RP code would need to confirm the CanonicalID i-number was
authoritative for the XRDS, which is essentially the same process the RP has
to go through anyway when the OP returns a different identifier than the one
the user originally entered at the RP (such as in the directed identity
flow).

In the first editor's draft of WD11, we only specified Canonical ID
verification when an XRDS was discovered from an XRI. But in the second
editor's draft (due early next week), we could add text specifying how to do
Canonical ID verification when the XRDS is discovered from a URL.

Although it's not yet content complete, you can review the Canonical ID
verification section (section 11) as well as the Yadis section (section 8)
in the first editor's draft of WD11 at:


http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0-
wd-11-ed-01.doc 

To make it easier to review, we've also posted section 8 (the Yadis section)
as a wiki page on the XRI TC wiki. See my next message about that.

=Drummond 

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

Re: Specifying identifier recycling

[Johannes Ernst]

On May 30, 2007, at 21:02, Johnny Bufu wrote:


...The bottom line is
that it can't be done easily - a mechanism similar to XRI's canonical
ID verification would have to be employed, to confirm that the i-
number actually 'belongs' to the URL on which discovery was
initiated. (Otherwise anyone could put any i-number in their URL-
based XRDS files.)


Public keys ... public keys ... with the added benefit that no  
centralized or trusted verification service needs to be employed  
whatsoever ...





Johannes Ernst
NetMesh Inc.


<><>
 http://netmesh.info/jernst

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

Re: Specifying identifier recycling

[Johnny Bufu]

Josh,

On 30-May-07, at 1:28 PM, Josh Hoyt wrote:

> Providers can also provide a redirect from the general form of the
> identifier to the current version of the identifier so that users do
> not need to remember or type the uniquified version. This is pretty
> much equivalent to the fragment scheme, except:
>
>   * It does not require spec changes (and is backwards-compatible!)
>
>   * The uniquifying component is user-visible
>
> I'd like to hear opinions on whether this unique-URL solution is good
> enough to solve the problem.

If Dick's original assessment on the requirements is right:

> Motivating use case:
>   For large OPs, user identifier namespace is a scarce resource and
> they need to be able to recycle human readable identifiers
>
> Design Considerations:
>
>   + Existing identifiers continue to work
>   + A human readable, memorable identifier can be entered by the user
> and displayed to other users
>   + A globally unique identifier is user by RPs that is different for
> different users of the same human readable identifier

... by pushing the uniquifying part into the displayed URL the  
displayed identifiers become unfriendly / human-unreadable.


It would be great the ones who consider identifier recycling a show  
stopper agreed that your proposal is good enough.


Johnny

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

Re: Specifying identifier recycling

[Johnny Bufu]

On 30-May-07, at 1:28 PM, Josh Hoyt wrote:

> How should the discovery process work?
> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?

Here's how I see the fragments approach working:

a) Discovery: strip the fragment from the user-supplied identifier  
before initiating discovery.

b) Auth response: if a different op-local identifier is not  
specified, the claimed identifier sans fragment MUST be used as the  
value for openid.identity.

c) Verification of discovered information against auth response fields:
strip_fragment(openid.claimed_id) == discovered claimed id
openid.identity == discovered op-local id (no change)

d) Identifying the user:
openid.claimed_id in auth response SHOULD be used as a key (no change)
strip_fragment(openid.claimed_id) MAY be used as user-visible id


 From your list of issues:

> 1. Using a URI fragment with a uniquifying value:
>
>   * Potential problems with initiation and discovery

No issues with the proposal above (but please think over and confirm!)

>   * Potential problems with inconsistent behaviours on OpenID 1 sites

OPs should send claimed IDs with fragments only for OpenID2 messages.

>   * URLs that user see may be ugly or inconsistent across sites (if
> some relying parties do and others do not strip the fragment
> before display)

Maybe enforce that fragments SHOULD NOT be used for display?

>   * There is no difference between different versions of a
> *user-displayed* identifier (users can't tell if a reference to a
> URL in the wild belongs to the current ownder of a URL or another
> user).

Not sure how RPs can be notified and then how they should act when an  
identifier gets recycled. Do we need to deal with this?

Here are three scenarios and what would happen in each case:

--

no delegation:

user-supplied id: http://example.com/user#1234
or:
user-supplied id: http://example.com/user

discovery:
claimed id = http://example.com/user
op-local id = http://example.com/user

auth request:

openid.claimed_id=http://example.com/user
openid.identity=http://example.com/user

auth response:

openid.claimed_id=http://example.com/user#1234
openid.identity=http://example.com/user

--

delegation (1):

user-supplied id=http://blog.com/
http://blog.com/  delegates to  http://op.com/user#4567

discovery:

claimed id=http://blog.com/
op-local id=http://op.com/user#4567

auth request:

openid.claimed_id=http://blog.com/
openid.identity=http://op.com/user#4567

auth response:

openid.claimed_id=http://blog.com/
openid.identity=http://op.com/user#4567

--

delegation (2):

user-supplied id=http://blog.com/#1234
http://blog.com/  delegates to  http://op.com/user#4567

discovery:

claimed id=http://blog.com/
op-local id=http://op.com/user#4567

auth request:

openid.claimed_id=http://blog.com/
openid.identity=http://op.com/user#4567

auth response:

openid.claimed_id=http://blog.com/#1234
openid.identity=http://op.com/user#4567

- a binding between http://op.com/user#4567 and the http://blog.com/ 
#1234 claimed id must be done somehow by the OP
- do we need to support this use case?

--


Johnny


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

Re: Specifying identifier recycling

[Johnny Bufu]

On 30-May-07, at 6:21 PM, Martin Atkins wrote:

> John Panzer wrote:
>>
>> Has there been a discussion about an extension to map to/from i- 
>> numbers
>> via AX?  If there were a generic attribute you could stuff an i- 
>> number
>> or a hash of an internal ID in there to help solve the disambiguation
>> problem.  Alternatively it'd be nice to have a way to ask when the
>> account was created, if the OP is amenable.
>>
>
> If you're going to use i-numbers, then there's no reason at all not to
> use the XRD CanonicalID element. The same mechanism that's used to map
> i-names onto i-numbers can also be used to map URLs onto i-numbers, or
> URLs onto other URLs.
>
> I'm sure Drummond can talk in more detail about this. We did  
> discuss it
> briefly at IIW, but once the majority had decided that the fragment
> approach was the way to go we didn't get a chance to investigate this
> further.

We did look at this (with Drummond) in December. The bottom line is  
that it can't be done easily - a mechanism similar to XRI's canonical  
ID verification would have to be employed, to confirm that the i- 
number actually 'belongs' to the URL on which discovery was  
initiated. (Otherwise anyone could put any i-number in their URL- 
based XRDS files.)


Johnny

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

Re: Specifying identifier recycling

[Martin Atkins]

John Panzer wrote:
> 
> Has there been a discussion about an extension to map to/from i-numbers 
> via AX?  If there were a generic attribute you could stuff an i-number 
> or a hash of an internal ID in there to help solve the disambiguation 
> problem.  Alternatively it'd be nice to have a way to ask when the 
> account was created, if the OP is amenable.
> 

If you're going to use i-numbers, then there's no reason at all not to 
use the XRD CanonicalID element. The same mechanism that's used to map 
i-names onto i-numbers can also be used to map URLs onto i-numbers, or 
URLs onto other URLs.

I'm sure Drummond can talk in more detail about this. We did discuss it 
briefly at IIW, but once the majority had decided that the fragment 
approach was the way to go we didn't get a chance to investigate this 
further.


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

Re: Specifying identifier recycling

[John Panzer]

At some point, the weak link will be humans trying to disambiguate 
http://joe.example.org/ from http://joe.example.org/2 (or 
http://joe.example.org/#2).  I don't think there's a big difference 
between the two in that context, and I don't think that OID2 needs to 
solve this more deeply than allowing unique-URL.  But would this be an 
additional requirement placed on OPs?

   (Query:  I assume a 302 redirect from http://joe.example.org to 
http://joe.example.org/2 will work?)

Has there been a discussion about an extension to map to/from i-numbers 
via AX?  If there were a generic attribute you could stuff an i-number 
or a hash of an internal ID in there to help solve the disambiguation 
problem.  Alternatively it'd be nice to have a way to ask when the 
account was created, if the OP is amenable.

-John

>   

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

Re: Specifying identifier recycling

[Johannes Ernst]

On May 30, 2007, at 13:28, Josh Hoyt wrote:

After thinking this over for a while, I'm no longer convinced that
using URI fragments as the uniquifying value is the right
approach.


I agree with you. Our reasons may differ slightly, but the result is  
the same.


I have no problem in not solving this problem this time around. I  
would have a problem with adding a solution to the spec that turns  
out to not be a solution after all. ;-)


Cheers,


Johannes.



Johannes Ernst
NetMesh Inc.


<><>
 http://netmesh.info/jernst

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