Alternative protocol models

[Philip Hallam-Baker <pbaker@verisign.com>]

Collegues, 

	Below are some possible schema fragments concerning the possible
arrangement of the toplevel elements in the assertion. My belief is that the
contentious issues (if any) concern the arrangement at this level rather
than the specific semantics of the component parts:
o	SAML Assertion
SAML specifies several different types of assertion for different purposes,
these are:
	Authentication Assertion
	Attribute Assertion
	Decision Assertion
The different types of SAML assertion are encoded in a common XML package
which at a minimum consists of:
	Basic Information.
	Each assertion MUST specify a unique identifier that serves as a
name for the assertion. In addition an assertion MAY specify the date and
time of issue and the time interval for which the assertion is valid.
	Claims.
	The claims made by the assertion. This document describes the use of
assertions to make claims for Authorization and Key Delegation applications.
In addition an assertion MAY contain the following additional elements. An
SAML client is not required to support processing of any element contained
in an additional element with the sole exception that an SAML client MUST
reject any assertion containing a Conditions element that is not supported.
	Conditions.
	The assertion status MAY be subject to conditions. The status of the
assertion might be dependent on additional information from a validation
service. The assertion may be dependent on other assertions being valid. The
assertion may only be valid if the relying party is a member of a particular
audience.
	Advice.
	Assertions MAY contain additional information as advice. The advice
element MAY be used to specify the assertions that were used to make a
policy decision.
The SAML assertion package is designed to facilitate reuse in other
specifications. For this reason XML elements specific to the management of
authentication and authorization data are expressed as claims. Possible
additional applications of the assertion package format include management
of embedded trust roots [XTASS] and authorization policy [XACML].
The <Assertion> element is specified by the following schema:
<element name="Assertion">
   <complexType>
      <sequence>
			<!-- Basic Information -->
         <element name="AssertionID" type="s0:AssertionID"/>
         <element name="RequestID" type="s0:AssertionID"/>
         <element name="Issuer" type="string"/>
         <element name="ValidityInterval" type="s0:ValidityInterval"/>

         <!-- Data -->
         <element name="Claims" type="s0:Claims"/>
         <element name="Conditions" type="s0:Conditions"/>
         <element name="Advice" type="s0:Advice"/>

     </sequence>
  </complexType>
</element>
o	SAML Request
*	Request by Identifier or Location
An assertion MAY be requested by means of the assertion identifier or a
location in which the assertion is stored.
*	Request by Query
An assertion MAY be requested by means of a query. 
The query specifies the principal and the resources for which access is
requested by use of the claim element syntax. The information requested in
the response is specified by means of the Respond element described in
section 3.3.3.
[Discuss]
<element name="SAMLQuery">
   <complexType>
      <sequence>
			<!-- Basic Information -->
         <element name="RequestID" type="s0:AssertionID"/>
         <element name="ValidityInterval" type="s0:ValidityInterval"/>

         <!-- Data -->
         <element name="Query"       type="s0:Claims"/>
         <element name="Conditions"  type="s0:Conditions"/>
         <element name="Advice"      type="s0:Advice"/>

         <element name="Respond"     type="s0:Respond"/>
     </sequence>
  </complexType>
</element>
*	Element <Respond> 
The <Respond> element in the request specifies one or more strings included
in the request that specify data elements to be provided in the response. 
The Service SHOULD return a requested data element if it is available. The
Service MAY return additional data elements that were not requested. In
particular, the service MAY return data elements specified in the request
with the response.
Defined identifiers include:
Identifier	Description	
Decision	Return the result of the Query (True/False).	
Static	Specifies that the response may return any data element and omit the
RequestID specified in the request. Thus allowing the responder to return a
static pre-signed assertion.	
ValidityInterval	Return the ValidityInterval element	
Conditions	Return the assertion conditions	
Claims	Return the assertion claims	
Advice	Return additional advice elements	
The <Respond> element is defined by the following schema:
<element name="Respond" >
   <complexType>
      <sequence>
         <element name="string" type="string" 
               minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
   </complexType>
</element>
o	SAML Response
[An alternative packaging that might be desirable would be to specify a
query response. In this case the natural location for the Request ID would
be here]
<element name="SAMLQuery Response">
   <complexType>
      <sequence>
			<!-- Basic Information -->
         <element name="RequestID"   type="s0:AssertionID"/>
         <element name="Decision"    type="s0:Decision"/>
         <element name="Assertion"   type="s0:Assertion"/>

     </sequence>
  </complexType>
</element>


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227 <<Phillip Hallam-Baker (E-mail).vcf>>

Phillip Hallam-Baker (E-mail).vcf