RE: XMLP Comments to XMLE LC

Joseph,

First off, I have to make an apology.  You did indeed send a message to XMLP
on Sep 10th asking for use cases.  I blew it and missed that message.
Please realize that the combination of starting at BEA on Aug 20th, moving
houses on Aug 29th, different work computers between Aug 20th and Sept 18th,
and Sep 11th made things extremely chaotic.  I obviously fumbled the ball on
this.

Can you repost the scenarios, and I at least guarantee that I will respond?

I understand why you would consider usage scenarios optional.  But another
perspective is that if you ask me (speaking for myself, not xmlp) to review
a doc and I say I don't understand how it works, and then you tell me that
the usage stuff is optional, your response doesn't really help me understand
how it works.  If you look at it as incumbent upon me to document how it
works, then that doesn't help me much either.

I can't say whether XMLE meets XMLP requirements or not because I don't see
the scenarios.   I assume you'd like to know that, given that the XMLE reqs
doc says that XMLE should meet the requirements of XMLP.  Now I'm caught
between: 1) saying that XMLE meets XMLP reqs because I don't know that it
doesn't, or 2) saying that XMLE does not meet xmlp reqs because I don't know
that it does.

I agree that comments around scenarios/usage are application specific, but
you should probably expect that you will get application specific comments
when you ask an application specific vocabulary committee (like soap, saml)
for comments ;-)

Cheers,
Dave

> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org]
> Sent: Friday, December 14, 2001 2:25 PM
> To: David Orchard
> Cc: David Fallside; w3c-xml-protocol-wg@w3.org; xenc
> Subject: Re: XMLP Comments to XMLE LC
>
>
> On Friday 14 December 2001 14:31, David Fallside wrote:
> > [1]
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0175.html
>
> With respect to David's comment:
> >  The comments
> > are around the usage scenarios of SOAP with XMLE, and the
> > processing model under validation and transformation.
>
> Such a document would be useful. Consequently, after your
> first comment I
> took the initiative of creating a list, with the folks who
> said they were
> interested, [a] upon which we could build up a set of
> scenarios. I also
> took at stab contributing a scenario [b] with questions. After a few
> requests, Yves sent a comment off-list (thank you) on my
> scenario but no
> further contributions nor comments were made. Most of the questions
> identified are application questions which are specifically
> out-of-scope of
> XENC. So I'm happy to help and contribute but "scenarios and
> recommendations regarding the affects and requirements of XML
> Encryption
> processing on XML parsing and validation" is purposefully
> identified as
> optional in our charter, which means if folks don't
> contribute it doesn't
> happen. (Actually, I expect these issues to get more
> attention in CR while
> folks play with using these two implementations together.)
>
> [a]
http://lists.w3.org/Archives/Public/www-xenc-xmlp-tf/2001Aug/0001.html
[b] http://lists.w3.org/Archives/Public/www-xenc-xmlp-tf/2001Sep/0000.html

> provides a schema, it presumably must be used by an XML Schema validator.

Schema validation is not required. There's a sentence in the xmldsig spec
that makes this clear that I forget to carry forward to xenc, the editors'
copy now says, "Implementation MUST generate laxly schema valid
[XML-schema] EncryptedData or EncryptedKey as specified by the subsequent
schema declarations. "

> We suggest that the XMLE group should provide documentation
> that describes the expected processing and validation model for documents
> containing XMLE content.

This is up to those applications as agreed to at our Workshop [c] and
since represented in the requirements document [d].

[c] http://www.w3.org/2000/11/02-xml-encryption-ws/minutes.html
[d] http://www.w3.org/Encryption/2001/Drafts/xml-encryption-req.html
    2. XML Instance Validity {[66]WS}
         1. Encrypted instances must be well-formed but need not be valid
            against their original definition (i.e. applications that
            encrypt the element structure are purposefully hiding that
            structure.)
         2. Instance authors that want to validate encrypted instances
            must do one of the following:
              1. Write the original schema so as to validate resulting
                 instances given the change in its structure and
                 inclusion of element types from the XML Encryption
                 namespace.
              2. Provide a post-encryption schema for validating
                 encrypted instances.
              3. Only encrypt PCDATA text of element content and place
                 its decryption and key information in an external
                 document. (This requires [67]granular detached /external
                 encryption.)

> This would certainly help for groups that have publicly stated intensions
> of use SOAP and XMLE, such as OASIS SAML.

If they're considering any of the options above, or other more clever
approaches, I'm happy to work with any of them on it.

--

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

--

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Monday, 17 December 2001 09:33:26 UTC