Draft minutes: face-to-face 2 May 2007

Draft minutes from our face-to-face meeting on 2 May are available


I'm including a text version below.

Thomas Roessler, W3C  <tlr@w3.org>


                                   - DRAFT -

                    XML Security Spec Maint WG face-to-face

2 May 2007


   See also: [3]IRC log


          Ed Simon
          Frederick Hirsch
          Konrad Lanz
          Juan Carlos Cruellas
          Phill Hallam-Baker
          Greg Whitehead
          Greg Berezowski
          Sean Mullen
          Don Eastlake
          Hal Lockhart
          Rob Miller
          Thomas Roessler

          Tony Nadalin

          Frederick Hirsch

          Greg Whitehead, Rob Miller


     * [4]Topics
         1. [5]Administrative
         2. [6]Approval of 2007-04-17 telecon minutes
         3. [7]Teleconference schedule
         4. [8]F2F plans
         5. [9]Introduction to W3C, W3C process and Tools [Thomas Roessler]
         6. [10]Presentation:  Overview  of  Canonical  XML 1.1 and XPath
            essentials [Konrad Lanz]
         7. [11]XML 1.1 and C14N
         8. [12]XML Signature Syntax and Processing - Overview and Proposed
            Changes [Thomas Roessler]
         9. [13]Review of XML Signature errata
        10. [14]E06, base64 URI
        11. [15]Interop discussion and planning
        12. [16]interop
        13. [17]Future work topics
     * [18]Summary of Action Items


   <Ed> Yes, Ed is Ed Simon

   <fjh> Members of the group introduced themselves

Approval of 2007-04-17 telecon minutes


   RESOLUTION: 2007-04-17 telecon minutes approved

Teleconference schedule

   fjh: weekly Tuesdays 9-10 am Eastern, 6-7 am PT, 3pm
   ... European
   ... no call next week

F2F plans

   fjh: will want to do a workshop at some point to solicit additional input
   for future work
   ... also Joint Technical Plenary and AC Meetings Week, 5-10 November 2007,
   Cambridge MA

   tlr: first two days working meetings, third day plenary, followed by more
   working meetings
   ... we could plan on 1.5 days thu-fri

   fjh: need a decision this week
   ... this group chartered through the end of the year. ideally our work is
   done by november

   <tlr> [20]http://www.w3.org/2002/09/wbs/34786/TPAC07/

   tlr: one of the outputs of this group will be a proposal for a charter for
   continued work
   ... in preparation for workshop: call for participation, prepare agenda
   ... second f2f = workshop

   <Ed> I agree with the November plans.

