RE: [xri] Context URI (was RE: [xri] Minutes: XRI TC Telecon 8-9AMPT Tue 2009/02/03)

[Eran Hammer-Lahav <eran@hueniverse.com>]

Hopefully, the increasing complexities of the HTTP approach will stay confined to the debate and will be resolve in the spec. But either way, the DNS approach does not solve anything. You still have the same issue of the undefined relationship between a 'resource' and 'URI', and the semantic meaning of HTTP response code as they apply to their representation.

Consider OpenID. You still have to follow redirects and figure out your claimed identifier, even if when you find it, you use DNS and not link headers...

EHL

> -----Original Message-----
> From: Peter Davis [mailto:peter.davis@neustar.biz]
> Sent: Wednesday, February 04, 2009 5:41 AM
> To: Eran Hammer-Lahav
> Cc: Drummond Reed; 'XRI TC'
> Subject: Re: [xri] Context URI (was RE: [xri] Minutes: XRI TC Telecon
> 8-9AM PT Tue 2009/02/03)
>
> I have to say that the increasing complexities of redirects and the
> varied manifestations of the Link property make the DNS approach even
> more desirable for my implementations.  Setting aside folks lack of
> familiarity of NAPTR RRs, the rest is pretty trivial to implement.
>
> It would also allow for provide host-meta for hosts which are not HTTP
> hosts (say, mail hosts/relays for example, who might want to advertise
> relay policies instead of HTTP services)
>
> food for thought, but then, of course, I am a tad biased :-P
>
> =peterd
>
> On Feb 4, 2009, at 1:53 AM, Eran Hammer-Lahav wrote:
>
> > Sure.
> >
> > The trick is to use it but not really define it... other then it is
> > the 'subject' of the link relation. In a way, this flips the
> > semantics. Instead of talking about a resource that has a URI, we
> > are talking about a URI that (when dereferenced and accessed) has a
> > resource representation.
> >
> > There are so many pitfalls in this that I spent the whole day
> > writing text only to erase it each time, with the conclusion that it
> > really cannot be directly addressed.
> >
> > Few examples:
> >
> > The spec (-01) says to follow redirects on Link header/element. This
> > of course breaks its compatibility with host-meta (new name for site-
> > meta) because the template in host-meta cannot express redirections.
> > It goes directly to the descriptor.
> >
> > Turning it around, that is, telling the client to first follow
> > redirects (i.e. try to HEAD the resource), find the context URI,
> > then look for links there (or use the template on it), breaks it
> > too, because now the benefit of host-meta not requiring any resource
> > interaction is gone.
> >
> > The only thing the spec can do (it seems) is to perform URI
> > discovery, that is, finding a descriptor that is linked to a
> > specific URI, no redirects etc. If that descriptor is not suitable,
> > a new context URI has to be found. Only, URI discovery is a bad term
> > because the descriptor is for a resource, not a URI...
> >
> > Then again, host-meta loses the added value of knowing the HTTP
> > response code of the resource it is attached to, which in all of
> > these examples, means something for the discovery itself. That's bad
> > because the HTTP response code cannot be part of this. It is too
> > specific to HTTP, to semantic meanings of response codes, to the
> > subjective definition of a representation (and what constitutes one).
> >
> > So I don't think we will end up with a new useful and well defined
> > term. Seems 'context URI' is like porn. I can't define it but I know
> > it when I see it.
> >
> > EHL
> >
> >
> >
> >> -----Original Message-----
> >> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> >> Sent: Tuesday, February 03, 2009 10:34 PM
> >> To: 'XRI TC'
> >> Subject: [xri] Context URI (was RE: [xri] Minutes: XRI TC Telecon
> >> 8-9AM
> >> PT Tue 2009/02/03)
> >>
> >> Sorry to miss the meeting today (Brian, thanks for keeping
> >> minutes). I
> >> am
> >> very interested in this concept of a Context URI. It could address a
> >> number
> >> of longstanding issues. Eran, can we put it on the agenda for
> >> Thursday?
> >>
> >> =Drummond
> >>
> >>> -----Original Message-----
> >>> From: Brian Eaton [mailto:beaton@google.com]
> >>> Sent: Tuesday, February 03, 2009 9:07 AM
> >>> To: XRI TC
> >>> Subject: [xri] Minutes: XRI TC Telecon 8-9AM PT Tue 2009/02/03
> >>>
> >>> Following are the minutes of the unofficial telecon of the XRI TC
> >>> at:
> >>>
> >>> Date:  Tuesday, 3 February 2009 USA
> >>> Time:  8:00AM - 9:00AM Pacific Time (16:00-17:00 UTC)
> >>>
> >>> ATTENDING (may be incomplete, scribe was incompetent).
> >>>
> >>> Peter Davis
> >>> Breno de Medeiros
> >>> Eran Hammer-Lahav
> >>> John Bradley
> >>> Brian Eaton
> >>>
> >>>
> >>> AGENDA
> >>>
> >>> Note that the agenda for Tuesday calls is now on the Self-Service
> >> Agenda
> >>> page:
> >>>
> >>>       http://wiki.oasis-open.org/xri/SelfServeAgenda
> >>>
> >>> The agenda items below are listed on that page with dated/numbered
> >>> headings.
> >>>
> >>> Meeting minutes, XRI TC Tuesday, Feb 3
> >>>
> >>>
> >>> ------ Resource descriptor discovery
> >>>
> >>> Eran working on rewriting spec to figure out handling of 3xx and
> 4xx
> >>> return codes.
> >>>
> >>> New concept: context URI.
> >>> For a browser: the page being displayed.
> >>> For a semantic web app: might be anything, maybe 303 is relevant,
> >> maybe
> >>> not.
> >>> For OpenID: starts with claimed ID, follows redirects, then
> performs
> >>> discovery on final URL.
> >>>
> >>> Problem exists if you get a 302 and a Link header.  What if the
> >>> resource returns a 302, but I'm interested in the original URL, not
> >>> the destination of the redirect?
> >>>
> >>> Another example: just because a resource returns a 401 doesn't mean
> >>> that you didn't discover useful information.  A 401 with a Link
> >> header
> >>> could be really useful.
> >>>
> >>> Context URI could be defined as "the resource URI that is relevant
> >>> to
> >>> the application".
> >>>
> >>> OpenID (and other usages) of Link header will need to define the
> >>> context URI, this will have to be carefully profiled.  There is
> some
> >>> disagreement about how this is defined in OpenID today, but
> everyone
> >>> agrees the spec is open to multiple interpretations.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ------ Status of site/hostmeta.
> >>>
> >>> New draft coming out in the next day or two.
> >>>
> >>> New file name: hostmeta
> >>> New format: flat file, one entry per line.  Base spec will define
> >> Link
> >>> field.  Discovery will add an additional field.
> >>> Registration authority will exist for new fields.
> >>>
> >>>
> >>>
> >>> ------ Simple XML DSig
> >>>
> >>> Clarification: we are signing the serialized XML document, not XML
> >> doc
> >>> plus metadata.
> >>>
> >>> Example: to generate the signature you would need to open a file
> and
> >>> read in the raw bytes of the file.  You could also base64 encode
> the
> >>> raw octet stream and embed it in an XRDS to get back the raw octet
> >>> stream.
> >>>
> >>> Why not sign the base64 encoding?  Because not everybody base64's
> >>> the
> >>> same way.  Some software adds line breaks, other doesn't.
> >>>
> >>> What about CR LF conversion in operating systems?  Some software
> >>> will
> >>> screw up text files by tampering with line feed characters.  We are
> >> OK
> >>> with people suffering as they figure out how read files as binary.
> >>> Every modern OS has this capability, it's necessary for image
> >>> processing/multibyte character streams.
> >>>
> >>> Signature bytes are not included in the file, but all signature
> >> metadata
> >>> is.
> >>>
> >>> Any security implications if doc is not served over https?  You
> >>> don't
> >>> get privacy without https.  You still have integrity checks.
> >>>
> >>> Integrity checks based on X.509 certificates and prayer.
> >>>
> >>> Should we include support for PGP/other key types?
> >>> Cons: no support in libraries.
> >>> Cons: nobody expects anything but X.509 to work.
> >>> Pros: if we don't need to forbid it, why should we?
> >>>
> >>> We do have support for self-signed certs, no mention of trust
> >>> hierarchy.  People are free to innovate.
> >>>
> >>>
> >>> How much can we reuse XML DSIG code?
> >>> Potentially some reuse of the XML parsing code, not anything else.
> >>> Very little code needed to implement simple sign (under 400 lines
> of
> >>> java.)
> >>>
> >>>
> >>> Peter will notify SSTC about xml dsig simple sign.  It's bad to
> have
> >>> multiple simple sign algorithms floating around.
> >>>
> >>>
> >>>
> >>>
> >>> ------ Trust model
> >>>
> >>> Eran asks Brian what he thinks of Subject at Link level.
> >>>
> >>> Brian doesn't want to argue about trust in the abstract, too hard
> to
> >>> pin down use cases.  Google is looking at how OpenID trust will
> >>> interact with trusted XRD discovery.
> >>>
> >>> Eran does see a need for generic XRI discovery trust.
> >>>
> >>> John thinks that we need to figure out the claimed ID before we can
> >>> figure out trust.  (Amen!)
> >>>
> >>>
> >>>
> >>> ------ HTML discovery
> >>>
> >>> Eran wants to forbid accepting Link elements outside of <head> in
> >>> HTML, or appropriate place in ATOM.
> >>>
> >>> Eran is not sure whether we can make people accept that limitation.
> >>>
> >>> Most OpenID libraries just use regular expressions.
> >>>
> >>> If we restrict discovery mechanisms we lock out users who don't
> have
> >>> access to the <head> of their own pages.
> >>>
> >>> There is a need for a priority order in discovery, so that all
> >>> discovery approaches produce the same descriptor.
> >>>
> >>> Eran's proposed requirement: no matter which approach the client
> >> uses,
> >>> it always gets the same descriptor set.
> >>>
> >>> John's proposed requirement: sites should try to make sure that is
> >>> true, but in the real world there will sometimes be
> inconsistencies.
> >>>
> >>> If we get restrictive about discovery, blog hosting providers will
> >>> need to provide users good tools to help them be compatible with
> >>> discovery.
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> 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
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> Peter Davis: NeuStar, Inc.
> Director & Distinguished Member of the Technical Staff
> 45980 Center Oak Plaza Sterling, VA 20166
> [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W]
> http://www.neustar.biz/
>   [X] xri://@neustar*pdavis [X] xri://=peterd
> The information contained in this e-mail message is intended only for
> the use of the recipient(s) named above and may contain confidential
> and/or privileged information. If you are not the intended recipient
> you have received this e-mail message in error and any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately and delete the original message.
>