[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
Good point, Eran - I didn't provide sufficient context. I meant an app that
dealt natively with XRIs -- for example an XDI dictionary validator, that
needs to apply the URI scheme binding in order to turn the XRI into an
absolute URI (for example, to resolve it). Currently the proposal is to
define one default binding - to http://xri.net (or https://xri.net) -- or,
for scale, to any of its subdomains (see the details at
http://wiki.oasis-open.org/xri/XriAsRelativeUri).
But if we want to let any site declare its own base URI for XRI resolution -
so apps that trust that site can dynamically bind XRIs to the base URI
published by that site -- the site's /site-meta file looks like a good way
to discover and verify this base URI.
=Drummond
> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Wednesday, January 21, 2009 10:30 PM
> To: Drummond Reed; 'Nat Sakimura'; 'XRI TC'
> Subject: RE: [xri] SSSS, /site-meta, and HTTP-based Resource Descriptor
> Discovery
>
> I don't know much about this stuff... but how would the application know
> to ask example.com about an XRI? If the XRI uses http binding, shouldn't
> it already include the http://xri.example.com/ prefix?
>
> EHL
>
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, January 21, 2009 10:26 PM
> > To: 'Nat Sakimura'; 'XRI TC'
> > Cc: Eran Hammer-Lahav
> > 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]