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

[Anthony Nadalin <drsecure@us.ibm.com>]

Ron,

Can you put some context around this sequence of notes ? Are you proposing
something here ?

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122


|---------+---------------------------->
|         |           Ron Monzillo     |
|         |           <ronald.monzillo@|
|         |           sun.com>         |
|         |                            |
|         |           04/22/2003 11:07 |
|         |           AM               |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                              |
  |       To:       wss@lists.oasis-open.org                                                                                                     |
  |       cc:                                                                                                                                    |
  |       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
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>