One last plea: fix problem with "delegate" terminology

[Martin Atkins]

Drummond Reed wrote:
> 
> However, in the two months since I last had that conversation, I've had to
> explain the concept of "OpenID delegate" to a bunch more people, and I'm
> telling you, STICKING WITH THIS TERMINOLOGY IS GOING TO BITE OPENID IN THE
> BUTT!!
> 
> The problem is: the more OpenID grows, the more folks who are familiar with
> mainstream identifier systems like DNS are going to be exposed to it, and
> the more they are going to go bananas trying to figure out what OpenID means
> by this term "delegate" when essentially the OpenID meaning is the exact
> opposite of what everyone else in the naming world means by it.
> 

I propose simply that openid:Delegate becomes openid:Identifier. This is 
actually a variation on my early proposal for then OpenID bindings for 
Yadis, where I intentionally avoided using the "delegate" terminology.

    <Service priority="50">
     <Type>http://openid.net/signon/1.1</Type>
     <URI>http://www.whatever.com/openid</URI>
     <openid:Identifier>http://mart.whatever.com/</openid:Identifier>
    </Service>

Perhaps I should have made this more explicit at the time, but my 
thinking here was to separate "the identifier I present to the RP" from 
"the identifier I present to my IdP".

This does change the mental model a bit, but it also makes it more 
consistent and thus, to my mind, easier to wrap your head around. I 
suspect it'd also be easier to explain in the spec. The implementation 
remains the same, of course.

I find this model fits a lot better than the delegation model. In 
particular, it's not possible to cascade "delegations" — that is, you 
can't delegate to another identifier which itself delegates to a third. 
This confused me in the early days. If you think instead of the URI here 
being a "login" for the named IdP, suddenly everything seems to make 
more sense.

Backward-compatibility isn't of great concern here since OpenID 2 is 
presumably going to have its own Yadis service type anyway, so those 
supporting both will need to list both 1.1 and 2.0 Service elements, 
which don't necessarily have to be the same.