openid.delegate explained.

Drummond Reed drummond.reed at cordance.net
Wed Oct 4 00:38:38 UTC 2006


Dick, the problem I tried to describe is this:

OpenID meaning of term "delegate": one URI is delegating to another URI to
be authoritative for *the first URI*.

DNS meaning of the term "delegate": one namespace authority delegating a
portion of its namespace to another namespace authority which the first
authority *does not control*.

It's a diametrically opposite meaning of who controls what. From the DNS
perspective, what OpenID is doing isn't delegation at all. It's mapping one
identifier to another -- the OpenID the equivalent of assigning a CNAME in
DNS. This DNS name = that DNS name.

It wouldn't be so bad if the meanings weren't in conflict. Unfortunately DNS
is about 10^10 more established than OpenID today. Thus the recommendation
to stop rowing against the river and adopt a term that will be more easily
understood to mean "equivalent", "maps to", or "canonical".

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Dick Hardt
Sent: Tuesday, October 03, 2006 4:52 PM
To: Marius Scurtescu
Cc: specs at openid.net
Subject: Re: openid.delegate explained.

fwiw: I was -1 on Josh's proposal. I am now a 0.

I think the name "delegate" is the right name though. It made sense  
to me right away. One URI is delegating to another URI to be  
authoritative about it. Drummonds explanation just reinforced my  
view. But perhaps I am missing something there.

-- Dick

On 3-Oct-06, at 1:41 PM, Marius Scurtescu wrote:

> I think that the proposal made by Josh makes sense.
>
> First of all, why would you hide the claimed identifier from the IdP?
> If you don't trust your IdP you should not use it. Same thing if the
> IdP tries to charge you more because you are using delegate
> identifiers. If it is unreasonable then move on (and it actually can
> be a reasonable thing to do, not sure).
>
> I can see three problems with the current scheme (adding to the
> problem highlighted by Josh):
>
> 1. It is hard to implement a stateless RP.
>
> 2. The flow can get confusing for the end user. The RP and the IdP
> are presenting different identifiers to him.
>
> 3. Bare responses will not work.
>
> A question about doing discovery on delegated identifiers. Would you
> expect the exactly same XRDS from both the claimed and delegated
> identifiers?
>
> Marius
>
> On 3-Oct-06, at 12:13 PM, Josh Hoyt wrote:
>
>> On 10/3/06, Brad Fitzpatrick <brad at danga.com> wrote:
>>> but LiveJournal.com knows jack shit about bradfitz.com ... and
>>> perhaps Brad doesn't trust LJ to know about bradfitz.com ...
>>> or fears LJ might charge more to use that feature.  etc.
>>
>> What my protocol change proposal[1] amounts to is making the IdP do
>> the work, which does change this aspect of delegation. It doesn't
>> change the "portability" of identifiers. In fact, it's a seamless
>> transition from the perspective of users, unless their IdP sucks.
>> Because OpenID is decentralized, if you're using delegation, you can
>> choose an IdP that doesn't suck (for whatever your definition of suck
>> is), so I don't think it's a real issue.
>>
>> Josh
>>
>> 1. http://openid.net/pipermail/specs/2006-September/000002.html
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs




More information about the specs mailing list