John, I took a stab at simplifying the charter (based on your initial #3). In some places, the details can be moved into I-D's. My changes excluded the front and back matter
I managed to pare it from 1000 words to 182, and dropped the fog index from 11.58 to 9.68. I think a bit more could be done (look for the <todo: ...> statements, but didn't want to step on your toes too much ;). Take or leave all or parts at will. Jim 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. Deployment of DIX-aware services and solutions should require minimal modifications to existing software to enable participation in an identity information exchange. The protocol should be scalable, requiring no centralized services beyond those that already exist (i.e. DNS). 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. <todo: further distillation) An identifier will be chosen to refer to a digital identity. The identifier should be based on existing identifier schemes and namespace mechanisms to ensure flexibility and interoperability. The working group should consider current best practices in choosing this. For example, a URI, a URL or a UUID may be considered as a good fit for an identifier. This identifier may include various properties including: - that the user can concurrently maintain multiple personas, - that there is a separation between the digital identity and the identifier, and - that there be a separation between the identifier and the parties exchanging information. The specification should be transport independent in general. Bindings to one particular transport may be carried out while other transports are left for future specifications. <todo: make up our minds as to how much of the payload is talked about. Distill further> 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. 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 a receiving 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. Work In Scope A user-centric, simple, secure, interoperable protocol for digital identity information exchange. <todo: distill this> While any solution should allow DIX messages to be carried over multiple alternative transports, including, but not limited to: HTTP, XMPP, and SIP. It is anticipated that this working group will initially focus on a HTTP based solution. Doing this will help ensure interoperability among independent implementations. Support for both compartmentalized and anonymous identities. <todo: does this warrant adding another I-D to the list below?> An advanced work item would consider how to use this protocol for 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. 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. <todo: does this mean authentication between a protocol peers, or the use of DIX as part of an AuthN/AuthZ solution?> - The schema and type system for identity information. Internet Drafts The Working Group anticipates the authoring of at least three Internet-Drafts. Two of these are expected to become Standards Track documents. <Todo: which two?> 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. 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. _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
