See also: IRC log; full minutes (member-confidential)
<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0054.h tml
<klanz2> re: xpointer http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml
<EdS> starting at 9am, going for 90 min, is good for me
fjh: change meeting from 90 mins to 1 hour - only Hal has a problem
<klanz2> +1 to fjh (+30 mins on demand)
<tlr> +1 to 90 min
hal: only problems every other week
fjh: keep it simple - 90 mins every week - 1 hr
+ 30 mins on demand
... Phil to scribe
<fjh> minutes from last week http://www.w3.org/2007/08/ 14-xmlsec-minutes
next week
fjh: next week
resolution: last week's minutes approved
fjh: action 26 open
<tlr> http://www.w3.org/2007/xmlsec/w s/venue is the logistics page
<scribe> Action 50 to done [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action01]
<tlr> I need to set up registration, though
<scribe> Action 65 to open [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action02]
<klanz2> Re ACTION-72: XPointers with location steps basically in every Austrian eGov Signature, this maight change for future signature generation, but legacy signatures will remain. EBICS a german and potentially future European Payment/Banking/MoneyTransfer system has currently use of xpointer() scheme.
<scribe> Action 72 to done [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action03]
There has been a paper submitted already to the workshop - there should therefore be enough discussion already. Sent email to ask if worth getting EBICS involved too
klanz2: is it worth getting in touch direct with EBICS
action 1 - is there a danger in changing the reference from the previous candidate rec to the new working draft?
NO danger
<scribe> Action 74 still open [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action04]
<scribe> Action 75 to still open [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action05]
<scribe> Action 79 to closed [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action06]
action 80 closed
fjh: XML sig draft needs to be closed and start editing
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0041.h tml
TOPIC: xpointer
about warning wrt deprecating xpointer pointer scheme
<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0040.h tml
klanz2: change to the wording proposed by Thomas is that we want to see a change of "minimal usage" to "usage" and "support for use" of xpointer to "use of xpointer"
only 1st sentence is changed
tlr: fine with edits. Slightly -ve on additional text but can live with
<tlr> The original edition of this specification [XMLDSIG-2002]
<tlr> referenced the XPointer Candidate Recommendation
<tlr> [XPTR-2001]. That Candidate Recommendation has been
<tlr> superseded by the [xptr-fwk], [xptr-xmlns] and
<tlr> [xptr-element] Recommendations, and -- at the time of this
<tlr> edition -- the [xptr-xpointer] Working Draft. Therefore,
<tlr> the use of the xpointer() scheme beyond the usage discussed
<tlr> in this section is discouraged.
pasted section excludes change to 1st sentence
<tlr> change to first sentence:
<tlr> The original edition of this specification [XMLDSIG-2002]
<tlr> referenced the XPointer Candidate Recommendation
<tlr> [XPTR-2001] and some implementations support it optionally.
fjh: explains rationale for not using original xpointer spec
klanz2: can we accept the changes?
<tlr> ", and some implementations supported the xpointer() scheme."
tlr: proposes above
klanz2: remove the "ed" - i.e.
<klanz2> ", and some implementations support the xpointer() scheme."
<tlr> PROPOSED: to accept wording proposal from http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml including change to first sentence
<tlr> RESOLUTION: to accept wording proposal from http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0055.h tml including change to first sentence
fjh: propose not to make the change
close the issue with no action?
tlr: might be useful to talk about E canon in the best practices doc
tony says some material might be captured in ws-sec
should not be seen to duplicated Exclusive canonicalisation
<fjh> exclusive canonicalization is explicitly mentioned in
<fjh> section 6.5
seems current text is clear enough - since no strong proposals to reference Exclusive Canon
<tlr> PROPOSED: not to make further changes to list of algorithms in 6.5
<klanz2> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-NamespaceContext< /a>
klanz2: maybe worth making a note that this stuff is around
<sean> see last paragraph of section 6.5
<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-c14nAlg
hal: concern that there might be an implication that exclusive is no good
tlr: this sort of concern can be dealt with in announcing the doc
<fjh> +1
tlr:in announcing this - a clarification of relation to exclusive is worth adding
<EdS> +1
klanz2: maybe worth adding a sentence " unused ancestor context from a canonicalized subdocument and is not suceptible to inheritance problems"
PROPOSED: in communicating the update to XML core we shall call attention to the fact that exclusive canon' does not suffer from the xml ID problem
<klanz2> fine with me
<fjh> also with 2nd edition XML Signature
<tlr> PROPOSED: in communicating update to xmldsig-core, to call attention to fact that xml-exc-c14n does not suffer from xml:id issue, and ask XML Core WG to do same in announcing xml-c14n11
tlr: earmark for easy future spec work
<tlr> RESOLUTION: in communicating update to xmldsig-core, to call attention to fact that xml-exc-c14n does not suffer from xml:id issue, and ask XML Core WG to do same in announcing xml-c14n11
<fjh> RESOLUTION: in communicating update to xmldsig-core, to call attention to fact that xml-exc-c14n does not suffer from xml:id issue, and ask XML Core WG to do same in announcing xml-c14n11
<tlr> actually, konrad, there are a couple Candidate Recs in there....
tlr: we should consider an update to Exclusive Canonicalization in the future, to clarify that it is valid and up to date, and to update references at the same time
PROPOSAL: do not change the spec to add exclusive canonicalization
<fjh> RESOLUTION: do not change the spec to add exclusive canonicalization
<EdS> +1
<tlr> konrad, your question about references in exclusive was a good one. Just grep for the word Candidate. #@$%&
<fjh> updated examples per sean's message - http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0050.h tml
PROPOSED: accept these changes
<fjh> Remove digest values in s10 and s13 since these should not be confused as valid
tlr: suggest to remove digest values and replace them with something which people don't confuse with a digest value of the document
either make sure the digest value is still the same for these reference statements or drop them
<fjh> 2.1.1 s10, 2.2 p9
we could turn them into test cases and capture action item to update spec accordingly once we know what the sigs are
<tlr> also section 2.3, m07
<scribe> ACTION: update the digest values in sec 2 examples when we have the test cases which produce those values [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action07]
<tlr> ACTION: frederick to update digest values in section 2 examples when we have test cases which produce values (or else insert dots) [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action08]
<trackbot-ng> Created ACTION-81 - Update digest values in section 2 examples when we have test cases which produce values (or else insert dots) [on Frederick Hirsch - due 2007-08-28].
<fjh> PROPOSAL: accept changes in http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0050.h tml
<tlr> RESOLUTION: accept changes in http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0050.h tml
<klanz2> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-Same-Document
<tlr> or else, put in VGhpcyBpcyBub3QgYW4gYWN0dWFsIGRpZ2VzdCB2YWx1ZQo= as the digest value
<tlr> http://www. w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI
<fjh> see 4.3.3.1 The URI Attribute
<klanz2> http://www. w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-URI
klanz: section 4.3.3.1 (uri attributes) would like to know if final text is subject to discussion from position papers (Marcus E)
if we stabilise this now, do we put this into a new draft?
<fjh> Concern about implementation and "Characters disallowed in URI references by [URI] MUST be escaped as follows in [URI]"
<fjh> tlr: suggest test case for this with URI encoded brackets
tlr: text is meant to say that you need to apply uri encoding including an xpointer
at least one well-known implementer saw there was no need to do that encoding
concern - is there a reasonable reading of the old text by which an implementation might not need to do encoding
<tlr> xpointer()
<tlr> xpointer(/)
<klanz2> xpointer('/')
do test case where we include a mandatory xpointer char e.g. (/) and where it is encoded
tlr: just test at interop
<fjh> ACTION: klanz2 add test case for XPointer URI encoding, including bracket characters [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action09]
<trackbot-ng> Created ACTION-82 - Add test case for XPointer URI encoding, including bracket characters [on Konrad Lanz - due 2007-08-28].
klans2: wants to make sure that current text expresses the correct meaning
there are some characters which you don't have to escape which everyone should be able to read when parsing a uri
tlr: if you have specific concerns about specific chars, prepare a test case.
<fjh> note following sentence - "XML signature applications MUST be able to parse URI syntax. "
<fjh> tlr: hence must be able to perform escaping
<fjh> tlr: WG believed change is not conformance effecting. Can we produce test case that shows conformance impact of change?
tlr: klanz2 must produce a test-case to prove that there is an effect on conformance
klanz2: not happy with the MUST here
<tlr> note the word "must" was in there before
klanz2: need more time to think
fjh: need stable doc for interop so want to freeze on this call
tlr: onus on Konrad to produce test case which shows that text change is conformance affecting
<tlr> PROPOSED: to consider xmldsig-core closed, pending interop testing, SOTD, and acknowledgements
<tlr> RESOLUTION: to consider xmldsig-core closed, pending interop testing, SOTD, and acknowledgements
<tlr> PROPOSED ACTION: konrad to look for test cases that might indicate the change to 4.3.3.1 is conformance-affecting
<tlr> ACTION: konrad to look for test cases that might indicate the change to 4.3.3.1 is conformance-affecting [recorded in http://www.w 3.org/2007/08/21-xmlsec-minutes.html#action10]
<trackbot-ng> Created ACTION-83 - Look for test cases that might indicate the change to 4.3.3.1 is conformance-affecting [on Konrad Lanz - due 2007-08-28].
Please see the full minutes for detail.
<tlr> <a><b><c><d><e><f>
<fjh> sean needs resolution of issue noted in email
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Aug/0049.h tml
<tlr> remove <b> to <e>
<klanz2> that is what i wanted to propose
<tlr> see? ;-)