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

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

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