Before putting forth a show of hands, I think we should hammer out the
proposed vocabulary, the scenarios, and specified methods in the charter
before a vote. In fact, is that not the purpose of this forum? I will start
with my take on the charter.
Vocabulary
Identity or Digital Identity is not precisely defined - it should
be.
User's Agent sounds too much like user-agent in HTTP terminology.
Potential Terms: User Agent Server (from SIP), Identity Authority, or
User Identity Server
Reputation Data - We should clarify this within the scenario...
Scenarios - Web sign-on and forms is not the only time user identity needs
to be asserted. XMPP and SIP sessions are important and different scenarios
that require identity and profiles. Not to discount logging into weblogs but
non-HTTP scenarios are just as important. This protocol should not be
service specific.
The HTTP binding spec is separate from the protocol spec (core). I would
suggest removing this section of the charter (it's another scenario):
> Any solution should support multiple transport layers, but it is
> anticipated that this working group will focus on a HTTP based solution.
> In this case the user's software is a web browser, to which no
> modifications should be required, and the relying party would be a
> website. Continuing with the theme of simplicity a website should require
> minimal changes to support identity information exchange. For example, a
> web form could receive information the same way that a user would provide
> it, as if they typed it into the form themselves.
In general I think this charter should be slimed down to the essence of
digital identity exchange. Negotiation of authentication should be part of
the solution offered by this group so I would remove or change the
following:
> The mechanisms by which authentication and authorization are performed.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John
Merrells
Sent: Wednesday, January 18, 2006 5:55 PM
To: Digital Identity Exchange
Subject: [dix] draft proposed charter - consensus?
Can I ask for a virtual show of hands on the draft proposed charter?
(See below if you missed it first time around.)
The question is: Would you support the creation of a working
group based on this charter?
Email a (yes/no + optional comment) to me. (Or the list if you wish,
but I don't want it to get too noisy.)
The next step is to request a BOF at IETF 65... but I'd like us to
get the proposed charter well and truly bashed before we get there.
John
-----
Digital Identity Exchange - DIX
Chairs
TBD
Applciations Area Director(s):
Ted Hardie <[EMAIL PROTECTED]>
Scott Hollenbeck <[EMAIL PROTECTED]>
Mailing Lists:
General Discussion: [EMAIL PROTECTED]
To Subscribe: [EMAIL PROTECTED]
In Body: In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/dix/
Description of Working Group:
The DIX group will work on the specification of the Digital Identity
Exchange protocol. DIX is an Internet scale protocol for exchanging
identity information between endpoints. The protocol architecture
maintains a separation of control between all parties of the exchange
and supports both compartmentalized and anonymous identities.
Problem Statement
The success of the Internet has led to a multitude of online
information sources and services. A consequence of this has been the
increasing demand for users to identify themselves and to provide
information about them. The user is currently bearing the burden of
managing their authentication credentials and is repeatedly having to
provide their identity information. For example, signing in to web
pages and completing user registration forms.
An illustrative example would be a website that accepts user
generated content. A significant problem exists today that these
sites attract the attention of spammers. Upon submission the site
needs to determine both the identity of the submitter and that they
are of good standing in the community. In other words, the site
requires the reputation of the submitter. This is not possible
without a protocol to identify a user across multiple sites and to
move that reputation data around.
Goal
The goal of this group is to specify a protocol for moving identity
information between parties and a system architecture that enables
the development of software agents to manage a user's identity
information.
Method
An identity information exchange should involve just three parties:
the user, their agent, and a relying party. The user's agent is where
they authenticate themselves and a repository where they store their
identity information, and the relying party is an entity requesting
identity information.
The protocol should be both simple and secure. Simple meaning that
minimal modifications should be required to the user's software and
the relying party's software to participate in an identity
information exchange. The protocol should be inherently scalable,
requiring no centralized services, beyond those that already exist,
in order to operate.
The security of a protocol is well understood within the IETF to be
the assurance of confidentiality and integrity of any transferred
information. But, in the context of digital identity we wish to also
be assured that user agents and relying parties maintain user privacy.
Any solution should support multiple transport layers, but it is
anticipated that this working group will focus on a HTTP based
solution. In this case the user's software is a web browser, to which
no modifications should be required, and the relying party would be a
website. Continuing with the theme of simplicity a website should
require minimal changes to support identity information exchange. For
example, a web form could receive information the same way that a
user would provide it, as if they typed it into the form themselves.
In moving identity information between parties it is expected that
the messages of the protocol will include elements that bind property
names and values to digital identities. How a digital identity is
referred to is an important consideration. The properties an
identifier could have are that it allows the user to concurrently
maintain multiple personas, that it could allow for a separation
between the digital identity and the identifier and that it allow for
separation between the identifier and the user's agent. In the
interests of flexibility and interoperability we would suggest that
the identifier be a string of characters. This working group may
consider current best practice of what that string might be. For
example, a URL or a UUID.
Work In Scope
A user-centric, simple, secure, interoperable protocol for digital
identity information exchange.
An advanced work item for this working group would be consideration
of how this protocol could operate over web services protocols (e.g.
SOAP, XML-RPC, REST), or interoperate with existing web services
protocols for security information (e.g. WS-Trust). The group must be
careful not to preclude interoperation at a later date.
Although the data that represents the identity information is
expected to be opaque it is worth mentioning that the data could be
raw attributes of the digital identity, or could be third party
claims. A third party claim is signed by an authoritative source so
that the relying party can be assured of its authenticity. The
benefit of third party claims, as supported by this protocol, is that
the separation of claim acquisition from claim presentation provides
both scalability and privacy benefits.
Out of Scope
How to federate identity namespaces.
How to manage digital certificates or certification authorities.
The mechanisms by which authentication and authorization are performed.
Goals and Milestones:
March 2006 - BOF meeting
June 2006 - First DIX Protocol Internet Draft
June 2006 - First DIX HTTP Transport Binding Internet Draft
July 2006 - Working Group meeting
November 2006 - Working Group meeting
December 2006 - Request Last Call for DIX Protocol
December 2006 - Request Last Call for DIX HTTP Transport Binding
March 2007 - Working Group meeting
April 2007 - Submit DIX Protocol to IESG for consideration as
Proposed Standard
April 2007 - Submit DIX HTTP Transport Binding to IESG for
consideration as Proposed Standard
_______________________________________________
dix mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________
dix mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dix
