OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]