OpenID 1.2 Extensions Proposal

[Drummond Reed]

Whew, miss a day and look how the threads pile up.

This issue of service dependencies (I'm ducking the issue of defining an
"extension" and just taking the simple approach of saying that one service
extends another if it depends on the first one to do its job) has been dealt
with extensively in the web services definition world, because it's a pretty
common case.

I don't, unfortunately, have the benefit of that all experience to apply
here, although others on the list like Gabe might have experience there that
they can share. However I am aware of one pattern developed in that work
that we might be able to use at the XRDS level to solve this problem in a
generic way (and I agree with Johannes that a good generic solution to
service dependencies would benefit Yadis as a simple service discovery
protocol much more than a service-specific solution).

The pattern is just to use a Requires element as a child of Service, and
express all dependencies uniformly in this manner. For example, the
following is how you would express that OpenID 1.0 Extension A 1.0 requires
OpenID Signon Service 1.2:

   <Service priority="20">
     <Type> http://openid.net/extensions/A/1.0</Type>
     <URI>http://www.myopenid.com/server</URI>
     <Requires> http://openid.net/signon/1.2</Requires>
   </Service>

Besides being very lightweight, it also allows you to chain dependencies as
deeply as you need to. For example, if OpenID 1.0 Extension B 1.0 requires
OpenID Extension A 1.0, you would simple add the following Service element:

   <Service priority="20">
     <Type> http://openid.net/extensions/B/1.0</Type>
     <URI>http://www.myopenid.com/server</URI>
     <Requires> http://openid.net/extensions/A/1.0</Requires>
   </Service>

An XRDS parser can quickly determine by looking at this Service block that
OpenID Extension B 1.0 requires OpenID Extension A 1.0, and then from the
previous Service block that OpenID Extension A 1.0 requires OpenID Signon
Service 1.2

=Drummond 

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Jonathan Daugherty
Sent: Wednesday, April 05, 2006 11:25 AM
To: Johannes Ernst
Cc: yadis at lists.danga.com
Subject: Re: OpenID 1.2 Extensions Proposal

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

# 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
reality.

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
file")?

# What about, then, extending XRDS to be able to express those
# dependencies instead of creating a Service-specific extensions
# mechanism?

What sort of XRDS extension are you thinking about?

-- 
  Jonathan Daugherty
  JanRain, Inc.