Issue 250: ValueType --> TokenType+ReferenceType?

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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).

---------------------------------------------------------------------

=====================================================================
/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
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
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.