FastFed Enterprise SAML Profile 1.0 - draft 03
fastfed-saml-1_0

Abstract

This specification defines the requirements to implement the FastFed Enterprise SAML Profile.

Table of Contents

• 1. Introduction
• 1.1. Requirements Notation and Conventions
• 1.2. Terminology
• 2. Overview
• 3. Protocol Extensions
• 3.1. FastFed Metadata
• 3.1.1. Authentication Profile URN
• 3.1.2. Application Metadata
• 3.2. FastFed Handshake
• 3.2.1. FastFed Registration Request
• 3.2.2. FastFed Registration Response
• 4. Schema Binding
• 4.1. SCIM-to-SAML Attribute Mapping
• 4.1.1. SAML Subject
• 4.1.2. SAML Attributes
• 4.2. Privacy Considerations
• 5. Interoperability Requirements
• 5.1. Identity Provider Requirements
• 5.2. Application Provider Requirements
• 5.3. Login Hint
• 5.4. Certificate Rotation
• 5.4.1. Certificate Rotation Requirements for an Identity Provider
• 5.4.2. Certificate Rotation Requirements for an Application Provider
• 6. Security Considerations
• 7. IANA Considerations
• 8. Normative References
• Appendix A. Acknowledgements
• Appendix B. Notices
• Author's Address

1. Introduction

This specification defines the functionality which a provider must implement to satisfy the Enterprise SAMLProfile for FastFed.

It consists of the following extensions to the FastFed Core specification:

• Additional metadata in the FastFed Handshake Flows to exchange SAML Metadata URLs.
• Mapping rules for generating SAML Attributes from a SCIM 2.0 schema.
• An interoperability profile describing the subset of the SAML specifications which must be implemented in order to be FastFed Compatible.
• The mechanics of certifcate rotation for SAML.

1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

In the .txt version of this specification, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. In the HTML version of this specification, values to be taken literally are indicated by the use of this fixed-width font.

1.2. Terminology

This FastFed Profile uses the terminology defined in Section 1.2 of the FastFed Core specification.

2. Overview

When using the SAML protocol, the FastFed Identity Provider and Application Provider have various responsibilities to comply with the protocol.

The Identity Provider fulfills the role of a SAML Identity Provider. It has a responsibility to host a SAML Metadata file as described in Section 5.1.

The Application Provider fulfills the role of a SAML Application Provider. It has a responsibility to host a SAML Metadata file as described in Section 5.2

This specification extends the FastFed Core handshake messages with the additional attributes necessary for each party to fulfill their respective obligations under SAML.

3. Protocol Extensions

3.1. FastFed Metadata

3.1.1. Authentication Profile URN

This specification extends the FastFed Core Provider Metadata (Section 3.3.1) with the following value for authentication_profiles:

urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise

A Provider who includes this URN in their list of capabilities MUST comply with the requirements described in this specification.

