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


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