OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [Fwd: RE: [wss] New issue: profile version identification]

-------- Original Message --------
Subject: RE: [wss] New issue: profile version identification
Date: Thu, 19 Dec 2002 15:36:14 -0500
From: Tim Moses <tim.moses@entrust.com>
To: "'ronald monzillo'" <ronald.monzillo@Sun.COM>
CC: wss@lists.oasis-open.org

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:ronald.monzillo@sun.com]
Sent: Tuesday, December 17, 2002 6:42 PM
Cc: wss@lists.oasis-open.org
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 

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]