This rewrite is based on Jim's editing down of draft #3 and the
conversations on the list over the past couple of weeks.
I'll work on some use cases / scenarios next.
John
----
Description of Working Group:
The Digital Identity Exchange (DIX) group will specify an Internet-
scale identity information exchange protocol. A system architecture
will be defined such that a separation of control may be maintained
between all parties of the exchange.
Problem Statement
The Internet is host to many online information sources and services.
There is a growing demand for users to identify, and provide
information about themselves. Users bear the burden of managing their
own authentication materials and repeatedly providing their identity
information. Signing in to web pages and completing user registration
forms is an example.
Goals
To specify a protocol for moving identity information between
parties, and a system architecture that enables the development of
software agents to manage this exchange.
To specify a protocol with minimal adoption barriers, for which the
following aspects of the protocol should be considered:
Deployment of DIX-aware services and solutions should require minimal
modifications to existing software to enable participation in an
identity information exchange.
The end-user should have control over their identity information and
always be providing consent for the exchange of any of their
information.
Initiation of an exchange between two parties should be possible
without any
pre-established relationship.
A naming scheme for user identifiers should be considered that allows
the user to concurrently maintain multiple personas, to separate
their digital identity from their identifier, and to separate the
parties exchanging information from their identifier.
Naming schemes for user attributes should be considered.
The data that represents the identity information is expected to be
opaque. It is expected that the messages of the protocol will include
elements that associate property descriptors and their values to
digital identities.
Security should be considered (confidentiality and data integrity of
any transferred information must be in place). Also, non-user parties
should maintain the user's privacy.
Existing techniques and technologies should be considered to ensure
ease of adoption, implementation, and interoperability.
Extensibility should be considered for each aspect of the protocol to
ensure flexibility for future uses.
The protocol should be scalable, requiring no centralized services
beyond those that already exist (i.e. DNS).
Out of Scope
- How to federate identity namespaces.
- How to use or issue digital certificates.
- The schema and type system for identity information.
- The mechanisms by which authentication is performed, (e.g. username/
password, one-time password devices). The scope is constrained to the
movement of the authentication result between parties.
Internet Drafts
The Working Group anticipates the authoring of at least three
Internet-Drafts.
DIX Use Cases * A catalogue of DIX protocol use cases which
illustrate the problems being solved, and to inform the decision
making of the Working Group. For example, one use case could
illustrate how DIX would be used by a website to check the reputation
of potential posters to an online forum. Another use case could show
how form fill-in could be automated.
DIX Protocol * A description of the DIX protocol. It is expected that
the protocol will be composed of discovery, exchange and
verification; discovery of endpoints and negotiation of capabilities,
exchange of identity information, and verification of the
authenticity of identity information. This document should specify
the protocol elements in a transport-independent manner.
DIX HTTP Transport Binding * How the DIX protocol will be mapped onto
HTTP as a transport layer. In this case the user's software is a HTTP
client, to which no modifications should be required, and the third
party would be a HTTP server. Continuing with the theme of simplicity
a HTTP server should require minimal changes to support identity
information exchange. For example, a HTML form could receive
information the same way that a user would provide it, as if they
typed it into the form themselves.
It is anticipated that both the protocol and transport binding
documents will be on the standards track.
These documents provide a foundation layer for protocol extensions
such as support for one party acting as an agent for another (e.g.
Web Services), interoperation with existing protocols for movement of
security information (e.g. WS-Trust, SAML), acquisition and
presentation of third-party claims (e.g. XML-DSIG), alternative
transport bindings (e.g. XMPP, SIP).
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
