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