[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] SSSS, /site-meta, and HTTP-based Resource DescriptorDiscovery
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]