[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04
Good idea. Let us do it on OpenID General and OAuth list at least. =nat -------------------------------------------------- From: "Breno de Medeiros" <breno@google.com> Sent: Tuesday, June 09, 2009 7:46 AM To: "Drummond Reed" <drummond.reed@cordance.net> Cc: "Scott Cantor" <cantor.2@osu.edu>; "XRI TC" <xri@lists.oasis-open.org> Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04 > Should we circulate these minutes in the openid general mailing list? As a > source of general feedback? > > On Sat, Jun 6, 2009 at 12:27 PM, Drummond Reed > <drummond.reed@cordance.net<mailto:drummond.reed@cordance.net>> wrote: > Scott, > > Thanks much for the clarifications. The next step is for Will to write > this > up in the next Working Draft. I'm sure he could use your help in getting > the > spec text right about these points. > > Will, you'll probably save yourself time by having Scott review your next > Working Draft early. > > =Drummond > >> -----Original Message----- >> From: Scott Cantor [mailto:cantor.2@osu.edu<mailto:cantor.2@osu.edu>] >> Sent: Saturday, June 06, 2009 9:27 AM >> To: 'XRI TC' >> Subject: RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04 >> >> Drummond Reed wrote on 2009-06-05: >> > Following are the minutes of unofficial telecon of the XRI TC at: >> >> Some clarifications inline (not corrections to the minutes, just the >> statements made in them). >> >> > Drummond asked for clarification on whether the signature MAY be >> > referenced rather than enveloped. It was still unclear whether the >> > constrained XML dSig profile allows this or not - what we are sure of >> > is >> > that it supports enveloped signatures. >> >> It doesn't preclude it, but it isn't formally addressed by a profile >> describing constraints on enveloped signatures. A detached signature >> would >> need to be described separately, but is supported by XML Signature >> itself. >> >> > (Dirk made the point that adding >> > an element to XML dSig should not break it because the added element >> > should be able to be excluded.) >> >> I'm not sure what that refers to, but adding elements to the XML >> Signature >> schema is only permitted in a few places where wildcards were defined. >> You >> can't do anyting that violates the schema. >> >> > Will explained this this profile references a W3C spec for "exclusive >> XML >> > canonicalization" adds a few additional constraints, most notably a >> strong >> > recommendation against using Q-names. >> >> That isn't a constraint of excl c14n, it's a best practice in order to >> maximize interoperability when you use it. With excl c14n, you don't >> output >> a namespace prefix decl until/unless it gets "used" by an element or >> attribute. With QNames in content, you don't know that the prefix is >> being >> used because the c14n algorithm is unaware of QNames in content. The fix >> is >> to include the prefix in the InclusivePrefixes parameter to the >> algorithm, >> but knowing to include the prefix in that list when signing requires >> application intervention. >> >> The support for InclusivePrefixes is trivial to implement in the >> signing/verifying layer. It doesn't make the work harder. The cost comes >> in >> the outer layer that's handling the thing being signed. >> >> > Will explained that normal XML dSig >> > canonicalization inherits from parent elements. Exclusive does not do >> that, >> > and does not require XPath referencing, because all you can reference >> > is >> a >> > single element by its ID attribute. >> >> That's also coming not from c14n itself but the profile. You avoid XPath >> by >> limiting what you can sign and place in the Reference URI, and by >> limiting >> the Transforms allowed so that you don't have to support XPath at all >> unless >> you choose to implement more than the profile requires. >> >> > Brian suggested that we have either use an existing set of XML dSig >> > libraries for testing or develop our own. There was strong consensus >> that >> > this is essential. >> >> As I said, there are test vectors from W3C that should work, or we can >> generate some easily enough. >> >> -- Scott >> >> >> >> --------------------------------------------------------------------- >> 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 > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]