OpenID 1.2 Extensions Proposal
cygnus at janrain.com
Wed Apr 5 18:24:45 UTC 2006
# But let's assume somebody now extends A with C. Do we get this,
If you "extend A with C", you have a new extension, D, not A+C.
# 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. 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 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.
# I think you feel uncomfortable just using the plain XRDS file
# because you do not see how you can express "B cannot be used without
# A" (aka "B is an extension of A", or "B depends on A").
What is "plain XRDS file" (and, conversely, what is non-"plain XRDS
# What about, then, extending XRDS to be able to express those
# dependencies instead of creating a Service-specific extensions
What sort of XRDS extension are you thinking about?
More information about the yadis