xcbf message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xcbf] WSS-XCBF value space
- From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
- To: "[OASIS XCBF]" <xcbf@lists.oasis-open.org>
- Date: Sun, 24 Nov 2002 08:17:22 -0500
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