OpenID Signed Assertions 1.0 - Draft 1

Sun, 03 Dec 2006 21:42:28 -0800 

Hello List
Attached is a specification for using SAML to bind properties to an OpenID Identifier. The mechanism for refreshing the Assertion still needs to be worked out. Look forward to discussing this and the Attribute Exchange specifications at IIW with those of you there. 

-- Dick



Title: Draft: OpenID Signed Assertions 1.0 - Draft 01





 TOC 




DraftD. Hardt


 Sxip Identity


 November 2006





OpenID Signed Assertions 1.0 - Draft 01



Abstract




	This document describes a SAML assertion schema extension for
	encoding third-party attested attribute value claims as
	OpenID attributes for use with the OpenID Attribute eXchange
	service.
      




Table of Contents



1. 
Introduction

2. 
Terminology

    2.1. 
Definitions and Conventions

3. 
SAML Introduction

    3.1. 
SAML Assertions

4. 
Employing SAML in OpenID

    4.1. 
Assertion Attributes

5. 
OpenID SAML Attribute Profile

    5.1. 
Required Information

    5.2. 
SAML Attribute Naming

    5.3. 
Profile-Specific XML Attributes

    5.4. 
SAML Attribute Values

    5.5. 
Example

6. 
Assertion Schema Extension

    6.1. 
Element openid:Assertion

        6.1.1. 
Element saml:Assertion

7. 
OpenID Assertion Schema

8. 
Refreshing an Assertion

9. 
Example Signed SAML Assertion

10. 
Security Considerations

11. 
Acknowledgements

12. 
References

    12.1. 
Normative References

    12.2. 
Informative References

§ 
Author's Address









 TOC 


