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

2007-06-05 Thread 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 link rel='me' / 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 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 

RE: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Recordon, David
Since it seems no one has replied yet, I'd agree that this would make
implementations easier.  Iterating via a regular expression seems ugly
and hard to do (well except in Perl). :-\

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Monday, April 30, 2007 12:48 PM
To: specs@openid.net
Subject: Auth 2.0 Extensions: Namespace Prefixes


As currently defined, an extension has a global namespace URI as well as

a request-local alias/prefix. For an extension with the namespace 
http://example.com/blah that has a field foo, the following fields are

to be sent:

 openid.ns.blah=http://example.com/blah
 openid.blah.foo=bar

It seems to me that the only way to discover the extension namespaces 
used in a particular message is to iterate over all keys looking for 
openid.ns.(\w+) and then see if the value matches.

This seems ugly since usually webapps deal with such arguments as a 
dictionary structure, and use dictionary dicipline while interrogating 
the values.

If we added an extra field:
 openid.extensions=blah,sreg,ax

then the extensions used in a message would be accessible by splitting 
that field on its commas and then accessing openid.ns.whatever for each
one.

It's still not ideal, of course; it'd be better if the full namespace 
URI were included in the key part of a (key,value) pair, but many 
frameworks[1] can't deal with wacky punctuation characters in the key.




[1] I'm looking at you, PHP.

___
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: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Granqvist, Hans
But it seems superflous: Since you cannot depend on args to
be ordered[1], you'll still need to iterate and match prefix
to values.

Also, any change adds complexity: You'll need to specify 
semantics to what happens if the list of extensions is
not there, or if it is incorrect, or if you use extensions
without declared namespaces, etc.

But if it still is needed, I'd propose, since the list of 
extensions is meta info, it should itself be an extension. 

 openid.ns.ext=some:fixed:uri
 openid.ext.namespaces=ns1,ns2,ns3
 openid.ns1.foo=...
 openid.ns1.bar=...
 openid.ns2.foo=...

This makes processing cleaner and it also makes it possible 
for future specification of extensional behavior (sounds 
very Sartre ;)

 openid.ext.policy=...
 openid.ext.foo=...


-Hans

[1] I'm looking at you HttpServletRequest.getParameterMap()

-Original Message-
From: [EMAIL PROTECTED] on behalf of Recordon, David
Sent: Tue 6/5/2007 8:00 AM
To: Martin Atkins; specs@openid.net
Subject: RE: Auth 2.0 Extensions: Namespace Prefixes
 
Since it seems no one has replied yet, I'd agree that this would make
implementations easier.  Iterating via a regular expression seems ugly
and hard to do (well except in Perl). :-\

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Atkins
Sent: Monday, April 30, 2007 12:48 PM
To: specs@openid.net
Subject: Auth 2.0 Extensions: Namespace Prefixes


As currently defined, an extension has a global namespace URI as well as

a request-local alias/prefix. For an extension with the namespace 
http://example.com/blah that has a field foo, the following fields are

to be sent:

 openid.ns.blah=http://example.com/blah
 openid.blah.foo=bar

It seems to me that the only way to discover the extension namespaces 
used in a particular message is to iterate over all keys looking for 
openid.ns.(\w+) and then see if the value matches.

This seems ugly since usually webapps deal with such arguments as a 
dictionary structure, and use dictionary dicipline while interrogating 
the values.

If we added an extra field:
 openid.extensions=blah,sreg,ax

then the extensions used in a message would be accessible by splitting 
that field on its commas and then accessing openid.ns.whatever for each
one.

It's still not ideal, of course; it'd be better if the full namespace 
URI were included in the key part of a (key,value) pair, but many 
frameworks[1] can't deal with wacky punctuation characters in the key.




[1] I'm looking at you, PHP.

___
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


Generalized solution to OpenID recycling (was RE: The WordPress User Problem)

2007-06-05 Thread =drummond.reed

