YADIS as an abstraction layer

[Martin Atkins]

(This is a big 'un. Sorry!)

I see YADIS fundamentally as an abstraction layer behind which a variety
of services can be hidden. It allows software rather than the user to
worry about the distinction between the various different things going
on "under the hood".

Given that viewpoint, YADIS can be reduced to the following:

* A document format for describing the capabilities available at a given
identity endpoint (URL) and how to make use of them.

* A convention for how to auto-discover the capability document.

That is really all there is to it. Therefore there really is no such
thing as a "YADIS server". As I proposed in my previous thread, the
server and identity sides of YADIS require no specialist software at
all. It is only on the consumer side that changes are necessary.

---------------------------------------

Taking it all down to it's bare essentials then, we can do this as follows:

* User enters an identity URL into some kind of consumer software. (Not
necessarily signon.)

* Consumer requests the identity URL with a particular, standard entry
in the HTTP "Accept" header marked at the highest preference.

* The response is either:
    * a capability description document, in the case where either the
    user gave the URL to a static capability document or some kind of
    content negotiation caused the Accept header to be honoured
    * an HTML document containing a LINK element pointing to a
    capability description document. In this case, the consumer
    must go off and fetch the given URL instead.

* The capability description document lists all of the capabilities
supported by the identity URL and enough information for a supporting
consumer to make use of them. The syntax of this document is not
important at this stage, so I'll just go on using something similar to
the current meta-identity format as an example...

capability: http://openid.net/signon
version: 1.0
server: http://www.livejournal.com/openid/server.bml
delegate: http://john.livejournal.com/

capability: http://lid.netmesh.org/sso
version: 1.0,2.0
identity: http://lid.netmesh.org/liddemouser/

capability: http://www.typekey.net/login
version: 0.9
username: johnno

capability: http://lid.netmesh.org/profile
version: 0.9
identity: http://lid.netmesh.org/liddemouser/

capability: http://www.payfriend.com/givemecash
version: 0.8
username: john_moneybags

* The consumer app can determine from this whether the given identity
URL is capable of supporting whatever operation it wants to perform and,
if so, the parameters necessary to make the transaction. What happens
next is outside of the scope of YADIS.

Now the user can hide a bunch of services handled by a plethora of
different providers behind a single identifier, which happens to be a
URL. Most users would have even this phase provided for them in a
similar sense to how LiveJournal users have been provided with an OpenID
identity, but it's also very easy to host this yourself while still
having all of the tricky stuff done by another entity.

You are free to change your provider for each service at will without
affecting the identity URL that you present to the world. Services that
are not based apon URLs are supported alongside URL-based ones, with the
end-user providing their single identity URL in place of, for example,
their TypeKey username.

Some things that are not directly supported by this approach:
* In the case of profile exchange, what if some of my profile data is
provided by one service and some provided by another? I imagine people
could come up with similar scenarios for other use cases.
* There is no allowance for a consumer to specify the kind of
capabilities that it is interested in. If this thing gets as popular as
everyone is hoping, they may be hundreds or thousands of different
capabilities, so the descriptor document would get pretty big; at that
point, it would be useful for a consumer to be able to ask "What signon
protocols do you support?" rather than retrieving the entire list.
* The use of more human-friendly identifiers. I'm new to all of this XRI
business, but from what I understand they can be mapped resolved into
URLs somehow, so they may later provide a suitable human-friendly layer
on top of the URL based identifier.

--------------------------------------

I've made the following changes to YADIS as currently specced:
* The capability document is (can be) just a static document on your
website.
* The endpoints for the declared services are configurable rather than
assumed to be the same as the capability document.
* The trick of requesting with ?meta=identity to as a hint to provide a
capability document has been replaced with the use of the HTTP Accept
header, which is less likely to conflict with existing applications at
the identity URL and can be implemented using the content negotiation
capabilities in Apache. The indirection through HTML is still provided
for those who are unable to switch based on the Accept header.
* The delegation functionality, which is pretty specific to OpenID
anyway, is now in the capability file rather than in the HTML document.
YADIS is acting as a delegation layer anyway, so there's no need for
this as a core feature.
* I'm ignoring all of the profile exchange stuff, since I don't think
that has any place in YADIS. It is just another capability.

---------------------------------------

How does that grab you all?