[wss] New issue: profile version identification

[ronald monzillo <ronald.monzillo@sun.com>]

Jerry did a good job of describing the issue, which I have preserved.

Jerry Schwarz wrote:

> A. Profiles are specifying "identification", but there isn't any place 
> to put it.  That there is no way to specify what profile or version 
> the profile a security token (or SecurityTokenReference) is being used.

Token specific profiles of wss-security are identified by URN; but as 
Jerry points out, the specification
has not defined how the version of a token specific binding is 
identified in security tokens, signatures, or
security token references, resulting form the use of the profile.

I propose that versioning of security tokens is the responsability of 
the designers of the security token
and that the specification of security token version identifiers need 
not and should not be the
responsability of the binding of the token to ws-security. The 
distintion is less clear when
the security token (e.g. username/password) is being defined by ws-security.

It would seem that the security token reference forms used in a token 
specific binding of
ws-security should indicate the version of the binding that yielded the 
reference. Following our earlier
discussions I propose that this should be accomplished by addding a 
mandatory ProfileVersion attribute to
the security token reference element.

A mandatory ProfileVersion attribute on the STR will not facilitate the 
versioning of
non-STR (e.g. keyName) token references. I propose that such references 
need not be
versioned.

I see 2 potential problems with this approach.

1. A manadatory binding/profile version attribute in the STR will 
implicitly identify
    the type of the referenced token. This information may introduces a 
measure
    of redundancy WRT the ValueType attribute.

2. Because this attribute was proposed as mandatory, its affect would be 
to require
    a message sender to implicitly provide ValueType information, that 
up to now
    was optional.