OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] trust profiles for XRD


On Wed, Dec 24, 2008 at 3:31 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
>
>
> Ben Laurie wrote:
>> On Thu, Dec 18, 2008 at 4:44 PM, Sakimura Nat <n-sakimura@nri.co.jp> wrote:
>>
>>> Indeed, and one of the most obvious way to mitigate the problem is to rely on a trusted registry that makes sure that it does not get reassigned to another party. Then the problem is reduced to whether you believe the operation and longevity of that registry.
>>>
>>> For example, Alice may at one time claim that alice.name belongs to her and she intents to use it as an abstract identifier for her.
>>> Then, she could obtain a cert from, say, a reputed CA called Verising. However, she cannot get it for http://alice.name/. Instead, she has to create a fragment portion as well, so that the abstract identifier would look like http://alice.name/#20081216 .
>>> Verising issues a certificate for this abstract identifer.
>>>
>>> At a later date, Alice looses alice.name. Bob gets it.
>>> To impersonate her accounts, he tries to get a cert from Verising for http://alice.name/#20081216.
>>> Verisign then checks if Bob is the same person as Alice, and finds out he is not.
>>> Then, Verising would not issue the cert. It would for something like http://alice.name/#20110303 but not http://alice.name/#20081216 .
>>>
>>
>> So, in other words, we solve the identity problem by getting somebody
>> else to solve the identity problem.
>>
>> I don't find this idea very attractive.
>>
>> If users really want identifiers that last forever, then they can buy
>> them from a domain that promises to stay around forever (for example,
>> for £500 I could get a domain in .uk for the next 100 years). I don't
>> see why we'd want to construct the spec so that the _only_ way to get
>> an identifier is through a similarly expensive process.
>>
>> By all means, though, point out that if you lose your domain, then you
>> lose your identifier.
>>
> And that's what we know as OpenID recycle problem and ID loss problem.
>
> I was suggesting one solution to that. It might be costly, but I could
> not come up with
> any better idea. If you have another solution, please let me know.
> I am very interested.

It is not actually a solution, though - it still relies on Verising
continuing to be in the ID business, and not getting the issuance
process wrong.

It seems less risky to me to buy a domain and not forget to renew it.

So, there are many possibilities, all of which should be allowed for
by the spec...

1. User doesn't care if the ID disappears when the domain does.

   1a. Because it belongs to a company and once the company stops
trading, who cares what happens to its IDs?

   1b. Because it belongs to the user, who does not intend to not renew it.

   1c. Because the user has paid for lifetime ownership of the domain,
so it doesn't disappear until the user dies.

2. A name registrar appears who will not reissue the same name to
someone else (this could be a domain name, of course, rather than a
single ID) (this is your proposal).

Of course, the type of risk is unaltered even in case 2: continuity of
the name relies on continuity of the registrar. If Verising goes bust,
or loses interest in the ID business, or you lose your ability to
prove you are you, then you lose your name still. I don't see any
interesting difference between these cases.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]