OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]