W3C

XML Security Specifications Maintenance Working Group Teleconference

16 Oct 2007

Agenda

See also: IRC log

Attendees

Present
Juan_Carlos_Cruellas, Frederick_Hirsch, Rob_Miller, Thomas_Roessler, Konrad_Lanz, Hal_Lockhart, Phillip_Hallam-Baker, Bruce_Rich
Regrets
Sean, Mullan
Chair
Frederick Hirsch
Scribe
Juan Carlos Cruellas

Contents


 

 

<trackbot-ng> Date: 16 October 2007

<FrederickHirsch> Meeting: XML Security Specifications Maintenance WG Conference Call

<FrederickHirsch> Scribe: Juan Carlos Cruellas

<tlr> http://www.w3.org/1998/12/bridge/Zakim.html

Administrivia: scribe confirmation, next meeting, other

<FrederickHirsch> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0005.html

hal will scribe at next week

fh: the group will meet on Thursday and Friday in Boston during the plenary

tr: registration implies lunch. This has to be taken into account when registered

fh: who will be able to attend Monday and Tuesday for meeting XML Core?
... we could at least attend some XML Core session.

fh: proposal to meet preferably with XML Core on Tuesday for progressing on the issues related with that group
... asks Konrad if he will be able to call in

konrad: as long as the time framework is reasonable

fh: will investigate time frameworks

<tlr> http://www.w3.org/2002/09/wbs/35125/TPAC2007/

fh: registration of the technical plennary is about to be closed. Need to fill in the form if...
... you want to attend other groups' meetings as observers.

tr: did some work on the XMLSig draft, all of them editorial.
... hopes they are not controversial

fh: any comment on this draft, not in this call but in the next one.

<FrederickHirsch> http://www.w3.org/2007/10/09-xmlsec-minutes

approval of minutes

minutes

RESOLUTION: the group approves the minutes of last conf call

RESOLUTION: the group approves the minutes of the workshop

Action item review

<FrederickHirsch> action 26 - how to deal with changes to changes in xml namespace (and associating canonicalization approaches) etc

<FrederickHirsch> tlr: moot if we have a xml security group that is able to do this work

th: proposed to drop action 26. Looked at minutes and emails, I think that the things there could be
... better fit in other places.

<FrederickHirsch> see http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Oct/0010.html

tr: strong dependencies on how we organize the future work on canonicalization
... suggest close this action.

kl: what direction we should take?

tr: should be a wg addressing these issues...
... the question on how to technically deal best with canonicalization, this could
... fit within one new place that would appear in the future after the discussions
... we had in the workshop
... move ahead in the charter discussion of potential future groups (?)

fh: any problem with this?
... proposes closing the action and proceed as tr suggested.

ACTION-26: CLOSED; see http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Oct/0010.html

ACTION-71: OPEN

ACTION-74: OPEN

ACTION-81: OPEN

ACTION-93: OPEN

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0003.html

ACTION-97: closed. see URL above

kl: this action deals with the frequent usage of square brackets in xpointers syntax

<FrederickHirsch> A Potential Conclusion: There should be no issue with changing to RFC 3986, with the caveat that we may want to allow to verify references with a "fragment only uri reference" that actually has unescaped square brackets.

fh: do we need any change?

<klanz2> section 4.3.3.1

kl: section 4.3.3.1 will be affected
... could add a note on this issue.
... read the text and try to reach a conclusion at the next meeting: may, should?
... implementations should be able to verify signatures with unescaped square brackets in the
... uri fragments xpointers....maybe something like this
... rfc2732 moves square brackets to the set of characters allowed in the uri's fragments.
... it also says that square brackets are mainly used for being scaped..

fh: relationship with further interop? required new interop?

kl: actually most implementations would accept unescaped square brackets

fh: look at this during this week and add an item in the agenda of next conf call

<brich> +1

fh: disscussion on the mail also

ACTION-98: kl: email produced but not sent to the list OPEN

ACTION-99: OPEN

