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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


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


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>

    1. 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>

  



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


Powered by eList eXpress LLC