XML Security Working Group Face-To-Face Meeting
17 Jul 2008

See also: IRC log


Bruce Rich, Subramanian Chidambaram, Brian LaMacchia, Hal Lockhart, Thomas Roessler, Frederick Hirsch, Konrad Lanz, Juan Carlos Cruellas, Chris Solc, Gerald Edgar, Sean Mullan, Rob Miller, Ed Simon, Magnus Nystrom, Pratik Datta, Anil Saldhana
Frederick Hirsch
Bruce Rich, Chris Solc


Review of workshop materials

Frederick going through some of things covered in workshop

<fjh> http://www.w3.org/2007/xmlsec/ws/slides/06-zhang-ximpleware/

Essence is "Think bottom-up, rather than top-down"

klanz: staying close to current spec language forced applications to be overly complex

fjh: is it a tree model issue?

bal: perhaps use case analysis would show a better way

klanz: xpath accomodation is what makes c14n so expensive

fjh: pre-xpath model might be what we look at

bal: new c14n with not full compatibility with current might be strawman

<fjh> might want to consider looking at original canonicalization before infoset version

<klanz2> distibuting namespace declarations across the data model (i.e. the xpath data model)

<klanz2> .. is the expensive part

<fjh> klanz: XPath data model makes it expensive

<fjh> klanz: one issue is spec language that forces more complexity of implementation

<fjh> csolc: expensive to create copy of input data set

fjh: EXI may need to enter discussion

<fjh> issue - is there requirement to canonicalize/sign exi representation

<fjh> issue - can exi be used by xmlsec wg as part of solution

<fjh> issue - can spec be written to not rely on XPath data model and achieve same functionality

<fjh> e.g. maintain context information for tree nodes using stacks

looking at Ed Simon's position paper now

perhaps should wait and see if Ed will join call later

bal/klanz: family of c14n levels, select what is needed

bal: could do at least a simple one and a more complicated one

klanz: need to consider schema and non-schema aware as well

fjh: does "infoset" introduce unnecessary complexity

tlr: or is it only a vocabulary to talk about things

bal: xpath selections were perceived as important
... xpath2 introduced more complexity?
... subsetting selection potential may help

<fjh> issue: can we limit the generality of subsetting to reduce complexity, e.g. XPath 2.0

<trackbot> Created ISSUE-3 - Can we limit the generality of subsetting to reduce complexity, e.g. XPath 2.0 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/3/edit .

klanz: c14n will still be slow if still accomodating full xpath2

<fjh> asking about infoset generality, shorthand for need to create full model representing xml in memory and for processing

hal: do some benchmarks with representative sample documents?

<hal> specifically hotspot various implementations to see what is not worth optimizing

<fjh> issue: need to allow transforms to go between octets and nodeset

<trackbot> Created ISSUE-4 - Need to allow transforms to go between octets and nodeset ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/4/edit .

<fjh> issue: which selections from subtree are required

<trackbot> Created ISSUE-5 - Which selections from subtree are required ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/5/edit .

fjh: postpone streamable nodeset discussion until afternoon

bal, fjh, tlr: minimal c14n from early dsig work...old working draft?

sean: some perf issues are really best practices issues

fjh: ...discussion of xpath2 filter additions?
... ...propose a guest gives us more background on this?

<klanz2> Minimal Canoniclaization: http://tools.ietf.org/html/rfc3075#section-6.5.1

<klanz2> Old XMLDSIG Drafts: http://tools.ietf.org/html/draft-ietf-xmldsig-core-11