timeline for the group

fh: need to coordinate with XML Core group. Maybe needed to extend our group's life other

<klanz2> +1

fh: 3 months...is it acceptable?

hal: no problem

<rdmiller> +1

bruce: ok

tr: one reason: takes more time achieve our goals....

another reason: need to go into next year for overlaping with progresion of canonicalization work

<tlr> +1 actually

hal: very undesirable having two groups: if this goes on, no other one should be started while this one is alive

<klanz2> +1 to hal

tr: agrees on that.

<FrederickHirsch> +1 to hal - not have two overlapping xmlsec groups

<FrederickHirsch> this one and the next

tr: it might be a single reason for this to happen: if there are patent policy issues that
... cause problems in dealing with them at the same group

<FrederickHirsch> tr: e.g IPR

PLENARY

fh: want to have an initial list of topics in the agenda.

<FrederickHirsch> - Finalization of Interop Report- Charter drafting- Best Practices draft- XML Signature Proposed Edited Rec- Joint meetings - EXI, Core- Other

bruce: does not plan to attend at this point of time

fh: next call we need to figure out how to go forward for the interop

tr: asked for a telephone bridge, so remote participation is OK
... two open ends at this point:
... question on the dname encoding test cases. We found that this did not raise any problem. Maybe
... extend this a little bit.
... question on the square brackets. Open: maybe new test cases...

kl: this could only be optional as xpointers are optional

fh: appendix a What is the point on this, Konrad

kl: this action does not deal with writing new annex a but giving some pointers on certain aspects of the wording

fh: wording seemed a bit confusing.

kl: one reason: little differences with original text.
... maybe a good idea could be that XML core asked our group to make a new proposal

fh: this is what I understood from an email from Paul
... we need the equivalent to what Bruce had.

tr: do not conclude that the message by Paul is a request to our group...
... in consequence maybe better to remain silent, observing and prepared
... current annex a wording is problematic....
... so my reading is leaving annex a as it is is not acceptable for us and
... xml core should notice it.

fh: this is related with our timeline.

tr: next xml core call is tomorrow.

kl: maybe tr could join the call.

tr: conflict with other wg.

kl: if people give me proposals, I can, as member of xml core bring them to xml core.

fh: we have given our input already.

<tlr> another two weeks, actually

fh: useful to indicate to xml core that we are waiting they indicate what they plan on this topic
... indicate that annex a must be changed.
... xml core should indicate what change they plan, and when
... anyone is welcome to post on the list any suggestion on annex a.

fh: other things in the plenary?
... maybe decryption transform....
... time constraints on issues to be dealt with depending on availability of members

WORKSHOP

fh: proposes to publish the workshop report

RESOLUTION: the wg agrees in publishing the workshop report

<tlr> ACTION: thomas to work toward publishing workshop report [recorded in http://www.w3.org/2007/10/16-xmlsec-minutes.html#action01]

<trackbot-ng> Created ACTION-101 - Work toward publishing workshop report [on Thomas Roessler - due 2007-10-23].

tr: what about publishing the minutes?

<hal> I must leave to attend ws-fed

fh: currently no list of attendees.

bruce: some missing pieces in the interop test cases.

<tlr> public list should be ok

fh: should raise this issue in the email list
... public list.
... will try to work a little bit more on the participants list of workshop during this week

<brich> aa is brich

tr: send the report at the public list

fh: first give the attendees the chance to take a look to them

<tlr> +1 to giving attendees notice before things go to old list

fh: and then send it to old list xmlsig-ietf

Interop

For a full record of this discussion, please refer to the member-confidential full minutes. In summary, the Working Group has information that the implementors affected by the second issue recorded in the interop meeting report (section 2.4 of C14N 1.1, xml:base fix-up) expect to have conforming implementations within the next few weeks.

Summary of Action Items

[NEW] ACTION: thomas to work toward publishing workshop report [recorded in http://www.w3.org/2007/10/16-xmlsec-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/10/23 17:59:30 $