<trackbot> Date: 21 April 2009

Administration

<fjh> next meeting 5 May, Bruce Rich

<fjh> f2f questionnaire results

<fjh> http://www.w3.org/2002/09/wbs/42458/f2fbosrsa2009/results

<fjh> next week 28 April 2009 , kelvin scribing

<fjh> 2009 F2F #4: 12-13 May, Boston

RESOLUTION: June 30 meeting cancelled.
... No meetings 4 weeks in August

liaisons

<fjh> refined elliptic curve question

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0026.html

<fjh> Widget Signature published, please review now

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0061.html

Minutes

RESOLUTION: Minutes for 7 April Approved

<fjh> http://www.w3.org/2009/04/07-xmlsec-minutes.html

Editorial updates

<fjh> Updated XML Signature 1.1 for ISSUE-96

<fjh> replace should with SHOULD, In 4.4.2.3 XML Signature 1.1

<fjh> "the OID should be encoded according to RFC3061"

<fjh> done, see http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-ECKeyValue

Publication Roadmap

<fjh> http://www.w3.org/2008/xmlsec/wiki/RoadmapandPublicationStatus

<fjh> planning

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Apr/0005.html

<klanz2> Is it all about XSLT vs. a new name isn't it?

<scantor> for the minutes, I was saying that the timing for 2.0 is dependent on final resolutions on syntax, tossing use cases, specific c14n changes, etc.

<klanz2> Is it all about XSLT vs. a new name isn't it? (repost)

Interop planning

<klanz2> XSLT, being a surrogate for the use cases that allow to sign content derived from XML instead of the XML itself ...

<fjh2> sean notes interop test cases but not elliptic curve may be available for May F2F, enabling some interop then, depending on who else is ready

<fjh2> klanz notes that thomas might have had script for interop testing, to generate table

