From: http://www.ietf.org/internet-drafts/draft-merrells-dix-02.txt Title: DIX: Digital Identity Exchange Protocol Reference: IETF Working Group, Internet-Draft 'draft-merrells-dix-02.txt' Date: May 2006 ======================================================================== Network Working Group J. Merrells Internet-Draft Sxip Identity Expires: November 2, 2006 P. Rowley Red Hat J. Sermersheim Novell M. Pohlman Oracle May 2006 DIX: Digital Identity Exchange Protocol draft-merrells-dix-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract DIX is an Internet scale protocol for the exchange of identity information that is designed for ease of adoption and user privacy. Merrells, et al. Expires November 2, 2006 [Page 1] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 This document specifies a binding and two profiles of the Security Assertion Markup Language (SAML) for identity information message exchanges, a discovery protocol based on HTML/HTTP, a message signing mechanism based on HMAC, and a signature verification protocol based on HTML/HTTP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Changelog . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.1. draft-merrells-dix-01 to draft-merrells-dix-02 . . . . 6 1.2. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 2. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9 2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. SAML Introduction . . . . . . . . . . . . . . . . . . . . 13 4.2. Abstract Request/Response Protocol . . . . . . . . . . . . 13 4.3. Employing SAML in DIX . . . . . . . . . . . . . . . . . . 13 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Property Name . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Property Value . . . . . . . . . . . . . . . . . . . . . . 15 6. Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Service Provider . . . . . . . . . . . . . . . . . . . . . 16 6.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Identity Agent . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. Name . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Security Considerations . . . . . . . . . . . . . . . . . 17 7. Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Service Representation . . . . . . . . . . . . . . . . . . 18 7.2. Service Description . . . . . . . . . . . . . . . . . . . 18 8. Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Service Provider Form . . . . . . . . . . . . . . . . . . 19 8.2. Identity Agent Name . . . . . . . . . . . . . . . . . . . 21 8.3. Identity Agent Inspection . . . . . . . . . . . . . . . . 21 8.4. Agent Document . . . . . . . . . . . . . . . . . . . . . . 21 8.4.1. Element LINK . . . . . . . . . . . . . . . . . . . . . 21 8.4.2. Attribute REL . . . . . . . . . . . . . . . . . . . . 21 8.4.3. Attribute HREF . . . . . . . . . . . . . . . . . . . . 22 8.4.4. Example . . . . . . . . . . . . . . . . . . . . . . . 22 9. DIX HTTP POST Binding . . . . . . . . . . . . . . . . . . . . 23 Merrells, et al. Expires November 2, 2006 [Page 2] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 9.1. Required Information . . . . . . . . . . . . . . . . . . . 23 9.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2.1. Request Protocol Flow . . . . . . . . . . . . . . . . 23 9.2.2. Response Protocol Flow . . . . . . . . . . . . . . . . 24 9.3. Message Encoding . . . . . . . . . . . . . . . . . . . . . 24 9.4. Message Exchange . . . . . . . . . . . . . . . . . . . . . 26 9.5. Security Considerations . . . . . . . . . . . . . . . . . 26 9.6. Error Reporting . . . . . . . . . . . . . . . . . . . . . 26 9.7. Metadata Considerations . . . . . . . . . . . . . . . . . 26 10. Fetch Request Message . . . . . . . . . . . . . . . . . . . . 27 10.1. Element dix:DIXFetchRequest . . . . . . . . . . . . . . . 27 10.2. Element samlp:Issuer . . . . . . . . . . . . . . . . . . . 27 10.3. Element samlp:Attribute . . . . . . . . . . . . . . . . . 28 10.4. Element dix:SPName . . . . . . . . . . . . . . . . . . . . 28 10.5. Element dix:SPLogoURL . . . . . . . . . . . . . . . . . . 28 10.6. Element dix:SPCancelURL . . . . . . . . . . . . . . . . . 29 10.7. Element dix:SPExplanation . . . . . . . . . . . . . . . . 29 10.8. Element dix:SPAuthAge . . . . . . . . . . . . . . . . . . 29 11. Fetch Response Message . . . . . . . . . . . . . . . . . . . . 30 11.1. Element dix:DIXFetchResponse . . . . . . . . . . . . . . . 30 11.2. Element samlp:Issuer . . . . . . . . . . . . . . . . . . . 30 11.3. Element samlp:Status . . . . . . . . . . . . . . . . . . . 31 11.4. Element dix:IAFriendlyName . . . . . . . . . . . . . . . . 31 11.5. Element samlp:Attribute . . . . . . . . . . . . . . . . . 31 12. Store Request Message . . . . . . . . . . . . . . . . . . . . 32 12.1. Element dix:DIXStoreRequest . . . . . . . . . . . . . . . 32 12.2. Element samlp:Issuer . . . . . . . . . . . . . . . . . . . 32 12.3. Element samlp:Attribute . . . . . . . . . . . . . . . . . 33 12.3.1. Element samlp:AttributeValue . . . . . . . . . . . . . 33 12.4. Element dix:SPName . . . . . . . . . . . . . . . . . . . . 33 12.5. Element dix:SPFriendlyName . . . . . . . . . . . . . . . . 33 12.6. Element dix:SPLogoURL . . . . . . . . . . . . . . . . . . 33 12.7. Element dix:SPCancelURL . . . . . . . . . . . . . . . . . 33 12.8. Element dix:SPExplanation . . . . . . . . . . . . . . . . 33 13. Store Response Message . . . . . . . . . . . . . . . . . . . . 34 13.1. Element dix:DIXStoreResponse . . . . . . . . . . . . . . . 34 13.1.1. Element samlp:Issuer . . . . . . . . . . . . . . . . . 34 13.1.2. Element samlp:Status . . . . . . . . . . . . . . . . . 34 13.1.3. Element dix:IAFriendlyName . . . . . . . . . . . . . . 35 14. DIX Fetch SAML Profile . . . . . . . . . . . . . . . . . . . . 36 14.1. Required Information . . . . . . . . . . . . . . . . . . . 36 14.2. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 36 14.2.1. Fetch Request . . . . . . . . . . . . . . . . . . . . 36 14.2.2. Fetch Request Message Processing . . . . . . . . . . . 37 14.2.3. Fetch Response . . . . . . . . . . . . . . . . . . . . 37 14.3. Error States . . . . . . . . . . . . . . . . . . . . . . . 37 14.4. Security Considerations . . . . . . . . . . . . . . . . . 37 15. DIX Store Profile . . . . . . . . . . . . . . . . . . . . . . 38 Merrells, et al. Expires November 2, 2006 [Page 3] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 15.1. Required Information . . . . . . . . . . . . . . . . . . . 38 15.2. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.2.1. Store Request . . . . . . . . . . . . . . . . . . . . 38 15.2.2. Store Request Message Processing . . . . . . . . . . . 39 15.2.3. Store Response . . . . . . . . . . . . . . . . . . . . 39 15.2.4. Store Response Message Processing . . . . . . . . . . 39 15.3. Error States . . . . . . . . . . . . . . . . . . . . . . . 39 15.4. Security Considerations . . . . . . . . . . . . . . . . . 39 16. Message Signing and Verification Protocol . . . . . . . . . . 40 16.1. Message Signing . . . . . . . . . . . . . . . . . . . . . 40 16.2. Signature Envelope Parameter . . . . . . . . . . . . . . . 40 16.3. Digest Generation . . . . . . . . . . . . . . . . . . . . 41 16.4. Response Message Verification . . . . . . . . . . . . . . 41 16.5. Request Message Verification . . . . . . . . . . . . . . . 41 16.6. Verify Request Message . . . . . . . . . . . . . . . . . . 42 16.7. Verify Response Message . . . . . . . . . . . . . . . . . 42 16.8. Security Considerations . . . . . . . . . . . . . . . . . 43 16.8.1. Fetch and Store Messages . . . . . . . . . . . . . . . 43 16.8.2. Verify Messages . . . . . . . . . . . . . . . . . . . 43 17. Persona URL . . . . . . . . . . . . . . . . . . . . . . . . . 44 17.1. Persona Property . . . . . . . . . . . . . . . . . . . . . 44 17.2. Persona Document . . . . . . . . . . . . . . . . . . . . . 44 17.2.1. Element LINK . . . . . . . . . . . . . . . . . . . . . 44 17.2.2. Attribute REL . . . . . . . . . . . . . . . . . . . . 44 17.2.3. Attribute HREF . . . . . . . . . . . . . . . . . . . . 44 17.2.4. Example . . . . . . . . . . . . . . . . . . . . . . . 45 17.3. Persona Delegation Verification . . . . . . . . . . . . . 45 17.4. Security Considerations . . . . . . . . . . . . . . . . . 45 17.4.1. Message Modification . . . . . . . . . . . . . . . . . 46 17.4.2. Authentication Strength . . . . . . . . . . . . . . . 46 18. DIX Services . . . . . . . . . . . . . . . . . . . . . . . . . 47 19. DIX Properties . . . . . . . . . . . . . . . . . . . . . . . . 48 20. Identity Agent Implementation Requirements . . . . . . . . . . 49 21. Service Provider Implementation Requirements . . . . . . . . . 50 22. Implementation Considerations . . . . . . . . . . . . . . . . 51 22.1. Service Provider's Discovery Procedure . . . . . . . . . . 51 22.2. Service Provider Cookie . . . . . . . . . . . . . . . . . 51 22.3. Service Provider Fetch Exchange Procedure . . . . . . . . 51 22.4. Identity Agent Fetch Exchange Procedure . . . . . . . . . 52 22.5. Service Provider Store Exchange Procedure . . . . . . . . 52 22.6. Identity Agent Store Exchange Procedure . . . . . . . . . 52 22.7. Service Provider Response Message Processing Procedure . . 53 22.8. Identity Agent Verify Request Messsage Processing Procedure . . . . . . . . . . . . . . . . . . . . . . . . 53 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 24. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 55 25. Example Fetch Request Message . . . . . . . . . . . . . . . . 57 26. Example Fetch Response Message . . . . . . . . . . . . . . . . 58 Merrells, et al. Expires November 2, 2006 [Page 4] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 27. Example Store Request Message . . . . . . . . . . . . . . . . 59 28. Example Store Response Message . . . . . . . . . . . . . . . . 60 29. Example Verify Request Message . . . . . . . . . . . . . . . . 61 30. Example Verify Response Message . . . . . . . . . . . . . . . 62 31. Security Considerations . . . . . . . . . . . . . . . . . . . 63 31.1. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 63 31.2. Message Replay . . . . . . . . . . . . . . . . . . . . . . 63 31.3. Message Insertion and Deletion . . . . . . . . . . . . . . 63 31.4. Message Modification . . . . . . . . . . . . . . . . . . . 63 31.5. Man-in-the-middle . . . . . . . . . . . . . . . . . . . . 63 31.6. Authentication Stength . . . . . . . . . . . . . . . . . . 63 31.7. Denial of Service . . . . . . . . . . . . . . . . . . . . 63 32. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 33. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 33.1. Normative References . . . . . . . . . . . . . . . . . . . 65 33.2. Informative References . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 Intellectual Property and Copyright Statements . . . . . . . . . . 69 Merrells, et al. Expires November 2, 2006 [Page 5] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 1. Introduction This document specifies a profile of the Security Assertion Markup Language (SAML) V2.0 called DIX in order to satisfy the use cases documented in [I-D.draft-merrells-use-cases]. Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- based framework for creating and exchanging security information. [OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-tech- overview-2.0-draft-08] provide non-normative overviews of SAMLv2. The SAMLv2 specification set is normatively defined by [OASIS.saml- conformance-2.0-os]. 1.1. Changelog 1.1.1. draft-merrells-dix-01 to draft-merrells-dix-02 Request and Response messages now encoded as SAML messages. Replaced DIX URIs with URNs. Renamed Membersite as Service Provider. Renamed Homesite as Identity Agent. Renamed Capability to Service. 1.2. TODO There are various TODO items throughout the text, with the initials of the contributor. General TODO items are: Document the security options, demonstrating the security gradient. Introduce alternative signing mechanisms and verification protocols for messages and identifiers. Provide a place holder for PKI. Can the SAML Authentication Assertion be reused for the Persona URL property? Can the SAML Subject Confirmation mechanism be reused for Persona URL Verification? An Identity Agent can be a Website, or an Application, this draft covers IAW, but not IAA, which is currently in a separate draft. Should they be merged? Merrells, et al. Expires November 2, 2006 [Page 6] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 1.3. Notation 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]. 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]. 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: dix XML Namespace: urn:ietf:params:dix:protocol This is the DIX protocol namespace. Prefix: samlp XML Namespace: urn:oasis:names:tc:SAML:2.0:protocol This is the SAML V2.0 protocol namespace [OASIS.saml-core-2.0-os]. 1.4. Definitions Absolute URI [RFC3986] [4.3] HTTP GET [RFC2616] [9.4] HTTP [RFC2616] scheme [RFC3986] [3.1] Merrells, et al. Expires November 2, 2006 [Page 7] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 URI [RFC3986] Throughout this specification there are many items of type URI. These MUST all be normalized [RFC2396] to ensure they can be easily compared. URL [RFC3986] [1.1.3] HTTPS Abbreviation for HTTP over TLS/SSL. Merrells, et al. Expires November 2, 2006 [Page 8] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 2. Specification Scope Based on the draft charter [I-D.draft-merrells-dix-charter] and use cases [I-D.draft-merrells-use-cases] the scope of this specification is: 2.1. In Scope o Identity Information Exchange Discussion: The primary goal of the DIX protocol is to automate the exchange of identity information over the Internet. o Ease of Adoption Discussion: The DIX protocol must provide the lowest possible barriers to adoption to ensure wide-spread usage of the protocol. o Internet Scale Discussion: The DIX protocol must provide an Internet scale solution to identity information exchange. o Privacy Discussion: The DIX protocol must ensure that all aspects of user privacy can be maintained. o Extensibility Discussion: The DIX protocol must provide for extensibility so that it has broad utility and becomes a platform for further innovation. 2.2. Out of Scope o Non-HTTP/HTML Bindings The DIX protocol defined here could be bound to many alternative transport layers. For example, HTTP, SMTP, or XMPP. Even within a single transport layer messages could be moved in alternative Merrells, et al. Expires November 2, 2006 [Page 9] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 ways. This docment only builds on an existing SAML Binding based on HTML/HTTP, and makes no attempt to detail any of these alternative protocol bindings. Merrells, et al. Expires November 2, 2006 [Page 10] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 3. Protocol Overview The DIX protocol participants are: an Identity Agent, the User Client, and a Service Provider. +-------------------+ +-------------------+ | | | | | Identity Agent | | Service Provider | | | | | +-------------------+ +-------------------+ | | | | DIX | +-------------------+ | DIX Protocol | | | | Protocol +--------------| User Client |------------+ | | +-------------------+ The DIX User is a person who participates in DIX based identity information exchanges using their User Client software, which is typically a web browser. The user's Identity Agent (either a website or an application) is responsible for authenticating and identifying the user, providing a repository for their identity data, and releasing that data (with user consent) to other sites using the DIX protocol via the user's client. A Service Provider is a website that uses the DIX protocol to request or store identity information. Identity Data or Identity Information are attribute values associated with a DIX User. The protocol flow between the participants proceeds in three stages: 1) Discovery of an Identity Agent, 2) Exchange of identity information, and 3) Verification of that exchange. The following interaction diagram briefly introduces the protocol flow: Merrells, et al. Expires November 2, 2006 [Page 11] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Client Service Provider Identity Agent 1 Hello --------------------------> <-- Get Identity Agent Name 2 Identity Agent Name ------------> 3 Get Endpoint ------------------> <---------------------- Endpoint 4 <------------------ Request Request --------------------------------------------------------> 5 Verification of Request Message 6 <------------------------------------------------- Response Response -----------------------> 7 Verification of Response Message 8 Verification of Message Content <----------------------- OK Figure 2: Protocol Flow Step 1. The DIX User browses to a Service Provider... Step 2. ...and provides the name of their Identity Agent. Step 3. The Service Provider determines the Identity Agent Endpoint. Step 4. The Service Provider sends a request to the Identity Agent through the User's Client. Step 5. The Identity Agent then optionally verifies the request message, using an appropriate mechanism. Step 6. The Identity Agent processes the request, prompting the User for consent and returns a response, again through the User's Client. Step 7. The Service Provider then optionally verifies the request message, using an appropriate mechanism. Merrells, et al. Expires November 2, 2006 [Page 12] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Step 8. The Service Provider then optionally verifies the message content, using appropriate machanisms. Merrells, et al. Expires November 2, 2006 [Page 13] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 4. SAML 4.1. SAML Introduction SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] [OASIS.sstc-saml-tech- overview-2.0-draft-08] defines an XML-based framework for exchanging "security assertions" between entities. In the course of making, or relying upon such assertions, SAML system entities may use SAML protocols, or other protocols, to communicate regarding an assertion itself, or the subject of an assertion. Thus one can employ SAML 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." Then one can cause such an assertion to be conveyed to some party who can then rely on it in some fashion for some purpose, for example input it into some local policy evaluation for access to some resource. This is done in a particular "context of use". The specification of how SAML is employed in a particular context of use is known as a "SAML profile". The specification of how SAML assertions and/or protocol messages are conveyed in, or over, another protocol is known as a "SAML Binding". Typically, a SAML profile specifies the SAML bindings that may be used in its context. Both SAML profiles and SAML bindings reference other SAML specifications, especially the SAML Assertions and Protocols, aka "SAML Core", specification [OASIS.saml-core-2.0-os]. A primary facet of SAML itself is the abstract Request/Response protocol, which we describe below: 4.2. Abstract Request/Response Protocol SAML defines an abstract request/response protocol for obtaining assertions. See Section 3 "SAML Protocols" of [OASIS.saml-core-2.0-os]. A request asks for an assertion. A response returns the requested assertion or an error. This abstract protocol may then be cast into particular contexts of use by binding it to specific underlying protocols, e.g. HTTP , and "profiling" it for the specific use case at hand. The SAML HTTP-based web single sign-on profile is one such example (see section 4.1 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). DIX , the topic of this specification, is another. 4.3. Employing SAML in DIX Employing SAML in DIX necessitates devising new SAML profiles because those already specified in the SAMLv2 specification set are specific Merrells, et al. Expires November 2, 2006 [Page 14] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 to other use contexts and use cases. Although existing SAML profiles may appear to address the DIX use cases, e.g. web-browser SSO, they in fact address only a subset. Thus new SAML profiles are warranted. This does not present any untoward difficulties due to SAML's inherent and explicit extensibility. This document introduces four new SAML Messages, a new SAML Binding, and two new SAML Profiles: o DIX Fetch Request - A SAML Request Message [Section 10]. o DIX Fetch Response - A SAML Response Message [Section 11]. o DIX Store Request - A SAML Request Message [Section 12]. o DIX Store Response - A SAML Response Message [Section 12]. o DIX HTTP POST Binding - A SAML Binding [Section 9]. o DIX Fetch Profile - A SAML Profile [Section 14]. o DIX Store Profile - A SAML Profile [Section 15] SAML provides a message signing mechanism [OASIS.saml-core-2.0- os][5.2] based on XML Signatures. Since interoperable implementations of XML Signature are not yet widely deployed, we introduce an alternative message signing mechanism, coupled with a signature verification protocol [Section 16]. Merrells, et al. Expires November 2, 2006 [Page 15] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 5. Information Model The DIX Protocol provides a mechanism for moving identity information between sites, as such it's information model is simple: A property is associated with an Identifier. A property has a property name and one or more property values. A property name is of type URI. A property value is of type UTF-8 string [RFC3629]. 5.1. Identifier An identifier for a set of attributes. It MUST be a URI. 5.2. Property Name A Property Name MUST be a URI, which is used for referring to property values. [Section 10.3]. If a Property Name URI can be resolved then it MAY be dereferenced to retrieve a description of the property. This provides for flexibility and extensibility. Flexibility in that both URNs and URLs can be used to refer to property values. Extensibility allows any individual site, or consortium of sites, to define their own property names with agreements on the syntax and semantics of their associated property values. 5.3. Property Value A property value MUST be a UTF-8 string and can optionally have no value, a single value or multiple values. For example Beth might have multiple home email addresses: beth@home.com and beth.surname@home.com. Merrells, et al. Expires November 2, 2006 [Page 16] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 6. Entities Participating in an identity information exchange there are two entities, the Identity Agent and the Service Provider [Section 3], both of which need consistent name identifiers and protocol endpoint identifiers. This section describes them. 6.1. Service Provider A Service Provider is a web site that requests and stores identity information. Its Name and Endpoint URLs are used in request and response messages to identify the Service Provider and to address the messages. 6.1.1. Name MUST be an absolute URL. MUST NOT be used as a unique identifier of an Identity Agent. For example: http://service-provider.com/, or http://service-provider.com/shopping/. 6.1.2. Endpoint The Endpoint to which Identity Agents send Response Messages. The unique identifier of a Service Provider. MUST be an absolute URL. The Endpoint URL MUST be equivalent to, or a decendant of, the Name URL. For example, http://service-provider.com/endpoint/. 6.2. Identity Agent An Identity Agent Name and Endpoint URLs are used in request and response messages to identify the Identity Agent and to address the messages. 6.2.1. Name MUST be an absolute URL. MUST NOT be used as a unique identifier of an Identity Agent. Merrells, et al. Expires November 2, 2006 [Page 17] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 For example: http://identity-agent.com/, or http://identity-agent.com/john/. 6.2.2. Endpoint The Endpoint to which Service Providers send Request Messages. The unique identifier of an Identity Agent. MUST be an absolute URL. For example, http://identity-agent.com/endpoint/. 6.3. Security Considerations Both Names and Endpoints can be based on the HTTPS URL protocol scheme guarding against eavesdropping and message modificaiton. Merrells, et al. Expires November 2, 2006 [Page 18] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 7. Services Services are offered by one protocol particpant to another participant. 7.1. Service Representation A service is represented by a URI. This specification uses URNs to represent services. For example "urn:ietf:params:dix:service:fetch". 7.2. Service Description If a Service URI can be resolved then it MAY be dereferenced to retrieve a description of the service. Merrells, et al. Expires November 2, 2006 [Page 19] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 8. Discovery Protocol The purpose of the discovery process is to determine the Identity Agent Endpoint. The descriptions below refer to the following figure. [Figure 3] +-------------------+ | | | Identity Agent | | | +-------------------+ * | http(s)://.../dix.html \|/ +-------------------+ (3) HTTP GET +-------------------+ | |<------------------------| | | Agent Document | | Service Provider | | |------------------------>| | +-------------------+ (4) HTTP Response +-------------------+ /|\ | (2) HTTP | | +-------------------+ POST | | (1) | |----------+ | HTML | User Client | | FORM | |<------------+ +-------------------+ Figure 3: Discovery Process 8.1. Service Provider Form The Service Provider MUST send an HTML page to the User Client containing a FORM that includes a text control prompting the DIX User for the Identity Agent Name and a submission control [Figure 3](1). The Form Class attribute MUST have as its value the consistent and well-known name "urn:ietf:params:dix:form", as this signals to the User Client that the form is a Service Provider Form. The name of the text control MUST be the consistent and well-known name "urn:ietf:params:dix:agent-path", as this ensures the benefit to the user of a web browser's automated form filling functionality. If known the Service Provider MAY provide the Name of the Identity Agent as the value of the text control. [Section 22.2 ] The form MAY also include a Request Message per the Fetch and Store Merrells, et al. Expires November 2, 2006 [Page 20] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 profiles [Section 14] [Section 15]. The attributes of the form element are: ACTION attribute MUST be a descendant of the Service Provider Name URL, typically the Service Provider Endpoint URL. METHOD attribute MUST be 'post'. CLASS attribute MUST be 'urn:ietf:params:dix:form'. ACCEPT-CHARSET attribute MUST be 'utf-8'. The value of the FORM tag includes at least two INPUT elements, one a text control, the other a button control. The attributes of the text control INPUT element are: TYPE attribute MUST be 'text'. NAME attribute MUST be 'urn:ietf:params:dix:agent-path'. VALUE attribute SHOULD be the user's Identity Agent Name, if already known by the Service Provider. The attribute of the submit control INPUT element are: TYPE attribute MAY be 'SUBMIT'. VALUE attribute is application specific. Here's an example Service Provider Form:
Merrells, et al. Expires November 2, 2006 [Page 21] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 8.2. Identity Agent Name The DIX User provides the Identity Agent Name through their User Client. [Figure 3](2) The Service Provider SHOULD accept a shortened form of URL, a URL easy for the user to remember, and then make every effort to transform it into a canonical URL, the Identity Agent Name. For example, homesite.com could be entered by the user and transformed into http://homesite.com/. 8.3. Identity Agent Inspection The Service Provider MAY determine the Endpoint of the User's Identity Agent using the following procedure. A URL is constructed, based on the Identity Agent Name, to the file "dix.html" in the site's root directory. HTTP GET is used to resolve that URL, retrieving the Agent Document. [Figure 3](3) If the file is not found then an alternative URL is constructed to the site's root document, "/". HTTP GET is used to resolve the alternative URL, retrieving the Agent Document. [Figure 3](3) The Service Provider MUST follow any HTTP redirects. The Agent Document examined for the Identity Agent Tag. [Section 8.4] 8.4. Agent Document The Identity Agent Name references an HTML document that contains data for inspection by Service Providers. The Agent Document is used to specify the Endpoint of an Identity Agent. The HTML document contains an Identity Agent Tag, which is a LINK element that MUST contain the following attributes. 8.4.1. Element LINK MUST occur in the HEAD section of the document. [W3C.XHTML.10] 8.4.2. Attribute REL MUST be the URN "urn:ietf:params:dix:agent-endpoint". Merrells, et al. Expires November 2, 2006 [Page 22] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 8.4.3. Attribute HREF MUST contain an absolute URL. MUST contain the Identity Agent's Endpoint. 8.4.4. Example Merrells, et al. Expires November 2, 2006 [Page 23] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 9. DIX HTTP POST Binding The DIX HTTP POST Binding defines a mechanism by which DIX Protocol Messages may be transmitted between Identity Agents and Service Providers. The structure of this section of the document follows that layed out in [OASIS.saml-bindings-2.0-os]. 9.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]. Identification: urn:ietf:params:dix:saml-binding:dix Contact Information: [TODO - JM - someone's or something's contact info goes here.] Description: Given below. Updates: This bindings is based on the SAML HTTP POST Binding, identified by the URN "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" and specified in [OASIS.saml-bindings-2.0-os] [3.5]. 9.2. Overview The identity information exchange protocol occurs once the Service Provider has discovered the Endpoint of the Identity Agent. Messages are exchanged between the Service Provider and the Identity Agent via the User's Client. This section describes the protocol flow that occurs between the participants. 9.2.1. Request Protocol Flow The Service Provider sends a Request message to the Identity Agent through the User's Client as a FORM (1) redirected as a HTTP POST (2) to their Identity Agent Endpoint. Merrells, et al. Expires November 2, 2006 [Page 24] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 +-------------------+ +-------------------+ | | | | | Identity Agent | | Service Provider | | | | | +-------------------+ +-------------------+ /|\ | | | (2) | +-------------------+ | (1) HTTP | | | | HTML POST +--------------| User Client |<-----------+ FORM | | +-------------------+ Figure 6: Request Message 9.2.2. Response Protocol Flow The Identity Agent sends a Fetch Response message to the Service Provider through the User's Client as a FORM (1) redirected as a HTTP POST (2) to their Service Provider Endpoint. +-------------------+ +-------------------+ | | | | | Identity Agent | | Service Provider | | | | | +-------------------+ +-------------------+ | /|\ | | (1) | +-------------------+ | (2) HTML | | | | HTTP FORM +------------->| User Client |------------+ POST | | +-------------------+ Figure 7: Response Message 9.3. Message Encoding As specified in [OASIS.saml-bindings-2.0-os] [3.5.4], where a SAML Request is interpreted to be a DIX Fetch or Store Request and a SAML Response to be a DIX Fetch or Store Response. For the purposes of this specification we introduce the term 'Envelope Parameter', to name a hidden form control within the HTML form control into which the message is encoded. An Envelope Parameter has a name, which is the name of the hidden form control, and a value, which is the value of the hidden form control. Merrells, et al. Expires November 2, 2006 [Page 25] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 [TODO - JM - Insert summary of [OASIS.saml-bindings-2.0-os] [3.5.4]?] In addition the Envelope Parameter named DIXMessageType MUST be sent with a value that indicates the type of the message to the receiving entity, which is intended for ease of message processing. In addition the Envelope Parameter named DIXRequiredServices MUST be sent with a value that indicates the services required of the receiving entity. Each service is a URI [Section 7.1] and the parameter value MUST be space separated. A Response Message Encoding MAY include form controls containing Properties. The Property Form Name is provided as the name of the form control and its value is the Property Value.[Section 10.3] Form submission MAY be automated using Javascript. [[ECMA262]] An example implementation would be.
. . . etc
Merrells, et al. Expires November 2, 2006 [Page 26] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 9.4. Message Exchange As specified in [OASIS.saml-bindings-2.0-os] [3.5.5]. 9.5. Security Considerations As specified in [OASIS.saml-bindings-2.0-os] [3.5.5.2]. The message MAY be signed using a DIX Message Signature [Section 16.1], which can be used for Message Verification [Section 16]. 9.6. Error Reporting As specified in [OASIS.saml-bindings-2.0-os] [3.6]. 9.7. Metadata Considerations None. Merrells, et al. Expires November 2, 2006 [Page 27] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 10. Fetch Request Message A Fetch Request Message is sent from the Service Provider to the Identity Agent to query for a set of property values. In the following subsections, this SAML Request message is specified element-by-element, in a top-down, depth-first manner, beginning with the outermost element, "". 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]. 10.1. Element dix:DIXFetchRequest Attribute samlp:ID MUST be provided. [OASIS.saml-core-2.0-os] [Section 1.3.4] The Service Provider MUST provide either a nonce or a none value. A nonce [RFC2617] guards against replay attacks. The none value, '0', enables support for simple Service Providers unable to generate a nonce. Attribute samlp:IssueInstant MUST contain the date and time the request was created. The Identity Agent MAY use this as a simple way to detect a message replay security attack. Attribute samlp:Version MUST be the SAML version, currently "2.0". Attribute dix:DIXVersion MUST be the DIX version, currently "1.0". 10.2. Element samlp:Issuer MUST contain the Service Provider Endpoint for the Identity Agent to POST the Fetch Response message to. This URL MUST contain the value of the dix:SPName element, the Service Provider Name, otherwise the message is invalid. Note that the URL could include return data. The code at this URL MUST perform the Verification Process. Merrells, et al. Expires November 2, 2006 [Page 28] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Attribute samlp:Format MUST contain the URN "urn:oasis:names:tc:SAML:2.0:nameid-format:entity" 10.3. Element samlp:Attribute A request for a property value. The property is referenced by its property name and its value is returned in one of two ways, depending upon the provision of a FormValue attribute value. Attribute samlp:Name MUST contain the Property Name [Section 5.2]. Attribute dix:FormName Optionally contains the name of the Envelope Parameter name-value pair to return to the Service Provider. If not provided then the Property Value is returned as an Attribute element in the SAML Response. Section 11.5 Attribute dix:Required The Service Provider MAY specify that a requested property is required. This means that the Identity Agent SHOULD inform the user that the property is required. Attribute dix:IfAvailable The Service Provider MAY specify that the Identity Agent SHOULD only prompt the user for the property if the property is available. 10.4. Element dix:SPName MUST contain the Service Provider Name. The Issuer element value, the Service Provider Endpoint, MUST contain the Service Provider Name, otherwise the message is invalid. 10.5. Element dix:SPLogoURL When the Identity Agent asks the user for permission to release properties to a Service Provider, the Identity Agent MAY display the graphic found at this URL. The Service Provider logo SHOULD be a 234 by 60 pixels image and be on a white background. Merrells, et al. Expires November 2, 2006 [Page 29] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 10.6. Element dix:SPCancelURL MAY contain the value URL the Identity Agent should return the user to should they cancel the operation. 10.7. Element dix:SPExplanation MAY contain a textual description of why the Service Provider is making the request. Intended for display to the user by the Identity Agent. 10.8. Element dix:SPAuthAge MAY contain an integer value, which is a number of seconds. If the user has not authenticated with the Identity Agent since (current time - seconds) then the Identity Agent MUST re-authenticate the user. A value of 0 is taken to mean that the Identity Agent MUST always re-authenticate the user. Merrells, et al. Expires November 2, 2006 [Page 30] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 11. Fetch Response Message Sent by the Identity Agent to the Service Provider in response to a Fetch Request Message. In the following subsections, this SAML Response message is specified element-by-element, in a top-down, depth-first manner, beginning with the outermost element, "". 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]. 11.1. Element dix:DIXFetchResponse Attribute samlp:ID MUST be provided. [OASIS.saml-core-2.0-os] [Section 1.3.4] Attribute samlp:InResponseTo MUST be the same as the SAML Request RequestID attribute, if provided. Attribute samlp:IssueInstant MUST be the UTC the response was created. Attribute samlp:Version MUST be the SAML version, currently "2.0". Attribute dix:DIXVersion MUST be the DIX version, currently "1.0". 11.2. Element samlp:Issuer MUST be the Identity Agent Endpoint, which is for the Service Provider to use for verifying the response message with the Identity Agent, and also serves as a unique identifier for the Identity Agent. Attribute Format MUST contain 'urn:oasis:names:tc:SAML:2.0:nameid-format:entity' Merrells, et al. Expires November 2, 2006 [Page 31] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 11.3. Element samlp:Status Element StatusCode MUST be provided and element StatusMessage SHOULD be provided. [OASIS.saml-core-2.0-os] [Section 3.2.2.1] 11.4. Element dix:IAFriendlyName SHOULD be a textual name for the Identity Agent, which is intended for display to the user by the Service Provider. 11.5. Element samlp:Attribute If a property is requested and a FormName is not provided then the Property is returned as an Attribute. An empty value is returned for a Property Name that is requested, but which has no Property Value. See the 'DIX Attribute Profile' in [I-D.draft-merrells-dix-assertion] for further details. Merrells, et al. Expires November 2, 2006 [Page 32] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 12. Store Request Message This message is sent from the Service Provider to the Identity Agent to store properties. In the following subsections, this SAML Request message is specified element-by-element, in a top-down, depth-first manner, beginning with the outermost element, "". 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]. 12.1. Element dix:DIXStoreRequest Equivalent to the DIXFetchRequest element, but used for storing identity information. Attribute samlp:ID MUST be provided. [OASIS.saml-core-2.0-os] [Section 1.3.4] Attribute samlp:IssueInstant MUST. As fetch request message. Attribute samlp:RequestID MAY. As fetch request message. Attribute samlp:Version MUST be the SAML version, currently "2.0". Attribute dix:DIXVersion MUST be the DIX version, currently "1.0". 12.2. Element samlp:Issuer MUST. As fetch request message. Attribute samlp:Format MUST contain "urn:oasis:names:tc:SAML:2.0:nameid-format:entity" Merrells, et al. Expires November 2, 2006 [Page 33] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 12.3. Element samlp:Attribute Attribute samlp:Name MUST contain the Property Name [Section 5.2]. Attribute dix:Identifier The Service Provider MAY suggest the Identifier for the property to be stored with. 12.3.1. Element samlp:AttributeValue MUST contain the Property Value [Section 5.3]. 12.4. Element dix:SPName MUST. As fetch request message. 12.5. Element dix:SPFriendlyName SHOULD. As fetch request message. 12.6. Element dix:SPLogoURL MAY. As fetch request message. 12.7. Element dix:SPCancelURL MAY. As fetch request message. 12.8. Element dix:SPExplanation MAY. As fetch request message. Merrells, et al. Expires November 2, 2006 [Page 34] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 13. Store Response Message Sent by the Identity Agent to the Service Provider in response to a Store Request Message. In the following subsections, this SAML Response message is specified element-by-element, in a top-down, depth-first manner, beginning with the outermost element, . 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]. 13.1. Element dix:DIXStoreResponse Attribute samlp:ID MUST be provided. [OASIS.saml-core-2.0-os] [Section 1.3.4] Attribute samlp:IssueInstant MUST be the UTC the response was created. Attribute samlp:Version MUST be the SAML version, currently "2.0". Attribute dix:DIXVersion MUST be the DIX version, currently "1.0". 13.1.1. Element samlp:Issuer MUST be the Identity Agent Endpoint, which is for the Service Provider to use for verifying the response message with the Identity Agent, and also serves as a unique identifier for the Identity Agent. Attribute samlp:Format MUST contain 'urn:oasis:names:tc:SAML:2.0:nameid-format:entity' 13.1.2. Element samlp:Status Element StatusCode MUST be provided and element StatusMessage SHOULD be provided. [OASIS.saml-core-2.0-os] [Section 3.2.2.1] Merrells, et al. Expires November 2, 2006 [Page 35] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 13.1.3. Element dix:IAFriendlyName SHOULD be a textual name for the Identity Agent, which is intended for display to the user by the Service Provider. Merrells, et al. Expires November 2, 2006 [Page 36] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 14. DIX Fetch SAML Profile The DIX Fetch SAML Profile describes a profile for a Service Provider to request properties from an Identity Agent. 14.1. Required Information Identification: urn:ietf:params:dix:service:fetch Contact Information: [TODO - JM - someone's or something's contact info goes here.] Description: Given below. Updates: None. 14.2. Binding Messages are exchanged between the Service Provider and the Identity Agent via the User's Client. The protocol flow for request and response messages is as described in the DIX HTTP POST Binding Section 9. SAML metadata utilization is as defined in the descriptions of the request and response messages. 14.2.1. Fetch Request MUST contain at least the following Envelope Parameters: DIXMessageType MUST be the URN "urn:ietf:params:dix:message:request:fetch" SAMLRequest MUST be a Fetch Request Message Section 10. DIXRequiredServices MUST be the services required of the Identity Agent by the Service Provider. Merrells, et al. Expires November 2, 2006 [Page 37] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 14.2.2. Fetch Request Message Processing The Identity Agent MUST authenticate the user before responding to the request. 14.2.3. Fetch Response MUST contain at least the following Envelope Parameters: DIXMessageType MUST be the URN "urn:ietf:params:dix:message:response:fetch" SAMLResponse MUST be a Fetch Response Message Section 11. name=value If a property is requested and a FormName is provided then the name is the value of the FormName and the value is the Property Value. A blank value is returned for a Property Name that is requested, but which has no Property Value. 14.3. Error States [TODO - JM - This section to be completed.] If the Identity Agent does not support the services requested, then the SAML status code 'urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported' is returned. 14.4. Security Considerations HTTPS based Endpoints can be used to guard against eavesdropping, and message insertion and deletion. Message replay attackes can be guarded against by the Service Provider providing a nonce with the Request message. Message modification can be guarded against using message signing and verification. [TODO - JM - There's no provision for mitigation of man-in-the-middle attacks.] Merrells, et al. Expires November 2, 2006 [Page 38] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 15. DIX Store Profile The DIX Store SAML Profile describes a profile for a Service Provider to store properties at an Identity Agent. 15.1. Required Information Identification: urn:ietf:params:dix:service:store Contact Information: [TODO - JM - someone's or something's contact info goes here.] Description: Given below. Updates: None. 15.2. Binding Messages are exchanged between the Service Provider and the Identity Agent via the User's Client. The protocol flow for request and response messages is as described in the DIX HTTP POST Binding Section 9. SAML metadata utilization is as defined in the descriptions of the request and response messages. 15.2.1. Store Request MUST contain at least the following Envelope Parameters: DIXMessageType MUST be the URN "urn:ietf:params:dix:message:request:store" SAMLRequest MUST be a Store Request Message Section 12 DIXRequiredServices MUST be the services required of the Identity Agent by the Service Provider. Merrells, et al. Expires November 2, 2006 [Page 39] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 15.2.2. Store Request Message Processing As DIX Fetch Profile. 15.2.3. Store Response MUST contain at least the following Envelope Parameters: DIXMessageType MUST be the URN "urn:ietf:params:dix:message:response:store" SAMLResponse MUST be a Store Response Message [Section 13]. 15.2.4. Store Response Message Processing As DIX Fetch Profile. 15.3. Error States As DIX Fetch Profile. 15.4. Security Considerations As DIX Fetch Profile. Merrells, et al. Expires November 2, 2006 [Page 40] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 16. Message Signing and Verification Protocol This section describes a message signing mechanism and signature verification protocol. The verification process can optionally occur after a site receives a signed message. The purpose of the verification process is to ensure that the message has not been tampered with and was indeed sent by the site the message claims it is from. Both Identity Agents and Service Providers can send verifyable messages and verify them. 16.1. Message Signing Either a Request or Response message can optionally include a signature Envelope Parameter. DIXSignature The sending entity MAY include a signature in the message for the receiving entity to verify the message. [Section 16.2] 16.2. Signature Envelope Parameter The signature function is used to generate a signature for a message. Since the signature generation function need only be known by the Identity Agent, and not the Service Provider, the nature of this function is implementation defined. It should however have the properties of protecting the message from modification. A signature which can only be verified by the holder of a symmetric secret is a Message Authentication Code (MAC) and the standard technique is HMAC. [RFC2104] A suggested implementation of a signature function would be to use the SHA1 algorithm, which takes as input a digest of the message and a secret known only to the Identity Agent. Signature = HMAC-SHA1 ( S , Digest ) Where, Digest is the message digest [Section 16.3], S is the Identity Agent Secret, and HMAC-SHA1 is the signature generation function. A suggested secret would be a random sequence of bytes. For the SHA1 algorithm an appropriate length would be 80 to 160 bits. When expressed as a value of a Envelope Parameter name-value pair it is encoded as lower-case hex without any leading characters, such as '0x'. Merrells, et al. Expires November 2, 2006 [Page 41] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 16.3. Digest Generation The digest function is used to generate a digest for a message. Digest = D ( M ) Where, M is a DIX Request [Section 10] [Section 12] or DIX Response [Section 11] [Section 13] messge and D is the digest function. The digest function D MUST be SHA-1 [SHA]. Since the Identity Agent and Service Provider must be able to generate interchangeable digests they both must implement the same digest function. 16.4. Response Message Verification Upon receiving a signed Response message the Service Provider can optionally check the integrity of the message by verifying the signature. +-------------------+ (1) HTTP POST +-------------------+ | |<------------------------| | | Identity Agent | | Service Provider | | |------------------------>| | +-------------------+ (2) HTTP Response +-------------------+ Figure 9: Response Message Verification To verify the integrity of the Response message the Service Provider constructs a Verify Request message that is sent to the Identity Agent [Figure 9] [1]. In the Verify Request message is the Signature from the Response message, and a message Digest computed by the Service Provider. [Section 16.3] Upon receipt of the Verify Request message [Figure 9] [1] the Identity Agent performs a comparison between the Signature provided and the result of computing a signature [Section 16.2] then a Verify Response message containing a status code is returned. 16.5. Request Message Verification Upon receiving a signed Request message the Identity Agent can optionally check the integrity of the message by verifying the signature. Merrells, et al. Expires November 2, 2006 [Page 42] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 +-------------------+ (1) HTTP POST +-------------------+ | |------------------------>| | | Identity Agent | | Service Provider | | |<------------------------| | +-------------------+ (2) HTTP Response +-------------------+ Figure 10: Request Message Verification The Identity Agent constructs a Verify Request message that is sent to the Service Provider [Figure 10] [1]. The Verify Request message includes the Signature from the Request message, and a message Digest computed by the Identity Agent. [Section 16.3] Upon receipt of the Verify Request message [Figure 10] [2] the Service Provider performs a comparison between the Signature provided and the result of computing a signature [Section 16.2] then a Verify Response message containing a status code is returned. 16.6. Verify Request Message This message is sent directly from site to site, not through the client. The Envelope Parameters are: DIXMessageType MUST contain the URN "urn:ietf:params:dix:message:request:verify" DIXSignature MUST be the value of the DIXSignature message parameter from the message being verified. DIXDigest MUST be the digest of the message being verified created using the Digest Generation algorithm [Section 16.3]. When expressed as a value of a Envelope Parameter value it is encoded as lower-case hex without any leading characters, such as '0x'. 16.7. Verify Response Message The body of the response MUST be of content-type "text/plain" and MUST contain a single URN, which MUST be followed by a Newline, which MAY be followed by further characters. These could optionally be human readable text to aide the user or developer. The meaning of the response URN is described in the following table. Merrells, et al. Expires November 2, 2006 [Page 43] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 urn:oasis:names:tc:SAML:2.0:status:Success Message passed verification check. urn:oasis:names:tc:SAML:2.0:status:AuthnFailed Message failed verification check. 16.8. Security Considerations 16.8.1. Fetch and Store Messages Signing and verifying a message provides protection against message modification. The HMAC-SHA1 algorithm, with a secret key length of 80-160 bits, is suggested as the message signing mechanism. A signing mechamism stronger than the verification method would not add any more security to the protocol. 16.8.2. Verify Messages The Endpoint URL that receives the Verify Request Message can be based on the HTTPS protocol scheme, which guards against eavesdropping. No further security provisions are provided to secure against message replay, modification, insertion and deletion attacks, or a man-in- the-middle attack. Merrells, et al. Expires November 2, 2006 [Page 44] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 17. Persona URL The Persona URL is a DIX Property, which serves as an Identifier Section 5.1 for a set of attributes, known as a Persona. 17.1. Persona Property Name urn:ietf:params:dix:property:persona-url Description A Persona URL is an Identifier Section 5.1 for a set of attributes. Syntax It MUST be a URL and MUST be of scheme HTTP or HTTPS. Semantics It MUST resolve to a Persona Document. [Section 17.2] It can be used as an Identifier. [Section 5.1] It is verifyable, using the 'urn:ietf:params:dix:service:verify-dns' service. [Section 17.3] 17.2. Persona Document The Persona URL references an HTML document that contains data for inspection by Service Providers. The Persona Document delegates authority for the Persona URL to a set of Identity Agents. The HTML document contains Persona Tags, which are LINK elements which MUST contain the following attributes. 17.2.1. Element LINK MUST occur in the HEAD section of the document. [W3C.XHTML.10] 17.2.2. Attribute REL MUST be the URN "urn:ietf:params:dix:agent". 17.2.3. Attribute HREF MUST contain the Name of an Identity Agent that is authoritative for the Persona. Merrells, et al. Expires November 2, 2006 [Page 45] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 17.2.4. Example 17.3. Persona Delegation Verification The Persona URL delegation verification process may occur after a Service Provider receives a Fetch Response message containing a Persona URL property. [Section 17.1] The purpose of this verification process is to ensure that the Identity Agent from which the response message was received is authoritative for the Persona URL received. +-------------------+ Delegation | | (1) +-----------* | Persona Document |------------+ HTTP | | | | GET | +-------------------+ | \|/ \|/ +-------------------+ +-------------------+ | | | | | Identity Agent | | Service Provider | | | | | +-------------------+ +-------------------+ Figure 12: Persona URL Verification The Service Provider uses HTTP(S) GET to fetch the Persona Document [Figure 12](1) and then inspects it for the Persona Tag [Section 17.2]. The Persona Tag contains a list of Identity Agents that are authoritative for that Persona. The Identity Agent Name provided in the Fetch Response message MUST be a member of the set of Identity Agents that are listed as authoritative for the Persona for the Fetch Response message to be valid, otherwise it MUST be discarded. 17.4. Security Considerations A Persona URL based on the HTTPS scheme guards against eavesdropping and message modification. Merrells, et al. Expires November 2, 2006 [Page 46] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 There is no provision for peer entity authentication. [TODO - JM - Suggest: Secure DNS. Certificate based authentication. Signing of Persona Document.] Message replay, insertion, and deletion have no effect on the Service Provider. There is no provision for defence against a man-in-the-middle attack. [TODO - JM - Secure DNS?] 17.4.1. Message Modification 17.4.1.1. Unsigned Messages If an attacher were to change the Identity Agent Name in a Fetch Response message then the Persona Delegation Verification algorithm would find the message to be invalid. If an attacker were to change both the Persona URL and the Identity Agent Name then the attacker will be changing the identifier so can't compromise the original identity. 17.4.1.2. Signed Messages If an attacker were to change the Persona URL then the digest would be found invalid by the Identity Agent. 17.4.2. Authentication Strength A response message containing a Persona URL property is a statement that the User owns that Identifier. Further, a signed and verified response message serves as an assertion that the Identity Agent has authenticated the User. The Identity Agent may use any method it choses to authenticate the User. The Service Provider may use the service request mechanism to request that the Identity Agent use a particular authentication method, or class of method. However, this document does not specify any. The Identity Agent can sign the response message and the Service Provider can verify it, which guards against message tampering attacks. As such the stength of the authentication assertion is no stronger then the message signing and verification mechanisms. Merrells, et al. Expires November 2, 2006 [Page 47] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 18. DIX Services This specification defines a number of services: urn:ietf:params:dix:service:fetch Supports the Fetch Request Profile [Section 14]. urn:ietf:params:dix:service:store Supports the Store Request Profile [Section 15]. urn:ietf:params:dix:service:verify-dns Supports the Verify Request [Section 16.6] and Verify Response messages. [Section 16.7] urn:ietf:params:dix:service:hash-sha-1 Supports message verification with the SHA-1 algorithm. Merrells, et al. Expires November 2, 2006 [Page 48] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 19. DIX Properties This specification defines a single property: urn:ietf:params:dix:service:fetch Supports the Persona URL property. [Section 17.1]. Merrells, et al. Expires November 2, 2006 [Page 49] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 20. Identity Agent Implementation Requirements [TODO - JM - Collect all the MUSTs here...] MUST implement the DIX Services described in section Section 18. Merrells, et al. Expires November 2, 2006 [Page 50] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 21. Service Provider Implementation Requirements [TODO - JM - Collect all the MUSTs here...] Merrells, et al. Expires November 2, 2006 [Page 51] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 22. Implementation Considerations This non-normative section describes the algorithms to be implemented by the Identity Agent and the Service Provider. 22.1. Service Provider's Discovery Procedure To discover the Identity Agent Endpoint the Service Provider follows the following procedure. 1. Prompt user via the Service Provider Form for the Identity Agent Name. 2. Fetch the Identity Agent Document and extract the Endpoint. Upon failure the Service Provider should inform the user and jump to the first step to prompt the user. If successful the Service Provider has now determined the Endpoint of the user's Identity Agent. The Service Provider uses the DIXRequiredServices Envelope Parameter to request that the Identity Agent supports requisite services for the identity information exchange. For example, a financial Service Provider might require that the Identity Agent use a specific two- factor device to authenticate the User. In this case the Service Provider would request that the Identity Agent have the service named "http://example.com/strong-auth". 22.2. Service Provider Cookie Once a user has visited a Service Provider and their Identity Agent Name has been determined that Service Provider can cookie the User's Client with their chosen Identity Agent Name. This is mearly a hint, but in many cases eliminates the need for the user to retype their chosen Identity Agent Name. 22.3. Service Provider Fetch Exchange Procedure Create fetch request message. [Section 10] Store message state. State management by the Service Provider is implementation dependent. If RequestID is provided then the Service Provider should store the nonce to ensure that a message has not been replayed. For example, in a cookie, in a secure way. A high resolution date/time stamp as a nonce. Because the data is passing over HTTP any more effort on replay attack prevention is Merrells, et al. Expires November 2, 2006 [Page 52] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 useless. Send fetch request message. Receive fetch response message. [Section 11] Verify fetch response message. [Section 16] 22.4. Identity Agent Fetch Exchange Procedure Receive fetch request message. [Section 10] Verify fetch request message. [Section 16] saml:IssueInstant - The Identity Agent could have a policy about how old a message is acceptable. For example, a couple of minutes. This assumes roughly synchronized clocks at the sites, which is a deployment issue. The Identity Agent verifies the Request message by checking that the Service Provider Endpoint contains the Service Provider Name. User interaction. Create fetch response message, [Section 11] optionally generating DIXSignature. [Section 16.2] Send fetch response message. 22.5. Service Provider Store Exchange Procedure Create store request message. [Section 12] Store message state. State management by the Service Provider is implementation dependent. If RequestID provided then the Service Provider should store the nonce to ensure that a message has not been replayed. For example, in a cookie, in a secure way. Send store request message. Receive store response message. [Section 13] Verify store response message. [Section 16] 22.6. Identity Agent Store Exchange Procedure Merrells, et al. Expires November 2, 2006 [Page 53] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Receive store request message. [Section 12] Verify store request message. [Section 16] User interaction. Create store response message, [Section 13] optionally creating DIXSignature. [Section 16.2] Send store response message. 22.7. Service Provider Response Message Processing Procedure Receive response message from Identity Agent. [Section 11][Section 13] Check that the datetime provided in IssueInstant is within the limits defined by the message age policy of the Service Provider. Check the nonce provided in InResponseTo is correct. Check that Issuer is authoritative for the Persona URL, if requested. Create verify request message, using the Digest Generation algorithm to create the value for DIXDigest [Section 16.3], and the DIXSignature from the response message. [Section 16.6] Send verify request message to Identity Agent. Receive verify response message. [Section 16.7] 22.8. Identity Agent Verify Request Messsage Processing Procedure Receive verify request message from Service Provider. [Section 16] Compute comparison signature based on DIXDigest provided. [Section 16.2] Compare with DIXSignature provided in the verify request message. Create verify response with the body text being the status code URI. Merrells, et al. Expires November 2, 2006 [Page 54] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 23. Acknowledgements The subscribers of the DIX mailing list. The attendees of the IETF 65 DIX BOF: particularly Bob 'RL' Morgan and Jeff Hodges. The authors of 'draft-tschofenig-sip-saml-05' a SAML profile for SIP, from which portions of text were lifted and reworked: Hannes Tschofenig, Jon Peterson, James Polk, Douglas C. Sicker, and Jeff Hodges. The engineering team at Sxip Identity Corporation: Laurie Rae, Dick Hardt, Keith Grennan, Weston Triemstra, and Marius Scurtescu. The attendees of IIW 2006 for their feedback including Pete Rowley, Prasanta Behera, and Jeff Hodges. For their comments on draft-merrells-dix-01: Terry Hayes, Hans Granqvist and Dan Connolly. For their comments on draft-merrells-dix-02: Scott Cantor, Carl Howells, Pete Rowley, Marlin Pohlman and Jim Sermersheim. Merrells, et al. Expires November 2, 2006 [Page 55] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 24. Protocol Schema Merrells, et al. Expires November 2, 2006 [Page 56] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Merrells, et al. Expires November 2, 2006 [Page 57] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 25. Example Fetch Request Message http://geeknews.com/sxip geeknews.com Geek News http://geeknews.com/geeknews_logo.jpg http://geeknews.com/cancel geeknews.com is requesting your first name and email address to allow you access to their content. Merrells, et al. Expires November 2, 2006 [Page 58] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 26. Example Fetch Response Message http://example.com/homesite Your Friendly ISP Beth beth@home.com http://work.beth.com Merrells, et al. Expires November 2, 2006 [Page 59] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 27. Example Store Request Message http://geeknews.com/sxip geeknews.com Geek News http://geeknews.com/geeknews_logo.jpg http://geeknews.com/cancel You have requested to store your photo from Geeknews.com with work persona. http://bethsite.com/smallimage.gif Merrells, et al. Expires November 2, 2006 [Page 60] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 28. Example Store Response Message http://example.com/homesite Your Friendly ISP Merrells, et al. Expires November 2, 2006 [Page 61] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 29. Example Verify Request Message POST /endpoint HTTP/1.1 Host: homesite-example.com User-Agent: membersite Content-Type: application/x-www-form-urlencoded Content-Length: 202 DIXMessageType%3Durn%3Aietf%3Aparams%3Adix%3Amessage%3A request%3Averify%26DIXSignature%3DNWJhYTYxZTRjOWI5M2YzZ jA2ODIyNTBiNmNmODMzMWI3ZWU2OGZkOA%3D%3D%26DIXDigest%3Dy zg3zjA0Zjblzwm1ywfjnti5zjy1ywvimmmxm2e3nzewnjlizwuxng%3 D%3D Merrells, et al. Expires November 2, 2006 [Page 62] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 30. Example Verify Response Message HTTP/1.1 200 Ok Connection: close urn:oasis:names:tc:saml:2.0:status:success Merrells, et al. Expires November 2, 2006 [Page 63] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 31. Security Considerations The 'Security Considerations' sections throughout this document are based on the guidelines set out in [RFC3552]. 31.1. Eavesdropping URLs can be based on the HTTPS protocol scheme providing confidentiality. This applies to Entity Names, Entity Endpoints, and Persona URLs. 31.2. Message Replay The RequestID Fetch Request message attribute provided by the Service Provider serves as a nonce, which guards against a reply attack, assuming proper implementation by the Service Provider. [TODO - JM - Discuss 'none' nonce.] 31.3. Message Insertion and Deletion [TODO - JM - There's no provision for this in the protocol.] 31.4. Message Modification Both Identity Agents and Service Providers can sign and verify messages to guard against message modication attacks. 31.5. Man-in-the-middle [TODO - JM - The protocol is vulnerable to MITM attacks. Could guard against with Secure DNS. Or certificate based authentication?] 31.6. Authentication Stength The DIX protocol is designed for moving identity information between Identity Agents and Service Providers. That information can include assertions that result from an authentication mechanism. This is discussed further in the Persona URL section [Section 17]. 31.7. Denial of Service [TODO - JM - A Service Provider could be hammered with Response messages, a Indentity Agent Website could be hammered with Request messages. Consider Fetch and Store versus Verify.] Merrells, et al. Expires November 2, 2006 [Page 64] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 32. IANA Considerations This document proposes the registration of new URNs to identify DIX message parameters, DIX Property Names and SAML Profiles. They must be agreed upon, and then registered with IANA per [RFC3553]. [TODO - JM - Read and reference RFC2434.] Merrells, et al. Expires November 2, 2006 [Page 65] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 33. References 33.1. Normative References [ECMA262] "ECMAScript Language Specification, 3rd Edition, December 1999.". [I-D.draft-merrells-dix-assertion] Merrells, J., "DIX Assertions", May 2006. [I-D.draft-merrells-dix-charter] Merrells, J., "DIX Charter", March 2006. [I-D.draft-merrells-use-cases] Merrells, J., "DIX Use Cases", May 2006. [OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-bindings-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-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-metadata-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. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Merrells, et al. Expires November 2, 2006 [Page 66] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [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. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [SHA] "NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.". [W3C.XHTML.10] W3c, "XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)", August 2002. 33.2. Informative References [IANA.application.samlassertion-xml] OASIS Security Services Technical Committee (SSTC), Merrells, et al. Expires November 2, 2006 [Page 67] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 "application/samlassertion+xml MIME Media Type Registration", IANA MIME Media Types Registry application/ samlassertion+xml, December 2004. [OASIS.draft-saml-protocol-ext-02] Cantor, S., "SAML Protocol Extensions", OASIS SSTC Working Draft draft-saml-protocol-ext-02, Februrary 2006. [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-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. [OASIS.saml-sec-consider-2.0-os] Hirsch, F., Philpott, R., and E. Maler, "Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0", OASIS Standard saml-sec-consider- 2.0-os, March 2005. [OASIS.sstc-saml-exec-overview-2.0-cd-01] Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", OASIS SSTC Committee Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. [OASIS.sstc-saml-tech-overview-2.0-draft-08] Hughes, J. and E. Maler, "Security Assertion Markup Language (SAML) V2.0 Technical Overview", OASIS SSTC Working Draft sstc-saml-tech-overview-2.0-draft-08, September 2005. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. Merrells, et al. Expires November 2, 2006 [Page 68] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Authors' Addresses John Merrells Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 Canada Email: merrells@sxip.com URI: http://sxip.com/ Pete Rowley Red Hat 444 Castro Street Mountain View, CA 94041 USA Email: prowley@redhat.com URI: http://redhat.com/ Jim Sermersheim Novell 1800 South Novell Place Provo, Utah 84606 USA Email: jimse@novell.com URI: http://novell.com/ Marlin Pohlman Oracle 7966 East 41st Unit 11 West Tulsa, Ok 74145 USA Email: marlin.pohlman@oracle.com URI: http://oracle.com/ Merrells, et al. Expires November 2, 2006 [Page 69] Internet-Draft DIX: Digital Identity Exchange Protocol May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Merrells, et al. Expires November 2, 2006 [Page 70]