RE: [wss] New issue: profile version identification

Title: RE: [wss] New issue: profile version identification

Ron - This sounds fine to me.  It was the versioning of the "profiles", not the "tokens", that motivated the original question.  

The ProfileVersion attribute that you propose should be of type xs:anyURI, rather than xs:integer, because the "versions" may not emerge from a single configuration management body.  I.e. a body other than the WSS TC that wants to write a profile using (say) SAML tokens, should not have to have their profile recognized by the WSS TC.

Because of the redundancy that you refer to, if the ProfileVersion attribute were to be attached to the SecurityTokenReference element, does that not mean that the ValueType can remain optional?  The necessary information is available from either the ProfileVersion or the ProfileVersion and the ValueType (if it is present).

By the way, why do we have an element-name ending in "Type"?  Why don't we reserve that ending for the names of type definitions?

All the best.  Tim.

-----Original Message-----

From: ronald monzillo [mailto:]

Sent: Tuesday, December 17, 2002 6:42 PM

Cc: 

Subject: [wss] New issue: profile version identification

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.

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

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>