Implementing YADIS with no new software

[Drummond Reed]

Hi, I'm just joining the list after the discussions of YADIS last week at
the Internet Identity Workshop
(https://www.socialtext.net/iiw2005/index.cgi). 

At the workshop, we had a session in which the OASIS XRI folks discussed
with the LID folks and OpenID folks (specifically Johannes and Brad and
David) using the OASIS XRI Descriptor document format for YADIS capabilities
description.

This seemed to make sense because XRIs (http://en.wikipedia.org/wiki/XRI)
and specifically the human-friendly format of XRIs known as i-names
(http://en.wikipedia.org/wiki/iname) are abstract identifiers that use an
HTTP-based resolution mechanism to retrieve an XML document that describes
the identified resource. Since under the YADIS architecture that's also the
function of LID and OpenID URLs, it was agreed that if we can agree on one
interoperable capabilities description format, then websites can accept
either an XRI or an URL as a login, resolve it to the capabilities
descriptor document, and then complete authentication according to one of
the available capabilities.

I'm cc'ing Gabe Wachob, my co-chair of the XRI TC, as well as the other TC
members who were at IIW (and some that weren't), to prompt them to join the
list and this conversation. It is particularly revelant because the XRI TC
is currently discussing and trying to come to closure on XRI Descriptor
(XRID) document format used in XRI resolution.

Although we considered RDF, it was felt to be too heavyweight for the kind
of very simple bootstrap capabilities discovery that XRI resolution and
resource description needs. So we've been working with a very lightweight
XML document format that primary uses URIs to define and declare
capabilities.

I have to get on a phone call right now but I'll try to send an example of
this format later this afternoon, and invite Gabe and the others on the TC
to join in an help explain the advantages/disadvantages/tradeoffs we've be
discussing about XRIDs for some months now.

Best,

=Drummond 
__________________________________________________
i-name: =Drummond.Reed
http://public.xdi.org/=Drummond.Reed
 

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Christopher E. Granade
Sent: Monday, October 31, 2005 11:48 AM
To: yadis at lists.danga.com
Subject: Re: Implementing YADIS with no new software

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benjamin Yu wrote:
> For those that are unfamiliar with RDF, just think it as a bunch of
Statements
> formed as: Subject Predicate(Property) Object. Where Object is either
another
> Subject or a Literal String. All Subjects (aka Resources) and Predicates
are
> URI identified. Thus, a collection of Statements can form a graph of
> descriptive meta-data.
> 
> -Ben
Thanks for the summary! As I said, I'm none too familiar with RDF- I
suggested it because it seems to work well for things such as Creative
Commons licenses, which can almost be visualized as another
"capability": they have a distinct URL that associates with a Work (in
the case of YADIS, a Consumer). Furthermore, the use of the rel="meta"
construction seems to have a fairly wide basis, being recommended for CC
and Dublin Core metadata. Other formats, like RSS, incorporate RDF
directly into the schema, allowing for RDF+CC/DC/YADIS (RCDY?) to be
embedded directly, or included via XInclude or an XSL stylesheet.

I must say that in recent months, programs like xsltproc have made an
XML-lover out of me- not because XML itself is so wonderful, but because
it is a well-understood standard with lots (and I do mean lots) of
developer support available. Seems to me, why reinvent the wheel? RDF
seems like it was designed- or at least is widely used- for exactly this
kind of purpose, and that mechanisms exist to couple RDF to arbitrary
XML documents.

- --Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDZnT00dXuuZr00J4RAvhGAKDvAOBcuGPJNKhvr2AThjvzNzPgCACePSiJ
k2CsUCKwF9bMAvEzM/vbTc4=
=efgK
-----END PGP SIGNATURE-----