[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]