David Recordon wrote:

snip of explanation of problems with fragment solution to OpenID recycling

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 link rel='me' / 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, first I just want to point out that XRI i-numbers are no more
centralized than DNS, so I don't think there's any difference between #2
and #3 other than #2 uses XRI registries and #3 uses DNS registries.

Second, I agree with you that the better architectural approach to the
OpenID recycling problem is to provide a standard reassignable-to-persistent
synonym mapping capability that will work for both URLs and XRIs (and even
URNs). This solves the problem by allowing *any* reassignable identifier
(either a URL, or an XRI i-name) to be mapped to *any* persistent identifier
(either a persistent URL, an XRI i-number, or even a resolvable URN). 

The fragment solution is in fact just a special case of this architecture,
i.e., it maps a URL-without-a-fragment (reassignable) to
the-same-URL-with-a-fragment (persistent). It does have some special issues
due to the use of URL fragments vs. other components of a URI, but otherwise
it is just one option that could be implemented to map a reassignable to a
persistent identifier.

As Martin has pointed out, the purpose of the CanonicalID element in XRDS is
to support reassignable-to-persistent identifier mapping. Although this is a
native function of XRI resolution (because XRI architecture was explicitly
designed to address the reassignable-to-persistent synonym mapping problem
and thus has explicit syntax for reassignable and persistent identifiers),
there is nothing to prevent CanonicalID mapping from being done with URLs.
Discussion on this thread so far has only entertained using this mechanism
to handle reassignable-URL to persistent-XRI mapping, however there's
nothing to prevent it being used for reassignable-URL to persistent-URL
mapping, or even reassignable-URL to persistent-URN mapping (as long as the
URN is resolveable, such as a Handle ID).

Everything is already in place in XRDS architecture except the Canonical ID
verification rules. The OASIS XRI TC has already published the
reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the
first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed
explanation of those rules will be in the second editor's draft due out
tomorrow). Per Martin's suggestion, in the second editor's draft will also
add the Canonical ID verification rules for
reassignable-URL-to-persistent-XRI mapping.

I see no reason we can't add the rules for
reassignable-URL-to-persistent-URL mapping as well, since it's simply a
matter of the RP confirming that the persistent identifier is also
authoritative for the XRDS.

If we approached it this way, all the OpenID Authentication 2.0 spec would
need to do is specify the use of Canonical ID verification as part of the
OpenID discovery process, and then everyone -- users, OPs, and RPs, would be
able to use any
reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping
process that worked best for them.

Thoughts?

=Drummond

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


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

2007-06-05 Thread 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 link rel='me' / 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) We use public/private key pairs, though this has the 

Re: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Josh Hoyt
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote:
 Since it seems no one has replied yet, I'd agree that this would make
 implementations easier.  Iterating via a regular expression seems ugly
 and hard to do (well except in Perl). :-\

-1. It's one more thing to get wrong. There would then be the case
where an extension had a namespace alias declaration but was missing
from that list, or was in that list but did not have a namespace alias
declaration.

Iterating one time to build a lookup table is easy, and you get the
namespace URIs out of that one iteration.  It doesn't take regular
expressions (it's just a prefix match), and I've never used a language
that would make this kind of iteration difficult.

Each technique implemented in Python for comparison:

prefix = openid.ns.
prefix_len = len(prefix)

def extractNamespaceAliases(query):
Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.

This code implements the current draft of the OpenID 2.0
specification. Very straightforward.


namespace_aliases = {}

for k, v in query.iteritems():
if k.startswith(prefix):
alias = key[prefix_len:]
namespace_aliases[alias] = v

return namespace_aliases

def extractNamespaceAliases1(query):
Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.

This version implements the proposal in this thread. The code has
more branches and has to build new strings as lookup keys.

namespace_aliases = {}

namespace_string = query.get('openid.extensions')

# Ignore missing or empty openid.extensions parameter
if namespace_string:
aliases = namespace_string.split(',')

for alias in aliases:
try:
namespace_aliases[alias] = query[prefix + alias]
except KeyError:
pass # Ignore declared but missing extensions

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


Re: Generalized solution to OpenID recycling (was RE: The WordPress User Problem)

2007-06-05 Thread Martin Atkins
=drummond.reed wrote:
 
 As Martin has pointed out, the purpose of the CanonicalID element in XRDS is
 to support reassignable-to-persistent identifier mapping. Although this is a
 native function of XRI resolution (because XRI architecture was explicitly
 designed to address the reassignable-to-persistent synonym mapping problem
 and thus has explicit syntax for reassignable and persistent identifiers),
 there is nothing to prevent CanonicalID mapping from being done with URLs.
 Discussion on this thread so far has only entertained using this mechanism
 to handle reassignable-URL to persistent-XRI mapping, however there's
 nothing to prevent it being used for reassignable-URL to persistent-URL
 mapping, or even reassignable-URL to persistent-URN mapping (as long as the
 URN is resolveable, such as a Handle ID).
 
 Everything is already in place in XRDS architecture except the Canonical ID
 verification rules. The OASIS XRI TC has already published the
 reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the
 first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed
 explanation of those rules will be in the second editor's draft due out
 tomorrow). Per Martin's suggestion, in the second editor's draft will also
 add the Canonical ID verification rules for
 reassignable-URL-to-persistent-XRI mapping.
 
 I see no reason we can't add the rules for
 reassignable-URL-to-persistent-URL mapping as well, since it's simply a
 matter of the RP confirming that the persistent identifier is also
 authoritative for the XRDS.

I think that URL-to-URL is more useful in the short term, because 
(unless something's changed since we last talked) you can't currently 
get an i-number without purchasing an i-name.

This does, however, raise a transitional issue: as soon as providers 
start publishing CanonicalID, all of the existing accounts are 
effectively broken because the primary key is being changed.[1]

If LiveJournal were to suddenly start publishing in the XRDS for 
http://frank.livejournal.com/ that the CanonicalID were 
http://www.livejournal.com/u/3449 (for example) frank would lose his 
account on any site he had already been using.

For this to work out, RPs would have to change to retaining a list of 
synonyms rather than simply keying off the CanonicalID, but then that 
defeats the object of creating the ability for identifiers to be recycled.

The only solution which springs immediately to mind is to get all of the 
big OP players to implement this and then have the burden be on RPs to 
handle the migration from the old display identifiers to the new 
CanonicalIDs as they transition from 1.1 to 2.0. This only works if 
things are changed in a particular order, though.

I'm attracted to the cleanliness of using the same CanonicalID mechanism 
for both URLs and XRIs and any combination of the pair, but unless the 
above can be resolved I don't think it's workable.

[1] This issue exists for the fragment approach too, but with the 
obvious solution that you simply don't starting appending a fragment 
until an identifier enters its second generation. This solution is not 
appropriate for CanonicalID because it has more broad semantics than 
simply identifying the generation number of the identifier.


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


Re: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Martin Atkins
Johnny Bufu wrote:
 On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
 
 But it seems superflous: Since you cannot depend on args to
 be ordered[1], you'll still need to iterate and match prefix
 to values.
 Martin's proposal seems like a minor improvement to me - iterating  
 thorough openid.ns.* or splitting the value of openid.extensions and  
 then iterating through the result seems roughly equivalent.
 
 Our implementation builds a map of extension aliases to namespaces  
 when a message is received and after that, at any point during the  
 life cycle of that message, extensions queries are  simple and quick  
 map lookups.
 
 So I'd rather not add the openid.extension field.
 

For what it's worth, I'm no longer in favour of my own proposal. :)

It was ill-thought-out and does not solve the problem I set out to solve.

My intention was to create a situation where the question of Is 
extension x used in this request requires a single dictionary lookup, 
which the extensions field does not solve.

