At 10:26 PM 6/6/2003, DeMartini, Thomas wrote:
I'm afraid my XML is too weak to understand this proposal. I don't know
what the "ValueTypes" are and where they appear in the Security
header.
Everything we define is already in wsse. Profiles can't always
define things they use because they sometimes need to use XML defined by
other organizations, e.g. the SAML profile. And they can't modify
wsse because we want other organizations to be able to define profiles in
the future without any association with this TC.
So within those constraints, if I'm defining a new profile what do I do
to ensure that it is possible to determine from a Security element where
that new profile is being used?
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
