Another way to address this problem might
be to have all the ValueType values defined by this TC reside in the wsse
namespace and require that they not be reused in future profiles unless the
future profiles are backward compatible with the existing one.
So, if we have a new profile version that
is backwards compatible we leave the ValueType unchanged. If we have a new profile version that
has some different semantics then we specify a different ValueType.
This way the ValueType exactly indicates
the processing rules of the value.
We do not end up in a situation where one ValueType could have two
different processing rules depending on the profile Version attribute or two
different ValueTypes could have the same processing rules because of the profile
Version attribute.
Thoughts?
&Thomas.
-----Original Message-----
From: Jerry Schwarz
[mailto:]
Sent: Wednesday, June 04, 2003
10:22 AM
To: WSS
Subject: [wss] ISSUE 62:
Versioning
As I promised, here is a proposal including exact word changes
At line 619 (of version 13, after the paragraph describing /wsse:SecurityTokenReference/@wsse:Usage) add
/wsse:SecurityTokenReference/@Version
This optional attribute indicates what profile and version
provides the semantics of this SecurityTokenReference. It is a URN specified in
some profile. For example, the identifier for version 1 of the X509
profile might be "urn:oasis:names:tc:WSS:1.0:profiles:WSS-X509"
Corresponding change to the .xsd (my xsd knowledge is
almost non-existent so this may be wrong)
add
<xsd:attribute name="Version"
type="xsd:anyURI"/>
to the definition of SecurityTokenReferenceType
If the above is accepted, then the editors of all profiles will need to
ensure that a URI is specified in that profile and I hope they could agree on
some uniform scheme.
You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
