[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wss] Document Naming Action Item
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> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC