Re: [wss] ISSUE 62: Versioning

[Ron Monzillo <ronald.monzillo@sun.com>]

The notions of ValueType and version seem to overlap (and I agree with the
idea of  extending valuetype to more precisely define the context of use).
When I fisrt looked at this I was assuming that version information woul be
manadatory, and noted that valuetype attributes are often optional. I'm not
sure if this remains a concern, as we have since discussed only needing to
include version info, when using otherthan the original verison of a 
profile.

Ron
Tim Moses wrote:

>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
>
>
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
>
>  
>