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]