RE: [security-services] AI-19 re: Versioning in protocol messages andassertions

["Philpott, Robert" <rphilpott@rsasecurity.com>]

I believe our intent behind the versioning was as described in item b) in my attached message.  That is, Assertion and Protocol versions might change independently, but Request and Response versions should really be the same for any revision of the SAML spec.  It would seem very odd to have a Request version in the spec different from the Response version.

 

Unfortunately, defining a new "version" type and using it in new elements within the <Assertion>, <Request> and <Response> elements in the schema would not be backward compatible. So any actual changes of this sort will have to wait until V2.0 (if we do them at all).

 

In the mean time, I'm attaching a document which recommended changes to core section "4 SAML Versioning" that at least clarifies what I believe the intent should be and also cleans up some other terminology usage.

 

Please send comments... I suggest we review it and settle this on the next call.

 

Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com

-----Original Message-----
From: Philpott, Robert
Sent: Monday, January 20, 2003 11:43 PM
To: 'security-services@lists.oasis-open.org'
Subject: [security-services] AI-19 re: Versioning in protocol messages and assertions

 

Attached is the item I raised last January re: versioning in protocol messages and assertions. The referenced line numbers are no longer correct, but the point is still valid - the use of versioning in the SAML XML documents is a little ambiguous.

 

Actually, perhaps another question needs to be addressed before the specific questions below.  That is, do we need this version info in our schema at all?  The SAML protocol and assertion versions can be directly determined from the name of the schema files we define.  Is this adequate?  How do other TC's handle this issue?

Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com

-----Original Message-----
From: Philpott, Robert
Sent: Monday, January 21, 2002 2:29 PM
To: 'oasis sstc (security-services@lists.oasis-open.org)'
Subject: [security-services] comment/question on version info definition

 

Line 1229: What does it mean to call this "SAML Protocol 1.0"? 

1. Requests and Responses each have Major/Minor version info attributes, which implies that, in theory, they could be upgraded independently (I didn't see where this is explicitly prohibited).  If so, Line 1228-1229 should be explicit: "This document defines SAML Assertions 1.0, SAML Request Protocol 1.0, and SAML Response Protocol 1.0".
2. If the intent is to keep the request and response protocols synchronized with a single SAML protocol version (separate from the assertion version), then the RequestAbstractType type (3.2.1) and the ResponseAbstractType type (3.4.1) should replace the MajorVersion and MinorVersion attributes with a new <ProtocolVersionInfo> element defined something like:

<element name="ProtocolVersionInfo" type="samlp:ProtocolVersionInfoType"/>

<complexType name="ProtocolVersionInfoType">

   <attribute name="MajorVersion" type="integer" use="required"/>

   <attribute name="MinorVersion" type="integer" use="required"/>

</complexType>

3. If the intent is to keep the version info synchronized for assertions, request protocol, and response protocol, then we could use the following in the <assertion> element (2.3.3) and the request/response abstract types could include the <VersionInfo> element:

<element name="VersionInfo" type="saml: VersionInfoType"/>

<complexType name="VersionInfoType">

   <attribute name="MajorVersion" type="integer" use="required"/>

   <attribute name="MinorVersion" type="integer" use="required"/>

</complexType>

  

Attachment: SAML Versioning.doc
Description: MS-Word document