OpenID 1.2 Extensions Proposal

[Johannes Ernst]

On Apr 5, 2006, at 11:24, Jonathan Daugherty wrote:

> # But let's assume somebody now extends A with C. Do we get this,
> # then?
>
> If you "extend A with C", you have a new extension, D, not A+C.

Why? Let's say I'm extending your sreg proposal with an additional  
data field type, say "blood type", because I run a medical site and I  
could offer more customized content if I knew your blood type in  
addition to the other registration information you defined already --  
entirely optional, of course. Then everything that supports sreg  
supports my site, but if they, in addition, also support the blood  
type, they get better content.

In my mind, "blood type" is an extension of the sreg extension, not a  
separate extension, and I don't see why "sreg + blood type" would  
form an entirely new extension either as you seem to be saying.

> # Also note that this hierarchical scheme does not allow you to say
> # "Here is an extension C, and it depends on *both* A and B".
>
> Agreed, but I don't expect (or want) anyone to "extend extensions" in
> this way.

This is the slippery slope of ad-hoc extension formats. You may not  
expect or want anybody to do that, but then, others may want to do  
exactly that, and a zillion other things that will break the  
assumptions behind a typical ad-hoc extension. (at least that's my  
experience over so many years)

As a reminder: the reason we have a well-thought-out, well-reviewed  
format like XRDS is that we want to get away from custom hacks of  
specifying composition of pieces defined in different places. (I  
think that is also the argument of others on the list who have chimed  
in.) So far I have not heard an argument from you what piece of  
information you cannot express within the standard XRDS file format,  
and thus why you believe you need to extend it.

As an example, the openid:Delegate piece of information is clearly  
needed, and clearly not available in XRDS, for good reasons, thus an  
extension was entirely appropriate.

I don't think you would argue that the Service element cannot capture  
what you want to express? (or do you?) See also strawman proposal below.

To be clear, I'm not opposed to extended XRDS when necessary, but in  
my view, the hurdle for doing so should be very very high --  
otherwise there is not much of a point of agreeing on the same format  
in the first place, because the tower of babel is now within the same  
XML format instead of with different discovery mechanisms, and not  
much progress would have been made.

>   I wouldn't create a plugin for a plugin for the same
> reason.  If you want a new behavior, create a new extension.  Besides:
> at this level of granularity, I don't think the XRDS is the right
> place to specify these relationships *at all*.  Whether my extension
> depends on Bob's is something I should specify in my extension spec,
> and it's something that users of my extension should therefore know
> about.  If you allow these dependencies to be *generally* specified in
> the XRDS, I guarantee you that at some point they won't align with
> reality.

I happen to agree with you -- but then you need to admit that the  
idea of creating a new XML tag that allows you to represent "sreg is  
an extension of OpenID and not of something else"  is inherently  
flawed, regardless of how it is expressed ;-)

> I do agree that it's possible that someone will want to express these
> dependencies at some point, but in the OpenID context I don't see it
> happening (well, not if you buy what I am saying about OpenID
> extensions).  If and when LID needs to, <Service> elements for LID can
> choose to do that however seems best for LID.

We have tons of dependencies in LID -- for example, VCard profile  
queries can only be performed if the Traversal and Selection profile  
is present, just like sreg only works if OpenID is present. We  
represent both of them as separate entries in the XRDS file, and that  
works just fine.

> What is "plain XRDS file" (and, conversely, what is non-"plain XRDS
> file")?

I used 'plain' as an alias for 'not extended'.

[[And I was about to write about how this could be folded into the  
XRDS format as a general mechanism, when I saw Drummond's e-mail that  
actually proposes something better than I just would have ... so I  
defer to his e-mail on the list.]]


Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060405/6e0f94d5/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst