[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Quick overview of descriptor discovery flow
Hi.
Comments and questions inline below:
Eran Hammer-Lahav wrote:
> 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}
> <http://example.com?meta=%7B+uri%7D>>; 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</
> <http://example.com/resource/1%3C/>CanonicalID>
> <URI>http://example.com/api/v1/resources?id=1</URI>
> <http://example.com/api/v1/resources?id=1%3C/URI%3E>
> <Type>http://example.com/some_type_of_resource</Type>
> <http://example.com/some_type_of_resource%3C/Type%3E>
> <Link>
> <Rel>http://example.com/rel/my_calendar</Rel>
> <URI>http://example.com/calendar/1</URI>
> <http://example.com/calendar/1%3C/URI%3E>
> </Link>
> <Link>
> <Rel>signature</Rel>
> <MediaType>application/signature+xml</MediaType>
> <URI>http://example.com/signature</URI>
> <http://example.com/signature%3C/URI%3E>
> </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>
Just to be clear: The http://example.com/signature in /site-meta example
and XRD example has different content, right?
>
> 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.
I was wondering if we should stick to XML DSig sintax for describing
X509 certs data etc. Since it is not XML DSig anymore, I was wondering
if using ds:... could be a bit confusing.
Also, when we take into the XRI resolution <XRDS> use case, the file
signing alone would not solve the issue. Brian, John and I have been
discussing about it for a week or so now.
>
> 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}
> <http://example.com?meta=%7B+uri%7D>>; 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>
> <http://example.com?meta=%7Buri%7D%3C/TemplateURI%3E>
> > <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]