Fwd: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery

[David Recordon]

This is worth reading as it outlines what Eran plans to do with the  
current XRDS and XRDS-Simple specifications.  It will have future  
implications on OpenID as the current Yadis discovery protocol  
actually violates the HTTP and web architecture (as pointed out by the  
W3C).  I'm going to be following this work and figure a future version  
of OpenID should make use of it.  That will mean that OPs will likely  
need to support the new discovery mechanism while also supporting the  
current one for a period of time as it becomes deprecated.


cc'ing Eran in case there are questions, but the discussion is  
occuring on the XRDS Simple list at http://groups.google.com/group/xrds-simple 
 for the time being.


--David

Begin forwarded message:


From: Eran Hammer-Lahav <[EMAIL PROTECTED]>
Date: October 27, 2008 3:06:41 PM PDT
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery
Reply-To: [EMAIL PROTECTED]

I have been reviewing XRDS and XRDS-Simple for the past couple of  
months, including their relationship to HTTP, web architecture, and  
most importantly, the use cases that are driving the development of  
an HTTP discovery protocol. What I am most interested in has always  
been a protocol for discovering metadata about an HTTP resource.  
This metadata is focused on two things: the resource itself, and its  
relationship to other resources.


Brand / Document Type

I would like to change focus from XRDS/XRDS-Simple to XRD. XRDS as a  
sequence of XRD elements is specific to XRI resolution where the  
sequence of XRDs adds value. The inclusion of multiple XRD elements  
does not fit within the model of a document describing a resource.  
My proposed use of URI fragment together with xml:id attributes ads  
much complexity and little value and will be dropped.


I propose to name this specification ‘XRD: Extensible Resource  
Descriptor’. There is existing value in the XRDS and XRDS-Simple  
brands, but it is extremely low outside the social-web/identity echo- 
chamber. Pushing out a somewhat new brand of XRD with a simple  
acronym (Extensible Resource Descriptor) goes a long way in  
delivering our message.


Focusing on the application/xrd+xml and XRD schema will also make  
the transition easier as there will be less overlap in headers,  
elements, and existing documents. By offering an XRD-top-level  
document, there is less chance of conflicting with existing XRI and  
OpenID documents.


This effort should be branded as XRD 1.0. XRDS is currently in  
version 2.0 (which failed an OASIS vote) and is now planned to  
become 3.0. I think that for branding purposes, starting with  
version 3.0 is counterproductive, but I do not have strong opinions  
in the version number. One idea I like is to drop the version and  
use a date instead (common for W3C standards).


Another advantage of keeping XRDS XRI-specific is that the current  
XRDS element not included in the new XRD schema will be able to get  
assigned to the XRDS namespace which will prevent the need to define  
a third namespace just for XRI-specific elements (on top of the XRDS  
and XRD namespaces).


Venue / Namespace

