See also: IRC log
<trackbot> Date: 13 April 2010
<fjh> ScribeNick: Gerald-E
<fjh> WS-RA Last Call, including WS-Fragment
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0000.html
<fjh> Widget Signature update
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0004.html
<fjh> Approve 30 March minutes
<fjh> http://www.w3.org/2010/03/30-xmlsec-minutes.html
<fjh> ScribeNick: fjh
RESOLUTION: Minutes from 30 March 2010 approved.
http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0008.html
Proposal: http://www.w3.org/2008/xmlsec/Drafts/proposals/xpath-profile-levels.html
scantor: notes we might want relative addresses
<scantor> seems like selection needs to be relative to the URI reference in general
<Gerald-E> Pratik: profile of QName onlhy
pratik: suggests adding qname profile as well, supportive of new separate XPath document
<Gerald-E> Pratik: we need to define relative and absolute in XPath profile
<Gerald-E> Pratik: we need to review the XPath profile
<Gerald-E> ACTION: Ed Simon to review XPath Profile [recorded in http://www.w3.org/2010/04/13-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-548 - Simon to review XPath Profile [on Ed Simon - due 2010-04-20].
<scantor> there are really two key review aspects: the details of the XPath subset, and how the XPath "fits" into the surrounding XML Signature components
proposal is to create new XPath profile document containing XPath profile in XML SIgnature 2.0, Level 1 profile in WS_Fragment
and QName expression language from WS-Fragment
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-XPath-2.0
http://www.w3.org/TR/2010/WD-ws-fragment-20100330/#QName
sections 5,6,7 in WS-Fragment
proposal to merge http://www.w3.org/2008/xmlsec/Drafts/proposals/xpath-profile-levels.html
<Gerald-E> The review is to cover those sections above
proposed RESOLUTION: Create new XPath profile document including 4.4.3.11 XPaths in 2.0 mode from XML Signature 2.0 and sections 5-7 of WS-Fragment
proposed RESOLUTION: WG supports creating a new XPath profile document including 4.4.3.11 XPaths in 2.0 mode from XML Signature 2.0 and sections 5-7 of WS-Fragment
RESOLUTION: WG supports creating a new XPath profile document including 4.4.3.11 XPaths in 2.0 mode from XML Signature 2.0 and sections 5-7 of WS-Fragment
<esimon2> Note: Ed's Action-548 will pertain to the new XPath Profile document
http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0007.html
http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0011.html
<Gerald-E> review of comments form Scott Cantor
<Gerald-E> The editiorial suggestions were good
<Gerald-E> There are a number of sustantive comments we need to discuss.
<Gerald-E> SCantor: There is a lot of confusion about sorting input document subsets. This may be relatively expensive
<Gerald-E> SCantor: The input are likely to be DOM nodes
<Gerald-E> SCantor: we need to be clear
<Gerald-E> Pratik: what we are passing are element nodes
<Gerald-E> SCantor it may be good to be a bit abstract
<Gerald-E> Pratik: we need to sort because we go through 1 by 1
<Gerald-E> SCantor: the only way to sort would be to process the whole document?
<Gerald-E> SCantor would it be more efficient to cannolcalize each subtree? to detect containment on the fly.
scantor: canonicalize subsets in order provided, detect containment on the fly
<Gerald-E> Pratik: it is the responsability of C14N to sort it
<Gerald-E> SCantor: we could detect containment on the fly.
<Gerald-E> Pratik: for small documents sorting is efficient.
<Gerald-E> Pratik: sorting the whole document is expensive, but it would be more efficient to sort the roots.
what if the c14n is for whole document, then the subtree might be large?
<Gerald-E> SCantor: ON THE STREAMING SIDE HOW DO YOU SORT THE TWO PATHS?
<esimon2> Streaming does not exclude the possibility of multi-pass, right? With that, anything do-able in DOM should be do-able in streaming.
<Gerald-E> SCantor: the document does nto give enough information for streaming.
<Gerald-E> Pratic: use an off the shelf X-path library which you then give to the canonicolizer
pratik notes that when using standard xpath library nodes are returned, order not guaranteed, hence need for sorting
<Gerald-E> SCantor: you need to use the order to be predictable and consistant
<Gerald-E> SCantor: all the subtrees need to be from the same document.
pratik: need output in consistent order
next item - combining xmlXAncestors
scantor: not sure we need separate parameters, want to be consistent
<Gerald-E> Pratik: no strong thoughts
RESOLUTION: combine xmlXAncestors parameters, reducing number of parameters
next item, xsiTypeAware
<scantor> sorting of the subsets is needed because an XPath union operation returns the subsets in no specified order
<Gerald-E> Please remember to mute if you are not talking
<Gerald-E> there is a lot of noise
<Gerald-E> XSI Type Aware
comment from Scott -
Regarding xsiTypeAware, I would still like to see this expanded to
something at least a little more generic and just allow a list of
qualified node names to treat as QName-valued. Or perhaps leave
xsiTypeAware and just add a separate parameter for this, if it's
important for conformance to make this one MTI but not the other.
Speaking for myself, I don't know that I would want to implement
prefix rewriting, but I really could use the ability to handle QNames
in other places.
<Gerald-E> SCantor: Qname is a larger problem than prefix rewriting
<scribe> ACTION: scantor to provide proposal related to generic parameter relatedto xsiTypeAware [recorded in http://www.w3.org/2010/04/13-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-549 - Provide proposal related to generic parameter relatedto xsiTypeAware [on Scott Cantor - due 2010-04-20].
http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0009.html
related to Ed's email, prefixRewrite="digest
<Gerald-E> ESimon: rewriting - the idea of a hash or other unique qualifier per namespace
<Gerald-E> ESimon: if you have the name space you have a qualifier for the namespace
why do we need both counting approach and digest approach?
<Gerald-E> ESimon: you are not comparing whole documents but fragments
<Gerald-E> ESimon we need a qualifier that is not dependent on context
<Gerald-E> ESimon: to use the digest approach
scantor: too much additional processing and complexity, to hash and b64 encode etc
<Gerald-E> SCantor: is there a way to get the Base64 approach out?
esimon: could have third approach, escaped namespace, but this would be long
<Gerald-E> ESimon: to have a unique qualifier per namespace
scantor: if we don't require well-formed output then prefix could be namespace and not well formed
<Gerald-E> SCantor: it does not matter is the qualifier is "legal", you can just use the namespace
not sure we have use case of C14N document being an interchange format
<Gerald-E> ESimon: to make it well formed is better.
pdatta: increasing size will slow subsequent digest, hence argument for sequential prefixes
<Gerald-E> Pratic: the advantage of the sequential approach is that it is smaller.
<kwouters> computing a digest is rather fast, I would say
<Gerald-E> ESimon: it is good to keep things simple.
<Gerald-E> SCantor: simplicity enhances conformance
RESOLUTION: adopt editorial changes from scott and ed
<esimon2> I'm not suggesting creating a digest is slow; I thought the concern was the textual length of the digest so my proposal was to calculate the digest the same way, but (if one is concerned about length), just use the first 8 characters (or so).
<scribe> ACTION: pdatta to implement editorial changes from scott and ed [recorded in http://www.w3.org/2010/04/13-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-550 - Implement editorial changes from scott and ed [on Pratik Datta - due 2010-04-20].
next item, references comment from scott
http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0007.html
Is C14N 1.x a normative reference? Probably informative, no? Same for the
XPath Filter?
Are URI and XMLBASE normative?
<Gerald-E> SCantor: there are two normative references - and two non-normative references
<Gerald-E> SCantor: his comments are in the same order as the document
<Gerald-E> SCantor: to sort lexigraphicly.
<Gerald-E> SCantor: this is assiciated with UNICODE
<scribe> ACTION: fjh to ask Dom about URI sorting question [recorded in http://www.w3.org/2010/04/13-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-551 - Ask Dom about URI sorting question [on Frederick Hirsch - due 2010-04-20].
<Gerald-E> SCantor: sorting is harder than many people think
next item, ignoreDTD
suggest renaming parameter
esimon: processSchema or ignoreSchema possible names
<Gerald-E> SCantor: schema and DTDs are treated differently.
scantor: DTDs are mandatory part of XML
<Zakim> fjh, you wanted to ask about DTDs mandatory yet not specified for XML Signature 2.0
<Gerald-E> ESimon are we handling only DTDs?
scott: issue is DTD definition within document for entity replacement etc
<Gerald-E> SCantor: DTDs can be internal to a document
proposal - treat external separately for C14N 2.0 canonicalization parameter handling?
<Gerald-E> (Ed, can you put a summary of this into this chat?)
<Gerald-E> ESimon: there may be security concerns with default attributes.
<Gerald-E> SCantor: historically, DTDs have been treated differently than other methods/languages
<Gerald-E> fjh: can we abstract the fuctionality?
<Gerald-E> SCantor: the relationship between a document and a DTD is well defined. this is not true of schema
<Gerald-E> fjh: can we have a compatability parameter?
<esimon2> In my view, where a document's information set is dependent upon a schema (e.g. DTD or XML Schema) then canonicalization ought to include schema processing. (I have an issue open to further investigate this but that is still on my long-term to-do list.) Note: Because RELAX NG does not (intentionally) have functionality that alters the XML information set, it is safe to canonicalize documents defined according to RELAX NG without specifically processing the R
<esimon2> If one chooses to canonicalize a DTD-defined or XML Schema-defined document without processing the schema, then that ought to be explicitly clear.
<Gerald-E> SCantor: DTDs are not like schemas
<esimon2> Ergo, I support the "ignoreDTD" (properly renamed) parameter.
<scantor> specifically in that XML 1.0 defines how to reference DTDs and does not address schemas
<esimon2> Ed's "Ergo..." statement refers to Ed's previous statement.
<esimon2> what about closign action items?
mark as pending using tracker tool, then we close pending later
http://www.w3.org/2007/xmlsec/Group/Overview.html#closing-actions
ACTION-523?
<trackbot> ACTION-523 -- Ed Simon to review C14N 2.0 draft -- due 2010-03-30 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/523
action-523 closed
<trackbot> ACTION-523 review C14N 2.0 draft closed