OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Quick overview of descriptor discovery flow


Title: Re: [xri] Quick overview of descriptor discovery flow
What I envisioned as the trust architecture (after our last meeting at Google) was based on the idea that a document could link to a signature document which will include all the necessary information to verify trust. This will allow any format that supports links to use this mechanism for establishing trust, including HTML, ATOM, /site-meta, and XRD.

For example, lets assume we defined an XML document format for signatures called application/signature+xml which contains all the information needed to verify a signature, include the signature itself. We also defined a relationship type ‘signature’.

A /site-meta file can contain such a link:

Link: <http://example.com/policy/privacy>; rel=”privacy”; type=”application/p3p+xml”
Link: <http://example.com/site/descriptor>; rel=”describedby”; type=”application/xrd+xml”
Link-Template: <http://example.com?meta={+uri}>; rel=”describedby”; type=”application/xrd+xml”
Link: <http://example.com/signature>; rel=”signature”; type=”application/signature+xml”

And an XRD can contain such a link:

<XRD>
    <CanonicalID>http://example.com/resource/1</CanonicalID>
    <URI>http://example.com/api/v1/resources?id=1</URI>
    <Type>http://example.com/some_type_of_resource</Type>
    <Link>
        <Rel>http://example.com/rel/my_calendar</Rel>
        <URI>http://example.com/calendar/1</URI>
    </Link>
    <Link>
        <Rel>signature</Rel>
        <MediaType>application/signature+xml</MediaType>
        <URI>http://example.com/signature</URI>
    </Link>
<XRD>

What each of these documents is pointing to is a document looking something like this:

<Signature method="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
    <ds:KeyInfo>
        <ds:X509Data>
            <ds:X509Certificate />
            <ds:X509Certificate />
        </ds:X509Data>
    </ds:KeyInfo>
    <Value>kjfsdlkfj943j4309jfl;kj;934jf;iwjf;934jf;oijdflkjsda==</Value>
<Signature>

And to verify it, the entire document linking to the signature (i.e. The HTTP body used to retrieve it) is used with the listed certificates to verify the signature. The authority of the certificates is verified using something like the <CanonicalID> of the XRD and the domain name of the /site-meta.

The same exact mechanism can be applied to an HTML or ATOM documents containing useful (and trust-conscious) links.

EHL

On 12/15/08 1:43 PM, "Brian Eaton" <beaton@google.com> wrote:

There are some interesting wrinkles in how URI templates interact with
delegation and security.  Let's say that site A wants to securely
delegate metadata descriptions about 1 million users to site B.  If
the URI mapping occurs before the delegation, then 1 million user
documents on site B have to be signed by site A.  That's a major pain
to administer.

It's much easier if the delegation statement and signature occurs
before (or at the same time as) the URI mapping.

If URI templates can only be in site-meta, it's really important that
site-meta also support signing and delegation.

On Mon, Dec 15, 2008 at 12:55 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> The following method describes how to perform R-URI --> D-URI: finding the
> descriptor URI from the resource URI. The process starts with a resource
> URI. It doesn't matter how that URI has been obtained. In the examples
> below, 'D-URI' is used to indicate the placeholder containing the desired
> descriptor URI.
>
> 1. Method selection
>
> The consumer (entity performing discovery) has three options based on
> information available to it with regard to the resource:
>
> * If the resource is known to be an HTML or ATOM document, and the document
> has been and will be retrieved via HTTP GET either way, the consumer can
> look for <Link> elements:
>
>     <Link href=""D-URI"" rel="describedby" type="application/xrd+xml">
>
> * If the resource is going to be retrieved via HTTP GET/HEAD, the consumer
> can look for Link: headers:
>
>     Link: <D-URI>; rel="describedby"; type="application/xrd+xml"
>
> * If the first two options are not applicable, the consumer obtains the
> /site-meta document for the resource's domain. The consumer may request an
> XRD representation but must be able to parse the text representation. It is
> not clear if there is real value in offering an XRD representation of
> /site-meta (please discuss).
>
> Text:
>
>     Link-Template: <http://example.com?meta={+uri}>; rel="describedby";
> type="application/xrd+xml"; syntax="plain"; vocabulary="uri"; scheme="mailto
> http"
>
> XRD:
>
>     <XRD>
>         <Link>
>             <Rel>describedby</Rel>
>             <MediaType>application/xrd+xml</MediaType>
>             <TemplateURI syntax="plain"
> vocabulary="uri">http://example.com?meta={uri}</TemplateURI>
>             <site-meta:scheme>mailto http</site-meta:scheme>
>         </Link>
>     </XRD>
>
> The 'plain' template syntax means simple substitution of {variable}s. If the
> variable name is prefixed with a '+', it must be percent-encoded prior to
> substitution. The 'uri' template vocabulary includes: uri, scheme,
> authority, domain, port, path, query, fragment, and username.
>
> Using the template, the consumer construct the D-URI from the R-URI.
>
>
> EHL
> Ps. The above syntax for /site-meta is the expected format in the next
> draft. This flow does not use the regular Link records in /site-meta as
> those are used for the entire site (an abstract concept) and not for
> individual resources. There is no such URI identifying the "site".
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]