OpenID 1.2 Extensions Proposal
jernst+lists.danga.com at netmesh.us
Wed Apr 5 19:52:47 UTC 2006
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
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
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.]]
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060405/6e0f94d5/lid-0001.gif
-------------- next part --------------
More information about the yadis