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 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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
