Re: [wss] Document Naming Action Item

[Phil Griffin <phil.griffin@asn-1.com>]

 From a quick read of the current draft, under "security
token formats" there may be a need for a "Biometrics
Token Profile" to enable the XCBF TC work to make use
of WSS.

But this points to the larger issue of assumptions in
the current WSS draft that I believe are invalid when
placed in an OASIS context.

Within OASIS, W3C XSD is not the only schema for XML
markup. In OASIS there are at least three schemas for
XML markup. Adding a token attribute, perhaps defaulting
to XSD, that identifies the schema would correct this
problem and allow any OASIS schema to be used.

For example, the XML Common Biometric Format (XCBF) TC
relies on an ASN.1 schema for its simple XML messages.
XCBF does not depend on any of the W3C canonicalization
mechanisms, but relies instead on the canonical XML
Encoding Rules (cXER) defined in X.694.

The assumption that cryptographically enhanced XML
content is always protected using XMLDSIG and XMLENC
is also incorrect within OASIS security TCs. Adding a
token attribute, perhaps defaulting to XMLDSIG or
XMLENC, that identifies the type of cryptographic
processing would correct this problem (in part) and
would allow any OASIS signature or encryption processing
mechanism to be used.

For example, XCBF uses the same signature processing
that is used for X.509 signatures on canonical binary
content (DER), but which in XCBF is applied to XML
markup encoded using cXER.

XCBF also uses the familiar Cryptographic Message Syntax
(CMS) types SignedData and AuthenticatedData defined in
RSA PKCS#7 and IETF SMIME. But in the XCBF work these are
based on the same ASN.1 Schema, but represented in an XML
format with all cryptographic processing  applied to
canonical XML encodings using cXER. No particular versions
of XPath, XPointer, exclusive or inclusive canonicalization
are used. Abstract values are simply encoded into XML
markup and signed.

For encryption, XML representations of the familiar CMS
types EncryptedData and EnvelopedData are used in XCBF. And
again, none of these messages rely on XSD or any of the W3C 
canonicalization mechanisms, or on XMLDSIG or XMLENC for
their security.

Phil


Philpott, Robert wrote:

> Paul Cotton, Hal Lockhart, and I received an action item at the f2f to 
> provide naming recommendations for documents produced by the TC.  At 
> this week's TC con-call, we agreed to send out a note this week. After 
> e-mail exchanges with Paul and Hal, I agreed to write up our suggestions 
> for consideration by the full TC.
> 
>  
> 
> The main issue we attempted to deal with was to have the naming 
> convention reflect the various concerns raised at the f2f regarding our 
> TC's scope.  First, there is a desire to capitalize on the "goodwill and 
> capital" associated with the name "Web Services Security". Yet there is 
> also a need to deal with the strong concern by a number of members which 
> noted that WSS actually encompasses much more than just the SOAP message 
> security addressed by current "core" document. Thus they feel the 
> document names should reflect the actual document content in order to 
> avoid confusing the public who may think the spec's cover something more 
> than the titles imply.
> 
>  
> 
> With this issue in mind, the three of us recommend the following approach:
> 
>  
> 
>    1. We recommend the use of an "umbrella" tag as a prefix to all
>       document names.  We recommend "Web Services Security" for this tag.
> 
>  
> 
>    1. As stated in the current draft document labeled "Core
>       Specification", the goal of the document is to "enable
>       applications to construct secure SOAP message exchanges". 
>       Therefore we recommend that this document be labeled with one of
>       the following:
> 
> ·         Web Services Security: SOAP Message Protection
> 
> ·         Web Services Security: SOAP Message Security
> 
> ·         Web Services Security: Secure SOAP Message Exchange
> 
> ·         Web Services Security: Core Specification (see note)
> 
> [Note] The team was split on whether to provide "Core Specification" as 
> an option.  The two opinions were a) this is the key document of the 
> set, and b) the name does not reflect the restricted, explicit scope of 
> the document.
> 
>  
> 
>    1. The additional documents that have been drafted thus far deal with
>       the use of various security token formats within the context of
>       the SOAP message headers.  These draft documents currently are
>       labeled as "Binding" documents.  The OASIS SAML TC uses the term
>       "Profile" for such documents. Either term should be acceptable. 
>       It is recommended here that these usage documents be referred to
>       as "Token Profile" documents.  Thus, we currently would have the
>       following set of documents:
> 
> ·         Web Services Security: X509 Token Profile
> 
> ·         Web Services Security: Kerberos Token Profile
> 
> ·         Web Services Security: SAML Token Profile
> 
> ·         Web Services Security: XrML Token Profile
> 
>  
> 
> Rob Philpott
> RSA Security Inc.
> The Most Trusted Name in e-Security
> Tel: 781-515-7115
> Mobile: 617-510-0893
> Fax: 781-515-7020
> mailto:rphilpott@rsasecurity.com
> 
>  
> 
>  
>