<scribe> ACTION: fjh to ask for XPath 2.0 presentation to group [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-11 - Ask for XPath 2.0 presentation to group [on Frederick Hirsch - due 2008-07-24].

<bal> this is the first WD on C14N I could find: http://www.w3.org/1999/07/WD-xml-c14n-19990729.html

ISSUE: is there requirement to canonicalize/sign exi representation

<trackbot> Created ISSUE-6 - Is there requirement to canonicalize/sign exi representation ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/6/edit .

ISSUE: can exi be used by xmlsec wg as part of solution

<trackbot> Created ISSUE-7 - Can exi be used by xmlsec wg as part of solution ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/7/edit .

ISSUE: can spec be written to not rely on XPath data model and achieve same functionality

<trackbot> Created ISSUE-8 - Can spec be written to not rely on XPath data model and achieve same functionality ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/8/edit .

<fjh> konrad: what context is there besides namespaces


jcc: ...look at XAdES for best practices ideas

<fjh> jcc: please do not redefine existing work

bal: may be asked to do timestamps, should do like XAdES did

<bal> XAdES defines some particular signed attributes that can be added to an XMLDSIG signature, along with a standard mechanism for adding signed & unsigned attributes

jcc: presenting some XAdEs slides now in workgroup

<bal> if we want to include a timestamp attribute, for example, might make sense to do it in an XAdES-compatible way

jcc: XAdES defines containers for timestamps, not timestamps themselves
... no rqmts out of XAdES on DSig at this point

<scribe> ACTION: jcc review archive from maint. group to revisit type issue [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-12 - Review archive from maint. group to revisit type issue [on Juan Carlos Cruellas - due 2008-07-24].

fjh: look at what BSP says about DSig

ISSUE: Review WS-I BSP constraints on DSig

<trackbot> Created ISSUE-9 - Review WS-I BSP constraints on DSig ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/9/edit .

ISSUE: Perform c14n with a tree-walk rather than a nodeset

<trackbot> Created ISSUE-10 - Perform c14n with a tree-walk rather than a nodeset ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/10/edit .

<fjh> issue what would it take for XML Signature to be usable for Mail

<fjh> issue: what would it take for XML Signature to be usable for Mail

<trackbot> Created ISSUE-12 - What would it take for XML Signature to be usable for Mail ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/12/edit .

<fjh> issue: what would it take to use XML Signature for structured non-XML content

<trackbot> Created ISSUE-13 - What would it take to use XML Signature for structured non-XML content ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/13/edit .

<scribe> ACTION: klanz2 Review streaming using 2nd edition Signature [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-13 - Review streaming using 2nd edition Signature [on Konrad Lanz - due 2008-07-24].

<tlr> ACTION-1 (new WG) closed

<fjh> schema appears ok with existing interop tests

<tlr> tlr: one of the test cases turns out to have an illegitimate xml:space value

<tlr> ACTION-3 (new WG) closed

<tlr> tlr: we heard back from the OOXML folks, and they don't like the style of the schema

<tlr> http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0020.html

<klanz2> I recalled there was an Issue around SignedInfo not having a chain of transforms it cannot be made robust against indention, besides using a custom canonicalization

<tlr> trackbot, close ACTION-169

<trackbot> ACTION-169 Produce updated cheat sheet closed

<tlr> trackbot, close ACTION-8

<trackbot> ACTION-8 Read this action's number closed

Widgets 1.0 Requirements review

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0004.html

fjh: working group members are welcome to review and comment

Proposed Final Review of W3C TAG Finding "Passwords in the Clear"

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0002.html

XML 1.1 and XML Core update

<fjh> tlr: XML 1.0 5th edition AC review has closed

<fjh> klanz: implication, support for character sets for element and attribute names

<tlr> status update: http://lists.w3.org/Archives/Member/w3c-ac-members/2008AprJun/0065.html

<fjh> tlr: XML 1.1 changes may be provided to XML 1.0

<fjh> tlr: namespace undeclarations will have an impact - XML Core

<fjh> issue: need to understand plans and impact of namespace undeclarations

<trackbot> Created ISSUE-14 - Need to understand plans and impact of namespace undeclarations ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/14/edit .

<fjh> need to know plan, timing for xml namespaces to effect 1.1

<fjh> what will happen to namespaces going forward

<fjh> ACTION: frederick to ask about namespaces/undeclarations in xml coordination group [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-14 - Ask about namespaces/undeclarations in xml coordination group [on Frederick Hirsch - due 2008-07-24].

<rdmiller> I just hung up and will not be participating this afternoon because of a prior commitment

<csolc> Scribe: Chris Solc

RESOLUTION: Thanks to Juan Carlos for hosting, providing excellent meals and logistics help.


fjh: use issues to track requirements for now

<fjh> Created ISSUE-15 - Minimal caching to support streaming ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/15/edit .

<fjh> Created ISSUE-16 - Backward reference for streaming - don't know what is referenced, algs ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/16/edit .

<fjh> Created ISSUE-17 - Placement of KeyInfo relative to SIgnedInfo ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/17/edit .

<fjh> Created ISSUE-18 - Data between algorithm info and digest? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/18/edit .

<fjh> Created ISSUE-19 - Placement of signature relative to signing or verification, different placement? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/19/edit .

<fjh> Created ISSUE-20 - Transform model should support streaming, filtering model ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/20/edit .

<fjh> Created ISSUE-21 - Arbitrary selection from nodeset vs XPath expressions without backward references, traversal and navigation; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/21/edit .

<fjh> Created ISSUE-22 - Requirement to validate xml before application processing, signature processing, thus need to read entire document before processing, thus not true streaming ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/22/edit .

pratik: ok to have whole doc in memory as byte array, enable validation. but avoid building DOM

<EdS> Actually, I think it may be possible to create a streaming hash function (where one does NOT have to validate an entire document to have confidence in a portion of it) if one treats the document as an authenticated dictionary. This could be quite an intersting area for XML Signature. More on authenticated dictionaries here: http://citeseer.ist.psu.edu/anagnostopoulos01persistent.html

pratik: can verify document until the whole doc is streamed

klanz: may need a streaming hash function.

pratik: hard to-do nodesets without an XML DOM
... streaming doesn't provide much benefit for small docs
... can use two passes with streaming to collect data then verify.

klanz: what is the advantage of two pass over using a dom

<fjh> Created ISSUE-24 - Requirement for NodeSets ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/24/edit .

<fjh> Created ISSUE-25 - Web services profile ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/25/edit .

<fjh> pratik streaming presentation http://www.w3.org/2007/xmlsec/ws/slides/12-mishra-oracle/Overview.pdf

pratik: nodesets imply dom, difficulty

pratik: could an event stream be used instead
... example would be beginElement(...),,, text(..) endElement(...)
... problem1. some nodesets can't be represented by xml streams

fjh: why are these problems: why do do we need these type of nodesets

bal: XML Encryption WG had discussion - decided it did not make sense to encrypt attributes

klanz: could require well formed XML between transforms

<fjh> Created ISSUE-26 - Require well formed XML between transforms ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/26/edit .

sean: this is related to compatibility

<fjh> Created ISSUE-27 - Profile XML Signature spec to disallow removal of used namespace nodes from nodesets ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/27/edit .

klanz: does this imply exclusive canonicalization?

<fjh> Created ISSUE-28 - QNames? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/28/edit .

pratik: exclusive c14n doesnt solve anything, can get namespace declarations multiple times

pratik: shouldn't allow removal of used namespace nodes

<fjh> knowing it is used requires more work and look-ahead

klanz: how nan you tell if a namespace is used if you are streaming, you need to look ahead

pratik: would have to restrict xpath filtering to only look self and ancestors

<klanz> I'm wondering whether we want a joint work on this with others doing XPath

<fjh> xpath filter 2.0 easier to write since starting from root but need constraints and possible conversion

sean: could define 3.0

klanz: would others be interested to simplify xpath to work only on the current node instead of the whole doc.

klanz: may need separate rec to gain visibility/adoption

<fjh> Created ISSUE-29 - Able to run transforms in parallel (in general parallelism related to pipelining) ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/29/edit .

<fjh> hard to anticipate use reason for multiple transforms, e.g. like unix pipes

<fjh> Created ISSUE-30 - Limit XPath Filter transform to be first transform or to not use parent axis ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/30/edit .

pratik: summary: can we get away without an dom?

pratik: goal, not require DOM, hence with constraints/profile and events

need an identifier to allow streaming

<fjh> Created ISSUE-31 - Role for XML processing instruction, if any ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/31/edit .


<fjh> Created ISSUE-32 - How to identify profile, when, where. Not in signature but earlier? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/32/edit .

pratik: profile based on current assumptions for streaming implementations?

<EdS> profile identifier would have to be signed, right?

bal: may only support streaming for enveloping signatures

<fjh> Created ISSUE-33 - Schema not validating when enveloped signature added and not included in original doc schema ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/33/edit .

tlr: put some information early in the document -- maybe some XML tags

bal: generic hint attributes in a Signature namespace?

fjh: is this idea to have an additional atttribute in document start?

klanz: processing instruction?

bal: not a first class object

klanz: well, maybe.......

bal: want to look closely

klanz: then various hack!

sean: don't need an identifier for streaming if you use a two pass method

<fjh> if element has attribute in xmlsec namespace to indicate that it needs to be included in signature

<fjh> could be in xml namespace or xmlsec namespace (see xmlink)

<fjh> ACTION: brian to provide proposal on xmlsec namespace approach to identify elements to be processed [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action05]

<fjh> ACTION: bal to provide proposal on xmlsec namespace approach to identify elements to be processed [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action06]

<tlr> ACTION: frederick to make bal to provide proposal on xmlsec namespace approach to identify elements to be processed [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-15 - Make bal to provide proposal on xmlsec namespace approach to identify elements to be processed [on Frederick Hirsch - due 2008-07-24].

klanz: processing instructions have the advantage of not invalidating schema's

<tlr> ick, we don't have an extension point for adding attributes to ds:Signature


fjh: need to contact thomas to get access to cvs

jfh: could have Editorial teams
... members of that team don't have edit every doc

each member of that team get credit even if some one on that team didn't work on a specific doc

scribe: editor teams would have their own meetings.
... may want to have two versions of each doc. draft/working and WG approved
... wiki is an option for the working/draft doc

klanz: could use inline editing

tlr: rather not, and certainly not using "per-person tags"

fjh: can make use of the mailing list to exchange text proposals if we make use of clear product and section indicators

fjh: Please think about products that you want to define.


fjh: re editing, hope to maintain process so we get a proper issues list that's atctually tied to what editors do.


<tlr> ScribeNick: tlr

fjh: "The Working Group is asked to consider the benefits of compatibility with the existing specification environment. If the Working Group decides to make breaking changes to one of the XML Security specifications, it will communicate such a decision broadly and early."

klanz: progress vs maintenance -- breaking chagnes or not?
... charter says "please communicate changes early" ...
... think about criticism that there is need to rethink overall approach ...
... Peter Gutmann ...

bal: Any breaking change is going to impact a large set of spec
... some of these consumers won't adopt a breaking change ...

cruellas: there is a perception that Signature is more open, that leads to complexity ...
... profiling? ...

<scribe> ... "new great thing" may not fly ...

UNKNOWN_SPEAKER: compatibility is critical ...

klanz: sell a basic profile as a profile, as a subset?

bal: "Take your implementation, take these things out, and it's more lightweight" -- using extension points
... there's probably a bunch of features for which this works ...
... or a more radical break ...
... might have the more radical new version, or a variant that we rip some options out from ...

klanz: synchronize into one document, not call it a profile

bal: don't care

klanz: when we constrain xpath, xslt... -- say "this enables us to do safer signatures"

tlr: let's talk about the substance firrst, the perception then

csolc: need benefit for adopters

fhirsch: Feed-back at the workshop that people want simplification
... there's also no question that algorithm stuff is important ...

bal: can do either a profile or a minor revision that doesn't breka back-compat
... straight forward ...

csolc: referencing model without breaking backward compatibility?

bal: That won't be all
... bundling question -- how to deliver certain features?
... smaller change, or bundle new features

tlr: I suspect changes to the reference model will be breaking changes

csolc: adoption by corporation
... couple new algorithms might not be enough ...

klanz: inline data in certain places?

klanz: xinclude use etc

bal: Don't include dependencies on xml stack?

klanz: also taking advantage of web archicture?

bal: not everything in it!
... as few dependencies as possible ...

tlr: XML Signature processors do not need to be xinclude aware at this point

fjh: anything else useful that this leads us to?

cruellas: what's the general leaning in terms of compatibility?

fjh: what precisely does it mean?
... not sure we're there quite yet to understand that ...
... generation vs verification ...
... not sure we need to change schema?

sean: Change namespace anyway?

<fhirsch> Created ISSUE-34 - Review namespace versioning policy, define going forward ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/34/edit .

tlr: I think ds:Reference is most brittle in terms of extensions; I think we need to look at that first in order to understand whether we have a breaking change on our hands.

klanz: @@

cruellas: don't chagne the namespace every time you need a new schema
... we're doing that in XADES ...

klanz: new elements in new namespace?
... maintain some elements in old namespace?
... e.g. keyInfo ...

<fhirsch> jcc: what is granularity of namespacing, can use old elements in old namespace

klanz: avoid duplication of implementation code ...

sean: That's radically different schema. Redesigning Java API is not going to happen.

fhirsch: Move things around?

sean: that might be ok
... add another method to return that element ...

fhirsch: Change order of elements?

<klanz> sean: would we have a new namespace for streaming nodesets?

sean: the schema comes out in the API quite a bit

fhirsch: API change?

klanz: @sean: I think the namespace could remain the same as long as we can deal with only being able to dereference Nodesetdata/Octetstream data only.

<fhirsch> tlr: to repeat what sean said, changes that are not exposed at api might be acceptable, but if apps that use API it might be an issue

sean: Really change structure of Signature -- APIs would be a problem

tlr: So change of namespace ok, if API addition is modular?

sean: yeah keyInfo2 would be ok

fhirsch: What if one couldn't use certain arguments?

brian: Implementation approach would be to have flag associated with it "generate in constrained mode"
... so newer code could take advantage of constraints ...
... default might be getting the old, unprofiled version ...
... agree with sentiment that we're in relatively good place if we can do things without breaking API ...
... suspect that between the implementations here, we're very constrained in what we can do without breaking at least one of us ...

klanz: I think the APIs are pretty similar
... JSR 105 rules ...

brian: [we may not be able to make changes without breaking at least one implementation]

klanz: ds2:Reference?
... just as a thought experiment ...
... anybody got a feeling?

tlr: so you're talking about a change to the content model for ds:Signature that would not match the existing schema?

fhirsch: I think I hear that most people in the room don't want to go more extreme
... I also wonder whether the nodeset stuff wouldn't be breaking APIs?
... this doesn't seem to actually be consistent

brian: well, yeah

bruce: I want to have cake and eat it too.

fhirsch: Can we do that? /TR/REC-cake, /TR/REC-eating?

brian: We might end up there, with two things
... Look at the algorithm issue ...
... there are plenty of folks there who are content (not happy) with dsig today
... except for algorithm ...
... they want things sooner than later ...
... existing implementations can rev with minor, non-breaking fixes relatively easily, ...
... hit marketplace ...
... if we go for new schema or new namespace, we're back to square one in terms of interop and work ...
... longer time, and you still have the existing stuff ...
... I saw that with TLS, and with S/MIME ...
... push for suite B -- demand was, just get the algos in there ...
... TLS went through baby step process ...
... guess what, we hardcoded MD5/SHA1 into pre-master secret ...
... we can't get rid of that ...
... suite B in 1.0, rev-ed 1.1, got rid of 1.2 which is breaking ...
... 1.0 and 1.1 out, everybody goes out to work on 1.2
... immediate need is on algorithms ...
... we might have to bite that bullet

fhirsch: Risk is good enough to stop with first one?
... a lot of people wanted the maint WG do this

klanz: Useful to formulate this into strategy?
... 1.1 and 1.2?

<EdS> or 1.1 and 2.0

fhirsch: If strategy is "just go for big thing" it might end up not getting deployed

klanz: if there is a 1.1, 1.2 -- and a 2.0 where people will ask about compatibility
... why call it xml dsig 2.0 instead of foobar

fhirsch: looking at milestones...

brian: Keep going on requirements and identify what can be done in 1.1 and what in 2.0

fhirsch: So we can go through streaming and see where that can go

cruellas: Feeling about market?
... or is this an implementors' issue ...

fhirsch: Lots of input that sig is too expensive
... e.g. simpleSign ...

cruellas: profiling?

fhirsch, sean: their own thing

cruellas: Try to determine what to target?

brian: Look at what is addressible.
... we got a bunch of input, will get more ...
... some things will be easy ...

klanz: If we want to do new XMLDSig it should have a new name be disruptive a proper substitution and quickly implemented.

<klanz> Maybe have a processing instruction <?startdigest someAlgostuff?>

<klanz> ... xml goes here

fhirsch: Performance, canonicalization, algorithms, keyInfo

<klanz> as a child of the same parent as of the starting PI: <?stopdigest disgestvalue .... ?>

<fhirsch> looks like we should review requirements, note which could be implemented in 1.1 versus 2.0 change, public review of what is not in 1.1, get feedback

<fhirsch> maybe note that we can decide next step based on feedback

<fhirsch> tlr: open content model allows updates to KeyInfo, also Transform model can use existing extension points to enforce properties

<fhirsch> tlr: e.g. assertion transform (fails if assertion not true)

<fhirsch> fjh: algs, performance/c14n, keyinfo clarity/usable

fhirsch: Get rid of a bunch of junk, transforms, c14n -- that's one story
... c14n is actually a separate one ...

subu: security -- DOS
... you get transformations that run out of control

fhirsch: This relates to complexity and simplification

tlr: Wrapping attacks? Sounds like References.

fhirsch: Workaround from Mike? Transform assertions?

bruce: You pay a price in complexity.

fhirsch: Use profile for that?
... might also want a SOAP signature profile
... could include that point in this profile
... some stuff in minimalist profile

<subu> WS - BSP was mentioned by Hal

fhirsch: Evolving environment?

tlr: maybe part of the success story there is keeping part of the environment from evolving

Closing the day

fjh: next meeting in two weeks
... thanks for attending the face-to-face ...
... thanks to Juan Carlos for excellent hosting ...

tlr: I think strawman proposals would be useful

klanz: I'll be happy to write up an idea about reference
... URI is optional!
... pass stuff as parameter to a transform
... could do some enveloping signature

brian: well that's not what it's meant for
... my object model would have a hard time with that ...
... need to be able to extract that ...

<fhirsch> ACTION: klanz to write up proposal regarding use of transform that has parameter for passing xml model [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-16 - Write up proposal regarding use of transform that has parameter for passing xml model [on Konrad Lanz - due 2008-07-24].

fhirsch: Help with requirements would also be helpful


<EdS> Thanks everyone.

<anil> good evening all

<anil> RRSAgent: miutes