OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xcbf] [Fwd: Re: [wss] Document Naming Action Item]


FYI.
Phil

-------- Original Message --------
Subject: Re: [wss] Document Naming Action Item
Date: Fri, 27 Sep 2002 06:27:30 -0700
From: Donald Adams <dadams@tibco.com>
To: Phil Griffin <phil.griffin@asn-1.com>
CC: wss@lists.oasis-open.org
References: 
<F504A8CEE925D411AF4A00508B8BE90A03699F94@exna07.securitydynamics.com> 
<3D9447B2.2070305@asn-1.com>

Phil;
I agree that these options need to be considered. This is part of
why I recommended at the F2F that we have a liason with the
XCBF TC. Over time I expect to see biometrics as a requirement
rather than option in distributed business environments that WSS
and its successors will help enable.
-Don

Phil Griffin wrote:

 > 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
 >>
 >>
 >>
 >>
 >>
 >
 >
 >
 > ----------------------------------------------------------------
 > To subscribe or unsubscribe from this elist use the subscription
 > manager: <http://lists.oasis-open.org/ob/adm.pl>
 >
 >




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC