Subject: [woes] Scope of this work

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Sep 2011 13:05:50 -0700

I am still trying to get my head on the things that people do and do not
think are going to be needed for this work.  Specifically I am trying to
figure out what are the set of features that people want to see.

I think that it would be useful if someone were to write a throw away draft
that did the following.

Taking the current CMS structures that we thing should be mapped -
AuthenticatedEnvelopedData, SignedData and AuthenicatedData.
Walk through each of the fields in these structures and write a one line
summary of the function of the field.
Make a statement that this is or is not a feature that should be followed in
the WOES work.

Examples:

SignedData.digestAlgorithms - provides a list of content digest algorithms
to allow for one pass processing.  WOES does not need one pass processing

SignedData.signerInfos - provides a list of different signers for the data.
WOES does not need to support multiple signers

SignedData.encapContentInfo.eContent - optional field allowing the signed
content to either be embedded in the structure or detached from the
structure.  WOES will not support detached content.

We can then determine which of the features are to be supported and are not
to be supported.  There may be other fields from different structures that
also needed to be looked at.  However I believe that it is universally
stated that we don't want to do the transforms of XMLDigsig, although it
might be that canonicalization may need to be looked at.

Note - arguments that could be added to the above would be:

The digestAlgorithms field provides for the ability for one pass processing
for both senders and recipients.  Given that senders only do things once and
recipients do things multiple times it might be useful to enable one pass
processing for recipients and state that it does not exist for senders.
Doing this does not mean that we need to have this field, it could instead
be supported by placing the data contained in the signerInfo field before
the encapsulated content.  Options would be No One Pass Processing, One Pass
Processing for both, One Pass Processing for Sender, One Pass Processing for
Recipient.

Jim