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] SSSS, /site-meta, and HTTP-based Resource Descriptor Discovery


Nat,

I'm not sure it has any security implications different than that associated
with any other /site-meta metadata. In other words, if a /site-meta file for
a domain can be trusted (via whatever mechanism) to tell you where to find
the XRD for a resource, it should be able to be trusted (by that same
mechanism) to tell you the base URI for the XRI resolution service run by
that domain.

The use case is this: an application working with an XRI wants to resolve it
using a trusted resolution service but doesn't want to rely on a public
resolution service like xri.net. If the application knows it trusts
example.com, then it can ask for the /site-meta from example.com, look up
the URI for the XRI resolution service ("xri-base" in the example below),
discover "http://xri.example.com/";, and it's off to the races.

<metadata>
   <meta href="http://xri.example.com/"; rel="xri-base"/>
</metadata>

Hope this helps,

=Drummond 

> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: Wednesday, January 21, 2009 3:52 AM
> To: Drummond Reed; 'XRI TC'
> Cc: 'Eran Hammer-Lahav'
> Subject: Re: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor
> Discovery
> 
> Hi Drummond,
> 
> For "designate their own base URI for XRI resolution",
> what would be the security implication?
> 
> Or, are you suggesting it for community root?
> 
> =nat
> 
> --------------------------------------------------
> From: "Drummond Reed" <drummond.reed@cordance.net>
> Sent: Saturday, January 17, 2009 5:56 AM
> To: "Sakimura Nat" <n-sakimura@nri.co.jp>; "'XRI TC'"
> <xri@lists.oasis-open.org>
> Cc: "'Eran Hammer-Lahav'" <eran@hueniverse.com>
> Subject: RE: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor
> Discovery
> 
> > Nat,
> >
> > I didn't respond to this email right away because I wasn't quite sure
> what
> > you were asking. In re-reading it, I think the answers to your questions
> > are, "Yes". The examples look right to me.
> >
> > With SSSS
> > (http://wiki.oasis-open.org/xri/XriThree/SuperSimpleSepSelection),
> > I agree that XRI 3.0 resolution should specify either $xrd (+xrd may
> also
> > work, but specs can only specify $ XRIs) as the type for XRDs that can
> be
> > used to select them.
> >
> > Also, last week, after reading HRDD draft 00 closely, I sent Eran an
> email
> > asking him something similar, i.e., can't we (the XRI TC) specify that
> > sites
> > can use /site-meta to designate their own base URI for XRI resolution
> > services? In other words, instead of http://xri.net, or
> http://*.xri.net,
> > having to be the base URI for all XRIs, a site like http://example.com
> > could
> > declare that the base URI for its XRI resolution services was
> > http://xri.example.com using the following /site-meta entry:
> >
> > <metadata>
> >   <meta href="http://xri.example.com/";
> > rel="http://oasis-open.org/xri/xri-base"/>
> > </metadata>
> >
> > Of course, if we registered xri-base with IANA as a rel-type, we could
> > shorten it to:
> >
> > <metadata>
> >   <meta href="http://xri.example.com/"; rel="xri-base"/>
> > </metadata>
> >
> > Thoughts?
> >
> > =Drummond
> >
> >
> >> -----Original Message-----
> >> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> >> Sent: Wednesday, January 14, 2009 5:23 PM
> >> To: XRI TC
> >> Cc: Drummond Reed; Eran Hammer-Lahav
> >> Subject: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor
> >> Discovery
> >>
> >> Hi. Looks like this message did not get through, so I am posting again.
> >>
> >> =nat
> >>
> >> ------------------------------------------
> >>
> >> In SSSS, <type> seems to be able to accommodate native XRIs such as
> >> +contact.
> >>
> >> Is that right?
> >>
> >> Are we going to define something like +xrd so that the URI for the XRD
> of
> >> an
> >> abstract resource
> >> http://xri.net/=nat would be http://xri.net/=nat/+xrd ?
> >>
> >> Or, do we always have to do two round trips so that we can make use of
> >> link-header, link element, or /site-meta?
> >> In case of /site-meta, what would be a good practice to find out the
> XRD
> >> of
> >> http://xri.net/=nat via /site-meta?
> >> I suppose it is going to be asking for http://xri.net/site-meta and it
> >> includes a template like
> >>
> >> <metadata>
> >>    <link-template template="http://xr.net?xrdof={%uri}";
> >>         rel="describedby"
> >>         type="application/xrd+xml"
> >>         scheme="http https" />
> >> </metadata>
> >>
> >> Is it possible to define a /site-meta like below as well?
> >>
> >> <metadata>
> >>    <link-template template="{%uri}/+xrd"
> >>         rel="describedby"
> >>         type="application/xrd+xml"
> >>         scheme="http https" />
> >> </metadata>
> >>
> >> Then, for http://xri.net/, as long as /site-meta cache is valid,
> >> one can just ask for http://xri.net/=nat/+xrd for my XRD, so it will
> >> in effect same as the first paragraph of this mail.
> >>
> >> To be compliant to XRI 2.0, the /site-meta may look like:
> >>
> >> <metadata>
> >>    <link-template template="{%uri}?_xrd_r=application/xrds+xml"
> >>         rel="describedby"
> >>         type="application/xrd+xml"
> >>         scheme="http https" />
> >> </metadata>
> >>
> >> =nat
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail.  Follow this link to all your TCs in OASIS at:
> >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >



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