Working Toward Draft 2 Meeting Recap

[David Recordon]

This past Thursday a group of eleven people joined us at the Six Apart
office to have a day long collaboration session around the current open
issues with YADIS.  In attendance were Johannes Ernst (NetMesh), Joaquin
Miller (NetMesh), Michael Graves (Verisign), Hans Granqvist (Verisign),
Steve Churchill (Ootao), Mike Mell (ID Commons), Nick Ragouzis (Enosis),
Victor Grey (2idi), Larry Debes (Janrain), Josh Hoyt (Janrain), Eugene
Kim (Blue Oxen), Byrne Reese (Six Apart), Anil Dash (Six Apart), and
Arthur Bergman (Six Apart) along with Brad and myself.  While I wish
more people were closer to the Bay Area and could have made this event,
it was really great having this many people in the room and I just want
to thank them all for taking the time to come once again.

What became pretty clear toward the start was that both for the meeting
and YADIS as a whole that there is a scope issue.  While YADIS' scope is
somewhat laid out by the draft originally published, the issue has
really not been addressed.  Is YADIS anything more than a capability
discovery layer?  Will it grow to include SSO as part of the spec?  As
well as other questions of that nature.  We made the decision to try and
ignore the scope issue for the time being and rather work on addressing
it after the second draft is published.

The first issue we attacked was the format of the capabilities document.
We explained the history behind how we came to the decision of
originally using a plain-text format and then what lead to deciding to
support the XRID format at the Internet Identity World conference.
While there are some issues in supporting an unpublished Oasis spec,
talking through them it seemed like we can both continue to support the
XRID spec as well as have an option to ditch if for whatever reason the
XRID spec is not formalized.  In the end, we decided that our support of
XRID in the YADIS spec will be clearly stated as being dependent on XRID
being formalized.  We will use our own name space until it is
formalized, though use the same XML structure.  This means we will be
able to cleanly make the transition to fully using XRID as well as be
able to not if anything were to go wrong.  I'd love for someone else to
post a bit more about the actual issues that were brought up and why we
made this decision as well.

The second issue, which is a bit hairier, was figuring out what is
required of a consumer (relying party) in terms of searching for the
capabilities document.  Looking at the various proposals made by members
of the community, we came to the following set of requirements:

	Relying party should for optimization:
		Send HTTP GET request of entered URL and add
application/xrds+xml to Accept header

	Relying party must:
		1) Check if response document is application/xrds+xml
via mime type
		2) Check if X-YADIS-Location response header returned,
or <meta http-equiv="X-YADIS-Location" content="URI" /> tag is defined
in HTML
			Response header takes precedent (W3C spec)
			GET X-YADIS-Location URI
				Parse as XRD

	Relying party may:
		3) Parse returned document as XRD or try to find
additional link to XRD document (method of parsing will not be defined
in YADIS spec)

These requirements, and optional optimizations, should provide enough
flexibility for adoption by users with various levels of technical
ability as well as allow consumers to remain efficient in their
processing of a URL.

The plan from here is that Joaquin Miller will be working on the second
draft of the spec within this next week.  My personal goal is to have it
circulated for feedback and then published before the end of the month.

You can also read Johannes' blog entry about this, where he goes into
other details, at
http://netmesh.info/jernst/Digital_Identity/yadis-meeting-2005-12-01-not
es.lidwriteback.

--David