See also: IRC log
<trackbot> Date: 07 December 2010
<fjh> ScribeNick: Ed_Simon
<fjh> Last Call publication of XML Signature 1.1 and XML Encryption 1.1 on 30 November, ends 22 December
<fjh> http://www.w3.org/News/2010#entry-8965
<fjh> Updated publications page and roadmap wiki, http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0000.html
<fjh> McGraw draft status, http://lists.w3.org/Archives/Public/public-xmlsec/2010Nov/0043.html
<fjh> Closing EXI last call comments, http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0001.html
<fjh> ACTION-730?
<trackbot> ACTION-730 -- Thomas Roessler to check if 1.0 comment list for xml signature is forward to our active errata list -- due 2010-11-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/730
<fjh> Approve minutes, 30 November 2010
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Nov/att-0038/minutes-2010-11-30.html
<fjh> Proposed RESOLUTION: Minutes from 30 November are approved.
RESOLUTION: Minutes from 30 November are approved.
fjh: We agreed on the list to explain more in text.
<mjensen> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0012.html
<fjh> updated grammar from Pratik is http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0028.html
Pratik: Grammar should support attributes.
... Cannot select nodes without selecting parents
... Hopes that other streaming apps will adopt streaming XPath work by us
... added top-level ID
... now a standalone grammar
Meiko: Happy with changes that were made
... F2F suggested complicated changes that Meiko felt changed the intended direction
... last step may not use attribute axis
fjh: Let's include what Pratik did as a separate file?
<fjh> proposed RESOLUTION: Accept grammar provided by Pratik in http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0028.html and incorporate into Streaming XPath Profile
RESOLUTION: Accept grammar provided by Pratik in http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0028.html and incorporate into Streaming XPath Profile
<fjh> ACTION: pdatta to add grammar to XPath profile [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-736 - Add grammar to XPath profile [on Pratik Datta - due 2010-12-14].
<fjh> updates, http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0013.html
Pratik: Pratik looked at if you have at an issue with a same document ID reference.
... XPath is evaluated using the document as a context (?) and there is an issue that needs fixing
... computed XPath is an attribute XPath and you have two URIs pointing to different subtrees and what to do with that
(Pratik, please correct my interpretations)
Scott: URIs are not absolute, they are relative to the root of the selection node; which could be the whole document or the fragment
<fjh> from 6.7.1.5 "The dsig2:IncludedXPath element is used in conjunction with XML-based dsig2:Selection algorithms to specify the subtree(s) to include in a selection. The element contains an XPath 1.0 expression that is evaluated in the context of the node established by the dsig2:Selection URI.
Scott: Scott has described this in the spec
Pratik says this makes it not streamable
Scott: If you cannot go outside the selection tree, why is it not streamable?
... really limits usefulness if one does not allow this, e.g. in Web Services apps
Pratik: But how do you do the selection if it is ID-based?
Scott: That is the selection issue; doesn't care whether you can stream that or not. If you can do ID-based selection, why cannot the XPath be relative to that?
Pratik: Streamable should commence before selection.
<pdatta> IncludedXPath and ExcludeddXPath need to be absolute XPath, absolute to the Document root
<fjh> issue is that when streaming unable to know if matching context?
Scott: Considers such a limitation to make XPath worthless where content can be moved
<pdatta> id("i1")/foo
<mjensen> how is this done in 1.0 for xpathfilter2 transforms?
Scott: should we just put the ID reference in the XPath rather than the URI
<mjensen> that's a similar situation, isn't it?
<scantor> If you can't combine URI="#foo" with XPaths, then why not preclude URI fragments and just use IncludedXPath alone
<fjh> http://www.w3.org/TR/xmldsig-filter2/ always from document root
Scott: If you cannot alter the context for XPath streaming, just have one way of doing this (no fragments in URI)
Pratik: That brings an issue with the Wrapping Attack
... Some XPath engines cannot do app-defined IDs like wsu:ID
<fjh> scantor: suggests uniform approach, URI without fragment, and id function in xpath when needed
Scott: If XPath engines cannot do IDs well, then one is stuck because even if one implements around that problem, other apps may not.
<fjh> proposed ISSUE relative context for IncludedXPath and ExcludedXPath not compatible with streaming
<pdatta> option 1) No URI, only IncludedXPath
<pdatta> option 2) both URI and IncludedXPath, can only use one at a time
<pdatta> option 3) both URI and IncludedXPath , do a Union
<pdatta> option 4) (does not work streaming) both URI and IncludedXPath, IncludedXPath is relative to URI
<fjh> ACTION: pdatta to summarize streamability issues and proposal for resolution to list [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-737 - Summarize streamability issues and proposal for resolution to list [on Pratik Datta - due 2010-12-14].
<fjh> other comments from f2f joint meeting: more rationale on why new profile,
<fjh> ISSUE-140?
<trackbot> ISSUE-140 -- Clarify how XPath is interpreted relative to entire document and ds:Reference -- closed
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/140
<fjh> we will re-open ISSUE-140
<fjh> meiko raised issue, potential issue to use //* to sign doc, select every node, add warning?
fjh: During F2F, it was suggested we describe how to, optimally, sign whole documents.
Meiko: Thought that was in best practices.
<fjh> ACTION-686?
<trackbot> ACTION-686 -- Pratik Datta to add sections on top-level expressions and predicate to XPath profile -- due 2010-11-08 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/686
<fjh> ACTION-691?
<trackbot> ACTION-691 -- Pratik Datta to add security considerations section to xpath profile -- due 2010-11-08 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/691
<fjh> ACTION-689?
<trackbot> ACTION-689 -- Pratik Datta to limit to xpath profile during xml signature 2.0 generation in 2.0 mode -- due 2010-11-08 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/689
<fjh> ACTION-638, http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0015.html
<fjh> ACTION-638?
<trackbot> ACTION-638 -- Scott Cantor to make proposal for ISSUE-210, see also http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0043.html (uncomplicate section) -- due 2010-08-31 -- CLOSED
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/638
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/
Scott: Document has been substantially reorganized but still more to be done.
fjh: Very much likes the reorg.
<fjh> we could change processing mode as I suggested
Pratik: The tone is one understands compatibility mode first, then present what is changed.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0017.html
Pratik: Better to present what is new first, then cover how compatibility works in.
Meiko: Have two documents -- one for all new, other for compatibility.
fjh: Then one has two specs to juggle; there's too much in common.
<fjh> concern about having two specs
fjh: Separate out processing
... Let's focus on getting content right for all the issues.
Scott: Let's not overestimate how much material is old.
... maybe some could be moved to an appendix.
<fjh> could have three docs, algorithms, 1.1 material, and 2.0, but sounds way too complicated
Pratik: Likes 3 document approach but agrees it would be much work.
fjh: Will make changes to process section
... Should we split 1.1 now and save work for 2.0
... Want to limit confusion when we do a publication release
<fjh> ACTION: fjh to summarize roadmap if we were to have multiple document approach for 2.0 with respect to 1.1 [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-738 - Summarize roadmap if we were to have multiple document approach for 2.0 with respect to 1.1 [on Frederick Hirsch - due 2010-12-14].
<fjh> proposed RESOLUTION: Update processing rules to separate 2.0 and compatibility mode as proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0017.html
RESOLUTION: Update processing rules to separate 2.0 and compatibility mode as proposed in http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0017.html
<fjh> ACTION: fjh to update 2.0 processing rules [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-739 - Update 2.0 processing rules [on Frederick Hirsch - due 2010-12-14].
Scott: We had decided there is no requirement to use C14N 2.0, only requirement to use algorithm compatible with 2.0+ interface.
... Changed digest length to non-negative integer
... Some questions...
... New stuff we created uses different schemes for plugability (signatures, digests, transforms, etc.); should we be consistent?
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0015.html
Pratik: Signature 1.0 was very procedural; 2.0 is more declarative.
<fjh> from scott's email: "Spec consistency...do we want to express the Verification children as type-specific elements, or as a generic element with an Algorithm or Type attribute? Certainly everything else in the spec tends to use generic elements. It stuck out a bit when I was editing. Should Selection "type/subtype" be expressed with a single Algorithm attribute?"
<mjensen> +1 for one Algorithm attribute
Experience with SAML has suggested two plug-points is a bad idea.
<fjh> do we need to complexity of type/subtype
Scott volunteers to rework the material in question
* fjh? Action item for Scott?
<fjh> ACTION: scantor to provide proposal for change to selection section use of type/subtype, algorithm usages [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-740 - Provide proposal for change to selection section use of type/subtype, algorithm usages [on Scott Cantor - due 2010-12-14].
Scott: Nowhere in core signature spec, does one see hard-coded elements for behaviour.
... Do we want children to use specific element names or be more consistent with other things in the spec?
... The content model selection is "xsd:any" because it should be.
... If the verification element needs type-specific children, then xsd:any.
<fjh> choice is xsd:any vs bag of choie plus ##other
Scott: Choice would include "xsd:any"
* Please correct any misrepresentations I make.
Scott: What should verification look like? That is the question.
... Not what the schema should like -- that is secondary.
<fjh> ACTION: scantor to summarize schema issue with content model again on list [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-741 - Summarize schema issue with content model again on list [on Scott Cantor - due 2010-12-14].
Scott: Security text re custom canonicalization algorithms?
fjh: Will defer that so fjh can look if it pertains to one of his actions.
Scott: Concern about type in Reference between 1.0 and 2.0
<fjh> Is Type in Reference also omitted in 2.0 Mode? Left optional? We may need to move the text around that describes its purpose.
<fjh> issue: status of Reference Type attribute in 2.0?
<trackbot> Created ISSUE-219 - Status of Reference Type attribute in 2.0? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/219/edit .
<fjh> ISSUE-219: is limited to Object and Manifest?
<trackbot> ISSUE-219 Status of Reference Type attribute in 2.0? notes added
Scott: Favours that we preclude Type
... along with URI
<fjh> ISSUE-219: how does use of Type attribute in Reference impact 2.0 mode selection and processing?
<trackbot> ISSUE-219 Status of Reference Type attribute in 2.0? notes added
Scott: In 2.0 mode, it says don't use URI, but does not say don't use Type
fjh: We have to think about how Manifest is used in 2.0; this may affect this issue
Scott: It might not be inconsistent to leave Type attribute, but a bit weird
Ed: Manifest is used in Microsoft Office digital signatures
... maybe in Open Document Format too; would have to check on that.
Scott: Comments and processing instructions: Do we have an option in C14N for it?
fjh: Thought we got rid of it, but backtracked in F2F.
Meiko: Node numbering changes if you have comments so problem there.
<fjh> meiko noted node numbering changes with comments, thus considered having comments signed.
Scott: Sections 5.3 and 5.4 discusses PIs and comments in sig elements; text needs to be harmonized.
... PIs are still significant; but comments may depend on c14n alg.
... text is probably OK but may need adjustment.
<fjh> ISSUE: Clarify handling of comments and processing instructions in 2.0 mode , currently in terms of C14N
<trackbot> Created ISSUE-220 - Clarify handling of comments and processing instructions in 2.0 mode , currently in terms of C14N ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/220/edit .
Scott: xml:space is section on subtrees
<scantor> 6.7.1.1
Scott: 6.7.1.1 section
... explains output of subtrees for exclusions which is input to canonicalization
... includes set of namespace declarations in scope, inheritied values of xml:base and xml:space
... if we are not not inheriting those, we don't care what they were.
<fjh> ISSUE: clarify xml:space and xml:base, section 6.7.1.1 , http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-subtrees-with-exclusions
<trackbot> Created ISSUE-221 - Clarify xml:space and xml:base, section 6.7.1.1 , http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-subtrees-with-exclusions ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/221/edit .
Pratik: need to inherit xml:space
... but not xml:base
Scott: xml:lang?
<fjh> ISSUE-221: may need to retain xml:space but remove xml:base
<trackbot> ISSUE-221 Clarify xml:space and xml:base, section 6.7.1.1 , http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-subtrees-with-exclusions notes added
Pratik: We should leave them in as part of the contract in case they are needed.
... not saying one has to use c14n 2.0
<fjh> how does section 6.7.1.1 work if using c14n2
<fjh> pdatta: notes, then not used
<fjh> ACTION: scantor to propose text regarding 6.7.1.1 and use of c14n2 [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-742 - Propose text regarding 6.7.1.1 and use of c14n2 [on Scott Cantor - due 2010-12-14].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0003.html
<fjh> ACTION-711?
<trackbot> ACTION-711 -- Meiko Jensen to add QnameAware elements and IDAttributes element to the examples (or check whether they're in and correct) -- due 2010-11-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/711
Meiko had proposed examples but we need some that demonstrate new features.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0004.html
Scott suggests including SOAP example
<fjh> ACTION: hal to look for soap example from sx examples document suitable for 2.0, showing qnames, eg. xsi:type and use of ids [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-743 - Look for soap example from sx examples document suitable for 2.0, showing qnames, eg. xsi:type and use of ids [on Hal Lockhart - due 2010-12-14].
Scott: We cannot do SOAP example until we figure out ID issue; example could include QNames and IDs in signing process.
fjh: Good to have a starting point example.
Hal: Main issue with WSS is most things will require a security token reference.
Hal will look for examples.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0004.html
<fjh> ACTION-538?
<trackbot> ACTION-538 -- Meiko Jensen to provide proposal related to namespace wrapping attacks once XPath profile available -- due 2010-03-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/538
<fjh> "Once Pratik's Algorithm for extracting prefixes from XPaths and treating them as "visibly utilized" is put to the spec, I consider this action ready to be closed"
Ed: sounds good to me.
<scantor> ISSUE-204?
<trackbot> ISSUE-204 -- Integrated recognition of QName content -- open
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/204
<fjh> ACTION-715?
<trackbot> ACTION-715 -- Pratik Datta to add content on scanning algorithm (augment to remove duplicates), and information on where to emit the namespace declaration -- due 2010-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/715
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0010.html
Bruce did a review of requirements and noted 1 issue
<fjh> proposed edit to requirements spec, http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0011.html
Bruce: fjh proposal addresses it.
<fjh> proposed change, Remove section 3.2.3, Replace "some grammar" with "a mechanism" in section 3.2.2
<pdatta> For the exclusive C14n wrapping attack, my action is ACTION-715
RESOLUTION: Remove section 3.2.3, Replace "some grammar" with "a mechanism" in section 3.2.2
<fjh> ACTION: fjh to implement change to 2.0 requirements document, to Remove section 3.2.3, Replace "some grammar" with "a mechanism" in section 3.2.2 [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-744 - Implement change to 2.0 requirements document, to Remove section 3.2.3, Replace "some grammar" with "a mechanism" in section 3.2.2 [on Frederick Hirsch - due 2010-12-14].
<fjh> ACTION-706?
<trackbot> ACTION-706 -- Scott Cantor to propose definition section text for Included/ExcludedXPath elements for XML Signature 2.0 -- due 2010-11-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/706
<fjh> ACTION-709?
<trackbot> ACTION-709 -- Pratik Datta to incorporate Meiko's examples in the document - ISSUE-217 -- due 2010-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/709
<fjh> ISSUE-43?
<trackbot> ISSUE-43 -- Improvements to XML Signature schema -- closed
<trackbot> http://www.w3.org/2008/xmlsec/track/issues/43
<fjh> interop examples, http://lists.w3.org/Archives/Public/public-xmlsec/2010Nov/0042.html
fjh thanks Pratik for interop examples
<fjh> additional, http://lists.w3.org/Archives/Member/member-xmlsec/2010Nov/0031.html
Scott's writeup very helpful too.
RESOLUTION: Accept proposed errata as proposed in http://lists.w3.org/Archives/Member/member-xmlsec/2010Nov/0031.html
<fjh> ACTION: tlr to update errata for exclusive c14n per http://lists.w3.org/Archives/Member/member-xmlsec/2010Nov/0031.html [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-745 - Update errata for exclusive c14n per http://lists.w3.org/Archives/Member/member-xmlsec/2010Nov/0031.html [on Thomas Roessler - due 2010-12-14].
<fjh> no discussion
<fjh> ACTION-716?
<trackbot> ACTION-716 -- Meiko Jensen to propose text for xpath and best practices -- due 2010-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/716
Meiko hopes to submit info on Friday
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0007.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0006.html
<fjh> one shows benefit of streaming vs dom in 1.0, other shows benefits of 2.0 c14n
<scantor> "Streamable Mode"?
<fjh> 2.0 one includes parameter that have been removed
<fjh> ACTION-717?
<trackbot> ACTION-717 -- Pratik Datta to document the Performance improvements with 2.0 -- due 2010-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/717
<mjensen> +1 for "Streamable Mode"
<scantor> change 2.0 Mode to Streamable Mode
<fjh> proposed RESOLUTION: change name "2.0 mode" to "Streamable Mode" in Signature 2.0
RESOLUTION: change name "2.0 mode" to "Streamable Mode" in Signature 2.0
<fjh> ACTION: fjh to implement 2.0 mode name change [recorded in http://www.w3.org/2010/12/07-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-746 - Implement 2.0 mode name change [on Frederick Hirsch - due 2010-12-14].
<Cynthia> +1 for the resolution
Pratik: We should list benefits of Streamable XPath
<fjh> do not want name as 2.0 mode, what happens with 2.1 etc
<scantor> ideally we want the new mode to be implicit, not something we give a name to
<fjh> will probably not want a 2.0 name at all, but just a 2.0 spec with a compatibility mode in it
<fjh> will depend on how we can organize document, e.g. separate docs etc
END OF MEETING