See also: IRC log
<trackbot> Date: 19 August 2008
<fhirsch3> Chair: Frederick Hirsch
<scribe> ACTION: fjh to do something [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-33 - Do something [on Frederick Hirsch - due 2008-08-26].
trackbot, close ACTION-33
<trackbot> ACTION-33 Do something closed
<fhirsch3> Scribe: Pratik Datta
<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0028.html
<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0028.html
sure
<fhirsch3> registration for tpac - http://www.w3.org/2002/09/wbs/35125/TPAC2008/
<brich> brich is on another call, will call in in a few minutes, until then will participate via IRC, apologies
<scribe> ACTION: tlr to set up questionnaire for next meeting [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-34 - Set up questionnaire for next meeting [on Thomas Roessler - due 2008-08-26].
<fhirsch3> xades http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0003.html
<fhirsch3> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0028.html
<fhirsch3> XProc http://lists.w3.org/Archives/Member/member-xmlsec/2008Aug/0008.html
<scribe> ACTION: fjh to contact XML Processing WG [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-35 - Contact XML Processing WG [on Frederick Hirsch - due 2008-08-26].
<fhirsch3> Updated NIST drafts http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0027.html
<fhirsch3> Randomized Hashing for Digital Signatures
<pdatta> ACTION: bal to take a look at NIST document [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-36 - Take a look at NIST document [on Brian LaMacchia - due 2008-08-26].
<pdatta> TOPIC minutes approval
<fhirsch3> http://www.w3.org/2008/08/12-xmlsec-minutes.html
RESOLUTION: 12 August minutes approved
<fhirsch3> http://www.w3.org/2008/xmlsec/track/actions/pendingreview
<pdatta> fjh: Principles will follow the same process as the Best Practices document
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0005.html
<pdatta> bal: give more time for principles document
WS-Fed contact should be Mike McIntosh (IBM)
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0026.html
<pdatta> hal: alternative c14n suggestions also produce valid xml, but in a different format
see http://www.w3.org/2007/xmlsec/ws/papers/20-thompson/
(my point was made
<pdatta> hal: if you are transmitting the canonical form, then it needs to be valid xml
<pdatta> hal: we do need to document the assumptions for canonicalization
<pdatta> hal: make a strong distinction between assumptions and requirements - requirements dictate the environment
<pdatta> hal: simplesign also preserves namespaces, that is a requirement
<pdatta> .. but simplesign assumes that docment is not modified
<fhirsch3> hal: prefixes may be need to preserved for xquery and xpath
<fhirsch3> hal: identify rqmts for possibly changing, relaxing, specifically maybe namespace prefix preservation qnames in content
for the record, at least for xpath, it is an error for a QName to occur with a prefix that is not mapped to a namespace URI in context. see 2.3 in w3.org/TR/xpath
<fhirsch3> bal: cannot look at rquiremets in vacuum, abstractly. need to look at specific use cases. issue for first edition. need to look at classes of applciation.
<fhirsch3> bal: web services, document signing and long term storage
<fhirsch3> bal: credentials - token signing
<scribe> ACTION: scantor to write up scenario for simple sign [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-37 - Write up scenario for simple sign [on Scott Cantor - due 2008-08-26].
<scribe> ACTION: bal to enlist kelvin to write up scenarios he's interested in; split of classes [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-38 - Enlist kelvin to write up scenarios he's interested in; split of classes [on Brian LaMacchia - due 2008-08-26].
bal: document embedding scenarios are interested
<bal> and tokens embedded in documents
fjh: hal, how about starting to write some material about web service scenarios
hal: think there may be some
materials available
... remember going through experience that exclusive worked
great for SAML assertions, but it didn't work for web
services
bal: the fact that tokens need to be self-contained and you don't want to inherit semantic changes -- what you just said is a prime example of that
<scribe> ACTION: hal to contribute web service related scenario [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-39 - Contribute web service related scenario [on Hal Lockhart - due 2008-08-26].
scantor: one of the big
differences is need for compatibility
... in these use cases ...
<pdatta> I am still here
<fhirsch3> scott: different scenarios will have different needs for backward compatibility
<pdatta> fjh: timeline draft of requirements out next month
yes
<pdatta> bal, next week, start drilling down on certain scenarios
<bal> that was me actually
<esimon2> Got to go.
<pdatta> hal: analyse performance measurements
bal: will get ACTION-38 done no later than in two weeks
scantor: will get ACTION-37 done no later than next meeting
hal: time line for ACTION-39 is two weeks
csolc: happy to review what Brian does. Archival and work-flow are important. Also important to document long-time archival requirements.
<scribe> ACTION: csolc to solicit and contribute long-time archival requirements [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-40 - Solicit and contribute long-time archival requirements [on Chris Solc - due 2008-08-26].
<fhirsch3> csolc: workflow needs to be covered explicitly
hal: cover workflow; may or may
not be same as WS
... There's probably a non-WS networking scenario that we need
to deal with
... could see signed XML shipped over plain HTTP
... maybe a subset of WS
fjh: back to workflow -- chris?
<scribe> ACTION: csolc to solicit and contribute requirements and assumptions from workflow scenarios [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-41 - Solicit and contribute requirements and assumptions from workflow scenarios [on Chris Solc - due 2008-08-26].
<fhirsch3> fjh: hardware scenario?
Just so we don't forget it: One requirement currently is that we can canonicalize an arbitrary XML document.
<pdatta> tlr: there are no constraints on the input XML in the current c14n
<pdatta> tlr: a document can have relative URI references, which depend on the context.
<pdatta> .., if we don't need relative URI references, we don't need complicated xml:base processing
<scribe> ACTION: tlr to elaborate on "any document" requirement vs canonicalizing xml:base [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-42 - Elaborate on \"any document\" requirement vs canonicalizing xml:base [on Thomas Roessler - due 2008-08-26].
<bal> fyi, i'm going to have to go in about 10 min
<fhirsch3> possible scenario is signing web pages on web server
pdatta: support for arbitrary
nodeset creates a lot of complexity
... xpath and moving around namespace nodes is painful
zakim
<pdatta> ACTION: pdatta write about constrained nodesets requirement [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-43 - Write about constrained nodesets requirement [on Pratik Datta - due 2008-08-26].
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0040.html
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0024.html
<pdatta> scantor: xml namespace attributes make xsd invalid, there is no automatic way to deal with them
yep
<pdatta> scantor: xml: attributes are no different from any other attribute
(discussion about processing instructions)
bal: PI is kind of funny, not
really data in the object model
... it's metadata that's somehow attached
... and if we'd left the schema a bit more open
... attributes would be a better way to do it
... but didn't leave it open
csolc: PI tells processor to do
an operation in some way
... could get into situation where signatures might not
verify
bal: off
<bal> bye all
<fhirsch3> tlr; xml 4th edition, pi not part of doc of character data, must be passed to application.
<fhirsch3> that is what I was trying to say before.
<fhirsch3> implementors agree that their implementations can handle pi's, but might ignore them
http://www.w3.org/TR/xml/#sec-pi
<fhirsch3> csolc: potential issue is that behaviour with pi might not match default behaviour without it, hence need to be clear on this
csolc: what the processing instruction indicates has to be what the signature grammar does
tlr: so what the PI says needs to be signed?
<fhirsch3> csolc: hence information in pi has to be redundant with information in signature
csolc: yes, and verify that the PI is correct
fjh: so we need to be careful how
PIs are used
... issue with strawman?
csolc: I don't have one
fjh: so strawman might be in a good place
pdatta: discounting attributes -- but in many implementations, don't expect schema validity
<fhirsch3> pdatta: implementations do not expect to validate according to schema so could use attributes
scantor: can't write a spec that creates schema-invalid XML
<fhirsch3> we already have validation issue with enveloped signatures
pdatta: wsu:id can be anywhere in the document?
scantor: it could be anywhere in
the schema
... that's the problem with it ...
... use proper extensibility points
... Signature schema would need to be much loser than it
is
... could have evolved more comfortably if signature had been
more loose
<fhirsch3> is schema validation a requirement?
scantor: need to be *very* clear that you can't expect schema validation of signed documents
<pdatta> scantor: if we go with approach, need to make it very clear that schema validation is not possible
scantor: lots of advantages to using them, if they get us around the problem
<pdatta> tlr: two discussions - one ability to extend the XML Signature schema
<fhirsch3> tlr: ability to expand xml signature schema, maybe can define schema with new extension points
<fhirsch3> ... will implementations break if new attribute extension point?
<pdatta> tlr: look at some implementations to see what extent they may break if there are new extension points
<fhirsch3> ... question2 - schema interaction, place to get this fixed could be in schema
<fhirsch3> +1
<fhirsch3> I aleady have this action to ask xml schema wg about this
scantor: heard people argue for layering things so you verify signatures, undo, then validate
<pdatta> fjh: xml schema could be extended so that it can do signatures and encryption in a special way
<pdatta> ACTION: fjh to send email on ordering and layering of xml signatures [recorded in http://www.w3.org/2008/08/19-xmlsec-minutes.html#action12]
<trackbot> Created ACTION-44 - Send email on ordering and layering of xml signatures [on Frederick Hirsch - due 2008-08-26].
scantor: about changing that schema -- think long and hard about it, people have been hurt while trying
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0000.html
<pdatta> talk about brad's changes next week
<fhirsch3> please review and send comments on list before next call
<fhirsch3> plan to approve those changes on that call
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0021.html
scantor: suggest we wait till I complete my action item about the scenario
<fhirsch3> action-2 open , donald eastlake is looking it it, still open
<pdatta> action-4 open,
<fhirsch3> action-4 refers to joint Cannes meetings
<pdatta> action-5 open, fjh need to figure out
<pdatta> ACTION-7: CLOSE Mike McInstosh identified
<trackbot> ACTION-7 Informally liase with WS-Fed notes added
action-7 closed
<trackbot> ACTION-7 Informally liase with WS-Fed closed
<fhirsch3> ACTIO7 close
<fhirsch3> ACTION-7 close
<fhirsch3> ACTION-7 closed
<trackbot> ACTION-7 Informally liase with WS-Fed closed
<pdatta> ACTION-13 open
<fhirsch3> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0021.html?
<pdatta> ACTION-16 open
<pdatta> ACTION 16, 19, 22 24, 25, 25 open
<trackbot> Sorry, couldn't find user - 16,
ACTION-32: no progress by 2008-08-19; expect to do it along with ACTION-30
<trackbot> ACTION-32 Document requirements and assumptions in simple signing strawman notes added
fjh: adjourned