Introduction to W3C, W3C process and Tools [Thomas Roessler]

   tlr: slides at [21]http://www.w3.org/2007/xmlsec/w3c101

   <fjh> ack

   <Zakim> fjh, you wanted to test this

   <fjh> if you are on the queue and muted, when acked are unmuted

   fjh: starting again

   <scribe>  ACTION: Frederick to update scribe instructions [recorded in

   <scribe>  ACTION:  Frederick to provide instructions on using bugzilla
   [recorded in [23]http://www.w3.org/2007/05/02-xmlsec-minutes.html#action03]

   <trackbot-ng> Created ACTION-4 - Provide instructions on using bugzilla [on
   Frederick Hirsch - due 2007-05-09].

   <tlr> ACTION: Thomas to teach tracker about common aliases [recorded in

   <trackbot-ng> Created ACTION-5 - Teach tracker about common aliases [on
   Thomas Roessler - due 2007-05-09].

   <fjh> We would like to avoid reaching need for formal objection

   <fjh> Consensus is for "in the set", i.e. people in good standing.

   <fjh> Good standing based on attendance and delivering on deadlines. See
   Thomas slides.

   <tlr> [25]http://www.w3.org/2005/10/Process-20051014/policies.html#coi

   <fjh> please review conflict of interest policy, noted in the link above

   grw: what is conflict of interest in the context of this group?

   tlr: see [26]process document for explanation of conflict of interest

   <fjh> current patent practice link -

   tlr: XML Signature predates current patent policy
   ... see patent policy transition procedure

   <fjh> Transition procedure link -

Presentation: Overview of Canonical XML 1.1 and XPath essentials [Konrad Lanz]

   <Ed> No, I do not have the slides.

   <tlr> [29]http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf

   <fjh> see also [30]http://www.w3.org/TR/DSig-usage/

   <fjh> XPointer used in URI, XPath Filter in Transform both allow getting
   document subset

   <tlr>  ACTION:  konrad  to share example for transform that depends on
   information   beyond   the   transform   input  nodeset  [recorded  in

   <trackbot-ng> Created ACTION-6 - Share example for transform that depends on
   information  beyond  the transform input nodeset [on Konrad Lanz - due


   <fjh> grw: Is C14N11 needed for SIgnedInfo?

   <fjh> Konrad: could use id on signed Info other than schema

   <fjh> juan-carlos: focus on current attributes in xml namespace

   old behavior is to inherit all xml: attributes

   proposal to change that to not inherit by default

   fjh: can we ask xml core to specify inheritance rules when new attributes

   hal: no, we can't count on that

   <fjh>  ISSUE: C14N11 does not clearly define how new attributes in xml
   namespace are to be handled (as inheritable, non-inheritable, undefined)

   klnaz2: raised this issue with xml core, but not solved there

   <tlr> +1 to Frederick

   <tlr> PROPOSED: up on groups that define XML namespace attributes to tell
   whether simply inheritable or not

   <tlr> (by juan Carlos)

   <fjh> proposal is to propose sentence and give to XML Core, other attributes
   in xml namespace are non-inheritable by default

   jcc: should be up to group defining xml attributes whether inheritable
   ... should have a registry of attributes

   klnaz2: maybe this is better for future work

   hal: c14 doc should be explicit, don't include implict rules

   tlr: how is conformance affected by future additions that break a current

   fjh: if c14 1.1 is to be compatible with 1.0 can we change the rules around
   xml: attribute inheritance

   phb: not relevant since you will never mix 1.0 and 1.1 (eg sign with 1.0 and
   verify with 1.1)

   <fjh> ie clear because you explicitly specify canonicalization method

   deastlak: default should be not inheritable since you can always work around
   that, but not the reverse

   <fjh> deastlak: desireable not to have to rev canonicalization

   deastlak: would be nice if inheritably could be determined syntactically
   ... alternatively, could have some explicit indication of inheritability

   hal: no way to anticipate future special cases

   klanz2: could have an extensibility parameter but not a big fan of that

   phb: just ask xml core what default they prefer: inheritable or not

   <Zakim> PHB, you wanted to raise the issue of qname mess

   <fjh> greg whitehead: need to change from default of inheriting for xml
   namespace attributes

   <fjh> ... perhaps extensibiilty to indicate how handled as input to canon

   <fjh> ... perhaps extensibiilty to indicate how handled as input to canon

   <fjh> ... perhaps uri

   <fjh> ... diminishing returns depending on how far this goes

   <fjh> ack

   <fjh> tlr: undefined behaviour leads to both security and interoperability

   tlr:  inheritance issue could be handled by a prefilter using existing
   extensibility points
   ... if you define a attribute that requires special processing, define a
   transform to do that processing

   klnaz2: this won't work because transforms always refer back to the original
   document, changes apply to original
   ... could do this only if we change the transform processing model to output
   a copy of input

   proposal - for attributes in xml namespace, not listed in c14n 1.1, there
   will be no special processing

   rationale - exceptional processing for future xml attributes can be handled
   by some mechanism without revving c14n (such as pre-processing)

   fjh: proposes to propose this to xml core
   ... also convey security concerns

   security concern - with this proposal, security may be compromised if new
   attributes are defined that require special processing

   <deastlak>  for clarity suggest "no special processing' -> "no special
   process, that is, they will be treated as not inheritable"

   hal: alternative is to stop with an error if an unknown xml attribute is

   tlr: this would prevent using existing extension points to handle special
   ... c14n would have to revved in all cases
   ... error proposal is safer, but has higher deployment cost

   deastlak: fixed behavior best, not inherited a better default since you can
   always copy attributes as a workaround
   ... not desireable to keep revving c14n

   <klnaz2> [33]http://www.w3.org/TR/C14N-issues/#S3

   ed: prefers inherited to be default

   <Ed> Ed prefers inheritance, but wants to study this issue more, and also
   see examples of the arguments against inheritance


   <fjh> return at 1:15 ET, about 1/2 hour

   <Ed> I'm back

   <fjh> Resuming meeting

   <tlr> ScribeNick: rdmiller

   <tlr> Scribe: RobMiller

XML 1.1 and C14N

   <fjh> konrad: this means cannot sign xml 1.1 at all

   <fjh> ... suggests looking at xml core archives

   Ed: wondering about XPATH 2.0

   klnaz2: Canonical XML is currently defined for XPath 1.0 and not XPath 2.0

   <Ed> Ed's point was whether XPath 2.0, though not defined in Canonical XML,
   might address or be of help in the issues re XPath 1.0 and XML 1.1

   <fjh> klanz2: canonization need not generate valid XML, is this a good

   <fjh>  klanz2:  namespace undelarations in xml 1.1 can cause issues in

   fjh: where is this applicable?

   klnaz2: this applies to XML 1.1 and canonicalization

   fjh: what are we trying to accomplish with this conversation right now? this
   is a discussion for future charterting.
   ... will submit a comment to propose wording be added to C14N11 that C14N11
   is applicable only to XML 1.0 and XPath 1.0

   <tlr> don, [34]http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf

   fjh: did we address the qname issue properly?

   tlr: not using qnames is a good topic for best practices.

   <scribe> ACTION: Phil to propose a change to C14N11 to handle the qname
   issue due 5/3/2007 [recorded in

   <trackbot-ng> Sorry, couldn't find user - Phil

XML Signature Syntax and Processing - Overview and Proposed Changes [Thomas

   <Ed> are there slides?

   tlr: The reference processing model should use C14N 1.0 as a default.
   ... the transform used for signing should be explicitly defined.

   <tlr> [36]http://www.w3.org/2007/xmlsec/20070502-tlr-dsigchange.pdf

   <sean> q

   <fjh> ack

   sean: RetrievalMethod has a sequence of transforms.

   <fjh> Dsig proposal has three parts

   <fjh> a. receivers must assume c14n10

   <fjh> b generators must put explicit transforms to be clear on c14 version

   fjh:  if you use xml:base with exclusive canonicalization there may be
   issues, but it is something that can be addressed.

   <fjh> c mandatory algs c14n1.0 and c14n11 (both)

   <scribe> ACTION: Thomas to provide precise wording for issues with exclusive
   canonicalization and xml:base [recorded in

   <trackbot-ng> Created ACTION-7 - Provide precise wording for issues with
   exclusive  canonicalization  and  xml:base  [on  Thomas Roessler - due

   <tlr> ACTION: Thomas to propose spec wording for conformance-affecting
   changes [recorded in

   <trackbot-ng>   Created   ACTION-8   -   Propose   spec   wording  for
   conformance-affecting changes [on Thomas Roessler - due 2007-05-09].

   <tlr> ACTION-7 closed

   <trackbot-ng> Sorry... I don't know how to close ACTION yet

Review of XML Signature errata

   <Ed> Is there a link to errata slides?

   <tlr> [39]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core

   <tlr> [40]http://www.w3.org/2001/10/xmldsig-errata

   <scribe>     ACTION:    Sean    to    review    E01    [recorded    in

   <trackbot-ng>  Created  ACTION-9  -  Review  E01 [on Sean Mullan - due


   <tlr> ACTION-9 also covers reviewing the old material -- "what was meant by

   fjh: E01 was meant to be editorial
   ... added a note addressing E02 stating that Exclusive XML Canonicalization
   may be used

   RESOLVED: E02 accepted

   <tlr> [43]http://www.w3.org/TR/xmldsig-filter2/#sec-Algorithm-Identifier

   RESOLVED: E03 edits accepted

   <Ed> I was cut off again; will call back shortly

   <tlr> ed, we were cut off

   RESOLVED: E04 edits accepted, but will require wordsmithing to replace
   "since" with "because".


   <scribe>    ACTION:    Whitehead    to   review   E05   [recorded   in

   <trackbot-ng>  Created ACTION-10 - Review E05 [on Greg Whitehead - due

   <tlr>  ACTION:  klanz2  to investigate Austrian eGov use case for Type
   attribute [recorded in

   <trackbot-ng> Created ACTION-11 - Investigate Austrian eGov use case for
   Type attribute [on Konrad Lanz - due 2007-05-09].

   <fjh> Greg W: consider changing "signed" to "referenced" in "type of object
   being signed"

   jcc: In E05 propose changing the word "signed" to "processed".

   <fjh> sean: implementation may need Type for RetrievalMessage processing

   <deastlak> RFC 4051 section 3.2 defines many additional RetreivalMethhod

   fjh: action-10 is reassigned to Konrad
   ... we think that E05 might be correct due to RFC 4051 section 3.2 and other
   language in that section may need to be adjusted.

   <fjh> General agreement to this

E06, base64 URI

   <fjh> question whether "base64" should be allowed or only URI allowed

   <fjh> Thomas suggests interop test for URI use for this

   E06 edits accepted

   klanz2: "#base64" is different than "base64"

   <fjh> Section 6.6.2 describes base64 URI for transform

   <fjh> see also 6.1

   <fjh> thomas: base64 encoding is manditory, URI declares the encoding in 6.1

   <fjh> ... No section that lists encoding algorithms

   <grw> base64 transform URI not listed in 6.1 (only base64 encoding URI)

   <fjh> update to errata would be to complete the list of transforms in 6.1

   tlr: explain what the base64 URI means in an encoding context

   <fjh> Konrad: "base64" is a URI

   <fjh> discussion whether this is an appropriate URI, issue of scheme

   <fjh> thomas: non normative change

   <fjh> juan carlos: usage of attribute is an application matter, so is it a
   concern here for platform?

   Ed: plain base64 is not defined anywhere in the spec, but the URI is
   ... are we going to have a new namespace for dsig?

   <deastlak> Gak no....!

   <tlr> [47]http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html

   tlr: our charter precludes us creating a new namespace for dsig
   ... the base64 URI issue has been settled in previous attribute testing.
   base64 was only tested as a URI

   Thomas proposed closing the discussion on E06 and accepting the edits

   RESOLUTION: E06 accepted

   RESOLUTION: E07 accepted

   deastlak: E08 looks correct to me

   RESOLUTION: E08 accepted

   fjh: do we need to go through dsig errata line by line or can we review
   Thomas' proposed changes?

   <fjh> ack

   fjh: by default the usage of URI is optional and the DTD requires it

   on break

   <fjh> return in 15 minutes

   <Ed> To clarify the XML DSig namespace question above -- my question was
   whether the current "xmlns="[48]http://www.w3.org/2000/09/xmldsig#"" might
   be changed to indicate a later version, say
   "xmlns="[49]http://www.w3.org/2007/12/xmldsig#"",  based  on this WG's
   activities. Answer: No, that implies changes beyond the scope of this WG.

Interop discussion and planning

   tlr: immediate next step for Dsig is an updated editors draft.
   ... is the inheritance issue something that will need to be in interop

   fjh: yes, and it may cause some schedule slip.

   tlr: what are people expecting as timelines with regard to implementing and

   fjh: we should look at interop testing in the the June or July timeframe.
   ... July is probably too late

   <fjh> Konrad: how will xml:base interact with xml Signature

   <fjh> thomas: impact on meaning of URI in Reference and RetrievalMethod

   <fjh> thomas: is an XML Signature with xml:base within it schema conformant

   <tlr> [50]http://www.w3.org/TR/xmlbase/

   <fjh>  from the xml base spec - "The deployment of XML Base is through
   normative reference by new specifications, for example XLink and the XML
   Infoset. Applications and specifications built upon these new technologies
   will natively support XML Base. The behavior of xml:base attributes in
   applications based on specifications that do not have direct or indirect
   normative reference to XML Base is undefined."

   <fjh> Juan Carlos: xml base for chartering activity

   <fjh> thomas: +1

   fjh: we are not defining any behavior for xmlbase so let's dodge it.

   <Ed> I expect xml:base, namespace canonicalization, and qnames will require
   chartering activity.

   fjh: how are we going to deal with confidentiality and interop?
   ... we may need a private interop mailing list.

   tlr: we will need to keep interop testing confidential, with a public report
   at the end.

   fjh: i would like to keep a record of who says they can do interop and what
   state they are in.
   ... members can use the member list to report status.

   tlr: technical work on test cases should be on the public list, all other
   interop communication should be on the member list.


   <tlr> ACTION: all to investigate interop testing capabilities [recorded in

   <trackbot-ng> Sorry, couldn't find user - all

   <tlr> ACTION: frederick to contact participants in previous interop testing
   [recorded in [52]http://www.w3.org/2007/05/02-xmlsec-minutes.html#action14]

   <trackbot-ng> Created ACTION-12 - Contact participants in previous interop
   testing [on Frederick Hirsch - due 2007-05-09].

   <tlr> interop testing logistics and availability to be discussed on the
   member list

   <tlr>  ACTION:  thomas to put up WBS form to ask about interop testing
   interest [recorded in

   <trackbot-ng> Created ACTION-13 - Put up WBS form to ask about interop
   testing interest [on Thomas Roessler - due 2007-05-09].

   tlr: I would like to get a timeframe, facility and next steps toward a

   fjh: That will be the first thing on the agenda tomorrow.

   grw: we can solicit information via email.

   fjh: we may not even need a workshop

   Thomas explained the workshop process.

   klanz2: why cant we put everything into a wiki and decide later if we need
   to meet?

   tlr: that would work well among the memnbers of the WG, but we are also
   targeting the public.
   ... we are looking at the entire stack regarding dsig/decryption. What comes

Future work topics

   <fjh> xml base and xml:id support with xml sig

   <fjh> (reference processing)

   <fjh> C14N support for xml 1.1?

   <fjh> XPath data model adjustments

   <fjh> Infoset data model

   <fjh> XPath 2.0

   <fjh> -- this material should go on the wiki

   <fjh> transform chaining referening original document, modification of
   original data

   <fjh> e.g. pass by value, not reference

   <fjh> canonicalization that throws out more "ruthless canonicalization"

   <fjh> additional algorithms (eg SHA-256)

   <fjh> performance bottlenecks

   <fjh> simplicity

   <fjh> issues related to protocol use

   <fjh> relationship with binary xml, combinations etc

   <fjh> (efficient xml)

   <fjh> discussion with efficient xml interchange group possibililty

   <fjh> implicit parsing that is not schema aware (in transform chain)

   <fjh> workshop item - what is canonicalization in sig context

   <deastlak> FIN

   <Ed> Thanks, I'm happy to stay and listen.

   <fjh>  may  wish  to  ask  others  that define XML languages to define
   canonicalization or canonicalization properties for them

   <Ed> language-specific canonicalization has its limits; e.g. canonicalizing
   mixed language xml instances still requires core canonicalization

Summary of Action Items

   [NEW] ACTION: all to investigate interop testing capabilities [recorded in
   [NEW] ACTION: frederick to contact participants in previous interop testing
   [recorded in [55]http://www.w3.org/2007/05/02-xmlsec-minutes.html#action14]
   [NEW] ACTION: Frederick to provide instructions on using bugzilla [recorded
   in [56]http://www.w3.org/2007/05/02-xmlsec-minutes.html#action03]
   [NEW]  ACTION:  Frederick  to  update scribe instructions [recorded in
   [NEW]  ACTION:  klanz2  to investigate Austrian eGov use case for Type
   attribute [recorded in
   [NEW]  ACTION:  konrad  to share example for transform that depends on
   information   beyond   the   transform   input  nodeset  [recorded  in
   [NEW] ACTION: Phil to propose a change to C14N11 to handle the qname issue
   due 5/3/2007 [recorded in
   [NEW]     ACTION:     Sean     to     review    E01    [recorded    in
   [NEW] ACTION: Thomas to propose spec wording for conformance-affecting
   changes [recorded in
   [NEW] ACTION: Thomas to provide precise wording for issues with exclusive
   canonicalization and xml:base [recorded in
   [NEW]  ACTION:  thomas to put up WBS form to ask about interop testing
   interest [recorded in
   [NEW] ACTION: Thomas to teach tracker about common aliases [recorded in
   [NEW]    ACTION:    Whitehead    to    review    E05    [recorded   in

   [End of minutes]

    Minutes formatted by David Booth's [67]scribe.perl version 1.128 ([68]CVS
    $Date: 2007/05/04 21:48:48 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Apr/0014.html
   3. http://www.w3.org/2007/05/02-xmlsec-irc
   4. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#agenda
   5. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item01
   6. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item03
   7. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item04
   8. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item05
   9. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item07
  10. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item10
  11. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item11
  12. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item12
  13. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item13
  14. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item14
  15. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item15
  16. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item16
  17. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#item17
  18. file://localhost/home/roessler/W3C/WWW/2007/05/02-xmlsec-minutes.html#ActionSummary
  19. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Apr/0008.html
  20. http://www.w3.org/2002/09/wbs/34786/TPAC07/
  21. http://www.w3.org/2007/xmlsec/w3c101
  22. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action01
  23. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action03
  24. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action04
  25. http://www.w3.org/2005/10/Process-20051014/policies.html#coi
  26. http://www.w3.org/2005/10/Process-20051014/
  27. http://www.w3.org/TR/2002/NOTE-patent-practice-20020124
  28. http://www.w3.org/2004/02/05-pp-transition.html
  29. http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf
  30. http://www.w3.org/TR/DSig-usage/
  31. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action05
  32. http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Feb/att-0013/C14N-diff.html
  33. http://www.w3.org/TR/C14N-issues/#S3
  34. http://www.w3.org/2007/xmlsec/20070502-klanz-c14n.pdf
  35. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action07
  36. http://www.w3.org/2007/xmlsec/20070502-tlr-dsigchange.pdf
  37. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action08
  38. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action09
  39. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core
  40. http://www.w3.org/2001/10/xmldsig-errata
  41. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action10
  42. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0039.html
  43. http://www.w3.org/TR/xmldsig-filter2/#sec-Algorithm-Identifier
  44. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/0109.html
  45. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action11
  46. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action12
  47. http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html
  48. http://www.w3.org/2000/09/xmldsig
  49. http://www.w3.org/2007/12/xmldsig
  50. http://www.w3.org/TR/xmlbase/
  51. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action13
  52. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action14
  53. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action15
  54. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action13
  55. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action14
  56. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action03
  57. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action01
  58. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action12
  59. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action05
  60. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action07
  61. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action10
  62. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action09
  63. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action08
  64. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action15
  65. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action04
  66. http://www.w3.org/2007/05/02-xmlsec-minutes.html#action11
  67. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  68. http://dev.w3.org/cvsweb/2002/scribe/

Received on Friday, 4 May 2007 21:50:24 UTC