<fjh2> ACTION: tlr to provide interop script for producing result tables as used before [recorded in http://www.w3.org/2009/04/21-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-262 - Provide interop script for producing result tables as used before [on Thomas Roessler - due 2009-04-28].

Aim to start interop testing by May f2f, but probably not ECC by then.

fjh: ECC interop testing needed if it's going to be REQUIRED. Target July?

<fjh2> Magnus and bruce to check on availability to participate in interop, May for non-elliptic curve, July for elliptic curve

<fjh2> Konrad to review availability for both interops

<fjh2> Sean, Pratik and Kelvin expect to be able to participate in both interops

<fjh2> For interop to keep light weight, plan to have test input and output files, readmes and summary table but no document

XPath filter transform/Namespace Declarations

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0025.html

<klanz2> depends on wheather inclusive or exclusive c14 is used isn't it?

<klanz2> inclusive, would sign it isn't it ...

<klanz2> what about http://www.w3.org/TR/xptr-xmlns/

<fjh2> proposal is

<fjh2> If an XPath Filtering Transform instance includes qualified nodes, then

<fjh2> associated namespace declarations MUST be specified through attributes

<klanz2> no that's not valid for XPath, isn't it ..

<fjh2> of the <XPath> element.

<fjh2> 1.1 Signature proposed change

<fjh2> konrad notes that c14n of signed info removes this problem

<fjh2> konrad notes exclusive would have an issue

<klanz2> need to use InclusiveNamespacePrefixList

<klanz2> http://www.w3.org/TR/xmldsig-core/#sec-XPath :

<klanz2> The set of namespace declarations in scope for the XPath expression.

<fjh2> pdatta notes that wss expects soap declaration at top, not expected to redeclare, in scope

<fjh2> pdatta notes that current usage is expected, implementations expect this

<klanz2> for the second case ... in the case where you use exclusive c14n, then to be safe use the InclusiveNamespacePrefixList ...

<fjh2> csolc suggests restriction on namespace node benefits for security reasons

<fjh2> csolc notes that xpath independent of general c14n

<klanz2> what would be the result if they are not there then ->? error, invalid, can't handle ???

<csolc> Do we have the same problem with namespace declarations with XPATH Filter 2

<fjh2> sean notes xpath expression in example is not correct, test needed

<klanz2> . = /doc:Document/doc:Title/descendant-or-self::* or so ....

<fjh2> sean notes java api encourages specifying namespace attribute with xpath element

<fjh2> suggest changing ed proposal to say SHOULD

<fjh2> Chair requests discussion on list of this one, for decision next week.

Ed: Maybe discuss next week - might not have a decision by then.

<fjh2> issue: XPath Filter Transform and Namespace Declarations for Qualified Nodes, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0025.html

<trackbot> Created ISSUE-115 - XPath Filter Transform and Namespace Declarations for Qualified Nodes, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0025.html ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/115/edit .

<fjh2> ACTION: esimon2 generate working examples for ISSUE-115 and review how toolkits handle the issue [recorded in http://www.w3.org/2009/04/21-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-263 - Generate working examples for ISSUE-115 and review how toolkits handle the issue [on Ed Simon - due 2009-04-28].

Issue Review

<fjh2> proposal to close these issues

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0029.html

RESOLUTION: close issues 79, 81, 85, 95, 96, 97, 101, 102, 108

ECC Issues

<fjh2> elliptic closed

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0032.html

<fjh2> request help locating resolution in editors draft for ISSUE-92, and ISSUE-103

RESOLUTION: Close above issues after email confirmation.

<fjh2> voluteer to review WS-I BSP, ISSUE-9?

<fjh2> will ask on list

<fjh2> Processing instructions, ISSUE-114?

<klanz2> for enhancing, or for 2.0?

<fjh2> suggestion to close issue, and not pursue this proposal given work on transform simplification

<fjh2> proposed resolution close-114 in favor of transform simplification

RESOLUTION: Close 114 in favor of transform simplification proposal

(for 2.0)

Konrad will email list with concerns re ruling out PIs.

<fjh2> Konrad notes not a serious concern with closing 114 and direction of wg but will provide additional input

Requirements

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0031.html

<fjh2> resolve to add requirement that QNames in content must be supported ?

<fjh2> Resolve not to support namespace undeclarations given status of XML and unclear need.

RESOLUTION: Close Issue 61 - streaming requirements captured.
... add requirement that QNames in content must be supported
... Resolve not to support namespace undeclarations given status of XML and unclear need.
... Close Issue 63

Leave issues 65, 66 open

Proposed Errata

<klanz2> what about listen ?

XML Encryption errata

<fjh2> suggest closing ISSUE-88, Spelling errors in XML Encryption Recommendation, with update to 1.1 editors draft

<fjh2> not issue errata for encryption for 1.0

RESOLUTION: Close Issue-88, 1.1 is updated, no errata for 1.0

Canonicalization

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0028.html

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0030.html

<klanz2> sean responded also

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0038.html

<fjh2> sean comment

<fjh2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0038.html

<scantor> IIRC, somebody had an action to review that stripped down algorithm and explain what use cases are precluded

<fjh2> tlr asks if most only implement canonicalization on subset of nodesets

<klanz2> optimizations, on a subset of node-sets maybe ...

<fjh2> is it time to remove features from c14n, simplify to get performance, start with exclusive?

<tlr_> action-259?

<trackbot> ACTION-259 -- Konrad Lanz to propoal for the C14N spec change -- due 2009-04-14 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/259

<klanz2> ACTION-259 Propoal for the C14N spec change wrt. namespace nodes

<fjh2> this action was to review that stripped down algorithm and explain what use cases are precluded...

<fjh2> scott notes key question is what is no longer possible with simplification

<fjh2> +1

<fjh2> question is to enumerate use cases not supported by simpler algorithm.

tlr: Are there use-cases that are not supported by simplified algorithm,

tlr: And are those edge-cases significant.

<fjh2> goal to remove edge cases, remove unused or unimportant use cases to achieve simplification and performance

<fjh2> scott focus not only on XML aspects, but document and processing related issues

<fjh2> konrad notes that library implementer does not have visibility into applications uses

<fjh2> konrad notes that cannot construct disjoint subtrees in xml

Konrad gives example of "flattened" data (removal of headers etc from book, just sign text nodes)

<fjh2> tlr question of what are well-formed nodesets

<fjh2> tlr example of signing table of contents for document

<tlr_> http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation