openid.delegate explained.

[Dick Hardt]

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