1. 
Introduction




	This document specifies an assertion schema extension of the
	Security Assertion Markup Language (SAML) V2.0 called 'OpenID
	Signed Assertions', for use with the OpenID [OpenID.authentication‑2.0] (Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 - Draft 10,” August 2006.) Attribute eXchange
	service [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.).
      




	Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is
	an XML-based framework for creating and exchanging security
	information.  The SAMLv2 specification set is normatively
	defined by [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
      





 TOC 


2. 
Terminology




	The key words "MUST", "MUST NOT",
	"REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT",
	"RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as
	described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
      





 TOC 


2.1. 
Definitions and Conventions




	  [NOTE: Update terminology based on final OpenID 2.0 draft.]
	




	  In this specification, the term, or term component,
	  "SAML" refers to SAML V2.0 in all cases. For
	  example, the term "SAML assertion" implicitly
	  means "SAMLv2 assertion".
	



      
	  For overall SAML terminology, see [OASIS.saml‑glossary‑2.0‑os] (Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
	




	  Conventional XML namespace prefixes are used throughout this
	  specification to stand for their respective namespaces as
	  follows, whether or not a namespace declaration is present
	  in the example:
	  




Prefix: openid



	      XML Namespace: http://openid.net/xmlns/2.0.
	    



Prefix: ds



	      XML Namespace: http://www.w3.org/2000/09/xmldsig#.  This
	      namespace is defined in the XML Signature Syntax and
	      Processing specification [W3C.REC‑xmldsig‑core‑20020212] (Solo, D., Eastlake, D., and J. Reagle, “XML-Signature Syntax and Processing,” February 2002.) and its governing schema.
	    



Prefix: saml



	      XML Namespace: urn:oasis:names:tc:SAML:2.0:assertion.
	      This is the SAML V2.0 assertion namespace [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.). 
	    



						
	





 TOC 


3. 
SAML Introduction




	SAML [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.) defines an
	XML-based framework for exchanging "security
	assertions" between entities.
      




	SAML can be employed to make and encode statements such as
	"Beth has these profile attributes and her domain's
	certificate is available over there, and I'm making this
	statement, and here's who I am."
      




	A SAML assertion profile is the specification of the assertion
	schema extension in the context of a particular SAML profile.
	It is possibly further qualified by a particular
	implementation and/or deployment context.  Condensed examples
	of SAML assertion profiles are:
	


    

  • 
	    The SAML assertion must contain at least one
	    authentication statement and no other statements.  The
	    relying party must be represented in the
	    <AudienceRestriction> element.  The
	    SubjectConfirmation Method must be Foo. etc.
	  

    • 

  • 
	    The SAML assertion must contain at least one attribute
	    statement and may contain more than one.  The values for
	    the subject's profile attributes named "Foo" and
	    "Bar" must be present.  An authentication
	    statement may be present. etc.
	  

    • 


      





 TOC 


3.1. 
SAML Assertions




	  A SAML assertion is a package of information including
	  issuer and subject, conditions and advice, and/or attribute
	  statements, and/or authentication statements and/or other
	  statements.  Statements may or may not be present.  The SAML
	  assertion "container" itself contains the following
	  information:
	  




Issuing information:



	      Who issued the assertion, when was it issued and the
	      assertion identifier.
	    



Subject information:



	      The name of the subject, the security domain and
	      optional subject information, like public key.
	    



Conditions under which the assertion is valid:



	      Special kind of conditions like assertion validity
	      period, audience restriction and target restriction.
	    



Additional advice:



	      Explaining how the assertion was made, for example.
	    




	




	  In terms of SAML assertions containing SAML attribute
	  statements, here is an explanatory example:
	  





	      With a SAML assertion containing a SAML attribute
	      statement, an issuing authority is asserting that the
	      subject is associated with certain attributes with
	      certain subject profile attribute values. For example,
	      user http://www.home.com/beth is
	      associated with the attribute http://openid.net/schema/contact/internet/email,
	      which has the value [EMAIL PROTECTED].
	    




	





 TOC 


4. 
Employing SAML in OpenID




	Employing SAML in OpenID necessitates devising a new SAML
	Assertion Profile and a new SAML Attribute Profile because
	those already specified in the SAMLv2 specification set are
	specific to other use contexts and use cases. This does not
	present any untoward difficulties due to SAML's inherent and
	explicit extensibility.
      





 TOC 


4.1. 
Assertion Attributes




	  The OpenID attribute exchange service [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.) is used to convey
	  SAML assertions within an OpenID protocol session.  In
	  effect, a SAML assertion is used as an envelope to contain
	  conventional OpenID attribute value pairs.  This envelope is
	  then assigned as a value for the SAML assertion attribute
	  type.  An attribute value that contains a SAML assertion
	  MUST be base 64 [RFC3548] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded.
	




	  Assertion attribute names MAY be any unique identifier as
	  outlined in [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.).
	





 TOC 


5. 
OpenID SAML Attribute Profile



 
	The OpenID Attribute Profile specifies how OpenID attributes
	can be represented as SAML Attributes.
      



 
	An OpenID attribute is an property value assertion that can
	either be self asserted or asserted by a third party. An
	example of a third party assertion would be a government
	agency aserting that Beth is older than 21. This Attribute
	Profile describes a OpenID attribute represented as a SAML
	Assertion.
      





 TOC 


5.1. 
Required Information




	  The information given in this section is similar to the
	  information provided when registering something, a MIME
	  Media Type, say, with IANA.  In this case, it is for
	  registering this profile with the OASIS SSTC. See section 2
	  "Specification of Additional Profiles" in [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
	




	  




Identification:



	      TBD: urn:openid:saml-profile:attribute or http://openid.net/saml-profile/attribute
	    



Contact Information:



	      TBD: someone's or something's contact info goes here.
	    



Description:



	      Given below.
	    



Updates:



	      None.
	    




	





 TOC 


5.2. 
SAML Attribute Naming




	  The NameFormat XML attribute in <Attribute> must be
	  urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri.  The
	  Name XML attribute MUST be the OpenID attribute name and
	  MUST adhere to the rules specified for that format.  OpenID
	  attribute names are defined in [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.).  SAML Attribute
	  Name formats are defined in [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
	





 TOC 


5.3. 
Profile-Specific XML Attributes




	  No additional XML attributes are defined for use with the
	  <Attribute> element.
	





 TOC 


5.4. 
SAML Attribute Values




	  The <AttributeValue> MUST be the OpenID attribute
	  value, as defined in [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.).
	





 TOC 


5.5. 
Example



<saml:Attribute
  NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"
  Name="http://openid.net/schema/contact/internet/email">
  <saml:AttributeValue>
    [EMAIL PROTECTED]
  </saml:AttributeValue>
</saml:Attribute>






 TOC 


6. 
Assertion Schema Extension




	An OpenID attribute value may be asserted by the user or by a
	third-party.  Third-party asserted attribute values include
	meta-data about the assertion in part to enable the recipient
	to verify the validity of the assertion.  There are multiple
	possible ways of encoding a third-party assertion, and
	multiple possible ways to verify them.  A SAML Assertion is
	one such encoding, and a digital signature is one verification
	mechanism.
      




	This section defines the particulars of how the sender,
	i.e. the SAML Authority, constructs certain portions of the
	SAML assertions it issues.  The schema for SAML assertions
	themselves is defined in Section 2.3 of [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
      




	An example SAML assertion, formulated according to this
	profile is given in Section 9 (Example Signed SAML Assertion).
      




	Overall SAML assertion profile requirements:
	





	    The SAML assertion MUST be signed by the same key as used
	    to sign the contents of the Identity header field. Signing
	    of SAML assertions is defined in section 5.4 of [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
	  




      




	In the following subsections, the SAML assertion profile is
	specified element-by-element, in a top-down, depth-first
	manner, beginning with the outermost element,
	"<OpenIDAssertion>". This specification
	introduces the "<OpenIDAssertion>" element as
	a wrapper around the SAML "<Assertion>"
	element to add OpenID meta-data to the assertion.  Where
	applicable, the requirements for an element's XML attributes
	are also stated, as a part of the element's description.
	Requirements for any given element or XML attribute are only
	stated when, in the context of use of this profile, they are
	not already sufficiently defined by [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
      





 TOC 


6.1. 
Element openid:Assertion




	  




Attribute openid:RefreshURL



	      RefreshURL is an OPTIONAL XML attribute that, if
	      specified, SHOULD be set to the URL where an updated
	      assertion can be requested as per Section 8 (Refreshing an Assertion). 
	    




	





 TOC 


6.1.1. 
Element saml:Assertion




	    




Attribute: ID



		The value for the ID XML attribute SHOULD be allocated
		randomly such that the value meets the randomness
		requirements specified in section 1.3.4 of [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language 	  (SAML) V2.0,” March 2005.).
	      



Attribute: IssueInstant



		The value for the IssueInstant XML attribute SHOULD be
		set at the time the SAML assertion is created (and
		cached for subsequent retrieval).
	      




	  





 TOC 


6.1.1.1. 
Element saml:Issuer




	      If the signature contains a ds:X509Certificate, the
	      value for the Issuer XML element SHOULD be a value that
	      matches either the Subject or the Subject Alternative
	      Name fields [RFC3280] (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.) in the certificate.
	      The certificate element is located on this path within
	      the SAML assertion:
	      


<saml:Assertion
  <ds:Signature
    <ds:KeyInfo
      <ds:X509Data
        <ds:X509Certificate



	      In this case the Issuer element is in the format of the
	      X.501 type Name.
	    




	      Assertions with signatures that do not contain an
	      X509Certificate may use an issuer identifier that
	      matches the ds:KeyName element (see [W3C.REC‑xmldsig‑core‑20020212] (Solo, D., Eastlake, D., and J. Reagle, “XML-Signature Syntax and Processing,” February 2002.)).
	    





 TOC 


6.1.1.2. 
Element saml:Subject




	      The <saml:Assertion> element MUST contain a
	      <saml:Subject> element.
	    




	      The <saml:Subject> element MUST contain a
	      <saml:NameID> element.
	    




	      The value of the <saml:NameID> element is a
	      subject identifier, either a Claimed Identifier or IdP
	      Identifier in OpenID parlance.
	    





 TOC 


6.1.1.3. 
Element saml:Conditions




	      The following XML attributes of the <saml:Conditions>
	      element MAY be set as follows:
	      




Attribute: NotBefore



		  The value of the NotBefore XML attribute must be set
		  to a time instant the same as the value for the
		  IssueInstant XML attribute discussed above, or to a
		  later time.
		



Attribute: NotOnOrAfter



		  The value of the NotOnOrAfter XML attribute MUST be
		  set to a time instant later than the value for
		  NotBefore.
		




	    





 TOC 


6.1.1.4. 
Element saml:AttributeStatement




	      The SAML assertion MUST contain a single
	      <saml:AttributeStatement> element. The
	      <saml:AttributeStatement> element MUST contain one
	      or more attribute-value pair, encoded according to the
	      OpenID attribute schema extension Section 5 (OpenID SAML Attribute Profile).  It is RECOMMENDED that the
	      number of <saml:Attribute> elements within the
	      <saml:AttributeStatement> be limited to one.
	    





 TOC 


7. 
OpenID Assertion Schema




      


<?xml version="1.0" encoding="UTF-8"?>
<!-- XML Schema for OpenIDAssertion -->
<schema
  targetNamespace="http://openid.net/xmlns/2.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  xmlns:openid="http://openid.net/xmlns/2.0"
  elementFormDefault="unqualified"
  attributeFormDefault="unqualified"
  blockDefault="substitution"
  version="1.0">

  <import
    namespace="urn:oasis:names:tc:SAML:2.0:assertion"
    schemaLocation="http://docs.oasis-open.org/security/
                    saml/v2.0/saml-schema-assertion-2.0.xsd"/>

  <element name="Assertion" type="openid:AssertionType"/>
  <complexType name="AssertionType">
    <sequence>
      <element ref="saml:Assertion" minOccurs="0" maxOccurs="1"/>
    </sequence>
    <attribute name="RefreshURL" type="anyURI" use="optional"/>
  </complexType>

</schema>



      





 TOC 


8. 
Refreshing an Assertion




	The mechanism for refreshing an assertion based on the
	RefreshURL attribute of the openid:AssertionType element is
	not presently defined.  [TBD: define refresh protocol]
      




	The RefreshURL attribute may be supplied by an asserting
	party, but SHOULD NOT be supplied to relying parties in
	general when it is retrieved from an identity provider.  This
	is in keeping with the rule of minimal disclosure.
      





 TOC 


9. 
Example Signed SAML Assertion




	Below is an example of a signed SAML assertion:
	



<openid:Assertion
   xmlns:openid="http://openid.net/xmlns/2.0"
   RefreshURL="http://example-verified-email.com/renew">

<Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
   IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
   xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
   <Issuer>
      example-verified-email.com
   </Issuer>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
   <ds:CanonicalizationMethod
      Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   <ds:SignatureMethod
      Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
   <ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
      <ds:Transforms>
         <ds:Transform
            Algorithm=
            "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
         <ds:Transform
            Algorithm=
            "http://www.w3.org/2001/10/xml-exc-c14n#">
      <InclusiveNamespaces
            PrefixList="#default saml ds xs xsi"
            xmlns=
            "http://www.w3.org/2001/10/xml-exc-c14n#"/>
         </ds:Transform>
      </ds:Transforms>
      <ds:DigestMethod
            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <ds:DigestValue>
            Kclet6XcaOgOWXM4gty6/UNdviI=
      </ds:DigestValue>
   </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>
        hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubnmIfZ6RqVL+wNmeWI4=
      </ds:SignatureValue>
      <ds:KeyInfo>
   <ds:X509Data>
       <ds:X509Certificate>
    MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
    MRIwEAYDVQQIEwlXaXNjb .....  dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX
    8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==
       </ds:X509Certificate>
   </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
   <Subject>
      <NameID
        Format=
           "urn:oasis:names:tc:SAML:1.1:nameid-format:entity">
        http://www.home.com/beth
      </NameID>
   </Subject>
   <Conditions NotBefore="2003-04-17T00:46:02Z">
   </Conditions>
   <AttributeStatement>
     <Attribute
       NameFormat=
       "urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"
       Name="http://openid.net/schema/contact/web/blog">
       <AttributeValue>http://bethexample.blogspot.com</AttributeValue>
    </Attribute>
  </AttributeStatement>
</Assertion>
</openid:Assertion>




      





 TOC 


10. 
Security Considerations




	[NOTE: TBD]
      





 TOC 


11. 
Acknowledgements




	The author, John Merrels, and other contributors to the
	document 'draft-merrels-dix-assertion'.  Portions of that
	document were re-used for this one.
      





 TOC 


12. 
References





 TOC 


12.1. Normative References




[OASIS.saml-conformance-2.0-os]
Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language
	  (SAML) V2.0,” OASIS Standard saml-conformance-2.0-os, March 2005.


[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language
	  (SAML) V2.0,” OASIS Standard saml-core-2.0-os, March 2005.


[OASIS.saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language
	  (SAML) V2.0,” OASIS Standard OASIS.saml-profiles-2.0-os, March 2005.


[OpenID.attribute-exchange-1.0]
Hardt, D., “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006 (TXT, HTML).


[OpenID.authentication-2.0]
Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 - Draft 10,” August 2006 (TXT, HTML).


[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


[RFC3280]
Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 3280, April 2002.


[RFC3548]
Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548, July 2003.


[W3C.REC-xmldsig-core-20020212]
Solo, D., Eastlake, D., and J. Reagle, “XML-Signature Syntax and Processing,” W3C Recommendation http://www.w3.org/TR/2002/REC-xmldsig-core-20020212, February 2002.







 TOC 


12.2. Informative References




[OASIS.saml-glossary-2.0-os]
Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language
	  (SAML) V2.0,” OASIS Standard saml-glossary-2.0-os, March 2005.


[OpenID.attribute-types-1.0]
Hardt, D., “OpenID Attribute Types - Draft 02,” November 2006 (TXT, HTML).







 TOC 


Author's Address




 
Dick Hardt


 
Sxip Identity


 
798 Beatty Street


 
Vancouver, BC  V6B 2M1


 
CA


Email: 
[EMAIL PROTECTED]


URI: 
http://sxip.com/





_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs






















					Reply via email to