Internet DRAFT - draft-merrells-dix
draft-merrells-dix
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:
<form
method='post'
accept-charset='utf-8'
class= 'urn:ietf:params:dix:form'
action= 'http://membersite.com/agent_discovery'>
<input
type='text'
name='urn:ietf:params:dix:agent-path'
value=''/>
<input
type='submit'
value='submit'/>
</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
<LINK
REL="urn:ietf:params:dix:agent-endpoint"
HREF="http://www.example.com/homesite"/>
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.
<html>
<body onload="document.theForm.submit()">
<form
name="theForm"
method="post"
action="http://membersite.com/url">
<input
type="hidden"
name="DIXMessageType"
value="urn:ietf:params:dix:message:request:fetch"/>
<input
type="hidden"
name="DIXRequiredServices"
value="urn:ietf:params:dix:service:fetch"/>
.
.
.
etc
<input type="submit" value="Post" />
</form>
<noscript>
<p>Click "Post" to complete the transaction.</p>
<p style="font-size: small">
Note: you are only seeing this page because you have Javascript
disabled, or because your browser does not support Javascript.</p>
</noscript>
</body>
</html>
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, "<DIXFetchRequest>". 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, "<DIXFetchResponse>". 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, "<DIXStoreRequest>". 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, <DIXStoreResponse>. 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
<LINK
REL="urn:ietf:params:dix:agent"
HREF="http://www.example.com/homesite"/>
<LINK
REL="urn:ietf:params:dix:agent"
HREF="http://www.homesite.com/">
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
<?xml version="1.0" encoding="UTF-8"?>
<!-- XML Schema for Extensions -->
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:dix="urn:ietf:params:dix:protocol"
targetNamespace="urn:ietf:params:dix:protocol"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
version="1.0">
<import
namespace="urn:oasis:names:tc:SAML:2.0:protocol"
schemaLocation="http://docs.oasis-open.org/security/
saml/v2.0/saml-schema-protocol-2.0.xsd"/>
<import
namespace="urn:oasis:names:tc:SAML:2.0:assertion"
schemaLocation="http://docs.oasis-open.org/security/
saml/v2.0/saml-schema-assertion-2.0.xsd"/>
<include schemaLocation="dix-schema-assertion.xsd"/>
<!-- DIX SAML FetchRequest and StoreRequest elements -->
<element
name="DIXFetchRequest"
type="dix:DIXAttributeQueryType"/>
<element
name="DIXStoreRequest"
type="dix:DIXAttributeQueryType"/>
<!-- DIX SAML Request Extension Elements -->
<element name="SPName" type="anyURI"/>
<element name="SPFriendlyName" type="string"/>
<element name="SPLogoURL" type="anyURI"/>
<element name="SPCancelURL" type="anyURI"/>
<element name="SPExplanation" type="string"/>
<element name="SPAuthAge" type="unsignedLong"/>
<!-- DIX SAML Response Extension Elements -->
<element
name="DIXFetchResponse"
type="dix:DIXResponseType"/>
<element
name="DIXStoreResponse"
type="dix:DIXResponseType"/>
Merrells, et al. Expires November 2, 2006 [Page 56]
Internet-Draft DIX: Digital Identity Exchange Protocol May 2006
<element name="IAFriendlyName" type="string"/>
<!-- DIX SAML Request Extension Group -->
<group name="DIXRequestGroup">
<sequence>
<element ref="dix:SPName"/>
<element ref="dix:SPFriendlyName" minOccurs="0"/>
<element ref="dix:SPLogoURL" minOccurs="0"/>
<element ref="dix:SPCancelURL" minOccurs="0"/>
<element ref="dix:SPExplanation"
minOccurs="0"/>
<element ref="dix:1SPAuthAge" minOccurs="0"/>
</sequence>
</group>
<!-- DIX SAML Request Complex Types -->
<complexType name="DIXAttributeQueryType">
<complexContent>
<extension base="samlp:RequestAbstractType">
<sequence>
<group ref="dix:DIXRequestGroup"/>
<element ref="saml:Attribute"
minOccurs="0" maxOccurs="unbounded"/>
<attribute name="DIXVersion"
type="string" use="required"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- DIX SAML Response Complex Types -->
<complexType name="DIXResponseType">
<complexContent>
<extension base="samlp:StatusResponseType">
<sequence>
<element ref="dix:IAFriendlyName"/>
<element ref="saml:Attribute"
minOccurs="0" maxOccurs="unbounded"/>
<attribute name="DIXVersion"
type="string" use="required"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Merrells, et al. Expires November 2, 2006 [Page 57]
Internet-Draft DIX: Digital Identity Exchange Protocol May 2006
25. Example Fetch Request Message
<?xml version="1.0" encoding="UTF-8"?>
<dix:DIXFetchRequest
xmlns:dix="urn:ietf:params:dix:protocol"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:dix:protocol
dix-schema-protocol.xsd"
Version="2.0"
DIXVersion="1.0"
ID="B3d42e457fda3d5a"
IssueInstant="2006-04-17T00:46:02Z">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://geeknews.com/sxip
</saml:Issuer>
<dix:SPName>geeknews.com</dix:SPName>
<dix:SPFriendlyName>Geek News</dix:SPFriendlyName>
<dix:SPLogoURL>
http://geeknews.com/geeknews_logo.jpg
</dix:SPLogoURL>
<dix:SPCancelURL>
http://geeknews.com/cancel
</dix:SPCancelURL>
<dix:SPExplanation>geeknews.com is requesting your
first name and email address to allow you access
to their content.</dix:SPExplanation>
<saml:Attribute
Name="urn:ietf:params:dix:property:persona-url"
NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"/>
<saml:Attribute
Name="http://dixs.org/contact/name/first"
NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"/>
<saml:Attribute
Name="http://dixs.org/contact/internet/email"
NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"/>
</dix:DIXFetchRequest>
Merrells, et al. Expires November 2, 2006 [Page 58]
Internet-Draft DIX: Digital Identity Exchange Protocol May 2006
26. Example Fetch Response Message
<?xml version="1.0" encoding="UTF-8"?>
<dix:DIXFetchResponse
xmlns:dix="urn:ietf:params:dix:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:dix:protocol
dix-schema-protocol.xsd"
Version="2.0"
DIXVersion="1.0"
ID="A3AC-34B8-BFD1-342B"
IssueInstant="2006-04-17T00:48:02Z">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://example.com/homesite
</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<dix:IAFriendlyName>Your Friendly ISP</dix:IAFriendlyName>
<saml:Attribute
Name="http://dixs.org/contact/name/first"
NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri">
<saml:AttributeValue>Beth</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
Name="http://dixs.org/contact/internet/email"
NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri">
<saml:AttributeValue>
beth@home.com
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
Name="urn:ietf:params:dix:property:persona-url"
NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri">
<saml:AttributeValue>
http://work.beth.com
</saml:AttributeValue>
</saml:Attribute>
</dix:DIXFetchResponse>
Merrells, et al. Expires November 2, 2006 [Page 59]
Internet-Draft DIX: Digital Identity Exchange Protocol May 2006
27. Example Store Request Message
<?xml version="1.0" encoding="UTF-8"?>
<dix:DIXStoreRequest xmlns:dix="urn:ietf:params:dix:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:dix:protocol
dix-schema-protocol.xsd"
Version="2.0"
DIXVersion="1.0"
ID="store-7721"
IssueInstant="2006-04-17T00:46:02Z">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://geeknews.com/sxip
</saml:Issuer>
<dix:SPName>geeknews.com</dix:SPName>
<dix:SPFriendlyName>Geek News</dix:SPFriendlyName>
<dix:SPLogoURL>
http://geeknews.com/geeknews_logo.jpg
</dix:SPLogoURL>
<dix:SPCancelURL>http://geeknews.com/cancel</dix:SPCancelURL>
<dix:SPExplanation>You have requested to store your photo from
Geeknews.com with work persona.</dix:SPExplanation>
<saml:Attribute
Name="http://dixs.org/media/image/48x48"
dix:Identifier="http://work.beth.com">
<saml:AttributeValue>
http://bethsite.com/smallimage.gif
</saml:AttributeValue>
</saml:Attribute>
</dix:DIXStoreRequest>
Merrells, et al. Expires November 2, 2006 [Page 60]
Internet-Draft DIX: Digital Identity Exchange Protocol May 2006
28. Example Store Response Message
<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response
xmlns:="urn:ietf:params:dix:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:dix:protocol dix-schema-protocol.xsd"
Version="2.0"
DIXVersion="1.0"
ID="store-7721"
IssueInstant="2006-04-17T00:50:02Z">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://example.com/homesite
</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<dix:IAFriendlyName>Your Friendly ISP</dix:IAFriendlyName>
</samlp:Response>
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]