Since that is not really workable without moving away from the use of 
URIs to identify extensions, I'm happy to accept this small wart for the 
sake of keeping things sane and simple.


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


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

2007-06-05 Thread 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: Generalized solution to OpenID recycling (was RE: The WordPress User Problem)

2007-06-05 Thread Johnny Bufu
Hi Drummond,

On 5-Jun-07, at 9:44 AM, =drummond.reed wrote:

 I see no reason we can't add the rules for
 reassignable-URL-to-persistent-URL mapping as well, since it's  
 simply a
 matter of the RP confirming that the persistent identifier is also
 authoritative for the XRDS.

 If we approached it this way, all the OpenID Authentication 2.0  
 spec would
 need to do is specify the use of Canonical ID verification as part  
 of the
 OpenID discovery process, and then everyone -- users, OPs, and RPs,  
 would be
 able to use any
 reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping
 process that worked best for them.

Not knowing how you plan to have the canonical ID verification for  
URLs (really looking forward to reading tomorrow's draft), I'm not  
sure it's a simpler approach or even a generalization of the fragment  
proposal.

Yes, it would be simpler to specify in the OpenID spec, but it would  
include a pointer to a section of the XRI spec, which scares so many  
people away.

 From your comments I understand that the persistent identifier has  
to be discoverable; in the fragment approach, the fragment itself  
(which is the actual persistent part) is stripped out at  discovery  
time, and only comes into play at the auth response / verification  
stages (hence not sure the generalization applies).

Keying your identity on a new / different URL also brings in the  
management effort required to maintain that second, persistent URL  
(and making sure it stays persistent). If that is an absolute URL,  
the cost is considerably higher than just keeping track of your  
persistent fragment. (In this respect the fragment approach is simpler.)


Johnny

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


RE: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Granqvist, Hans
On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:

 But it seems superflous: Since you cannot depend on args to
 be ordered[1], you'll still need to iterate and match prefix
 to values.
Martin's proposal seems like a minor improvement to me - iterating  
thorough openid.ns.* or splitting the value of openid.extensions and  
then iterating through the result seems roughly equivalent.

Fair enough.

I guess the question is:

Is the cost of semantical additions (as I outlined) worth such a minor 
improvement in processing?

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


Re: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Johnny Bufu

On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:

 But it seems superflous: Since you cannot depend on args to
 be ordered[1], you'll still need to iterate and match prefix
 to values.
Martin's proposal seems like a minor improvement to me - iterating  
thorough openid.ns.* or splitting the value of openid.extensions and  
then iterating through the result seems roughly equivalent.

Our implementation builds a map of extension aliases to namespaces  
when a message is received and after that, at any point during the  
life cycle of that message, extensions queries are  simple and quick  
map lookups.

So I'd rather not add the openid.extension field.

Johnny

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


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

2007-06-05 Thread 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 identifierrecycling)

2007-06-05 Thread =drummond.reed
Josh Hoyt 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. 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).

Isn't this a core flaw with the fragment approach? That if you lose control
of the base identifier, you lose control of any fragment?

Wouldn't it be fairly easy -- precisely because the fragment is not secret
-- for the party that takes over the base identifer to discover the
fragment(s) that have been used earlier, and thus for the new owner to then
be able to spoof any fragment that has been issued?

I supposed this doesn't apply to large sites, where all identifiers are
managed in trust for users and they can enforce non-access to previous
fragments. But for personal URLs it doesn't appear to work at all. Am I
missing anything?

=Drummond 

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


Re: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread Josh Hoyt
On 6/5/07, Drummond Reed [EMAIL PROTECTED] wrote:
 I supposed this doesn't apply to large sites, where all identifiers are
 managed in trust for users and they can enforce non-access to previous
 fragments. But for personal URLs it doesn't appear to work at all. Am I
 missing anything?

