RE: [wss] ISSUE 62: Versioning

[Tim Moses <tim.moses@entrust.com>]

Colleagues - Thomas's proposal sounds fine to me.  It does suggest that the
QNames we choose for our own profiles should incorporate a version
identifier.  Is there any chance that this group could define more than one
set of processing rules for the same token type?  If not, then simply
appending a version number to the local part of the QName would be
sufficient.  All the best.  Tim.

-----Original Message-----
From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
Sent: Saturday, June 07, 2003 3:54 AM
To: Jerry Schwarz; WSS
Subject: RE: [wss] ISSUE 62: Versioning


The core WSS specification defines that wsse:BinarySecurityToken,
wsse:SecurityTokenReference, and wsse:KeyIdentifier can have a ValueType
attribute.
 
The ValueType attribute can be any QName.  (The core WSS specification uses
an example x:MyType.)  In my understanding, the profiles are supposed to
define the QNames to be used for the respective profiles and the semantics
of using those QNames.
 
Some of the profile documents we have already use wsse QNames, but others do
not.  If each profile document uses QNames that are under their control,
then the QNames can be used to indicate the profile and can be versioned
accordingly.  It also avoids the possibility that two profiles from
different people specify the use of the same QName for the ValueType.
 
At least in WSS we should use wsse namespace for our profile document QNames
since that namesapce is under our control and we can version it
appropriately.  If we wish to require others to follow the same convention,
we could add a provision to the core document that says they should do so.
This way we would not need a Version attribute and there will not be risk of
confusion over ValueTypes.
 
So, to answer your question directly, if you are defining a new profile, in
your profile you will specify some QNames to put in ValueType to indicate
when your profile is being used.  Lets say you are defining a profile for
the Thomas token.  You are Jerry, so the namespace under your control is
jerry.  So, when you define a profile, you will define QNames in the jerry
namespace.  Version 1 of your Thomas token profile may define a QName like
jerry:thomas-a.  If Version 2 of your Thomas token profile is
backwards-compatible with Version 1, then you may wish to reuse
jerry:thomas-a because there is no compatibility issue.  If, however, there
is a compatibility concern, you may in your Version 2 document define a
QName like jerry:thomas-b.  Whenever jerry:thomas-a or jerry:thomas-b
appears on a ValueType attribute in a security header, the implementation
will know what profile is being used (and will also know whether or not the
version of the profile being used is compatible with the versions of that
profile supported by the implementation) or will know that it does not
support the profile or version of the profile being used.
 
Thanks,
Thomas.

	-----Original Message----- 
	From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com] 
	Sent: Fri 6/6/2003 11:55 PM 
	To: DeMartini, Thomas; WSS 
	Cc: 
	Subject: RE: [wss] ISSUE 62: Versioning
	
	
	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:jerry.schwarz@oracle.com] 
		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