Namespaces in YADIS Capabilities Documents

[Michael Graves]

Josh Hoyt <josh <at> janrain.com> writes:

> 
> It doesn't have to be hard. If we agree to define a minimum namespace
> that consists of things that we agree on, and leave out anything
> contentious, we can make the common case easier (for the people who
> have to create authoring tools, if for no one else). I think that
> adding a namespace that specifies a username is an obvious, useful
> extension, and I don't expect that if we use XRD, there will be any
> objection to that.

I'm OK with that in principle, but am concerned that this really is one of 
those "slippery slope" situations, where we start with sso:username, and then
decide we need this, then that, then the other, and oh, by the way, several of
these services that use the same tag have completely different meanings for the
tag...

As long as a firm hand is kept on it to keep it tight, minimal, focused, I'm
fine with it. Just be ready to say "no" when the kitchen sink is presented for
inclusion.

Also, it's become clear to me that if YADIS has any success at all, it will
quickly transcend identity, and become something much broader -- what the
Liberty folks dreamed "Disco" might be, what VeriSign dreamed "LDAP" might one
day become, etc.: a generic "meta" layer for the web. I won't say more than 
that to get things off track here, but want to point out that we're wise to
keep this as general as possible, with as little "hardwiring" to identity as 
we can get away with. This understanding on my part is also what is driving my
inclination to defer on coalescing verbs and nouns in the extensions tags for
and XRD...

 
> I have no objection to allowing services that need parameters that we
> can't agree on to create their own namespaces, and I don't want to
> cause any delay in moving forward, but I think that we can come up
> with a minimal useful set of common parameters, and that having those
> parameters available will make interoperability easier. Adding a new
> service type that needs parameters that another service type already
> defines will not require designing a new namespace and will allow code
> to be shared between services that use that same namespace.
> 

OK, as above, I'm game, if we're committed to "less is more" here. A minimal
core would be fine, and quite useful for getting this off the ground. But 
let's stay away from "feature creep".
 
> I think that using the same vocabulary to talk about elements with the
> same meaning is not mapping functions together. I also fear that
> namespace fragmentation will make the XRD files appear to be more
> complicated than they are. My instincts may be wrong here, but I just
> have an automatic objection to introducing a standard where
> <openid:delegate> and <typekey:username> both must be defined even
> though they serve the same purpose.

The example you give argues both ways, I think. As I understand it, an OpenID
"delegate" is just the URI one is know by for a particular OpenID server. If I
want to log in somewhere as "http://gravesfam.com/mike/", right now I need to
use a delegate ("http://www.livejournal.com/users/michaelgraves/") as my
"username" for the LiveJournal server. So far, so good, that maps OK to the
TypeKey username. But things diverge when I actually log in successfully with
"relying party" (heh!). Depending on what the local policy of the relying party
is, I can be represented there as either my presented YADIS ID
(http://gravesfam.com/mike/) or as my delegated YADIS ID
(http://www.livejournal.com/users/michaelgraves/). 

Now, in this case, my delegate YADIS ID and my TypeKey username are not
practically equivalent; for example, the relying party cannot forward me to yet
another relying party for SSO "bliss" with my TypeKey username. It can with my
delegate YADIS ID. See the difference. That may sound like hair-splitting, 
but I think we will find that in practice, what things are semantically "the
same" is going to be much hard to find unanimity, or even consensus on then we
think it may now. If that's the case, I'm inclined to relegate that issue to 
the "chaos" bucket, and let each participating service decide for itself what
elements for various services are interchangeable and what aren't.

Which leaves me firmly undecided and equivocal on this point. For now.
 

> 
> Thanks for your practical insights and feedback. I await your report.
> 
> Josh
> 
> 

OK, so I coded up a little "builder". Go to:

http://yadis.idsandbox.com/yadis/ycd_builder

and you fill find a crude form that let's you select from an array of services
and options. When you submit the form, it renders the (possibly) appropriate 
XMLfor the Yadis Capabilities Document (YCD), aka XRD. It's been implemented in
just an evening, and my understanding of the XRDS schema is still fairly shaky
(e.g., what about <ProducerID>). 

In any case, I think you can get a feel for how complex the XML can get, and
quickly. On the other hand, this proves my hunch that a *real* "builder" along
these lines would be an enormously useful tool, especially combined with a
validator. 

This one is just a proof of concept. After building this, I have a design in my
head that would allow the user to build the YCD/XRD the right way: using a
database of "capabilites", complete with all the right attributes, etc., the
user starts from scratch, and adds capabilites from the list, one at a time.
Custom parameters can be added to capabilites, so that when a capability like
LID's "traversal" profile is added as a capability, the system will be smart
enough to let the user provide the "path" and other "traversal-specific" tags.

That won't be an after-dinner project. But check out the prototype and let me
know what you think, so I can use your feedback in working on a real, useful
"builder" for YCD/XRDs...

-Mike