XRD is a product of the OASIS XRI TC and if for no other reason than  
to give proper attribution, should stay anchored there. I intend to  
draft and publish the XRD specification as a product of the XRI TC  
and will be joining OASIS in the next few days. As an OASIS  
standard, the XRD schema should have an OASIS http namespace (http://docs.oasis-open.org/ns/xri/xrd/1.0 
 or http://docs.oasis-open.org/ns/xri/xrd/2008/11).


However, much of the relevant community to a generic HTTP discovery  
mechanism and resource metadata resides in the IETF where HTTP is  
defined and evolved. I would like to find a way to publish OASIS  
drafts simultaneously as IETF I-Ds for informational purposes only.  
At the end, I would like to see the OASIS standard assigned an IETF  
RFC number. Again, this is not a proposal for standardization at the  
IETF, just using the RFC as a publication channel. This proposal  
needs much discussion by the XRI TC and would ultimately be their  
decision.


Discovery Workflow

The entire discovery workflow defined by Yadis will be replaced in  
XRD. Support for the ‘Accept’ HTTP header will be removed as it  
violates HTTP and web architecture. The direct-access use case (of  
accessing the metadata document without interacting with the  
resource itself) will be supported using the new /site-meta proposal  
[1] with a dynamic map to transform the resource URI to the metadata  
URI. The resource metadata map functionality will be added to the  
next draft of the /site-meta proposal or published as a separate  
proposal.


The plan is to add support for mapping between a resource’s URI to  
the URI of its metadata document by using a URI template. Currently,  
the draft only covers links to site-wide metadata. However, there  
are use cases in 

Re: Proposal to create the TX working group

[Nat Sakimura]

Hi David,
Thanks for your comments. My reply inline below:


2008/11/1 David Recordon <[EMAIL PROTECTED]>

> Hey Nat,Do you see this as being built atop Attribute Exchange for
> transport or as something new that TX defines?  I know Sxip had done work
> with AX to enable passing signed and encrypted attributes using SAML
> assertions.
>

I have thought of using AX as transport once, then gave up on it when I was
thinking of a mobile use case where the amount of payload that could be
carried with was very limited (URL length in GET is limited to one of
128bytes, 256bytes or 512bytes depending on the handset). So, the current
draft looks a lot like AX with bunch of hard coded attribute types in a
way.

As far as carrying SAML token etc. in AX are concerned, similar thing has
also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak
of Estonia (openid.ee) has been using XAdES with AX.
These approach are valid. However, I thought the approach partly defeats the
purpose of OpenID.
If we were using SAML, then we could have used it through out.
I wanted to make it easier for the developers by sticking to the tag-value
approach.
This made us define some of the attribute types defined in SAML and XAdES to
be defined as tag-value tag.



>
> Is "Trust Exchange" really the best name?  Seems like "trust" is quite a
> broad concept so something more specific might be better.
>

Right. Naming was a bit problematic. I started using "Trust" because the
messaging model is not dis-similar to WS-Trust. Now, the "trust" defined in
WS-Trust in our context is essentially "Contract". So I thought of changing
it to "CX" or something, but then, at least in Japan, quite a few key people
were already exposed to "TX" by now and thus I kept the name "TX".



> --David
>
> On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:
>
>  Dear Specification Council members:
>
> In accordance with the OpenID Foundation IPR policies and 
> proceduresthis note 
> proposes the formation of a new working group chartered to produce
> an OpenID specification.  As per Section 4.1 of the Policies, the specifics
> of the proposed working group are:
> **
>  *Trust Exchange (TX) Extension WG Charter*
>
> In accordance with the OpenID Foundation IPR policies and procedures this
> note proposes the formation of a new working group chartered to produce an
> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
> the proposed working group are:
>
>
> Proposal:
>
> (a)  Charter.
>
>  (i)  WG name:  Trust Exchange Extension (TX)
>
>  (ii)  Purpose:  The purpose of this WG is to produce a standard OpenID
> extension to the OpenID Authentication protocol that enables arbitrary
> parties to create and exchange a mutually-digitally-signed legally binding
> "contract". This protocol extension aims to be both broadband and mobile
> friendly by defining appropriate bindings for each use case.
>
> Although this specification defines one default protocol for transfering
> data based on the contract, the data transfer portion is intended to be
> pluggable so that other protocols may also be used for this purpose.
>
> The extension is not intended to be a general method for defining
> attributes; the scope is limited to a specific set of attributes necessary
> for contract semantics. The extension will also define a contract signature
> based on public key cryptography. When used with a digital certificate
> signed by a third party, the contract and signature can be used as an
> assertion of conformance to an applicable assurance program.
>
>  (iii)  Scope:
>
> Scope of the work
>
>-Development of the specification including:
>
>
> - An extensible tag-value contract format
>   - Public Key Cryptography based digital signature method applied to
>   the above contract format
>   - Query/response communication protocols for establishing the
>   contract
>   - Default data transfer protocol based on the contract
>   - Conformance requirements for other data transfer protocol bindings
>
>
>- Security, threats and Risk analysis
>
>
> - Perform Security Risk analysis and profiles for best practice
>
>  Out of scope
>
>- Term negotiation: Actual negotiation of the terms of a contract
>should be dealt with out-of-band or by other specifications.
> - General purpose data type identifiers: this should be determined on
>a per-community bases using other specifications such as OpenID Attribute
>Exchange.
> - Assurance programs or other identity governance frameworks.
> - It is the intent that this specification be usable by any trust
>community, whether it uses conventional PKI hierarchies, peer-to-peer trust
>mechanisms, reputation systems, or other forms of trust assurance. The
>specification of any particular trust root, trust hierarchy, or trust 
> policy
>is explicitly out of scope.
>
>
>  (iv)  Proposed Lis