Enabling recycling for large sites that control their own identifiers
was the use case that was declared mandatory to cover for the OpenID
2.0 specification. I would personally like to have a solution that
protects identifiers without a central manager, but that is not the
case that is holding up OpenID 2.0.

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


RE: Generalized solution to OpenID recycling (was RE: The WordPressUser Problem)

2007-06-05 Thread =drummond.reed

 =drummond.reed wrote:
 
 As Martin has pointed out, the purpose of the CanonicalID element in XRDS
is
 to support reassignable-to-persistent identifier mapping. Although this
is a
 native function of XRI resolution (because XRI architecture was
explicitly
 designed to address the reassignable-to-persistent synonym mapping
problem
 and thus has explicit syntax for reassignable and persistent
identifiers),
 there is nothing to prevent CanonicalID mapping from being done with
URLs.
 Discussion on this thread so far has only entertained using this
mechanism
 to handle reassignable-URL to persistent-XRI mapping, however there's
 nothing to prevent it being used for reassignable-URL to persistent-URL
 mapping, or even reassignable-URL to persistent-URN mapping (as long as
the
 URN is resolveable, such as a Handle ID).
 
 Everything is already in place in XRDS architecture except the Canonical
ID
 verification rules. The OASIS XRI TC has already published the
 reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the
 first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more
detailed
 explanation of those rules will be in the second editor's draft due out
 tomorrow). Per Martin's suggestion, in the second editor's draft will
also
 add the Canonical ID verification rules for
 reassignable-URL-to-persistent-XRI mapping.
 
 I see no reason we can't add the rules for
 reassignable-URL-to-persistent-URL mapping as well, since it's simply a
 matter of the RP confirming that the persistent identifier is also
 authoritative for the XRDS.

I think that URL-to-URL is more useful in the short term, because 
(unless something's changed since we last talked) you can't currently 
get an i-number without purchasing an i-name.

XDI.org is planning to change that policy. Also, effective June 1, the
wholesale annual price of personal i-names is USD $5, and personal i-numbers
is USD $1.

This does, however, raise a transitional issue: as soon as providers 
start publishing CanonicalID, all of the existing accounts are 
effectively broken because the primary key is being changed.[1]

If LiveJournal were to suddenly start publishing in the XRDS for 
http://frank.livejournal.com/ that the CanonicalID were 
http://www.livejournal.com/u/3449 (for example) frank would lose his 
account on any site he had already been using.

For this to work out, RPs would have to change to retaining a list of 
synonyms rather than simply keying off the CanonicalID, but then that 
defeats the object of creating the ability for identifiers to be recycled.

The only solution which springs immediately to mind is to get all of the 
big OP players to implement this and then have the burden be on RPs to 
handle the migration from the old display identifiers to the new 
CanonicalIDs as they transition from 1.1 to 2.0. This only works if 
things are changed in a particular order, though.

I agree that migration of RPs is necessary (it seems necessary for any
solution to the OpenID recycling issue), but is order really a problem?
Isn't it just the following sequence of migration steps:

1) RP today uses only Table #1 of reassignable OpenID identifiers (and so is
vulnerable to OpenID recycling issue).

2) When RP upgrades to OpenID libraries supporting mapping to Canonical IDs,
RP creates Table #2 (Canonical ID table) to go alongside current Table #1
(reassignable OpenID identifier table).

3) Until an RP discovers a Canonical ID for an OpenID user, RP continues to
use Table #1.

4) As RP discovers Canonical ID value for an OpenID user, RP starts
populating Table #2, now protecting each user in Table #2 from OpenID
recycling problem.

The result would be a smooth migration of the RP from supporting only
reassignable OpenIDs to supporting Canonical IDs. Note that this two-table
approach is documented on the dev.inames.net site at:

http://dev.inames.net/wiki/Tech_FAQs#What_are_the_recommended_modifications_
OpenID_Relying_Parties_.28RPs.29_should_make_to_their_user_tables.3F 

