Re: [wss] Issue 250: ValueType --> TokenType+ReferenceType?

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

DeMartini, Thomas wrote:

>There are three places that can have a ValueType attribute:
>BinarySecurityToken, Reference, and KeyIdentifier.  These are listed
>below along with their respective semantics and currently defined
>possible values (from core, username, x.509, rel, and saml).
>  
>
issue 250 was raised on the use of the ValueType attribute in STR's, and 
the different
meanings for this Attribute in the 2 different contexts of its use 
within STR's.
IMV, we should not  lump the use of the BST.ValueType attribute into 
this issue.

IMV, the BST attribute and the STR attribute(s) used to type referenced 
tokens
should use the same values for the same token types, but other than 
that, I would
prefer to focus this discussion on the use of ValueType in STRs.

>---------------------------------------------------------------------
>
>=====================================================================
>/wsse:BinarySecurityToken/@ValueType
>=====================================================================
>
>Semantics:
>
>The ValueType attribute is used to indicate the "value space" of the
>encoded binary data (e.g. an X.509 certificate). The ValueType attribute
>allows a URI that defines the value type and space of the encoded binary
>data. Subsequent specifications MUST define the ValueType value for the
>tokens that they define. The usage of ValueType is RECOMMENDED.
>
>Allowed Values:
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#X509v3
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#X509PKIPathv1
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#PKCS7
>
>=====================================================================
>/wsse:SecurityTokenReference/wsse:Reference/@ValueType
>=====================================================================
>
>Semantics:
>
>This optional attribute specifies a URI that is used to identify the
>type of token being referenced. This specification does not define any
>processing rules around the usage of this attribute, however,
>specifications for individual token types MAY define specific processing
>rules and semantics around the value of the URI [attribute] and how it
>SHALL be interpreted. If this [ValueType] attribute is not present, the
>[value of the] URI [attribute] MUST be processed as a normal URI. The
>ValueType attribute is RECOMMENDED for BinarySecurityToken and
>RECOMMENDED for Reference with non-local URI [as the value of the URI
>attribute].
>
>Allowed Values:
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-p
>rofile-1.0#UsernameToken
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#X509v3
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#X509PKIPathv1
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#PKCS7
>http://docs.oasis-open.org/wss/2004/##/oasis-######-wss-REL-token-profil
>e-1.0#license
>
>=====================================================================
>/wsse:SecurityTokenReference/wsse:KeyIdentifier/@ValueType
>=====================================================================
>
>Semantics:
>
>The optional ValueType attribute is used to indicate the type of
>KeyIdentifier being used. Each specific token profile specifies the
>KeyIdentifier types that may be used to refer to tokens of that type. It
>also specifies the critical semantics of the identifier, such as whether
>the KeyIdentifier is unique to the key or the token. If no value is
>specified then the key identifier will be interpreted in an
>application-specific manner.
>
>Allowed Values:
>
>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
>le-1.0#X509SubjectKeyIdentifier
>http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-x509-token-profi
>le-1.1#X509ThumbprintSHA1
>http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profi
>le-1.0#SAMLAssertionID
>
>---------------------------------------------------------------------
>
>Looking at this, so far it seems to me that everything is consistent and
>makes sense.  In the case of BinarySecurityToken, there is no reference,
>so the ValueType naturally speaks directly about the type of token.  In
>the case of SecurityTokenReference/Reference, the ValueType speaks
>primarily about the type of the token, since syntax/semantics of URIs
>are already defined by the URI specification.  In the case of
>SecurityTokenReference/KeyIdentifier, the ValueType speaks primarily
>about the type of the keyidentifier and incidentally speaks about the
>type of token by way of what can be expected based on the specific type
>of keyidentifier.
>
>While I can agree with the stylistic purity arguments in issue 250, I
>don't see any technical deficiency with the current approach.  Given we
>are creating a 1.1, I think we need to establish a larger burden of
>proof for changes than stylistic purity.  What would convince me is a
>
The intent of the proposal was to seperate the info being conveyed in 
these valuetype
attributes, such that there is always a place to convey both reference 
type and
token type, and such that the need to differentiate a new version of a 
token or of  a new
reference type, need not impact the interpretation of the other info.

KeyIdentifiers are NOT required to identify the type of the referenced 
token. As it turns out,
we have universally found it necessary to do so. By defining a a new 
token type attribute on STR,
and requring that all future profiles set this attribute, we would  not 
be adversely effecting exiting
implementations, while at the same time, we would be stabilizing, or at 
least slowing the introduction
of new keyIdentifier value types.

IMV, the recent addition to the description of the use of ValueType in 
Direct references, is one
indication of the recurring need to identify the type of a referenced 
token in the reference.

>The ValueType attribute is RECOMMENDED for BinarySecurityToken and
>RECOMMENDED for Reference with non-local URI [as the value of the URI
>attribute].
>  
>
As is the case with keyIdentifiers, and was recently added for 
references to BST's, we are finding it
desirable, if not necessary to type the token in the token reference. 
IMV, we should deprecate the
use of ValueType in (direct) References and require that this value be 
set using a new top
level token type attribute.

In our discussions of issue 310, we are considering adding support for 
multiple reference elements
(of different types) within a single STR. IF we do this, it would seem 
like representing the type of
the referenced token, in one place, above the alternative references, 
would free us from having to
ensure consistency among the various reference polluted type values.

>specific example of a situation we want to accommodate that cannot be
>accommodated with the current approach.  For example, I get a sense from
>reading issue 250 that there is a concern that there might be a specific
>type of keyidentifier that could resolve to any type of token and that,
>in that case, the ability to "incidentally speak about the type of token
>by way of what can be expected based on the specific type of
>keyidentifier" is not sufficient.  Is this correct?  If so, what
>
not yet, but with the current schema, it is unlikely that that could be 
the case.

Another dimension to token type is token version. For example, with the 
current scheme,
a keyIdentfier based lookup of a version 1.1 saml  assertion would 
represent both that the
identifier is an asertion id, and that the the type of the referenced 
token is a saml 1.1 assertion.
Support for 2.0 assertions would require a new keyIdentfier type value, 
even  though/if the
method of deferencing the assertion has remained unchanged across the 
versions.

Ron

>specific type of keyidentifier do we have in mind that would have these
>properties?  What is its syntax?  What is its semantics?  Where will it
>be defined?
>  
>
>&Thomas.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
>
>  
>