openid.delegate explained.

Drummond Reed drummond.reed at cordance.net
Wed Oct 4 02:11:25 UTC 2006


Dick,

I'm afraid we just disagree on this.

You cite the Google definition, which is the general English-language
meaning of the term. 

I cite the Wikipedia definition from the DNS entry:

"When a system administrator wants to let another administrator control a
part of the domain name space within his or her zone of authority, he or she
can *delegate* control to the other administrator. This splits a part of the
old zone off into a new zone, which comes under the authority of the second
administrator's nameservers. The old zone becomes no longer authoritative
for what comes under the authority of the new zone."

You say, "I don't think the use of delegation within DNS is that widely
known."

I've cited in several messages my direct experience trying to describe the
OpenID concept of "delegate" (which applies to identifiers) to folks in the
identifier space and having them thoroughly confused. After all, if an
OpenID identifier is a URL, it *uses* DNS.

Futhermore, the website and network administrators that are going to need to
understand the OpenID identifier trust model are absolutely *steeped* in
DNS.

Have you never run into that problem?

Has anyone else on the list never run into that problem?

=Drummond 

-----Original Message-----
From: Dick Hardt [mailto:dick at sxip.com] 
Sent: Tuesday, October 03, 2006 6:12 PM
To: Drummond Reed
Cc: 'Marius Scurtescu'; specs at openid.net
Subject: Re: openid.delegate explained.

Ok, I understand now your explanation now.

1) I'm don't think the use of delegation within DNS is that widely  
known.

2) Google defines delegate:

- transfer power to someone
- a person appointed or elected to represent others

I think this definition maps well for what we mean by delegate.

-- Dick

On 3-Oct-06, at 5:38 PM, Drummond Reed wrote:

> 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