I'm attracted to the cleanliness of using the same CanonicalID mechanism 
for both URLs and XRIs and any combination of the pair, but unless the 
above can be resolved I don't think it's workable.

[1] This issue exists for the fragment approach too, but with the 
obvious solution that you simply don't starting appending a fragment 
until an identifier enters its second generation. This solution is not 
appropriate for CanonicalID because it has more broad semantics than 
simply identifying the generation number of the identifier.

Agreed. But I'm with you that these broader semantics are well worth it
because, as pointed out earlier, the fragment approach only works in the
limited set of cases where you can trust the identifier authority issuing
the fragment never to reassign it. The Canonical ID mapping approach works
for all combinations of persistent and reassignable identifiers, i.e., the
user has their choice of both.

=Drummond 



Questions about IIW Identifier Recycling Table

2007-06-05 Thread David Fuelling

I wasn't at IIW, so please bear with me.

In reference to the wiki at
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can somebody
clarify what some of the terminology means?  Specific questions are below.

1.) For URL+Fragment, what is the distinction between private and
public?

2.) Ditto For URL+Token (I assume this means a public vs. private token?)

3.) What does DE mean in the Does not require change to DE?

4.) In the Stolen OP account header, it appears that all 4 of the proposed
methods have problems.  However do we really want an identifier to be
recycled if an account is stolen ( i.e., what if an account is only stolen
for a brief period, but then recovered?)

4.) What is Active Recycling?

5.) In the New DB Field header, doesn't an OP/RP need a new DB field in
the fragment scheme, in order to distinguish between the id and the current
fragment?  Or does the OP/RP simply store the whole URL (fragment included)
and parse as necessary?

6a.) What is MO in MO Strip Fragment?

6b.) What does the MO Strip Fragment header mean in general?



Thanks!

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


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

2007-06-05 Thread 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:

 a href=http://josh.example.com/#this-is-intended-for-machine- 
 consumption
  http://josh.example.com//a

 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)

2007-06-05 Thread 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:

 a href=http://josh.example.com/#this-is-intended-for-machine-
 consumption
  http://josh.example.com//a

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

2007-06-05 Thread =drummond.reed
David, just want to reinforce that the CanonicalID element in XRDS has
always been defined as containing anyURI, so it's been there to support
mapping of any reassignable identifier to any persistent identifier (or,
technically, any canonical identifier, even if not persistent, though
persistence is the main use case for it).

I'm happy to help with the writeup -- I've already spent a not-insignificant
portion of my lifespan dealing with this issue ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Tuesday, June 05, 2007 3:50 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject: RE: The WordPress User Problem (WAS: RE: Specifying
identifierrecycling)

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:

 a href=http://josh.example.com/#this-is-intended-for-machine-
 consumption
  http://josh.example.com//a

 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

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


RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread Recordon, David
Yes, I think this would be worthwhile to write-up.

--David 

-Original Message-
From: =drummond.reed [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 05, 2007 4:55 PM
To: Recordon, David; 'Johnny Bufu'
Cc: 'OpenID specs list'
Subject: RE: The WordPress User Problem (WAS: RE: Specifying
identifierrecycling)

David, just want to reinforce that the CanonicalID element in XRDS has
always been defined as containing anyURI, so it's been there to support
mapping of any reassignable identifier to any persistent identifier (or,
technically, any canonical identifier, even if not persistent, though
persistence is the main use case for it).

I'm happy to help with the writeup -- I've already spent a
not-insignificant portion of my lifespan dealing with this issue ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Tuesday, June 05, 2007 3:50 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject: RE: The WordPress User Problem (WAS: RE: Specifying
identifierrecycling)

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:

 a href=http://josh.example.com/#this-is-intended-for-machine-
 consumption
  http://josh.example.com//a

 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

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


RE: Specifying identifier recycling

2007-06-05 Thread =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: Specifying identifier recycling

2007-06-05 Thread =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
 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