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] WSS-XCBF value space


Monica,

Note that WSS-XCBF does not define a value space in its section
4.2 as done in the corresponding WSS-X509 section 3.2:

   The following value spaces are defined for @ValueType:

       QName                       Description
       wsse:X509v3              X.509 v3 certificate

The WSS-X509 authors use this name only in the ValueType attribute
in the wsse:BinarySecurityToken header to identify the token content in
this document. But they make important use of this in the WSS-Core
specification.

In WSS-XCBF, I merely listed the three attributes we used in a table,
and made no reference to @ValueType. So I wonder two things really:

    Does our use of the ValueType= attribute used in the binary security
    token problematic and introduce ambiguity?

    Do I need to state that this is part of a value space? If so, should I
    really be defining this as xcbf:ValueType to avoid conflict with their
    use of wsse:ValueType? Note that in WSS-Core line 544 they
    note that this attribute is extensible using namespaces. This
    makes me think that I need to define a namespace for XCBF
    to remove this ambiguity in the attributes in the header. But when
    I look at their use of EncodingType a few lines later, I think that
    instaed of an XCBF namespace that what I really need is for the
    core document to be changed to include wsee:XCBFv1, and our
     wsse:XER and wsse:DER encoding types.

The deeper I get into this the more I see the XCBF token as part of the
core specification, a new security token format, rather than as a seperate
binding document. And I see the need for another such token type to
support generalized PKCS #7 CMS messages.

Ultimately, my goal is to have WSS broaden their section 6.1 User Name
Token to include a biometric identifier. Right now they only include user
ID and password. Ideally, biometrics are part of a multifactor authentification
strategy and used along with harware tokens or pass phrases to enhace the
security and ease of use of accessing a system.

This is how I truely see XCBF adding value to WSS. I wonder if there will
be any support for this addition? If they want to support single sign-on that
has a biometrics capability then this is where the rubber meets the road. This
section 6.1 is where I'd make use of the @ValueType and other namespace
values defined in WSS-XCBF.

Phil



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


Powered by eList eXpress LLC