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