The following is a non-normative example of Provider Metadata showing the usage of the value:

 {
   "application_provider": {
     "capabilities": {
       "authentication_profiles": ["urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise"],
   ...
 }

3.1.2. Application Metadata

This specification extends the Application Provider Metadata defined in Section 3.3.9 of FastFed Core with an additional member having the name:

"urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise".

The value of the element is a structure containing the following members:

saml_subject

REQUIRED. A structure describing the attribute to use as the SAML Subject. The format of the structure is a "User Attribute" as defined in Section 3.3.6 of FastFed Core. The usage of the structure in this profile, including contraints upon the contents, is described in Section 4.1.1.

desired_attributes

OPTIONAL. A structure specifying the values to be included in the SAML Attributes. The format of the structure is described in Section 3.3.5 of FastFed Core. The usage of the structure in this profile, including constraints upon the contents, is described in Section 4.1.2.

Groups are not supported by this SAML profile. Therefore, the following MUST be omitted from the desired attributes:

• required_group_attributes
• optional_group_attributes

The following is a non-normative example of Application Provider Metadata with the profile extensions:

 {
   "application_provider": {
     "entity_id": "https://tenant-67890.app.example.com/"
     "provider_domain": "example.com",
     "provider_contact_information": {
       "organization": "Example Inc.",
       "phone": "+1-800-555-5555",
       "email": "support@example.com"
     },
     "display_settings": {
       "display_name": "Example Application Provider",
       "logo_uri": "https://app.example.com/images/logo.png",
       "icon_uri": "https://app.example.com/images/icon.png",
       "license": "https://openid.net/intellectual-property/licenses/fastfed/1.0/"
     }
     "capabilities": {
       "provisioning_profiles": [
         "urn:ietf:params:fastfed:1.0:provisioning:saml:2.0:enterprise"
       ],
       "schema_grammars": [
         "urn:ietf:params:fastfed:1.0:schemas:scim:2.0"
       ],
       "signing_algorithms": [
         "ES512",
         "RS256"
       ]
     },
     "fastfed_handshake_register_uri": "https://tenant-67890.app.example.com/fastfed/register",

     "urn:ietf:params:fastfed:1.0:provisioning:saml:2.0:enterprise": {
       "saml_subject": {
         "urn:ietf:params:fastfed:1.0:schemas:scim:2.0": 
           "userName"
       },
       "desired_attributes": {
         "urn:ietf:params:fastfed:1.0:schemas:scim:2.0": {
           "required_user_attributes": [
             "displayName"
           ],
           "optional_user_attributes": [
             "phoneNumbers[primary eq true].value"
           ]
         }
      }
   }
 }

3.2. FastFed Handshake

3.2.1. FastFed Registration Request

This specification extends the JWT contents of the FastFed Registration Request (Section 7.2.3.1 of FastFed Core) with an additional member sharing the same name as the profile:

"urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise".

The value of the element is a structure with the following members:

saml_metadata_uri

REQUIRED. Contains the URL of the Identity Provider's SAML Metadata document.

The following is a non-normative example of the contents of a registration request message prior to serialization:

 {
   "iss": "https://tenant-12345.idp.example.com",
   "aud": "https://tenant-67890.app.example.com",
   "exp": 1234567890,
   "authentication_profiles": [
     "urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise"
   ],
   "urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise": {
     "saml_metadata_uri": "https://tenant-12345.idp.example.com/saml-metadata.xml"
   }
 }

3.2.2. FastFed Registration Response

This specification extends the contents of the FastFed Registration Response (Section 7.2.3.3 of FastFed Core) with an additional member sharing the same name as the profile:

"urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise".

The value of the element is a structure with the following members:

saml_metadata_uri

REQUIRED. Contains the URL of the Application Provider's SAML Metadata document.

The following is a non-normative example of the contents of a registration response message:

 {
   "urn:ietf:params:fastfed:1.0:authentication:saml:2.0:enterprise": {
     "saml_metadata_uri": "https://tenant-56789.app.example.com/saml-metadata.xml"
   }
 }

4. Schema Binding

FastFed recommmends SCIM for user schemas. However, neither SAML nor SCIM specify how to represent SCIM attributes in the context of SAML assertions.

This specification fills the gap and defines how FastFed compatible Providers can use the SCIM 2.0 Schema Grammar (Section 3.3.4.1 of FastFed Core) with the SAML 2.0 protocol.

4.1. SCIM-to-SAML Attribute Mapping

4.1.1. SAML Subject

A SAML Response document contains a Subject element which identifies the authenticated user.

The Application Provider declares the attribute to populate in the SAML Subject via the saml_subject element in Section 3.1.2

The value of the saml_subject MUST be one of the SCIM Attributes in the table below.

Note: In the table, SCIM attributes refer to the "User" Resource Schema defined in Section 4.1 of the SCIM Core Specification. Individual members of a JSON structure are referenced in the table using the JSON path syntax defined in Section 3.5.2 of the SCIM Protocol.

As a reference to implementors, the following considerations can be taken into account when choosing a SAML subject:

• The format of externalId is defined in section 3.1 of the SCIM Core specification [RFC7643]. It is a persistent identifier, often a GUID, which is intended to reliably identify a user within the Identity Provider. However, it will vary between Identity Providers. Therefore, if an Application anticipates that Administrators may occasionally switch Identity Providers (as can happen in commercial settings, for example), additional matching rules may be necessary to reconcile provisioning events arriving from different sources.
  
  Note that while the SCIM Core specification defines the externalId as optional, this profile requires Identity Providers to support it, and hence Applications can depend upon it being available.
  
  
• The format of userName is defined in section 4.1.1 of the SCIM Core specification [RFC7643]. It is a displayable, user-friendly identifier for a user. In practice, the userName can often be an email, but other formats occur. No assumptions should be made about the format of the userName other than it being a string that the end-user typically enters as a login when authenticating.
  
  If the Administrator switches Identity Providers, it is usually the case that the userName remains consistent across providers, making it easier to correlate authentication and provisioning events to a single user when events are arriving from different sources.
  
  Note that userName is mutable, meaning an end-user can change their userName. In addition userName can be recycled and reassigned to other end-users. Therefore, Applications should consider how such situations will be handled. The ability to be notified when userName is changed or recycled, such as via the SCIM profile [FastFedProfile.EnterpriseSCIM], can help keep an Application Provider up-to-date with changes.
  
  
• The attribute "emails[primary eq true].value" represents the primary email address of the user, where emails is defined in section 4.1.2 of the SCIM Core specification [RFC7643].
  
  If an end-user does not have a value for email defined within the Identity Provider, the end-user will be unable to authenticate to the Application. As a result, choosing email as a SAML Subject is appropriate only when an Application requires an email address and is willing to reject end-users who lack it.
  
  In addition, emails can be changed or recycled in the same manner as the userName. Therefore, similar mechanisms are necessary to handle such events.
  
  
• In some circumstances, it may be necessary to use multiple attributes to best match a SAML Authentication response against a specific end-user in the Application. If this occurs, it is acceptable to use both the SAML Subject and the SAML Attributes in combination to perform the matching. In this scenario, the choice of SAML Subject becomes somewhat flexible, and one may choose whichever option is most likely to be available and useful.

When generating a SAML Response, the Identity Provider MUST populate the SAML Subject with a NameID containing the attribute requested by the Application Provider, and the associated NameID Format from the table above.

The Identity Provider MUST be able to provide a value of externalId and userName for all end-users. Email address is optional.

If a value for an optional attribute is not defined for an end-user, the Identity Provider MUST NOT perform any authentication activity into the Application Provider for the affected end-user. To assist with diagnostics, the Identity Provider SHOULD signal to the end-user that the attribute is missing and is required by the Application. The means of doing so are outside the scope of the specification, but could include displaying an informative error message when the end-user attempts to authenticate into the application, or making error logs available to the administrators of the Identity Provider.

The following is a non-normative example of the use of "externalId" as the SAML Subject:

 <saml:Subject>
   <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">1fc58220-7213-47bb-9161-bbd39ad75937</saml:NameID>
 </saml:Subject>

The following is a non-normative example of the use of "userName" as the SAML Subject:

  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified">bjensen</saml:NameID>
  </saml:Subject>

The following is a non-normative example of the use of "email[primary eq true].value" as the SAML Subject:

                                                                                          
 <saml:Subject>
   <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress">babs@example.com</saml:NameID>               
 </saml:Subject>

4.1.2. SAML Attributes

If users have been pre-provisioned into the Application through mechanisms such as SCIM, the SAML Subject alone can be sufficient to correlate the incoming SAML message with the appropriate pre-existing user. However, there can be circumstances when additional user attributes are necessary.

One such situation occurs when an application is using Just-In-Time provisioning instead of pre-provisioning. In this mode of behavior, the incoming user attributes are used to auto-instantiate a user in the Application.

To support these scenarios, FastFed allows a subset of user attributes to be included in SAML response messages according to the mapping rules below. Any attributes not in the mapping table are only accessible via SCIM provisioning and cannot be included in SAML response messages.

Attributes are requested by populating the member "desired_attributes" in the Application Provider Metadata (Section 3.1.2).

If attributes are requested, and values exist for the user, then the Identity Provider MUST include SAML Attribute elements in the response message with the following properties:

• Name set to the value in the mapping table below.
• NameFormat set to "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified".
• AttributeValue element with xsi:type="xs:string" and the value from the SCIM object according to the mapping table below.

Note: In the table below, SCIM attributes refer to the "User" Resource Schema defined in Section 4.1 of the SCIM Core Specification. Individual members of a JSON structure are referenced in the table using the JSON path syntax defined in Section 3.5.2 of the SCIM Protocol.

The following is a non-normative example demonstrating a transformation from a SCIM User to SAML Attributes:

 <saml:AttributeStatement>
   <saml:Attribute Name="externalId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">1fc58220-7213-47bb-9161-bbd39ad75937</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="userName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">bjensen</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="displayName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">Babs Jensen</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">Barbara</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="familyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">Jensen</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="middleName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">Jane</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">bjensen@example.com</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute Name="phoneNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml:AttributeValue xsi:type="xs:string">1-555-555-5555</saml:AttributeValue>
   </saml:Attribute>
 </saml:AttributeStatement>

4.2. Privacy Considerations

When exposing user information through SAML Attributes, FastFed Identity Providers MUST NOT expose any attributes which were not in the desired_attributes or saml_subject elements of the Application Provider Metadata (Section 3.1.2).

5. Interoperability Requirements

Each identity standard defines a set of optional features to enable usage in a wide variety of circumstances.

However, a consequence of the flexibility is that two Providers may find themselves incompabitible despite sharing the same protocols.

To deliver the simplified experience that is the goal of FastFed, it is important that two FastFed-enabled Providers have confidence that they can interoperate when sharing the same protocols.

The following sections describe the subset of the SAML specifications that Providers MUST implement to be compatible with this profile. Providers MAY support additional functionality, but MUST NOT require the additional functionality when configuring federation with another Provider using FastFed specifications.

5.1. Identity Provider Requirements

• MUST implement the required functionality of a SAML Identity Provider as defined in the SAML Web Browser SSO Profile (Section 4.1 of [SAML.Profiles]).
• MUST use the HTTP POST bindings for the authentication response of the Web Browswer SSO Profile.
• MUST use X509 Certificates for the Signature elements within the SAML Response object.
• MUST include a Signature element for the Assertion in the SAML Response, and in addition, MAY include a Signature element for the overall Response.
• The minimum algorithm stregth for the Signature elements SHOULD be SHA-256 for the hash digest, and either RSA with 2048 bit keys, or ECDSA with Curve P-256, for the signature.
• MUST include a "Conditions" element on the Assertion with NotBefore and NotOnOrAfter properties that constrain the validity period of the Assertion to the shortest feasible duration. As a reference to implementors, a 10 minute window is often sufficient to reduce the risk of replays while still allowing a small degree of clock skew between participants.
• MUST host a SAML Metadata document at the location specified by the saml_metadata_uri exchanged during the FastFed Handshake.
• MUST include an IDPSSODescriptor element in the SAML Metadata document as specified in [SAML.Metadata].
• MUST populate the IDPSSODescriptor element with all values needed by a SAML Service Provider to integrate with this SAML Identity Provider using the capabilities described in this section.

5.2. Application Provider Requirements

SAML Requirements for Application Providers:

• MUST implement the required functionality of a SAML Service Provider as defined in the SAML Web Browser SSO Profile (Section 4.1 of [SAML.Profiles]).
• MUST use the HTTP Redirect binding for the authentication request of the Web Browswer SSO Profile.
• MUST accept X509 Certificates for the Signature elements containined within the SAML Response object.
• SHOULD support Signature elements generated using the SHA-256 algorithm for the hash digest, and either RSA with 2048 bit keys, or ECDSA with Curve P-256, for the signature.
• MUST host a SAML Metadata document at the location specified by the saml_metadata_uri exchanged during the FastFed Handshake.
• MUST include an SPSSODescriptor element in the SAML Metadata document as specified in [SAML.Metadata].
• MUST populate the SPSSODescriptor with all values needed by a SAML Identity Provider to integrate with this SAML Service Provider using the capabilities described in this section.
• MAY use the information in the Identity Provider's corresponding SAML Metadata document to decide whether to use additional SAML capabilities, above and beyond the FastFed minimum interoperablity requirements. The additional capabilities must be optional and the federation MUST still succeed if one Provider does not support the additional capabilities.

5.3. Login Hint

The Application Provider MAY include the URL-encoded query parameter LoginHint={hint} when initiating an authentication request via the SAML HTTP Redirect binding.

The value is a hint to the Identity Provider about the login identifier the end-user might use to log in. This hint can be known to the Application Provider, for example, if it first asks the end-user for their e-mail address (or other identifier) in order to discover the authentication provider to be used for sign-in. It is RECOMMENDED that the hint value match the value used for discovery.

The use of this parameter is left to the Identity Provider's discretion.

The LoginHint MUST NOT be included in request signature for the HTTP Redirect Binding.

The Identity Provider MUST ignore the LoginHint parameter if the SAML Authentication Request message contains a Subject with an identifier.

The following is a non-normative example of a SAML HTTP Redirect request with a LoginHint:

 HTTP/1.1 302 Found
 Location http://idp.example.com/SAML?LoginHint=bjensen%40example.org&SAMLRequest=[...omitted for brevity...]

5.4. Certificate Rotation

While the full SAML specification supports a variety of key types, the FastFed Profile defined herein restricts Providers to only X509 Keys for signing SAML Assertions in Web Browser SSO response messages from the Identity Provider.

FastFed Providers MUST implement automatic rotation of the X509 Certificates. This section describes the interoperability requirements for certificate rotation.

5.4.1. Certificate Rotation Requirements for an Identity Provider

To rotate and publish new SAML signing certificates, the following requirements apply to the Identity Provider:

• MUST include new certificates in the response to queries against the SAML Metadata URL that was exchanged during the FastFed Handshake.
• MUST publish the new certificate in the SAML Metadata at least 14 days before the currently active certificate will expire or be revoked, where the expiration date is specified by the notAfter attribute within the X.509 certificate.
• MUST include the new certificate in the SAML Metadata, alongside the currently active certificate, using the recommended technique for multiple certificates defined in the SAML Metadata Interoperability Profile. As a reference, this Interopability Profile specifies that each certificate MUST be placed within its own <KeyDescriptor> element.
• SHOULD continue using the original key for signing SAML Assertions for at least 7 days after publishing the new certificate, to give consumers time to read the new certificate from the SAML Metadata and be ready to receive the new key.
• SHOULD begin signing assertions with the new key if less than 7 days remains until the old certificate expires. MAY continue using the old key if problems arise with the new key, to give time for diagnosis of the problems.
• SHOULD stop using the old key for signing assertions when less than 1 day remains until the old certificate expires.
• MUST support HTTP 1.1 ETag semantics [RFC2616] for all requests to the SAML Metadata URL, including:
  • Returning an ETag response header
  • Accepting an If-None-Match request header, and returning an HTTP 304 response if the SAML Metadata is unmodified.

• MAY return an HTTP 301 response code to indicate the SAML Metadata has moved to a new location.

5.4.2. Certificate Rotation Requirements for an Application Provider

To consume rotated SAML signing certificates, the following options are available to the Application Provider:

• MAY retrieve new keys on demand by reloading the Identity Provider's SAML Metadata file upon detecting a SAML authentication response signed with an unrecognized key.
• Alternatively, MAY preemptively retrieve new keys by querying the Identity Provider's SAML Metadata file on a recurring basis to check for updates.

When preemptively querying for updates on a recurring basis, the following requirements apply to the Application Provider:

• MUST re-query the Identity Provider's SAML Metadata URL to check for new certificates at least once every 24 hours. Because certificates can be rotated at any time, the Application Provider MUST NOT wait for the expiration date to check for updated certificates.
• MUST include the If-None-Match header in the request to download the SAML Metadata, populated with the value of the ETag response header received when previously downloading the SAML Metadata.
• SHOULD alert the Administrator if the Identity Provider has not published a new certificate and less than 14 days remains until expiration of the current certificate. The alert mechanism is an implementation detail that is outside the scope of the specification.
• MUST handle an HTTP 304 response code which indicates that the SAML Metadata is unchanged.
• SHOULD handle an HTTP 301 response code and use the new location for all future downloads of the Identity Provider's SAML Metadata.

In all cases of certificate refresh, both on-demand and preemptive, the following requirements apply to the Application Provider:

• MUST support the consumption of multiple certificates using the recommended techniques defined in the SAML Metadata Interoperability Profile. As a reference, this Interopability Profile specifies that each certificate MUST be placed within its own <KeyDescriptor> element.
• MUST ignore any changes in the SAML Metadata except for <KeyDescriptor> elements.
• MUST accept SAML assertions signed using any of the valid certificates specified within the <KeyDescriptor> elements of the Identity Provider SAML Metadata.

6. Security Considerations

For SAML security considerations, see SAML Security and Privacy Considerations.

For FastFed security considerations, see Section 8 of FastFed Core.

7. IANA Considerations

Pending

8. Normative References

Appendix A. Acknowledgements

The OpenID Community would like to thank the following people for their contributions to this specification:

• Brian Campbell (bcampbell@pingidentity.com), Ping Identity
• Zhen Chien Chia (chiazhenchien@outlook.com), Microsoft
• Pamela Dingle (pamela.dingle@microsoft.com), Microsoft
• Matt Domsch (matt.domsch@sailpoint.com), SailPoint
• Wesley Dunnington (wesleydunnington@pingidentity.com), Ping Identity
• Erik Gustavson (erikgustavson@google.com), Google
• Dick Hardt (dick.hardt@gmail.com), Independent
• Romain Lenglet (rlenglet@google.com), Google
• Karl McGuinness (kmcguinness@okta.com), Okta
• Chuck Mortimore (cmortimore@salesforce.com), Salesforce
• Brian Rose (brian.rose@sailpoint.com), SailPoint

Appendix B. Notices

Copyright (c) 2020 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

Author's Address