[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]