[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] ISSUE 62: Versioning
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-----
/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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]