From dix-bounces@ietf.org Thu Jan 05 08:32:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVEN-0006Id-Uv; Thu, 05 Jan 2006 08:32:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVEN-0006IX-4O for dix@megatron.ietf.org; Thu, 05 Jan 2006 08:32:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14072 for ; Thu, 5 Jan 2006 08:31:22 -0500 (EST) Received: from sbcsmtp3.sbc.com ([144.160.112.11] helo=tlph033.enaf.dadc.sbc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuVK2-0002G0-Ge for dix@ietf.org; Thu, 05 Jan 2006 08:38:31 -0500 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id k05DWPZM015642; Thu, 5 Jan 2006 07:32:25 -0600 Received: from MOSTLS1MSGHUB03.ITServices.sbc.com (mostls1msghub03.itservices.sbc.com [132.201.19.8]) by tlph033.enaf.dadc.sbc.com (8.13.4/8.13.4) with ESMTP id k05DWOlM015635; Thu, 5 Jan 2006 07:32:24 -0600 Received: from MOSTLS1MSGUSR12.ITServices.sbc.com ([132.201.19.63]) by MOSTLS1MSGHUB03.ITServices.sbc.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Jan 2006 07:32:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [dix] thoughts on "identity" and IETF Date: Thu, 5 Jan 2006 07:32:22 -0600 Message-ID: <5BCA148CF620434585515BA6EB61B86002A15D4B@MOSTLS1MSGUSR12.ITServices.sbc.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pAAH9FhsAAR96nHAAA6iAAAB/J0kAPgWjLwAFX9c2A= From: "THOMAS, BRIAN M \(SBCSI\)" To: "Hallam-Baker, Phillip" , "IETF DIX list" X-OriginalArrivalTime: 05 Jan 2006 13:32:24.0087 (UTC) FILETIME=[764DAA70:01C611FC] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.5.1048-14187.000 X-TM-AS-Result: No--26.900000-0.000000-31 X-Spam-Score: 0.9 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Phill: Sorry for the delay in responding; I left the office for the remainder of the year after composing my previous message. Happy new year! [...and with the new year comes a new corporate identity and a new email domain, which caused my post to be held the first time. Thanks, John, for the heads-up...] > The problem with this approach is that it requires the user to do more > than they are prepared to do which is vanishingly close to 'nothing at > all'. To the Win98 users who still find patching, backups, antivirus software and firewalls too much effort, such is of little value, I will readily concede, but I doubt that anything we can do will help them much. But for the users who have clamored for this effort, I'm convinced the problem is not mere laziness but confusion. If you give the user direct and visible control over concrete concepts that mean something to his life, I think that you'll find that his view of what constitutes a trivial task changes. "Are you willing to give the local Burger Barn restaurant your home address and phone number in exchange for getting every thirteenth hamburger free?" is a far simpler and more concrete question than "Are you willing to trust code from this provider?" In the first case, you must evaluate a relatively clear (and granular) value choice: decreased privacy versus cheaper junk food, clearly specified; no esoteric concepts to ponder. In the second, even as a specialist in the field I find myself wishing for more information and more choices. Further, it needn't require a lot of effort; properly designed, it can easily be arranged so that user interfaces only demand information you haven't already given, and at all other times actually save effort. Fill in a form? How many times will I have to type my name, address, phone number, SSN, account number, etc. etc. into a form for every new vendor I deal with? Even without other motive (or excuse), many merchant web sites would keep that information just to keep me from having to type it in every time I order something from them. Reduce the friction, right? Even if you don't have any previous experience with a site, if all the information they request carries tags from a namespace you've already used, a tool could supply default values you had made generally available, and ask about others. If their namespace is unknown to you, it could prompt for values from your own personal namespaces, possibly preferring more likely values heuristically, and creating the mapping for future use. Of course, for vendors that you know, you can have profiles previously saved that fill in all the fields based on your previously expressed preferences, and get rid of the "remember me?" preference on their site. All of these, however, are user interaction design decisions not directly related to the specification we need to produce, but exemplify the kinds of uses that should be supported. > I am very skeptical about the assertion that the user wants to really=20 > give out the information at all, or for that matter there is as much=20 > interest in the data requested as the inferences that can be drawn=20 > from it. I'm not entirely sure I take your meaning, but I think that I agree - and that it highlights some of the reasons that I have heard for starting this effort: that too often more information is given out than we would like, and more than is strictly necessary to provide what we want; and that more control over that information is deirable. Remember that merely giving users the ability to do something doesn't require them to do it; I can configure Firefox to dance and sing and act strangely, but my wife and kids don't have any problems using it as delivered. > I agree people want flexibility, but this was the starting point for=20 > SAML, GSSAPI, SASL. It is time to say 'choose one negotiation=20 > infrastructure, the existence of 6 negotiation standards does not mean > there is value to supporting more than one. No argument here. However, what we choose (or build) must begin with agreement on the requirements. Perhaps I have misunderstood where we are in this process, but I haven't seen such a detailed statement of requirements and have been under the impression that it doesn't yet exist. It is my belief, therefore, that what we must do is to specify a model for expressing fine-grained user choices in their own terms, so that implementors can provide products that translate those expressions into equivalent action with their mechanisms of choice. It is quite possible that this is not actually a model but a metamodel, since the metadata must be specifiable by the end-users. Many ad-hoc efforts, both open and proprietary, are currently underway in this area; I hope that we can - in contrast to the way things have often gone for standards work - coalesce, inform and focus these efforts rather than to try to compete with or control them, which we simply can't hope to do. brain[sic]=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 12 22:40:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFnq-0004u2-3y; Thu, 12 Jan 2006 22:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFno-0004tl-69 for dix@megatron.ietf.org; Thu, 12 Jan 2006 22:40:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25610 for ; Thu, 12 Jan 2006 22:39:13 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExFv1-0000oe-CW for dix@ietf.org; Thu, 12 Jan 2006 22:48:03 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0D3eNB6077273 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 Jan 2006 19:40:24 -0800 (PST) (envelope-from MERRELLS@SXIP.COM) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: dix@ietf.org From: John Merrells Date: Thu, 12 Jan 2006 19:40:34 -0800 X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Subject: [dix] Proposed Charter for DIX Working Group X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Hello 'DIX mailing list member', The following document is a proposed charter for a DIX Working Group. Feedback to me, or discussion on this list, is most welcome. This proposed charter will form part of a request to the application =20 area directors for a BOF at the next IETF meeting. At that meeting this =20 charter will be discussed, and if found to be acceptable, will become the =20 working group charter, should one be created. John ------------- Digital Identity Exchange - DIX Chairs TBD Applciations Area Director(s): Ted Hardie Scott Hollenbeck Mailing Lists: General Discussion: dix@ietf.org To Subscribe: dix-request@ietf.org 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 =20 Exchange protocol. DIX is an Internet scale protocol for exchanging =20 identity information between endpoints. The protocol architecture =20 maintains a separation of control between all parties of the exchange =20= and supports both compartmentalized and anonymous identities. Problem Statement The success of the Internet has led to a multitude of online =20 information sources and services. A consequence of this has been the =20 increasing demand for users to identify themselves and to provide =20 information about them. The user is currently bearing the burden of =20 managing their authentication credentials and is repeatedly having to =20= provide their identity information. For example, signing in to web =20 pages and completing user registration forms. An illustrative example would be a website that accepts user =20 generated content. A significant problem exists today that these =20 sites attract the attention of spammers. Upon submission the site =20 needs to determine both the identity of the submitter and that they =20 are of good standing in the community. In other words, the site =20 requires the reputation of the submitter. This is not possible =20 without a protocol to identify a user across multiple sites and to =20 move that reputation data around. Goal The goal of this group is to specify a protocol for moving identity =20 information between parties and a system architecture that enables =20 the development of software agents to manage a user=92s identity =20 information. Method An identity information exchange should involve just three parties: =20 the user, their agent, and a relying party. The user=92s agent is where =20= they authenticate themselves and a repository where they store their =20 identity information, and the relying party is an entity requesting =20 identity information. The protocol should be both simple and secure. Simple meaning that =20 minimal modifications should be required to the user=92s software and =20= the relying party=92s software to participate in an identity =20 information exchange. The protocol should be inherently scalable, =20 requiring no centralized services, beyond those that already exist, =20 in order to operate. The security of a protocol is well understood within the IETF to be =20 the assurance of confidentiality and integrity of any transferred =20 information. But, in the context of digital identity we wish to also =20 be assured that user agents and relying parties maintain user privacy. Any solution should support multiple transport layers, but it is =20 anticipated that this working group will focus on a HTTP based =20 solution. In this case the user=92s software is a web browser, to which =20= no modifications should be required, and the relying party would be a =20= website. Continuing with the theme of simplicity a website should =20 require minimal changes to support identity information exchange. For =20= example, a web form could receive information the same way that a =20 user would provide it, as if they typed it into the form themselves. In moving identity information between parties it is expected that =20 the messages of the protocol will include elements that bind property =20= names and values to digital identities. How a digital identity is =20 referred to is an important consideration. The properties an =20 identifier could have are that it allows the user to concurrently =20 maintain multiple personas, that it could allow for a separation =20 between the digital identity and the identifier and that it allow for =20= separation between the identifier and the user=92s agent. In the =20 interests of flexibility and interoperability we would suggest that =20 the identifier be a string of characters. This working group may =20 consider current best practice of what that string might be. For =20 example, a URL or a UUID. Work In Scope A user-centric, simple, secure, interoperable protocol for digital =20 identity information exchange. An advanced work item for this working group would be consideration =20 of how this protocol could operate over web services protocols (e.g. =20 SOAP, XML-RPC, REST), or interoperate with existing web services =20 protocols for security information (e.g. WS-Trust). The group must be =20= careful not to preclude interoperation at a later date. Although the data that represents the identity information is =20 expected to be opaque it is worth mentioning that the data could be =20 raw attributes of the digital identity, or could be third party =20 claims. A third party claim is signed by an authoritative source so =20 that the relying party can be assured of its authenticity. The =20 benefit of third party claims, as supported by this protocol, is that =20= the separation of claim acquisition from claim presentation provides =20 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 =96 BOF meeting June 2006 =96 First DIX Protocol Internet Draft June 2006 =96 First DIX HTTP Transport Binding Internet Draft July 2006 =96 Working Group meeting November 2006 =96 Working Group meeting December 2006 =96 Request Last Call for DIX Protocol December 2006 =96 Request Last Call for DIX HTTP Transport Binding March 2007 =96 Working Group meeting April 2007 =96 Submit DIX Protocol to IESG for consideration as =20 Proposed Standard April 2007 =96 Submit DIX HTTP Transport Binding to IESG for =20 consideration as Proposed Standard _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 11:18:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRdM-0004ea-AW; Fri, 13 Jan 2006 11:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRdK-0004eT-8K for dix@megatron.ietf.org; Fri, 13 Jan 2006 11:18:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19170 for ; Fri, 13 Jan 2006 11:17:07 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExRka-0001vx-U1 for dix@ietf.org; Fri, 13 Jan 2006 11:26:05 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0DGINVh018710; Fri, 13 Jan 2006 08:18:23 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:18:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 08:18:22 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A7A2@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYX83v6j8pNYn9hQECEXzIjLrQ12gAWcA0g From: "Hallam-Baker, Phillip" To: "John Merrells" , X-OriginalArrivalTime: 13 Jan 2006 16:18:22.0693 (UTC) FILETIME=[F9665950:01C6185C] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org The charter is somewhat more detailed than is usual. I am not sure that the term 'identity' is going to be understood by those who read it in the same sense as intended by those who wrote it. I prefer to use the terms 'identifier' and assertions concerning an identifier. I would also suggest that the application in the blog world is accountability based rather than permissions based. As I see it the problem divides up into two major parts, authentication and attributes. I think that the DIX group should only address the authentication part. There are already good standards based protocols for exchange of attributes, SAML for example. I don't see any value to revisiting that area, at the end of the day the issuer and the recipient of that information will both have to implement code. It is a back end office application that is going to require custom code whatever way you slice it.=20 If someone does think that there is a major technical advance possible over SAML attribute assertions I would prefer to work that back into the SAML spec (there is a WG still operating). The other reason for avoiding attributes is that that is where all the rat-holes lie. The Liberty org has spent years working up business rules to govern transfer of personal data through closely coupled bilateral agreements. The IETF is not a good venue for such discussions, it is a technical organization, not a legal one. =20 Where I think that we need to look at something different is on the authentication side. SAML has an authentication mechanism but it does not have quite the structure people seem to want to see. In SAML the federation is closely coupled, it is assumed that there is an a-priori federation agreement in place before the authentication transaction takes place. At the time it seemed like this was the inevitable, the correct approach. I now think that open federation is possible and the way forward. On the attributes side of thing I think that one of the points that has to be made here is that a lot of the personal information that flies around the web is not actualy needed at all. Publishers do not actually care who reads their publication, it's the advertisers who care. And the advertisers are in most cases looking to buy page views by particular demographic groups rather than looking for detailed information. The best way to get chartered to do the most urgent work is to propose to address only the authentication component and state that the group will rely on existing mechanisms (which do not even necessarily need to be enumerated) to address attributes. The problem as I see it in the federated identity space is that there is no simple, open federation protocol that allows a user to easily use an identity across multiple sites that do not have prior interchange agreements (or rule book structure if you like) in place. This is a very different application area to the one being considered by Liberty. In bloggish applications I expect that the main application will be simply the authentication component, laying claim to an identifier. The term 'simple' really needs to be qualified. Simple FOR WHOM? For a project to succeed in this space it must not exceed the complexity requirement of any party invovled. However the complexity requirements of the different parties are very different: Authentication service provider (user's agent) Relying party (blogger) User I believe that for a scheme to be successful the user experience myst be dramatically simpler than any that has been proposed to date. In fact I do not think that we can expect any mechanism that involves an identifier that is any more complex than an email address is going to be successful.=20 Traditionally the approach has been to try to minimize complexity for all parties, I think that this is a mistake. The parties responsible for administering the scheme at blogs or at authentication service providers are going to be several orders of magnitude more sophisticated than the least sophisticated users. The Internet has a billion users, the point of DIX is not to serve the most sophisticated 10%, it is to serve the least sophisticated. I think that it is well worth a marginal increase in sophistication on the administrator side if we can reduce complexity for the end user. The term 'secure' is going to get pounced on by the security people. Don't be surprised if you are required to write a threat model. Although the group is looking to be chartered in applications that will not stop the security people weighing in. In fact it may well be considered that the group should be under security. The issue that is most likely to get pounced on here is the problem of man in the middle and phishing attacks. The IETF has a policy that all new protocol standards MUST NOT require en-clair password transmission. I suspect in this case the bar will be higher and the group will be required to produce a protocol that guarantees that the password is not revealled to ANY party. I think that this problem can be overcome but I have not yet completed my own security analysis. Finally I think that the charter must make clear that the protocol will not involve the creation of any new registry. The Internet has one federated namespace - the DNS. If DIX is to be an Internet protocol then the federation must be based on the DNS, either explicitly or implicitly. The point here is enfranchisement and control, the whole rack of layer 9 issues that ICANN gets wrapped up in. To control your name on the Internet you have to own the domain name you rely on. If your web site is alice.blogsrus.com you are inevitably dependent on the continued terms of service of whoever owns the name blogsrus.com. To be an Internet citizen rather than a serf you have to own your own domain name. By implicit I mean a URI. The URIs used in YADIS/LID/OpenID/etc. ultimately rely on the DNS. Whoever owns the embedded DNS name can redefine the semantics for the rest of the name any way they like. From a control point of view http://yadis.blogsrus.com/people/alice is simply alice@blogsrus.com with more clutter.=20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of John Merrells > Sent: Thursday, January 12, 2006 10:41 PM > To: dix@ietf.org > Subject: [dix] Proposed Charter for DIX Working Group=20 >=20 >=20 > Hello 'DIX mailing list member', >=20 > The following document is a proposed charter for a DIX Working Group. > Feedback to me, or discussion on this list, is most welcome. >=20 > This proposed charter will form part of a request to the=20 > application area directors for a BOF at the next IETF=20 > meeting. At that meeting this charter will be discussed, and=20 > if found to be acceptable, will become the working group=20 > charter, should one be created. >=20 > John >=20 > ------------- >=20 > Digital Identity Exchange - DIX >=20 > Chairs >=20 > TBD >=20 > Applciations Area Director(s): >=20 > Ted Hardie > Scott Hollenbeck >=20 > Mailing Lists: >=20 > General Discussion: dix@ietf.org > To Subscribe: dix-request@ietf.org > In Body: In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/dix/ >=20 > Description of Working Group: >=20 > The DIX group will work on the specification of the Digital=20 > Identity Exchange protocol. DIX is an Internet scale protocol=20 > for exchanging identity information between endpoints. The=20 > protocol architecture maintains a separation of control=20 > between all parties of the exchange and supports both=20 > compartmentalized and anonymous identities. >=20 > Problem Statement >=20 > The success of the Internet has led to a multitude of online=20 > information sources and services. A consequence of this has=20 > been the increasing demand for users to identify themselves=20 > and to provide information about them. The user is currently=20 > bearing the burden of managing their authentication=20 > credentials and is repeatedly having to provide their=20 > identity information. For example, signing in to web pages=20 > and completing user registration forms. >=20 > An illustrative example would be a website that accepts user=20 > generated content. A significant problem exists today that=20 > these sites attract the attention of spammers. Upon=20 > submission the site needs to determine both the identity of=20 > the submitter and that they are of good standing in the=20 > community. In other words, the site requires the reputation=20 > of the submitter. This is not possible without a protocol to=20 > identify a user across multiple sites and to move that=20 > reputation data around. >=20 > Goal >=20 > The goal of this group is to specify a protocol for moving=20 > identity information between parties and a system=20 > architecture that enables the development of software agents=20 > to manage a user's identity information. >=20 > Method >=20 > An identity information exchange should involve just three parties: =20 > the user, their agent, and a relying party. The user's agent=20 > is where they authenticate themselves and a repository where=20 > they store their identity information, and the relying party=20 > is an entity requesting identity information. >=20 > The protocol should be both simple and secure. Simple meaning=20 > that minimal modifications should be required to the user's=20 > software and the relying party's software to participate in=20 > an identity information exchange. The protocol should be=20 > inherently scalable, requiring no centralized services,=20 > beyond those that already exist, in order to operate. >=20 > The security of a protocol is well understood within the IETF=20 > to be the assurance of confidentiality and integrity of any=20 > transferred information. But, in the context of digital=20 > identity we wish to also be assured that user agents and=20 > relying parties maintain user privacy. >=20 > Any solution should support multiple transport layers, but it=20 > is anticipated that this working group will focus on a HTTP=20 > based solution. In this case the user's software is a web=20 > browser, to which no modifications should be required, and=20 > the relying party would be a website. Continuing with the=20 > theme of simplicity a website should require minimal changes=20 > to support identity information exchange. For example, a web=20 > form could receive information the same way that a user would=20 > provide it, as if they typed it into the form themselves. >=20 > In moving identity information between parties it is expected=20 > that the messages of the protocol will include elements that=20 > bind property names and values to digital identities. How a=20 > digital identity is referred to is an important=20 > consideration. The properties an identifier could have are=20 > that it allows the user to concurrently maintain multiple=20 > personas, that it could allow for a separation between the=20 > digital identity and the identifier and that it allow for=20 > separation between the identifier and the user's agent. In=20 > the interests of flexibility and interoperability we would=20 > suggest that the identifier be a string of characters. This=20 > working group may consider current best practice of what that=20 > string might be. For example, a URL or a UUID. >=20 >=20 > Work In Scope >=20 > A user-centric, simple, secure, interoperable protocol for=20 > digital identity information exchange. >=20 > An advanced work item for this working group would be=20 > consideration of how this protocol could operate over web=20 > services protocols (e.g. =20 > SOAP, XML-RPC, REST), or interoperate with existing web=20 > services protocols for security information (e.g. WS-Trust).=20 > The group must be careful not to preclude interoperation at a=20 > later date. >=20 > Although the data that represents the identity information is=20 > expected to be opaque it is worth mentioning that the data=20 > could be raw attributes of the digital identity, or could be=20 > third party claims. A third party claim is signed by an=20 > authoritative source so that the relying party can be assured=20 > of its authenticity. The benefit of third party claims, as=20 > supported by this protocol, is that the separation of claim=20 > acquisition from claim presentation provides both scalability=20 > and privacy benefits. >=20 > Out of Scope >=20 > How to federate identity namespaces. > How to manage digital certificates or certification authorities. > The mechanisms by which authentication and authorization are=20 > performed. >=20 > Goals and Milestones: >=20 > March 2006 - BOF meeting > June 2006 - First DIX Protocol Internet Draft June 2006 -=20 > First DIX HTTP Transport Binding Internet Draft July 2006 -=20 > Working Group meeting November 2006 - Working Group meeting=20 > December 2006 - Request Last Call for DIX Protocol December=20 > 2006 - Request Last Call for DIX HTTP Transport Binding March=20 > 2007 - Working Group meeting April 2007 - Submit DIX Protocol=20 > to IESG for consideration as Proposed Standard April 2007 -=20 > Submit DIX HTTP Transport Binding to IESG for consideration=20 > as Proposed Standard >=20 >=20 >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 16:06:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExW7s-0003Dz-UX; Fri, 13 Jan 2006 16:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExW7p-00039M-JO for dix@megatron.ietf.org; Fri, 13 Jan 2006 16:06:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09633 for ; Fri, 13 Jan 2006 16:04:59 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWFD-0004Kz-1a for dix@ietf.org; Fri, 13 Jan 2006 16:13:59 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0DL6DFD032436; Fri, 13 Jan 2006 13:06:13 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 13:06:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] thoughts on "identity" and IETF Date: Fri, 13 Jan 2006 13:06:12 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A7FD@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] thoughts on "identity" and IETF Thread-Index: AcX5xqrMHZZ+jiCXQWyc7VldLrXT9gGH97bAABQ89pAAH9FhsAAR96nHAAA6iAAAB/J0kAPgWjLwAFX9c2ABotcxkA== From: "Hallam-Baker, Phillip" To: "THOMAS, BRIAN M \(SBCSI\)" , "IETF DIX list" X-OriginalArrivalTime: 13 Jan 2006 21:06:13.0291 (UTC) FILETIME=[2F7A77B0:01C61885] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I agree at some level, but again, you are assuming that we are dealling with the most sophisticated 50% of internet users, not the least sophisticated ones. Back in 1995 I proposed a scheme that would allow people to automatically fill in forms by establishing systems common tag values for form fields. Got laughed at. Four years later the same blighters who had laughed then tried to do the same thing but it was too late by then to do it well. I think that we have to break down the problem into parts. First there is the question of the identifier. I am the only person on the Internet who is allowed to call themselves pbaker@verisign.com. We can argue that this is subject to employment status but the basic principle still stands, if I want a name that is entirely mine I need to get my own domain name. Once we have an infrastructure that allows me to securely establish that I am the genuine pbaker@verisign.com to any other party on the net and without revealing to them information that allows them to go and impersonate me then we can go on to do the types of thing you talk about. But first we have to provide the infrastructure that allows me and only me to lay claim to my identifier. Bridging the gap from identifier to identity is probably going to involve policy decisions that are mediated by my identifier registry. I am not sure we even need to introduce standards there, SAML allows that information to be transported already. > -----Original Message----- > From: THOMAS, BRIAN M (SBCSI) [mailto:bt0008@att.com]=20 > Sent: Thursday, January 05, 2006 8:32 AM > To: Hallam-Baker, Phillip; IETF DIX list > Subject: FW: [dix] thoughts on "identity" and IETF >=20 >=20 > Phill: >=20 > Sorry for the delay in responding; I left the office for the=20 > remainder of the year after composing my previous message. =20 > Happy new year! >=20 > [...and with the new year comes a new corporate identity and=20 > a new email domain, which caused my post to be held the first=20 > time. Thanks, John, for the heads-up...] >=20 > > The problem with this approach is that it requires the user=20 > to do more >=20 > > than they are prepared to do which is vanishingly close to=20 > 'nothing at >=20 > > all'. >=20 > To the Win98 users who still find patching, backups,=20 > antivirus software and firewalls too much effort, such is of=20 > little value, I will readily concede, but I doubt that=20 > anything we can do will help them much. >=20 > But for the users who have clamored for this effort, I'm=20 > convinced the problem is not mere laziness but confusion. If=20 > you give the user direct and visible control over concrete=20 > concepts that mean something to his life, I think that you'll=20 > find that his view of what constitutes a trivial task=20 > changes. "Are you willing to give the local Burger Barn=20 > restaurant your home address and phone number in exchange for=20 > getting every thirteenth hamburger free?" is a far simpler=20 > and more concrete question than "Are you willing to trust=20 > code from this provider?" In the first case, you must=20 > evaluate a relatively clear (and granular) value choice: =20 > decreased privacy versus cheaper junk food, clearly=20 > specified; no esoteric concepts to ponder. In the second,=20 > even as a specialist in the field I find myself wishing for=20 > more information and more choices. >=20 > Further, it needn't require a lot of effort; properly=20 > designed, it can easily be arranged so that user interfaces=20 > only demand information you haven't already given, and at all=20 > other times actually save effort. > Fill in a form? How many times will I have to type my name,=20 > address, phone number, SSN, account number, etc. etc. into a=20 > form for every new vendor I deal with? Even without other=20 > motive (or excuse), many merchant web sites would keep that=20 > information just to keep me from having to type it in every=20 > time I order something from them. Reduce the friction, right? >=20 > Even if you don't have any previous experience with a site,=20 > if all the information they request carries tags from a=20 > namespace you've already used, a tool could supply default=20 > values you had made generally available, and ask about=20 > others. If their namespace is unknown to you, it could=20 > prompt for values from your own personal namespaces, possibly=20 > preferring more likely values heuristically, and creating the=20 > mapping for future use. >=20 > Of course, for vendors that you know, you can have profiles=20 > previously saved that fill in all the fields based on your=20 > previously expressed preferences, and get rid of the=20 > "remember me?" preference on their site. >=20 > All of these, however, are user interaction design decisions=20 > not directly related to the specification we need to produce,=20 > but exemplify the kinds of uses that should be supported. >=20 >=20 > > I am very skeptical about the assertion that the user wants=20 > to really=20 > > give out the information at all, or for that matter there=20 > is as much=20 > > interest in the data requested as the inferences that can be drawn=20 > > from it. >=20 > I'm not entirely sure I take your meaning, but I think that I=20 > agree - and that it highlights some of the reasons that I=20 > have heard for starting this effort: that too often more=20 > information is given out than we would like, and more than is=20 > strictly necessary to provide what we want; and that more=20 > control over that information is deirable. >=20 > Remember that merely giving users the ability to do something=20 > doesn't require them to do it; I can configure Firefox to=20 > dance and sing and act strangely, but my wife and kids don't=20 > have any problems using it as delivered. >=20 >=20 > > I agree people want flexibility, but this was the starting=20 > point for=20 > > SAML, GSSAPI, SASL. It is time to say 'choose one negotiation=20 > > infrastructure, the existence of 6 negotiation standards=20 > does not mean >=20 > > there is value to supporting more than one. >=20 > No argument here. However, what we choose (or build) must=20 > begin with agreement on the requirements. Perhaps I have=20 > misunderstood where we are in this process, but I haven't=20 > seen such a detailed statement of requirements and have been=20 > under the impression that it doesn't yet exist. >=20 > It is my belief, therefore, that what we must do is to=20 > specify a model for expressing fine-grained user choices in=20 > their own terms, so that implementors can provide products=20 > that translate those expressions into equivalent action with=20 > their mechanisms of choice. It is quite possible that this=20 > is not actually a model but a metamodel, since the metadata=20 > must be specifiable by the end-users. >=20 > Many ad-hoc efforts, both open and proprietary, are currently=20 > underway in this area; I hope that we can - in contrast to=20 > the way things have often gone for standards work - coalesce,=20 > inform and focus these efforts rather than to try to compete=20 > with or control them, which we simply can't hope to do. >=20 > brain[sic]=20 >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 16:23:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWOC-0006Mg-5h; Fri, 13 Jan 2006 16:23:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWOA-0006IH-QO for dix@megatron.ietf.org; Fri, 13 Jan 2006 16:23:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12459 for ; Fri, 13 Jan 2006 16:21:52 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWVY-0005aF-ME for dix@ietf.org; Fri, 13 Jan 2006 16:30:53 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0DLN8Hd008447 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 13:23:09 -0800 (PST) (envelope-from MERRELLS@SXIP.COM) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A7A2@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A7A2@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E4B8F8D-4847-4A5D-B552-C2487252074B@SXIP.COM> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 13:23:10 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 8:18 AM, Hallam-Baker, Phillip wrote: > The charter is somewhat more detailed than is usual. > Yes... because of the topic, 'identity', I wanted to scope the work down as clearly as possible. > I am not sure that the term 'identity' is going to be understood by > those who read it in the same sense as intended by those who wrote it. > What did it mean to you when you read it? My understanding, and I think the general understanding, is that 'identity' is a thing that a person has. > I prefer to use the terms 'identifier' and assertions concerning an > identifier. > And, I think that 'an identity is identified by an identifier'... and that 'attributes are bound to identifiers by assertions'. > I would also suggest that the application in the blog world is > accountability based rather than permissions based. I think that the user-generated content spam problem is similar to the email spam problem. Initial solutions were based on content analysis, but they have been defeated. There are now efforts afoot to identify the sender of an email, so that the reputation of the sender can be determined. 'Is the sender a good netizen?' The same problem exists for user-generated content. So, I believe that identity leads to reputation rather than to accountability or authorization. > As I see it the problem divides up into two major parts, > authentication > and attributes. > > I think that the DIX group should only address the authentication > part. > There are already good standards based protocols for exchange of > attributes, SAML for example. I don't see any value to revisiting that > area, at the end of the day the issuer and the recipient of that > information will both have to implement code. It is a back end office > application that is going to require custom code whatever way you > slice > it. > Our thinking is that DIX provides a mechanism for moving attribute assertions... those assertions could be about authentication or about attribute values... and they could be presented as plain text, or as XML, or as SAML, or whatever the endpoints agree to exchange. > The other reason for avoiding attributes is that that is where all the > rat-holes lie. The Liberty org has spent years working up business > rules > to govern transfer of personal data through closely coupled bilateral > agreements. The IETF is not a good venue for such discussions, it is a > technical organization, not a legal one. > I'm in total agreement. We don't want to go down that rat-hole. We have limited the scope to how the user moves their own identity information from their agent to a relying party. > Where I think that we need to look at something different is on the > authentication side. SAML has an authentication mechanism but it does > not have quite the structure people seem to want to see. > In the charter we've clearly stated that authentication mechanisms are out of scope. The agent can authenticate the user in any way it choses, and the relying party can chose whether to accept that authentication or not. DIX just moves the authentication assertion. > The problem as I see it in the federated identity space is that > there is > no simple, open federation protocol that allows a user to easily > use an > identity across multiple sites that do not have prior interchange > agreements (or rule book structure if you like) in place. > Yes, that's one of the things that's motivating this user-centric identity movement. > This is a very different application area to the one being > considered by > Liberty. In bloggish applications I expect that the main application > will be simply the authentication component, laying claim to an > identifier. > Note that that's just one example of many. Also that there is useful identity information associated with users in the blogosphere. My icon for instance. These days every blog or 'web2.0' website requests a URL to an image of me. It's making the web a friendlier place :-) > The term 'simple' really needs to be qualified. Simple FOR WHOM? > Good point. Perhaps I should have elaborated on that. In order of importance... 1) The end user - easy to adopt, easy to use. 2) The relying party - easy to enable a site, easy to deploy. 3) The agent - all complexity is pushed to these guys. > The Internet has a billion users, the point of DIX is not to serve the > most sophisticated 10%, it is to serve the least sophisticated. I > think > that it is well worth a marginal increase in sophistication on the > administrator side if we can reduce complexity for the end user. > Yeah, couldn't agree more. > The term 'secure' is going to get pounced on by the security people. > Don't be surprised if you are required to write a threat model. > Although > the group is looking to be chartered in applications that will not > stop > the security people weighing in. In fact it may well be considered > that > the group should be under security. > Yes... good advice. > Finally I think that the charter must make clear that the protocol > will > not involve the creation of any new registry. The Internet has one > federated namespace - the DNS. If DIX is to be an Internet protocol > then > the federation must be based on the DNS, either explicitly or > implicitly. > Yeah. The proposed charter states this: 'The protocol should be inherently scalable, requiring no centralized services, beyond those that already exist, in order to operate.' Perhaps oblique, but I meant what you said 'DNS'. Thanks for your illuminating comments. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 16:56:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWuW-0007YP-IV; Fri, 13 Jan 2006 16:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWuT-0007TP-0k for dix@megatron.ietf.org; Fri, 13 Jan 2006 16:56:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14922 for ; Fri, 13 Jan 2006 16:55:14 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExX1p-0006pZ-J7 for dix@ietf.org; Fri, 13 Jan 2006 17:04:15 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0DLuMk9004311; Fri, 13 Jan 2006 13:56:22 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 13:56:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 13:56:21 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYYh5Lh6hPiPGiVQGmP6VId49OKBQAAXu3g From: "Hallam-Baker, Phillip" To: "John Merrells" X-OriginalArrivalTime: 13 Jan 2006 21:56:22.0296 (UTC) FILETIME=[30FC3180:01C6188C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > What did it mean to you when you read it? My understanding,=20 > and I think the general understanding, is that 'identity' is=20 > a thing that a person has. Not to be too picky but your definition seems pretty close to the definition Douglas Adams suggested for 'life'. The same thing could apply to his glasses should he be wearing them. > > I prefer to use the terms 'identifier' and assertions concerning an=20 > > identifier. >=20 > And, I think that 'an identity is identified by an=20 > identifier'... and that 'attributes are bound to identifiers=20 > by assertions'. An identifier is a sign that stands for an identity. > > I would also suggest that the application in the blog world is=20 > > accountability based rather than permissions based. >=20 > I think that the user-generated content spam problem is=20 > similar to the email spam problem. Initial solutions were=20 > based on content analysis, but they have been defeated. > There are now efforts afoot to identify the sender of an=20 > email, so that the reputation of the sender can be=20 > determined. 'Is the sender a good netizen?' The same problem=20 > exists for user-generated content. So, I believe that=20 > identity leads to reputation rather than to accountability or=20 > authorization. Reputation is part of the accountability approach. In slashdot you are accountable to your reputation. The three components of an accountability scheme are authentication, accreditation and consequences. You have to have a way of knowing who to hold accountable, you have to know whether you are likely to be able to hold them accountable, you have to know that if they defect they will face consequences. Loss of reputation is one accountability strategy. However the SSL scheme hangs together through the threat of legal consequences in the case of a defection (at least with the high assurance CAs). > Our thinking is that DIX provides a mechanism for moving=20 > attribute assertions... those assertions could be about=20 > authentication or about attribute values... and they could be=20 > presented as plain text, or as XML, or as SAML, or whatever=20 > the endpoints agree to exchange. SAML is an XML format for describing attribute assertions. The reason I think you need to think about SAML rather than plain text is that in most of the cases that are interesting you are likely to be dealing with assertions from more than just the authentication provider, even though they might be distributed by the authentication provider. For example I might have an account hallam@gmail.com, I might log onto your blog and you might want to know what my Slashdot Karma is. I think that the missing piece here is the identifier. Once you have a common agreement on an identifier the other pieces fall into place. > I'm in total agreement. We don't want to go down that=20 > rat-hole. We have limited the scope to how the user moves=20 > their own identity information from their agent to a relying party. I would suggest less talk then that could be construed as being stuff that you don't intend to do. I have just been involved in getting the DKIM group chartered and you won't believe what people managed to get wrapped round their axles... > In the charter we've clearly stated that authentication=20 > mechanisms are out of scope. The agent can authenticate the=20 > user in any way it choses, and the relying party can chose=20 > whether to accept that authentication or not. DIX just moves=20 > the authentication assertion. Where I think the system falls down today is the integration of the various pieces. We have all the parts we need but none of them quite fit together. So I don't think you actually need to build any of the components you describe, but you do need to get them to work together.=20 I would however insist on a distinction between considering an authentication mechanism and considering authentication. The group is going to need to specify how to use at least one authentication mechanism in the context of the chosen identifier. What I would like to get to though is a framework that allows me to drop in a new authentication mechanism without disturbing any party in the ecology other than the user and their registry.=20 > > The term 'simple' really needs to be qualified. Simple FOR WHOM? > > >=20 > Good point. Perhaps I should have elaborated on that. In order > of importance... >=20 > 1) The end user - easy to adopt, easy to use. > 2) The relying party - easy to enable a site, easy to deploy. > 3) The agent - all complexity is pushed to these guys. I agree, but I would also divide 3 into two separate groups. Running a registry of a thousand or so users and running a registry of a hundred million are going to be two completely different things. I think that we really want to say that we will try to make it easy to do a low end registry without difficulty and make is possible to run a large registry. > > Finally I think that the charter must make clear that the protocol =20 > > will > > not involve the creation of any new registry. The Internet has one > > federated namespace - the DNS. If DIX is to be an Internet=20 > protocol =20 > > then > > the federation must be based on the DNS, either explicitly or > > implicitly. >=20 > Yeah. The proposed charter states this: >=20 > 'The protocol should be inherently scalable, requiring no centralized > services, beyond those that already exist, in order to operate.' >=20 > Perhaps oblique, but I meant what you said 'DNS'. Actually I brought it up mostly because people seem to have some strange ideas about what my motives might be in this area.=20 However there are protocols that try to establish a new registry without centralized services. I think it would be simpler to simply state that partitioning of the name space will be achieved using the existing DNS system. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 17:57:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXr2-00064f-Sw; Fri, 13 Jan 2006 17:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXr1-00064S-2a for dix@megatron.ietf.org; Fri, 13 Jan 2006 17:57:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18687 for ; Fri, 13 Jan 2006 17:55:43 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExXyM-0000To-Pj for dix@ietf.org; Fri, 13 Jan 2006 18:04:46 -0500 Received: from [192.168.6.246] (dhcp246.sxip.com [192.168.6.246]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0DMuq31012009 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 14:56:54 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47036F18-08E4-4C79-87A8-9BBDE31105F0@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Fri, 13 Jan 2006 14:56:45 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells Subject: [dix] Authentication out of scope X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 1:56 PM, Hallam-Baker, Phillip wrote: > >> In the charter we've clearly stated that authentication >> mechanisms are out of scope. The agent can authenticate the >> user in any way it choses, and the relying party can chose >> whether to accept that authentication or not. DIX just moves >> the authentication assertion. > > Where I think the system falls down today is the integration of the > various pieces. We have all the parts we need but none of them > quite fit > together. > > So I don't think you actually need to build any of the components you > describe, but you do need to get them to work together. > > I would however insist on a distinction between considering an > authentication mechanism and considering authentication. The group is > going to need to specify how to use at least one authentication > mechanism in the context of the chosen identifier. > > What I would like to get to though is a framework that allows me to > drop > in a new authentication mechanism without disturbing any party in the > ecology other than the user and their registry. Agreed. I don't think that you need to specify any authentication mechanism if you say it is out of band from moving "identity" _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 17:59:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXte-0006To-Jw; Fri, 13 Jan 2006 17:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXte-0006Tj-11 for dix@megatron.ietf.org; Fri, 13 Jan 2006 17:59:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18919 for ; Fri, 13 Jan 2006 17:58:26 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExY12-0000cJ-Sq for dix@ietf.org; Fri, 13 Jan 2006 18:07:29 -0500 Received: from [192.168.6.246] (dhcp246.sxip.com [192.168.6.246]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0DMxmlj012386 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 14:59:48 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Fri, 13 Jan 2006 14:59:40 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells Subject: [dix] attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 1:56 PM, Hallam-Baker, Phillip wrote: > >> Our thinking is that DIX provides a mechanism for moving >> attribute assertions... those assertions could be about >> authentication or about attribute values... and they could be >> presented as plain text, or as XML, or as SAML, or whatever >> the endpoints agree to exchange. > > SAML is an XML format for describing attribute assertions. > > The reason I think you need to think about SAML rather than plain text > is that in most of the cases that are interesting you are likely to be > dealing with assertions from more than just the authentication > provider, > even though they might be distributed by the authentication provider. SAML is one way to make a digital assertion. Supporting SAML would be A Good Thing. There are also lighter weight ways of making verifiable assertions that don't have the overhead, complexity and potential uncertainty of SAML. There are also IP issues there. > > For example I might have an account hallam@gmail.com, I might log onto > your blog and you might want to know what my Slashdot Karma is. > > I think that the missing piece here is the identifier. Once you have a > common agreement on an identifier the other pieces fall into place. Agreed _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 18:11:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExY4j-0000K6-RX; Fri, 13 Jan 2006 18:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExY4h-0000K1-T1 for dix@megatron.ietf.org; Fri, 13 Jan 2006 18:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19528 for ; Fri, 13 Jan 2006 18:09:52 -0500 (EST) Received: from exprod6og8.obsmtp.com ([64.18.1.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExYC6-0000z9-OZ for dix@ietf.org; Fri, 13 Jan 2006 18:18:55 -0500 Received: from source ([192.150.11.134]) by exprod6ob8.obsmtp.com ([64.18.5.12]) with SMTP; Fri, 13 Jan 2006 15:11:12 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0DNApYc017666; Fri, 13 Jan 2006 15:10:51 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0DNBAHb001746; Fri, 13 Jan 2006 15:11:11 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 15:11:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Authentication out of scope Date: Fri, 13 Jan 2006 15:09:49 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E4527F97@namail3.corp.adobe.com> In-Reply-To: <47036F18-08E4-4C79-87A8-9BBDE31105F0@sxip.com> Thread-Topic: [dix] Authentication out of scope Thread-Index: AcYYlQJ6b986Tkb+RX62IQTxMPoUrgAAMxew From: "Duane Nickull" To: "Dick Hardt" , "Hallam-Baker, Phillip" X-OriginalArrivalTime: 13 Jan 2006 23:11:51.0529 (UTC) FILETIME=[BC9E4D90:01C61896] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org We had a similar conversation in the OASIS WS-Security TC. The TC decided to build a modular set of specs to account for the addition or use of various existing and future authentication mechanisms. We have a core WS-Security spec, then a series of profiles. Currently Proposed 1.1 Specifications * SOAP Message Security 1.1 * Kerberos token profile 1.1 * Username token profile 1.1 * X.509 token profile 1.1 * SAML token profile 1.1 * REL token profile 1.1 * SwA profile 1.1 I would advocate a similar approach to preserve the core movement of identity without worrying about what goes on in the black boxes. Duane ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ *******************************=20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Friday, January 13, 2006 2:57 PM To: Hallam-Baker, Phillip Cc: dix@ietf.org; John Merrells Subject: [dix] Authentication out of scope On 13-Jan-06, at 1:56 PM, Hallam-Baker, Phillip wrote: > >> In the charter we've clearly stated that authentication >> mechanisms are out of scope. The agent can authenticate the >> user in any way it choses, and the relying party can chose >> whether to accept that authentication or not. DIX just moves >> the authentication assertion. > > Where I think the system falls down today is the integration of the > various pieces. We have all the parts we need but none of them =20 > quite fit > together. > > So I don't think you actually need to build any of the components you > describe, but you do need to get them to work together. > > I would however insist on a distinction between considering an > authentication mechanism and considering authentication. The group is > going to need to specify how to use at least one authentication > mechanism in the context of the chosen identifier. > > What I would like to get to though is a framework that allows me to =20 > drop > in a new authentication mechanism without disturbing any party in the > ecology other than the user and their registry. Agreed. I don't think that you need to specify any authentication mechanism =20 if you say it is out of band from moving "identity" _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 19:21:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExZAR-0004bz-Mf; Fri, 13 Jan 2006 19:21:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExZAP-0004YE-BJ for dix@megatron.ietf.org; Fri, 13 Jan 2006 19:21:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25155 for ; Fri, 13 Jan 2006 19:19:51 -0500 (EST) Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExZHl-0003qX-6N for dix@ietf.org; Fri, 13 Jan 2006 19:28:52 -0500 Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DEC481422AA; Fri, 13 Jan 2006 16:21:01 -0800 (PST) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0c1dc79d822ed61cd0114317d86952ea@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 16:20:57 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I agree with this. I got the impression from talking to Dick a while back, that DIX was going to leave a few very important pieces completely unspecified, which pretty much means no interoperability. I would expect that the group would have to produce at least one technical (though not necessarily complete) Internet-Draft *before* getting chartered, rather than making those post-charter milestones. lisa On Jan 13, 2006, at 1:56 PM, Hallam-Baker, Phillip wrote: > > I would however insist on a distinction between considering an > authentication mechanism and considering authentication. The group is > going to need to specify how to use at least one authentication > mechanism in the context of the chosen identifier. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 20:26:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExaBX-000335-07; Fri, 13 Jan 2006 20:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExaBV-00032v-0U for dix@megatron.ietf.org; Fri, 13 Jan 2006 20:26:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28904 for ; Fri, 13 Jan 2006 20:25:02 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExaIq-0005uc-K4 for dix@ietf.org; Fri, 13 Jan 2006 20:34:05 -0500 Received: from [192.168.6.246] (dhcp246.sxip.com [192.168.6.246]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0E1Q9Nx020205 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 17:26:10 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <0c1dc79d822ed61cd0114317d86952ea@osafoundation.org> References: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> <0c1dc79d822ed61cd0114317d86952ea@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <973592D1-8B2A-40FD-99BD-5311DECD2C40@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 17:26:03 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 4:20 PM, Lisa Dusseault wrote: > I agree with this. I got the impression from talking to Dick a > while back, that DIX was going to leave a few very important pieces > completely unspecified, which pretty much means no interoperability. Not sure how that means no interoperability ... but I will wait to be enlightened on that! > > I would expect that the group would have to produce at least one > technical (though not necessarily complete) Internet-Draft *before* > getting chartered, rather than making those post-charter milestones. Agreed. We have thoughts here. :-) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 20:27:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExaCh-00038d-VU; Fri, 13 Jan 2006 20:27:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExaCg-00038V-2B for dix@megatron.ietf.org; Fri, 13 Jan 2006 20:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29029 for ; Fri, 13 Jan 2006 20:26:16 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExaK6-0005y3-1P for dix@ietf.org; Fri, 13 Jan 2006 20:35:18 -0500 Received: from [12.144.188.147] (1153ahost147.starwoodbroadband.com [12.144.188.147]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0E1RYQ9020227 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 17:27:35 -0800 (PST) (envelope-from MERRELLS@SXIP.COM) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A810@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92F66F63-0E3F-43C3-B8F7-67FF1437278C@SXIP.COM> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 17:27:39 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 1:56 PM, Hallam-Baker, Phillip wrote: > >> What did it mean to you when you read it? My understanding, >> and I think the general understanding, is that 'identity' is >> a thing that a person has. > > Not to be too picky but your definition seems pretty close to the > definition Douglas Adams suggested for 'life'. The same thing could > apply to his glasses should he be wearing them. Identity is a philosophical thing... i think people get that. 'Digital Identity' seems to be the colloquial term people use for online identity. I'm content that it means what I think it means. >>> I prefer to use the terms 'identifier' and assertions concerning an >>> identifier. >> >> And, I think that 'an identity is identified by an >> identifier'... and that 'attributes are bound to identifiers >> by assertions'. > > An identifier is a sign that stands for an identity. Yes, we're in agreement. There's a paragraph in the charter that explicitly points out that a fundamental thing to work out is what an appropriate identifier is. > Reputation is part of the accountability approach. In slashdot you are > accountable to your reputation. > > The three components of an accountability scheme are authentication, > accreditation and consequences. You have to have a way of knowing > who to > hold accountable, you have to know whether you are likely to be > able to > hold them accountable, you have to know that if they defect they will > face consequences. > > Loss of reputation is one accountability strategy. However the SSL > scheme hangs together through the threat of legal consequences in the > case of a defection (at least with the high assurance CAs). The text you're discussing is just an example. You seem to be saying that there's a more general solution than the reputation one I'm suggesting... fine... but for the purposes of an example I'd rather it were more specific than more general. Yeah? >> I'm in total agreement. We don't want to go down that >> rat-hole. We have limited the scope to how the user moves >> their own identity information from their agent to a relying party. > > I would suggest less talk then that could be construed as being stuff > that you don't intend to do. I have just been involved in getting the > DKIM group chartered and you won't believe what people managed to get > wrapped round their axles... What do you think is missing from the 'out of scope' section? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 21:54:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbZ7-0004vt-NW; Fri, 13 Jan 2006 21:54:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbZ5-0004va-Rw for dix@megatron.ietf.org; Fri, 13 Jan 2006 21:54:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11059 for ; Fri, 13 Jan 2006 21:53:29 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExbgU-0002k2-My for dix@ietf.org; Fri, 13 Jan 2006 22:02:33 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0E2sdPc026883; Fri, 13 Jan 2006 18:54:39 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 18:54:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 18:54:38 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A865@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: attribute assertions Thread-Index: AcYYlRLfW57xIaC3StK1W15jpAx2WgAHxCyA From: "Hallam-Baker, Phillip" To: "Dick Hardt" X-OriginalArrivalTime: 14 Jan 2006 02:54:39.0393 (UTC) FILETIME=[DC7C7910:01C618B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells Subject: [dix] RE: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org =20 =20 > SAML is one way to make a digital assertion. Supporting SAML=20 > would be A Good Thing. >=20 > There are also lighter weight ways of making verifiable=20 > assertions that don't have the overhead, complexity and=20 > potential uncertainty of SAML.=20 I think that the complexity is in the problem rather than the solution. > There are also IP issues there. The only IP issue related to SAML I am aware of relates to four patents held by RSA that are entirely independent of the SAML specification itself. You do not escape the implications of the RSA patent by implementing something other than SAML, all that gets you to is having to cut a new license deal.=20 > > For example I might have an account hallam@gmail.com, I=20 > might log onto=20 > > your blog and you might want to know what my Slashdot Karma is. > > > > I think that the missing piece here is the identifier. Once=20 > you have a=20 > > common agreement on an identifier the other pieces fall into place. >=20 > Agreed >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 22:05:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exbjl-00087Q-K3; Fri, 13 Jan 2006 22:05:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exbjj-00087D-6m for dix@megatron.ietf.org; Fri, 13 Jan 2006 22:05:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11673 for ; Fri, 13 Jan 2006 22:04:28 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exbr9-00035q-Ly for dix@ietf.org; Fri, 13 Jan 2006 22:13:32 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0E35muF030935; Fri, 13 Jan 2006 19:05:48 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 19:05:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 19:05:47 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A866@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYYoGtQDlgDrZZtQFueuE9/byBxVwAFarQQ From: "Hallam-Baker, Phillip" To: "Lisa Dusseault" X-OriginalArrivalTime: 14 Jan 2006 03:05:48.0547 (UTC) FILETIME=[6B554530:01C618B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org The job that needs doing here is for someone to join the dots up. That is what DIX really needs to do. The common identifier format is the key to joining up the dots. In SAML and WS-Security we made the mistake of trying to please everyone. We ended up with a framework but no base case. There is a big problem with proliferating security mechanisms, the security you achieve tends to be the security of the weakest link in the chain. Digest Authentication was not a real step forward for HTTP security because we were not allowed to depricate BASIC, not even when it was only a week old. I think that we need to be able to show that we have selected a secure mechanism for password authentication (including One time passwords) and a secure mechanism for public key authentication and that it is possible to plug in biometric based authentication mechanisms if required. I do not think that it is acceptable to do the usual IETF move of punting and saying we will use everything.=20 The specification process is a process of removing degrees of freedom by making decisions. I do not think that there is any value in creating yet another meta-framework in this area. We already have two of those - WS-* and SAML.=20 What we need is an actionable strategy, a protocol, a set of bits on the wire, not yet another set of diagrams with bubbles marked 'user', 'user's agent', 'relying party' &ct. > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 > Sent: Friday, January 13, 2006 7:21 PM > To: Hallam-Baker, Phillip > Cc: dix@ietf.org; John Merrells > Subject: Re: [dix] Proposed Charter for DIX Working Group=20 >=20 > I agree with this. I got the impression from talking to Dick=20 > a while back, that DIX was going to leave a few very=20 > important pieces completely unspecified, which pretty much=20 > means no interoperability. >=20 > I would expect that the group would have to produce at least=20 > one technical (though not necessarily complete)=20 > Internet-Draft *before* getting chartered, rather than making=20 > those post-charter milestones. >=20 > lisa >=20 > On Jan 13, 2006, at 1:56 PM, Hallam-Baker, Phillip wrote: >=20 > > > > I would however insist on a distinction between considering an=20 > > authentication mechanism and considering authentication.=20 > The group is=20 > > going to need to specify how to use at least one authentication=20 > > mechanism in the context of the chosen identifier. >=20 >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 22:07:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exbl9-0000U2-8R; Fri, 13 Jan 2006 22:07:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exbl7-0000Tu-WD for dix@megatron.ietf.org; Fri, 13 Jan 2006 22:07:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11763 for ; Fri, 13 Jan 2006 22:05:55 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExbsX-00038N-0l for dix@ietf.org; Fri, 13 Jan 2006 22:14:59 -0500 Received: from [192.168.6.246] (dhcp246.sxip.com [192.168.6.246]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0E376Rk023126 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 19:07:07 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A865@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A865@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Fri, 13 Jan 2006 19:07:00 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells Subject: [dix] Re: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 6:54 PM, Hallam-Baker, Phillip wrote: > > >> SAML is one way to make a digital assertion. Supporting SAML >> would be A Good Thing. >> >> There are also lighter weight ways of making verifiable >> assertions that don't have the overhead, complexity and >> potential uncertainty of SAML. > > I think that the complexity is in the problem rather than the > solution. For problems as framed by SAML, likely. Is it not possible that not all problems that need a claim by a 3rd party have the same complexity? > > >> There are also IP issues there. > > The only IP issue related to SAML I am aware of relates to four > patents > held by RSA that are entirely independent of the SAML specification > itself. You do not escape the implications of the RSA patent by > implementing something other than SAML, all that gets you to is having > to cut a new license deal. Yes, if you are infringing. No if you are not. I know that is stating the obvious. :-) The last time I looked at the RSA license, you could not build a toolkit without them having to get a license from RSA. This makes it difficult to release open source modules. I see this is a huge barrier to adoption in the more innovative, less commercial markets. But the format of the assertion we are thinking out of scope for DIX. The focus is how to move the identity data around. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 22:14:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbsI-0002fd-NV; Fri, 13 Jan 2006 22:14:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExbsG-0002fU-Gv for dix@megatron.ietf.org; Fri, 13 Jan 2006 22:14:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12068 for ; Fri, 13 Jan 2006 22:13:17 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exbzh-0003LX-7L for dix@ietf.org; Fri, 13 Jan 2006 22:22:21 -0500 Received: from [192.168.6.246] (dhcp246.sxip.com [192.168.6.246]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0E3ETUT023280 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 13 Jan 2006 19:14:31 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A866@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A866@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 19:14:23 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I completely agree on joining the dots! I also agree on the common identifier! I don't see why authentication needs to be specified. There are already lots of ways of authenticating. The one with the required amount of security will be what is required in a given implementation. A key goal of DIX is to provide a spectrum of security. The web would have never taken off if every server needed an SSL cert. I think this will be pretty clear as we share our thoughts on how this all might work. DIX is for connecting a number of disparate things together in various ways so that there are real, deployable solutions. Summary: I think we are very aligned Phillip. I come from the Perl world, and am a very pragmatic on creating useful solutions to real problems. :-) -- Dick On 13-Jan-06, at 7:05 PM, Hallam-Baker, Phillip wrote: > The job that needs doing here is for someone to join the dots up. That > is what DIX really needs to do. The common identifier format is the > key > to joining up the dots. > > > In SAML and WS-Security we made the mistake of trying to please > everyone. We ended up with a framework but no base case. > > There is a big problem with proliferating security mechanisms, the > security you achieve tends to be the security of the weakest link > in the > chain. Digest Authentication was not a real step forward for HTTP > security because we were not allowed to depricate BASIC, not even when > it was only a week old. > > > I think that we need to be able to show that we have selected a secure > mechanism for password authentication (including One time > passwords) and > a secure mechanism for public key authentication and that it is > possible > to plug in biometric based authentication mechanisms if required. > > I do not think that it is acceptable to do the usual IETF move of > punting and saying we will use everything. > > The specification process is a process of removing degrees of > freedom by > making decisions. I do not think that there is any value in > creating yet > another meta-framework in this area. We already have two of those - > WS-* > and SAML. > > > What we need is an actionable strategy, a protocol, a set of bits > on the > wire, not yet another set of diagrams with bubbles marked 'user', > 'user's agent', 'relying party' &ct. > > >> -----Original Message----- >> From: Lisa Dusseault [mailto:lisa@osafoundation.org] >> Sent: Friday, January 13, 2006 7:21 PM >> To: Hallam-Baker, Phillip >> Cc: dix@ietf.org; John Merrells >> Subject: Re: [dix] Proposed Charter for DIX Working Group >> >> I agree with this. I got the impression from talking to Dick >> a while back, that DIX was going to leave a few very >> important pieces completely unspecified, which pretty much >> means no interoperability. >> >> I would expect that the group would have to produce at least >> one technical (though not necessarily complete) >> Internet-Draft *before* getting chartered, rather than making >> those post-charter milestones. >> >> lisa >> >> On Jan 13, 2006, at 1:56 PM, Hallam-Baker, Phillip wrote: >> >>> >>> I would however insist on a distinction between considering an >>> authentication mechanism and considering authentication. >> The group is >>> going to need to specify how to use at least one authentication >>> mechanism in the context of the chosen identifier. >> >> >> > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 22:25:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exc2e-00069x-B8; Fri, 13 Jan 2006 22:25:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Exc2b-00068x-F7 for dix@megatron.ietf.org; Fri, 13 Jan 2006 22:25:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12517 for ; Fri, 13 Jan 2006 22:23:58 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExcA1-0003b2-5w for dix@ietf.org; Fri, 13 Jan 2006 22:33:02 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0E3P9np002058; Fri, 13 Jan 2006 19:25:10 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 19:25:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Proposed Charter for DIX Working Group Date: Fri, 13 Jan 2006 19:25:09 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A867@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYYqbhWONeI8/3cSz6748bLc1Tl+QADbddA From: "Hallam-Baker, Phillip" To: "John Merrells" X-OriginalArrivalTime: 14 Jan 2006 03:25:09.0862 (UTC) FILETIME=[1F87E060:01C618BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: John Merrells [mailto:MERRELLS@SXIP.COM]=20 > On 13-Jan-06, at 1:56 PM, Hallam-Baker, Phillip wrote: >=20 > > > >> What did it mean to you when you read it? My understanding, and I=20 > >> think the general understanding, is that 'identity' is a=20 > thing that a=20 > >> person has. > > > > Not to be too picky but your definition seems pretty close to the=20 > > definition Douglas Adams suggested for 'life'. The same thing could=20 > > apply to his glasses should he be wearing them. >=20 > Identity is a philosophical thing...=20 I agree, that is why I spent a considerable time studying semiotics when I was working on the Web fundamentals. > i think people get that.=20 > 'Digital Identity' seems to be the colloquial term people use=20 > for online identity. I'm content that it means what I think it means. As a philosopher I am not content unless I can have a clearly defined meaning. As a pragmatist I worry that unless we can get the term locked down to the point where we can reasonably claim that it is an established term of art we get a confused IESG. > Yes, we're in agreement. There's a paragraph in the charter=20 > that explicitly points out that a fundamental thing to work=20 > out is what an appropriate identifier is. The problem with that approach is that the charter is quite likely to be filed as 'research' and the group told to go and talk to the IRTF chair. The problem with presenting a Identity 2.0 type sales pitch at the IETF is that most of the people have already seen the Identity 0.1, and 1.0 series talks. It's a hard sell. > > Reputation is part of the accountability approach. In=20 > slashdot you are=20 > > accountable to your reputation. > > > > The three components of an accountability scheme are=20 > authentication,=20 > > accreditation and consequences. You have to have a way of=20 > knowing who=20 > > to hold accountable, you have to know whether you are likely to be=20 > > able to hold them accountable, you have to know that if they defect=20 > > they will face consequences. > > > > Loss of reputation is one accountability strategy. However the SSL=20 > > scheme hangs together through the threat of legal=20 > consequences in the=20 > > case of a defection (at least with the high assurance CAs). >=20 > The text you're discussing is just an example. You seem to be=20 > saying that there's a more general solution than the=20 > reputation one I'm suggesting... fine... but for the purposes=20 > of an example I'd rather it were more specific than more=20 > general. Yeah? What I am saying here is that 'reputation' schemes are a proper subset of accountability schemes. You asserted that we were doing reputation NOT accountability. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 13 22:50:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExcQq-0005W1-8r; Fri, 13 Jan 2006 22:50:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExcQo-0005VG-9e for dix@megatron.ietf.org; Fri, 13 Jan 2006 22:50:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13773 for ; Fri, 13 Jan 2006 22:48:59 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExcYF-0004Jb-La for dix@ietf.org; Fri, 13 Jan 2006 22:58:04 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0E3oGr6000832; Fri, 13 Jan 2006 19:50:16 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 19:50:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 19:50:15 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A86A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: attribute assertions Thread-Index: AcYYt6GIHJkIU6WgR9SE+PXRqOE1rAAAovIg From: "Hallam-Baker, Phillip" To: "Dick Hardt" X-OriginalArrivalTime: 14 Jan 2006 03:50:16.0434 (UTC) FILETIME=[A1848520:01C618BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells Subject: [dix] RE: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: Dick Hardt [mailto:dick@sxip.com]=20 > > I think that the complexity is in the problem rather than the=20 > > solution. >=20 > For problems as framed by SAML, likely. Is it not possible=20 > that not all problems that need a claim by a 3rd party have=20 > the same complexity? I don't think it is possibel to answer your objection here without an indication of where you see the complexity in SAML. The basic assertion framework is pretty compact, the schema is only a couple of pages long. The conditions and advice components are entirely optional.=20 > Yes, if you are infringing. No if you are not. I know that is=20 > stating the obvious. :-) I was never convinced that we were infringing. However RSA was asked if they had any IPR that MIGHT infringe on the standard and they replied yes, then followed up with a royalty free license under standard reciprocal terms in full compliance with both the W3C and OASIS IPR policies. Given the subject matter of DIX I do not think it very likely that the RSA engineers are not going to attend the Working Group if formed. The IETF 'note well' rules then require them to make the same disclosure they made in SAML. > The last time I looked at the RSA license, you could not build a =20 > toolkit without them having to get a license from RSA. This makes it =20 > difficult to release open source modules. I see this is a huge =20 > barrier to adoption in the more innovative, less commercial markets. I do not see the difference in the situation here. The RSA patents have broad claims. If there is an arguable case that they cover SAML there is an arguable case that they cover DIX as well. Patent law does not require a patent holder to assert their claims in order to preserve them. At the end of the day it costs over $2 million to mount or defend a patent lawsuit in the USA. It is highly unlikely that anyone is going to mount a case over a defect in a royalty free license unless provoked by another patent suit. Given where the interminable wrangling over IPR got us in MARID I strongly suggest that the DIX WG adopt the W3C IPR licensing terms as a requirement. These have already been agreed to by Apache and the major Open Source groups and by all the major vendors who hold IPR and are likely to issue royalty free licenses. > But the format of the assertion we are thinking out of scope=20 > for DIX. The focus is how to move the identity data around. I think I need to see some bits on the wire before I can understand the distinction you are attempting to draw here.=20 As I see it there are two parts to an identity protocol: * There is an authentication process which allows the identity holder to claim their identity by authenticating themselves against an uniformly resolved identifier. * There is an attribute retrieval protocol that allows the relying party to obtain assertions binding particular attributes to the authenticated identifier. The source of these assertions may or may not be the same as the source of the authentication decision. The atteribute assertions may or may not be trustworthy and may or may not be trusted. If the first part AND the second part are both out of scope, what is left? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jan 15 16:29:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR2-0008Em-Q8; Sun, 15 Jan 2006 16:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR1-0008DS-LE for dix@megatron.ietf.org; Sun, 15 Jan 2006 16:29:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16375 for ; Sun, 15 Jan 2006 16:27:48 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYo-0003f4-MZ for dix@ietf.org; Sun, 15 Jan 2006 16:37:15 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLT1KY008134; Sun, 15 Jan 2006 22:29:01 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLSxHP007091; Sun, 15 Jan 2006 22:29:01 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:28:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [dix] Proposed Charter for DIX Working Group Date: Sun, 15 Jan 2006 22:28:31 +0100 Message-ID: Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYX83rOL4ovVoaPREiTszRknlGJowB52oQg From: "Tschofenig, Hannes" To: "John Merrells" , X-OriginalArrivalTime: 15 Jan 2006 21:28:31.0692 (UTC) FILETIME=[A20DC0C0:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org hi all,=20 i am not quite sure what you are trying to accomplish.=20 from the text i get the impression that you want to work on a new saml = version.=20 from the feedback provided by Phillip Hallam-Baker i understood that he = suggests to work on authentication mechanis. i don't think that this is = the right approach either. (saml comment: saml does not define any = authentication mechanisms) there is already plenty of work on authentication approaches out there.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] Im=20 > Auftrag von John Merrells > Gesendet: Freitag, 13. Januar 2006 04:41 > An: dix@ietf.org > Betreff: [dix] Proposed Charter for DIX Working Group=20 >=20 >=20 > Hello 'DIX mailing list member', >=20 > The following document is a proposed charter for a DIX Working Group. > Feedback to me, or discussion on this list, is most welcome. >=20 > This proposed charter will form part of a request to the application =20 > area > directors for a BOF at the next IETF meeting. At that meeting this =20 > charter > will be discussed, and if found to be acceptable, will become the =20 > working > group charter, should one be created. >=20 > John >=20 > ------------- >=20 > Digital Identity Exchange - DIX >=20 > Chairs >=20 > TBD >=20 > Applciations Area Director(s): >=20 > Ted Hardie > Scott Hollenbeck >=20 > Mailing Lists: >=20 > General Discussion: dix@ietf.org > To Subscribe: dix-request@ietf.org > In Body: In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/dix/ >=20 > Description of Working Group: >=20 > The DIX group will work on the specification of the Digital Identity =20 > Exchange protocol. DIX is an Internet scale protocol for exchanging =20 > identity information between endpoints. The protocol architecture =20 > maintains a separation of control between all parties of the=20 > exchange =20 > and supports both compartmentalized and anonymous identities. >=20 > Problem Statement >=20 > The success of the Internet has led to a multitude of online =20 > information sources and services. A consequence of this has been the =20 > increasing demand for users to identify themselves and to provide =20 > information about them. The user is currently bearing the burden of =20 > managing their authentication credentials and is repeatedly=20 > having to =20 > provide their identity information. For example, signing in to web =20 > pages and completing user registration forms. >=20 > An illustrative example would be a website that accepts user =20 > generated content. A significant problem exists today that these =20 > sites attract the attention of spammers. Upon submission the site =20 > needs to determine both the identity of the submitter and that they =20 > are of good standing in the community. In other words, the site =20 > requires the reputation of the submitter. This is not possible =20 > without a protocol to identify a user across multiple sites and to =20 > move that reputation data around. >=20 > Goal >=20 > The goal of this group is to specify a protocol for moving identity =20 > information between parties and a system architecture that enables =20 > the development of software agents to manage a user's identity =20 > information. >=20 > Method >=20 > An identity information exchange should involve just three parties: =20 > the user, their agent, and a relying party. The user's agent=20 > is where =20 > they authenticate themselves and a repository where they store their =20 > identity information, and the relying party is an entity requesting =20 > identity information. >=20 > The protocol should be both simple and secure. Simple meaning that =20 > minimal modifications should be required to the user's software and =20 > the relying party's software to participate in an identity =20 > information exchange. The protocol should be inherently scalable, =20 > requiring no centralized services, beyond those that already exist, =20 > in order to operate. >=20 > The security of a protocol is well understood within the IETF to be =20 > the assurance of confidentiality and integrity of any transferred =20 > information. But, in the context of digital identity we wish to also =20 > be assured that user agents and relying parties maintain user privacy. >=20 > Any solution should support multiple transport layers, but it is =20 > anticipated that this working group will focus on a HTTP based =20 > solution. In this case the user's software is a web browser,=20 > to which =20 > no modifications should be required, and the relying party=20 > would be a =20 > website. Continuing with the theme of simplicity a website should =20 > require minimal changes to support identity information=20 > exchange. For =20 > example, a web form could receive information the same way that a =20 > user would provide it, as if they typed it into the form themselves. >=20 > In moving identity information between parties it is expected that =20 > the messages of the protocol will include elements that bind=20 > property =20 > names and values to digital identities. How a digital identity is =20 > referred to is an important consideration. The properties an =20 > identifier could have are that it allows the user to concurrently =20 > maintain multiple personas, that it could allow for a separation =20 > between the digital identity and the identifier and that it=20 > allow for =20 > separation between the identifier and the user's agent. In the =20 > interests of flexibility and interoperability we would suggest that =20 > the identifier be a string of characters. This working group may =20 > consider current best practice of what that string might be. For =20 > example, a URL or a UUID. >=20 >=20 > Work In Scope >=20 > A user-centric, simple, secure, interoperable protocol for digital =20 > identity information exchange. >=20 > An advanced work item for this working group would be consideration =20 > of how this protocol could operate over web services protocols (e.g. =20 > SOAP, XML-RPC, REST), or interoperate with existing web services =20 > protocols for security information (e.g. WS-Trust). The group=20 > must be =20 > careful not to preclude interoperation at a later date. >=20 > Although the data that represents the identity information is =20 > expected to be opaque it is worth mentioning that the data could be =20 > raw attributes of the digital identity, or could be third party =20 > claims. A third party claim is signed by an authoritative source so =20 > that the relying party can be assured of its authenticity. The =20 > benefit of third party claims, as supported by this protocol,=20 > is that =20 > the separation of claim acquisition from claim presentation provides =20 > both scalability and privacy benefits. >=20 > Out of Scope >=20 > How to federate identity namespaces. > How to manage digital certificates or certification authorities. > The mechanisms by which authentication and authorization are=20 > performed. >=20 > Goals and Milestones: >=20 > 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 =20 > Proposed Standard > April 2007 - Submit DIX HTTP Transport Binding to IESG for =20 > consideration as Proposed Standard >=20 >=20 >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jan 15 16:29:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR4-0008G1-PV; Sun, 15 Jan 2006 16:29:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFR2-0008Dm-58 for dix@megatron.ietf.org; Sun, 15 Jan 2006 16:29:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16379 for ; Sun, 15 Jan 2006 16:27:48 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFYo-0003f6-P1 for dix@ietf.org; Sun, 15 Jan 2006 16:37:15 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLT1Qe013673; Sun, 15 Jan 2006 22:29:01 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k0FLSxYo031433; Sun, 15 Jan 2006 22:29:01 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jan 2006 22:28:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [dix] Proposed Charter for DIX Working Group Date: Sun, 15 Jan 2006 22:28:32 +0100 Message-ID: Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYX83v6j8pNYn9hQECEXzIjLrQ12gAWcA0gAGOGPoA= From: "Tschofenig, Hannes" To: "Hallam-Baker, Phillip" , "John Merrells" , X-OriginalArrivalTime: 15 Jan 2006 21:28:32.0786 (UTC) FILETIME=[A2B4AF20:01C61A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org hi phillip,=20 =20 please find my comments inline: > -----Urspr=FCngliche Nachricht----- > Von: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] Im=20 > Auftrag von Hallam-Baker, Phillip > Gesendet: Freitag, 13. Januar 2006 17:18 > An: John Merrells; dix@ietf.org > Betreff: RE: [dix] Proposed Charter for DIX Working Group=20 >=20 > The charter is somewhat more detailed than is usual. >=20 > I am not sure that the term 'identity' is going to be understood by > those who read it in the same sense as intended by those who wrote it. >=20 > I prefer to use the terms 'identifier' and assertions concerning an > identifier. >=20 > I would also suggest that the application in the blog world is > accountability based rather than permissions based. >=20 >=20 > As I see it the problem divides up into two major parts,=20 > authentication > and attributes. >=20 > I think that the DIX group should only address the=20 > authentication part. > There are already good standards based protocols for exchange of > attributes, SAML for example. I don't see any value to revisiting that > area, at the end of the day the issuer and the recipient of that > information will both have to implement code. It is a back end office > application that is going to require custom code whatever way=20 > you slice > it.=20 >=20 > If someone does think that there is a major technical advance possible > over SAML attribute assertions I would prefer to work that=20 > back into the > SAML spec (there is a WG still operating). i agree with you.=20 >=20 > The other reason for avoiding attributes is that that is where all the > rat-holes lie. The Liberty org has spent years working up=20 > business rules > to govern transfer of personal data through closely coupled bilateral > agreements. The IETF is not a good venue for such discussions, it is a > technical organization, not a legal one. =20 >=20 > Where I think that we need to look at something different is on the > authentication side.=20 why do you think so? there is plenty of work on authentication.=20 you are concerned about duplicated work in the are of security = information exchange (namely saml in your case) but you are not = concerned about the huge amount of authentication work out there.=20 to be more specific with my question:=20 a) do you want to define new authentication and key exchange protocols?=20 b) do you want to work on mechanisms to transport (or encapsulate) = authentication and key exchange protocols?=20 > SAML has an authentication mechanism but it does > not have quite the structure people seem to want to see. saml does not have an authentication mechanism.=20 >=20 > In SAML the federation is closely coupled, it is assumed that there is > an a-priori federation agreement in place before the authentication > transaction takes place. At the time it seemed like this was the > inevitable, the correct approach. I now think that open federation is > possible and the way forward. the term federation is just a fancy new term for an old concept. you can = compare this with the aaa infrastructure.=20 to make it simple: if the relying party does not directly or indirectly = trust the asserting party then the whole concept does not work. (note = that i particularly use the fuzzy term 'trust' here.)=20 that's the same with the aaa infrastructure where the relationship = between the different domains is typically based on business = relationships.=20 i got lost from here on... >=20 > On the attributes side of thing I think that one of the=20 > points that has > to be made here is that a lot of the personal information that flies > around the web is not actualy needed at all. Publishers do=20 > not actually > care who reads their publication, it's the advertisers who=20 > care. And the > advertisers are in most cases looking to buy page views by particular > demographic groups rather than looking for detailed information. >=20 >=20 > The best way to get chartered to do the most urgent work is to propose > to address only the authentication component and state that the group > will rely on existing mechanisms (which do not even=20 > necessarily need to > be enumerated) to address attributes. >=20 >=20 > The problem as I see it in the federated identity space is=20 > that there is > no simple, open federation protocol that allows a user to=20 > easily use an > identity across multiple sites that do not have prior interchange > agreements (or rule book structure if you like) in place. >=20 > This is a very different application area to the one being=20 > considered by > Liberty. In bloggish applications I expect that the main application > will be simply the authentication component, laying claim to an > identifier. >=20 >=20 > The term 'simple' really needs to be qualified. Simple FOR WHOM? >=20 > For a project to succeed in this space it must not exceed the=20 > complexity > requirement of any party invovled. However the complexity requirements > of the different parties are very different: >=20 > Authentication service provider (user's agent) > Relying party (blogger) > User >=20 > I believe that for a scheme to be successful the user=20 > experience myst be > dramatically simpler than any that has been proposed to date.=20 > In fact I > do not think that we can expect any mechanism that involves an > identifier that is any more complex than an email address is=20 > going to be > successful.=20 >=20 > Traditionally the approach has been to try to minimize complexity for > all parties, I think that this is a mistake. The parties=20 > responsible for > administering the scheme at blogs or at authentication=20 > service providers > are going to be several orders of magnitude more=20 > sophisticated than the > least sophisticated users. >=20 > The Internet has a billion users, the point of DIX is not to serve the > most sophisticated 10%, it is to serve the least=20 > sophisticated. I think > that it is well worth a marginal increase in sophistication on the > administrator side if we can reduce complexity for the end user. >=20 >=20 > The term 'secure' is going to get pounced on by the security people. > Don't be surprised if you are required to write a threat=20 > model. Although > the group is looking to be chartered in applications that=20 > will not stop > the security people weighing in. In fact it may well be=20 > considered that > the group should be under security. >=20 > The issue that is most likely to get pounced on here is the problem of > man in the middle and phishing attacks. The IETF has a policy that all > new protocol standards MUST NOT require en-clair password=20 > transmission. > I suspect in this case the bar will be higher and the group will be > required to produce a protocol that guarantees that the=20 > password is not > revealled to ANY party. >=20 > I think that this problem can be overcome but I have not yet completed > my own security analysis. >=20 >=20 > Finally I think that the charter must make clear that the=20 > protocol will > not involve the creation of any new registry. The Internet has one > federated namespace - the DNS. If DIX is to be an Internet=20 > protocol then > the federation must be based on the DNS, either explicitly or > implicitly. >=20 > The point here is enfranchisement and control, the whole rack=20 > of layer 9 > issues that ICANN gets wrapped up in. To control your name on the > Internet you have to own the domain name you rely on. If your web site > is alice.blogsrus.com you are inevitably dependent on the continued > terms of service of whoever owns the name blogsrus.com. >=20 > To be an Internet citizen rather than a serf you have to own your own > domain name. >=20 > By implicit I mean a URI. The URIs used in YADIS/LID/OpenID/etc. > ultimately rely on the DNS. Whoever owns the embedded DNS name can > redefine the semantics for the rest of the name any way they=20 > like. From > a control point of view=20 > http://yadis.blogsrus.com/people/alice is simply > alice@blogsrus.com with more clutter.=20 >=20 >=20 ciao hannes >=20 > > -----Original Message----- > > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > > Behalf Of John Merrells > > Sent: Thursday, January 12, 2006 10:41 PM > > To: dix@ietf.org > > Subject: [dix] Proposed Charter for DIX Working Group=20 > >=20 > >=20 > > Hello 'DIX mailing list member', > >=20 > > The following document is a proposed charter for a DIX=20 > Working Group. > > Feedback to me, or discussion on this list, is most welcome. > >=20 > > This proposed charter will form part of a request to the=20 > > application area directors for a BOF at the next IETF=20 > > meeting. At that meeting this charter will be discussed, and=20 > > if found to be acceptable, will become the working group=20 > > charter, should one be created. > >=20 > > John > >=20 > > ------------- > >=20 > > Digital Identity Exchange - DIX > >=20 > > Chairs > >=20 > > TBD > >=20 > > Applciations Area Director(s): > >=20 > > Ted Hardie > > Scott Hollenbeck > >=20 > > Mailing Lists: > >=20 > > General Discussion: dix@ietf.org > > To Subscribe: dix-request@ietf.org > > In Body: In Body: subscribe > > Archive: http://www.ietf.org/mail-archive/web/dix/ > >=20 > > Description of Working Group: > >=20 > > The DIX group will work on the specification of the Digital=20 > > Identity Exchange protocol. DIX is an Internet scale protocol=20 > > for exchanging identity information between endpoints. The=20 > > protocol architecture maintains a separation of control=20 > > between all parties of the exchange and supports both=20 > > compartmentalized and anonymous identities. > >=20 > > Problem Statement > >=20 > > The success of the Internet has led to a multitude of online=20 > > information sources and services. A consequence of this has=20 > > been the increasing demand for users to identify themselves=20 > > and to provide information about them. The user is currently=20 > > bearing the burden of managing their authentication=20 > > credentials and is repeatedly having to provide their=20 > > identity information. For example, signing in to web pages=20 > > and completing user registration forms. > >=20 > > An illustrative example would be a website that accepts user=20 > > generated content. A significant problem exists today that=20 > > these sites attract the attention of spammers. Upon=20 > > submission the site needs to determine both the identity of=20 > > the submitter and that they are of good standing in the=20 > > community. In other words, the site requires the reputation=20 > > of the submitter. This is not possible without a protocol to=20 > > identify a user across multiple sites and to move that=20 > > reputation data around. > >=20 > > Goal > >=20 > > The goal of this group is to specify a protocol for moving=20 > > identity information between parties and a system=20 > > architecture that enables the development of software agents=20 > > to manage a user's identity information. > >=20 > > Method > >=20 > > An identity information exchange should involve just three=20 > parties: =20 > > the user, their agent, and a relying party. The user's agent=20 > > is where they authenticate themselves and a repository where=20 > > they store their identity information, and the relying party=20 > > is an entity requesting identity information. > >=20 > > The protocol should be both simple and secure. Simple meaning=20 > > that minimal modifications should be required to the user's=20 > > software and the relying party's software to participate in=20 > > an identity information exchange. The protocol should be=20 > > inherently scalable, requiring no centralized services,=20 > > beyond those that already exist, in order to operate. > >=20 > > The security of a protocol is well understood within the IETF=20 > > to be the assurance of confidentiality and integrity of any=20 > > transferred information. But, in the context of digital=20 > > identity we wish to also be assured that user agents and=20 > > relying parties maintain user privacy. > >=20 > > Any solution should support multiple transport layers, but it=20 > > is anticipated that this working group will focus on a HTTP=20 > > based solution. In this case the user's software is a web=20 > > browser, to which no modifications should be required, and=20 > > the relying party would be a website. Continuing with the=20 > > theme of simplicity a website should require minimal changes=20 > > to support identity information exchange. For example, a web=20 > > form could receive information the same way that a user would=20 > > provide it, as if they typed it into the form themselves. > >=20 > > In moving identity information between parties it is expected=20 > > that the messages of the protocol will include elements that=20 > > bind property names and values to digital identities. How a=20 > > digital identity is referred to is an important=20 > > consideration. The properties an identifier could have are=20 > > that it allows the user to concurrently maintain multiple=20 > > personas, that it could allow for a separation between the=20 > > digital identity and the identifier and that it allow for=20 > > separation between the identifier and the user's agent. In=20 > > the interests of flexibility and interoperability we would=20 > > suggest that the identifier be a string of characters. This=20 > > working group may consider current best practice of what that=20 > > string might be. For example, a URL or a UUID. > >=20 > >=20 > > Work In Scope > >=20 > > A user-centric, simple, secure, interoperable protocol for=20 > > digital identity information exchange. > >=20 > > An advanced work item for this working group would be=20 > > consideration of how this protocol could operate over web=20 > > services protocols (e.g. =20 > > SOAP, XML-RPC, REST), or interoperate with existing web=20 > > services protocols for security information (e.g. WS-Trust).=20 > > The group must be careful not to preclude interoperation at a=20 > > later date. > >=20 > > Although the data that represents the identity information is=20 > > expected to be opaque it is worth mentioning that the data=20 > > could be raw attributes of the digital identity, or could be=20 > > third party claims. A third party claim is signed by an=20 > > authoritative source so that the relying party can be assured=20 > > of its authenticity. The benefit of third party claims, as=20 > > supported by this protocol, is that the separation of claim=20 > > acquisition from claim presentation provides both scalability=20 > > and privacy benefits. > >=20 > > Out of Scope > >=20 > > How to federate identity namespaces. > > How to manage digital certificates or certification authorities. > > The mechanisms by which authentication and authorization are=20 > > performed. > >=20 > > Goals and Milestones: > >=20 > > March 2006 - BOF meeting > > June 2006 - First DIX Protocol Internet Draft June 2006 -=20 > > First DIX HTTP Transport Binding Internet Draft July 2006 -=20 > > Working Group meeting November 2006 - Working Group meeting=20 > > December 2006 - Request Last Call for DIX Protocol December=20 > > 2006 - Request Last Call for DIX HTTP Transport Binding March=20 > > 2007 - Working Group meeting April 2007 - Submit DIX Protocol=20 > > to IESG for consideration as Proposed Standard April 2007 -=20 > > Submit DIX HTTP Transport Binding to IESG for consideration=20 > > as Proposed Standard > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > dix mailing list > > dix@ietf.org > > https://www1.ietf.org/mailman/listinfo/dix > >=20 > >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 13:37:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZEK-0008EZ-BE; Mon, 16 Jan 2006 13:37:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZEJ-0008DC-1M for dix@megatron.ietf.org; Mon, 16 Jan 2006 13:37:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05099 for ; Mon, 16 Jan 2006 13:35:58 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyZMG-0005Eo-8d for dix@ietf.org; Mon, 16 Jan 2006 13:45:37 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0GIbJhL002123; Mon, 16 Jan 2006 10:37:19 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 10:37:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Proposed Charter for DIX Working Group Date: Mon, 16 Jan 2006 10:37:18 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A8CD@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYX83rOL4ovVoaPREiTszRknlGJowB52oQgADv4MRA= From: "Hallam-Baker, Phillip" To: "Tschofenig, Hannes" , "John Merrells" , X-OriginalArrivalTime: 16 Jan 2006 18:37:19.0247 (UTC) FILETIME=[E19CC9F0:01C61ACB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I think that the real problem is that we have all the components its = just that they don't fit together. Its like the car that the guy made by taking one piece at a time home in = his lunchbox. He ended up with a gearbox from one year, an engine from = another, etc. etc. Nothing fit together. I think that most of the problems of the Internet protocols today are = problems of integration rather than base technology. The part that is dealt with worst is the user experience. The bits on = the screen are quite properly left to implementations, but there is = still something missing. I am not suggesting that we redo authentication or redo attributes. What = we need is: 1) a model that shows how all the pieces can fit together in a = consistent and coherent fashion. 2) A deployment strategy for getting the model into common use. (2) is much more important (and difficult) than (1). > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Tschofenig, Hannes > Sent: Sunday, January 15, 2006 4:29 PM > To: John Merrells; dix@ietf.org > Subject: AW: [dix] Proposed Charter for DIX Working Group=20 >=20 > hi all,=20 >=20 > i am not quite sure what you are trying to accomplish.=20 >=20 > from the text i get the impression that you want to work on a=20 > new saml version.=20 > from the feedback provided by Phillip Hallam-Baker i=20 > understood that he suggests to work on authentication=20 > mechanis. i don't think that this is the right approach=20 > either. (saml comment: saml does not define any=20 > authentication mechanisms) there is already plenty of work on=20 > authentication approaches out there.=20 >=20 > ciao > hannes >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] Im=20 > Auftrag von=20 > > John Merrells > > Gesendet: Freitag, 13. Januar 2006 04:41 > > An: dix@ietf.org > > Betreff: [dix] Proposed Charter for DIX Working Group > >=20 > >=20 > > Hello 'DIX mailing list member', > >=20 > > The following document is a proposed charter for a DIX=20 > Working Group. > > Feedback to me, or discussion on this list, is most welcome. > >=20 > > This proposed charter will form part of a request to the=20 > application=20 > > area directors for a BOF at the next IETF meeting. At that meeting=20 > > this charter will be discussed, and if found to be acceptable, will=20 > > become the working group charter, should one be created. > >=20 > > John > >=20 > > ------------- > >=20 > > Digital Identity Exchange - DIX > >=20 > > Chairs > >=20 > > TBD > >=20 > > Applciations Area Director(s): > >=20 > > Ted Hardie > > Scott Hollenbeck > >=20 > > Mailing Lists: > >=20 > > General Discussion: dix@ietf.org > > To Subscribe: dix-request@ietf.org > > In Body: In Body: subscribe > > Archive: http://www.ietf.org/mail-archive/web/dix/ > >=20 > > Description of Working Group: > >=20 > > The DIX group will work on the specification of the Digital=20 > Identity=20 > > Exchange protocol. DIX is an Internet scale protocol for exchanging=20 > > identity information between endpoints. The protocol architecture=20 > > maintains a separation of control between all parties of=20 > the exchange=20 > > and supports both compartmentalized and anonymous identities. > >=20 > > Problem Statement > >=20 > > The success of the Internet has led to a multitude of online=20 > > information sources and services. A consequence of this has=20 > been the=20 > > increasing demand for users to identify themselves and to provide=20 > > information about them. The user is currently bearing the burden of=20 > > managing their authentication credentials and is repeatedly=20 > having to=20 > > provide their identity information. For example, signing in to web=20 > > pages and completing user registration forms. > >=20 > > An illustrative example would be a website that accepts=20 > user generated=20 > > content. A significant problem exists today that these=20 > sites attract=20 > > the attention of spammers. Upon submission the site needs=20 > to determine=20 > > both the identity of the submitter and that they are of=20 > good standing=20 > > in the community. In other words, the site requires the=20 > reputation of=20 > > the submitter. This is not possible without a protocol to=20 > identify a=20 > > user across multiple sites and to move that reputation data around. > >=20 > > Goal > >=20 > > The goal of this group is to specify a protocol for moving identity=20 > > information between parties and a system architecture that=20 > enables the=20 > > development of software agents to manage a user's identity=20 > > information. > >=20 > > Method > >=20 > > An identity information exchange should involve just three=20 > parties: =20 > > the user, their agent, and a relying party. The user's=20 > agent is where=20 > > they authenticate themselves and a repository where they=20 > store their=20 > > identity information, and the relying party is an entity requesting=20 > > identity information. > >=20 > > The protocol should be both simple and secure. Simple meaning that=20 > > minimal modifications should be required to the user's software and=20 > > the relying party's software to participate in an identity=20 > information=20 > > exchange. The protocol should be inherently scalable, requiring no=20 > > centralized services, beyond those that already exist, in order to=20 > > operate. > >=20 > > The security of a protocol is well understood within the IETF to be=20 > > the assurance of confidentiality and integrity of any transferred=20 > > information. But, in the context of digital identity we=20 > wish to also=20 > > be assured that user agents and relying parties maintain=20 > user privacy. > >=20 > > Any solution should support multiple transport layers, but it is=20 > > anticipated that this working group will focus on a HTTP based=20 > > solution. In this case the user's software is a web=20 > browser, to which=20 > > no modifications should be required, and the relying party=20 > would be a=20 > > website. Continuing with the theme of simplicity a website should=20 > > require minimal changes to support identity information=20 > exchange. For=20 > > example, a web form could receive information the same way=20 > that a user=20 > > would provide it, as if they typed it into the form themselves. > >=20 > > In moving identity information between parties it is=20 > expected that the=20 > > messages of the protocol will include elements that bind property=20 > > names and values to digital identities. How a digital identity is=20 > > referred to is an important consideration. The properties an=20 > > identifier could have are that it allows the user to concurrently=20 > > maintain multiple personas, that it could allow for a separation=20 > > between the digital identity and the identifier and that it=20 > allow for=20 > > separation between the identifier and the user's agent. In the=20 > > interests of flexibility and interoperability we would suggest that=20 > > the identifier be a string of characters. This working group may=20 > > consider current best practice of what that string might be. For=20 > > example, a URL or a UUID. > >=20 > >=20 > > Work In Scope > >=20 > > A user-centric, simple, secure, interoperable protocol for digital=20 > > identity information exchange. > >=20 > > An advanced work item for this working group would be=20 > consideration of=20 > > how this protocol could operate over web services protocols (e.g. > > SOAP, XML-RPC, REST), or interoperate with existing web services=20 > > protocols for security information (e.g. WS-Trust). The=20 > group must be=20 > > careful not to preclude interoperation at a later date. > >=20 > > Although the data that represents the identity information=20 > is expected=20 > > to be opaque it is worth mentioning that the data could be raw=20 > > attributes of the digital identity, or could be third party=20 > claims. A=20 > > third party claim is signed by an authoritative source so that the=20 > > relying party can be assured of its authenticity. The=20 > benefit of third=20 > > party claims, as supported by this protocol, is that the=20 > separation of=20 > > claim acquisition from claim presentation provides both scalability=20 > > and privacy benefits. > >=20 > > Out of Scope > >=20 > > How to federate identity namespaces. > > How to manage digital certificates or certification authorities. > > The mechanisms by which authentication and authorization are=20 > > performed. > >=20 > > Goals and Milestones: > >=20 > > March 2006 - BOF meeting > > June 2006 - First DIX Protocol Internet Draft June 2006 - First DIX=20 > > HTTP Transport Binding Internet Draft July 2006 - Working Group=20 > > meeting November 2006 - Working Group meeting December 2006=20 > - Request=20 > > Last Call for DIX Protocol December 2006 - Request Last=20 > Call for DIX=20 > > HTTP Transport Binding March 2007 - Working Group meeting=20 > April 2007 -=20 > > Submit DIX Protocol to IESG for consideration as Proposed Standard=20 > > April 2007 - Submit DIX HTTP Transport Binding to IESG for=20 > > consideration as Proposed Standard > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > dix mailing list > > dix@ietf.org > > https://www1.ietf.org/mailman/listinfo/dix > >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 13:51:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZRZ-0003h7-Kj; Mon, 16 Jan 2006 13:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZRX-0003gX-Vb for dix@megatron.ietf.org; Mon, 16 Jan 2006 13:51:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06107 for ; Mon, 16 Jan 2006 13:49:38 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyZZU-0005hG-5i for dix@ietf.org; Mon, 16 Jan 2006 13:59:18 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0GIot94031017; Mon, 16 Jan 2006 10:50:55 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 10:50:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] RE: attribute assertions Date: Mon, 16 Jan 2006 10:50:54 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A8D2@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] RE: attribute assertions Thread-Index: AcYaw85q4o09c+csS7+7gRDzh0YoCgACED1A From: "Hallam-Baker, Phillip" To: "Phil Hunt" X-OriginalArrivalTime: 16 Jan 2006 18:50:55.0413 (UTC) FILETIME=[C815D650:01C61ACD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org =20 > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, January 16, 2006 12:39 PM > To: Hallam-Baker, Phillip > Cc: Dick Hardt; dix@ietf.org; John Merrells > Subject: Re: [dix] RE: attribute assertions >=20 > I would tend to argue that whilst authentication is simply=20 > another assertion, authentication of the asserting party is=20 > actually the important part. SAML is basically saying, if=20 > you trust me, then trust that this is Joe. I agree with=20 > Dick, not all scenarios require SAML or a certificate, but I=20 > think the catch is that there must be =20 > some form of "authentication" or "validation" in the communication. =20 > E.g. When I look at a state driver's license, I judge whether=20 > or not it is real. This in itself is a form of=20 > authentication. Once I "trust" the driver's license, then I=20 > might trust the name asserted on the face of the card. >=20 > Phil Hunt > Oracle USA The origin of the SAML assertion structure is XTASS where I was trying to separate out the question of the assertion context from the semantics of the assertion statement(s). At the tim I found the traditional semantic web approach unconvincing, it was assumed that the biggest problem was deciding how to interpret information that was assumed trustworthy. I think this problem is actually solved through discourse, people attempt to express ideas in terms that lead to common intersubjective interpretation. The probvlem is really working out whether a datum is to be trusted. In conventional rhetoric propositions are argued axiomatically. In the real world the bulk of our reasoning is ad-hominem.=20 If we think about blogs, the biggest problem is not in interpreting the statement "Alice has a reputation score of five stars", its working out how to evaluate the party making the statement. The statement made by spamsalot.com has little weight... SAML allows but does not require consideration of this aspect of the problem _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 20:44:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyftK-00037l-PW; Mon, 16 Jan 2006 20:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyftJ-00037f-GP for dix@megatron.ietf.org; Mon, 16 Jan 2006 20:44:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02944 for ; Mon, 16 Jan 2006 20:42:44 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyg1L-0005EG-7d for dix@ietf.org; Mon, 16 Jan 2006 20:52:27 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0H1hvL4022084 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 16 Jan 2006 17:43:57 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A8CD@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A8CD@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <29E3954C-2436-41DF-A94F-54C34527BC6A@sxip.com> Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Mon, 16 Jan 2006 17:43:51 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells , "Tschofenig, Hannes" X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Phillip, that resonates in why I got involved in kicking off DIX. I agree that deployment is the more difficult problem. Partly because=20=20 it is NOT technical. For deployment to happen, not only does it need to be simple and=20=20 solve a real problem. There is the proverbial Chicken and Egg issue,=20=20 which in this case is user and site. No site wants to deploy until=20=20 there are users that have the functionality, and the users are not=20=20 motivated until there are sites that accept the functionality. Fortunately, IETF only has to solve the technical issues, albeit in a=20=20 manner that has low barriers to adoption. -- Dick On 16-Jan-06, at 10:37 AM, Hallam-Baker, Phillip wrote: > I think that the real problem is that we have all the components=20=20 > its just that they don't fit together. > > Its like the car that the guy made by taking one piece at a time=20=20 > home in his lunchbox. He ended up with a gearbox from one year, an=20=20 > engine from another, etc. etc. Nothing fit together. > > I think that most of the problems of the Internet protocols today=20=20 > are problems of integration rather than base technology. > > The part that is dealt with worst is the user experience. The bits=20=20 > on the screen are quite properly left to implementations, but there=20=20 > is still something missing. > > > I am not suggesting that we redo authentication or redo attributes.=20=20 > What we need is: > > 1) a model that shows how all the pieces can fit together in a=20=20 > consistent and coherent fashion. > > 2) A deployment strategy for getting the model into common use. > > (2) is much more important (and difficult) than (1). > > >> -----Original Message----- >> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On >> Behalf Of Tschofenig, Hannes >> Sent: Sunday, January 15, 2006 4:29 PM >> To: John Merrells; dix@ietf.org >> Subject: AW: [dix] Proposed Charter for DIX Working Group >> >> hi all, >> >> i am not quite sure what you are trying to accomplish. >> >> from the text i get the impression that you want to work on a >> new saml version. >> from the feedback provided by Phillip Hallam-Baker i >> understood that he suggests to work on authentication >> mechanis. i don't think that this is the right approach >> either. (saml comment: saml does not define any >> authentication mechanisms) there is already plenty of work on >> authentication approaches out there. >> >> ciao >> hannes >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] Im >> Auftrag von >>> John Merrells >>> Gesendet: Freitag, 13. Januar 2006 04:41 >>> An: dix@ietf.org >>> Betreff: [dix] Proposed Charter for DIX Working Group >>> >>> >>> Hello 'DIX mailing list member', >>> >>> The following document is a proposed charter for a DIX >> Working Group. >>> Feedback to me, or discussion on this list, is most welcome. >>> >>> This proposed charter will form part of a request to the >> application >>> area directors for a BOF at the next IETF meeting. At that meeting >>> this charter will be discussed, and if found to be acceptable, will >>> become the working group charter, should one be created. >>> >>> John >>> >>> ------------- >>> >>> Digital Identity Exchange - DIX >>> >>> Chairs >>> >>> TBD >>> >>> Applciations Area Director(s): >>> >>> Ted Hardie >>> Scott Hollenbeck >>> >>> Mailing Lists: >>> >>> General Discussion: dix@ietf.org >>> To Subscribe: dix-request@ietf.org >>> 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 >>> dix@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dix >>> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> >> > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 21:05:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygE3-0008Sp-1c; Mon, 16 Jan 2006 21:05:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygE1-0008SW-IP for dix@megatron.ietf.org; Mon, 16 Jan 2006 21:05:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04173 for ; Mon, 16 Jan 2006 21:04:08 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EygM2-0005qW-Qb for dix@ietf.org; Mon, 16 Jan 2006 21:13:52 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0H25MW6024339; Mon, 16 Jan 2006 18:05:22 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 18:05:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Proposed Charter for DIX Working Group Date: Mon, 16 Jan 2006 18:05:21 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A912@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Proposed Charter for DIX Working Group Thread-Index: AcYbB5UlUPKhD1o2R5meNR61V8dXTwAAOc+g From: "Hallam-Baker, Phillip" To: "Dick Hardt" X-OriginalArrivalTime: 17 Jan 2006 02:05:22.0137 (UTC) FILETIME=[79104490:01C61B0A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells , "Tschofenig, Hannes" X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org =20 > From: Dick Hardt [mailto:dick@sxip.com]=20 > Phillip, that resonates in why I got involved in kicking off DIX. >=20 > I agree that deployment is the more difficult problem. Partly=20 > because it is NOT technical. The internet has a billion users, that's a lot of mass, think of changing it as the problem of turning an oil supertanker. We have in the past made the mistake of assuming that such changes can be led by a single major vendor, since then we have discovered that it is hard for even consortiums of vendors to act. > For deployment to happen, not only does it need to be simple=20 > and solve a real problem. There is the proverbial Chicken and=20 > Egg issue, which in this case is user and site. No site wants=20 > to deploy until there are users that have the functionality,=20 > and the users are not motivated until there are sites that=20 > accept the functionality. >=20 > Fortunately, IETF only has to solve the technical issues,=20 > albeit in a manner that has low barriers to adoption. Don't go the the IETF to solve a technical problem. It is always much easier to solve a technical problem is a room with ten good people and a whiteboard than on the Internet with everyone with an opinion and a keyboard chiming in. The point of IETF process is to establish the critical mass and the broad consensus required to make a deployment successful. It is a process of achieving buy-in. The first third of my book on Internet crime is all about the problem of how to effect change and how to deploy. Its all about design for deployment. What I think we need to identify first is a killer application. We need to identify a pain point that affects a tightly defined, highly motivated community that is likely to deploy new infrastructure quickly. Then we have to design the solution so that the infrastructure built out by our early adopter community can evolve organically into the broader solution. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 21:14:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygMV-0002ed-Kg; Mon, 16 Jan 2006 21:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygMV-0002eY-1s for dix@megatron.ietf.org; Mon, 16 Jan 2006 21:14:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04687 for ; Mon, 16 Jan 2006 21:12:53 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EygUX-0006Qn-Ap for dix@ietf.org; Mon, 16 Jan 2006 21:22:37 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0H2EEkX022862 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 16 Jan 2006 18:14:14 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A912@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A912@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Proposed Charter for DIX Working Group Date: Mon, 16 Jan 2006 18:14:09 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells , "Tschofenig, Hannes" X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 16-Jan-06, at 6:05 PM, Hallam-Baker, Phillip wrote: > >> From: Dick Hardt [mailto:dick@sxip.com] > > > Don't go the the IETF to solve a technical problem. It is always much > easier to solve a technical problem is a room with ten good people > and a > whiteboard than on the Internet with everyone with an opinion and a > keyboard chiming in. Agreed. I've been involved in lots of open source projects. Fortunately there, code talks. > > The point of IETF process is to establish the critical mass and the > broad consensus required to make a deployment successful. It is a > process of achieving buy-in. Lots of people have pain in this area. I have been talking to them. The lack of consensus on which direction to take, and lack of a simple, complete solution to their pain is holding them back. I see the IETF process as a way of building consensus on the technical solution. > The first third of my book on Internet crime is all about the > problem of > how to effect change and how to deploy. Its all about design for > deployment. Agreed. As I said, low barrier to adoption. > What I think we need to identify first is a killer application. We > need > to identify a pain point that affects a tightly defined, highly > motivated community that is likely to deploy new infrastructure > quickly. We think that blog spam is a good pain. Blogosphere is innovating rapidly. False positives are not life threatening. > Then we have to design the solution so that the infrastructure > built out > by our early adopter community can evolve organically into the broader > solution. All in favor of a layered approach. Easy to deploy is key. Ability to extend is critical. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 21:28:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygaG-0006IP-FK; Mon, 16 Jan 2006 21:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EygaD-0006Hx-Bf for dix@megatron.ietf.org; Mon, 16 Jan 2006 21:28:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05726 for ; Mon, 16 Jan 2006 21:27:03 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EygiF-0006u0-NC for dix@ietf.org; Mon, 16 Jan 2006 21:36:48 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0H2SKm6023468 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 16 Jan 2006 18:28:21 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A86A@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A86A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73790DB0-8BC5-4A6D-BF63-C22A03BF7F78@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Mon, 16 Jan 2006 18:28:15 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells Subject: [dix] Re: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 13-Jan-06, at 7:50 PM, Hallam-Baker, Phillip wrote: > >> From: Dick Hardt [mailto:dick@sxip.com] > >>> I think that the complexity is in the problem rather than the >>> solution. >> >> For problems as framed by SAML, likely. Is it not possible >> that not all problems that need a claim by a 3rd party have >> the same complexity? > > I don't think it is possibel to answer your objection here without an > indication of where you see the complexity in SAML. > > The basic assertion framework is pretty compact, the schema is only a > couple of pages long. The conditions and advice components are > entirely > optional. First of all, I'd like to clarify that I think SAML is a great solution for a number of existing problems. If a site wants my email address, my blog URL, a link to my buddy icon etc. SAML is more horse power than I need to automate the exchange of that identity data. The use of SAML requires an XML parser. Name / value pairs are all that are required to move this simple data. If a site just wants to know I am the same entity that has visited in the past, then SAML is "heavy" as well. >> Yes, if you are infringing. No if you are not. I know that is >> stating the obvious. :-) > > I was never convinced that we were infringing. However RSA was > asked if > they had any IPR that MIGHT infringe on the standard and they replied > yes, then followed up with a royalty free license under standard > reciprocal terms in full compliance with both the W3C and OASIS IPR > policies. > > Given the subject matter of DIX I do not think it very likely that the > RSA engineers are not going to attend the Working Group if formed. The > IETF 'note well' rules then require them to make the same disclosure > they made in SAML. I hope the RSA people do join. Lots of smart people there. > > >> The last time I looked at the RSA license, you could not build a >> toolkit without them having to get a license from RSA. This makes it >> difficult to release open source modules. I see this is a huge >> barrier to adoption in the more innovative, less commercial markets. > > I do not see the difference in the situation here. The RSA patents > have > broad claims. If there is an arguable case that they cover SAML > there is > an arguable case that they cover DIX as well. Patent law does not > require a patent holder to assert their claims in order to preserve > them. Which makes you wonder why RSA makes you sign the license. The issue is the barrier created by having to execute their license. > Given where the interminable wrangling over IPR got us in MARID I > strongly suggest that the DIX WG adopt the W3C IPR licensing terms > as a > requirement. These have already been agreed to by Apache and the major > Open Source groups and by all the major vendors who hold IPR and are > likely to issue royalty free licenses. I like the Apache IPR terms myself. > > >> But the format of the assertion we are thinking out of scope >> for DIX. The focus is how to move the identity data around. > > I think I need to see some bits on the wire before I can understand > the > distinction you are attempting to draw here. hopefully that will add clarity! > > As I see it there are two parts to an identity protocol: > > * There is an authentication process which allows the identity > holder to > claim their identity by authenticating themselves against an uniformly > resolved identifier. > > * There is an attribute retrieval protocol that allows the relying > party > to obtain assertions binding particular attributes to the > authenticated > identifier. The source of these assertions may or may not be the > same as > the source of the authentication decision. The atteribute > assertions may > or may not be trustworthy and may or may not be trusted. > > If the first part AND the second part are both out of scope, what is > left? I think there is more to identity exchange then those two points. I break it down as such: 1) Discovery: negotiation between the parties on how to communicate and capabilities 2) Authentication: the user proving who they as you discuss above 3) Attribute exchange: retrieving one or more attributes. In essence a query. I think there should also be a way to store attributes. 4) Attribute schema: the method of describing the attribute(s) to be exchanged 5) Verification: the process of checking if one or more attributes are "trustworthy" I think there is lots of stuff that solves (2). I think there are some standards for the others, but it is not all well glued together as you mention. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 22:01:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyh5i-0007cd-At; Mon, 16 Jan 2006 22:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyh5g-0007cV-PT for dix@megatron.ietf.org; Mon, 16 Jan 2006 22:01:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08198 for ; Mon, 16 Jan 2006 21:59:35 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyhDj-0008C4-IJ for dix@ietf.org; Mon, 16 Jan 2006 22:09:19 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0H30s3I031930; Mon, 16 Jan 2006 19:00:54 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 19:00:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2006 19:00:53 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A91A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: attribute assertions Thread-Index: AcYbDbmItjPkyNaLQjKZ/F7f9iaBoAAAN+zg From: "Hallam-Baker, Phillip" To: "Dick Hardt" X-OriginalArrivalTime: 17 Jan 2006 03:00:54.0786 (UTC) FILETIME=[3B7A2620:01C61B12] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells Subject: [dix] RE: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > If a site wants my email address, my blog URL, a link to my=20 > buddy icon etc. SAML is more horse power than I need to=20 > automate the exchange of that identity data. The use of SAML=20 > requires an XML parser. Name / value pairs are all that are=20 > required to move this simple data. OK we can simplify things massively for a very small subset - where the data being asserted does not have to be trustworthy. Sounds to me like you are talking about a vcard type format.=20 > Which makes you wonder why RSA makes you sign the license.=20 > The issue is the barrier created by having to execute their license. Probably because like me they are facing giving three to five depositions in various patent infringement lawsuits this year, many of which probably don't even involve RSA as a plaintiff or defendant. The really iniquitous part of the patent process is the way that we all get forced to participate simply to protect ourselves. During the design of XKMS I had several design ideas vetoed on the grounds they were too clever, someone might have patented them. I am currently dealling with the legacy of something like 100 patents that make claims that relate to my work, none of which are mine. > I like the Apache IPR terms myself. The Apache license is a copyright license, not a patent license, there are different issues. What the IPR holders are trying to do here is to establish a GNU like poison pill that requires other vendors who might make IPR claims to offer equivalent royalty free terms.=20 The Apache group participated in the W3C process that led to the development of their IPR terms.=20 > I think there is more to identity exchange then those two=20 > points. I break it down as such: >=20 > 1) Discovery: negotiation between the parties on how to=20 > communicate and capabilities >=20 > 2) Authentication: the user proving who they as you discuss above >=20 > 3) Attribute exchange: retrieving one or more attributes. In=20 > essence a query. I think there should also be a way to store=20 > attributes. >=20 > 4) Attribute schema: the method of describing the=20 > attribute(s) to be exchanged >=20 > 5) Verification: the process of checking if one or more=20 > attributes are "trustworthy" >=20 > I think there is lots of stuff that solves (2). I think there=20 > are some standards for the others, but it is not all well=20 > glued together as you mention. That makes things a lot clearer. If we can solve 1 & 2 we have an 80% solution for the blog single sign on problem. We can take it to a 90% solution by adding limited support for attributes. We can expect organic growth to take it the rest of the way using SAML and third party issued assertions.=20 I would strongly suggest people look at the power of DNS SRV records wrt discovery (point 1). As far as negotiation is concerned I tend to favor single round 'best offer schemes' over attempts at multi-step convergence such as was attempted in PEP etc.=20 As far as authentication goes I think we need to have _a_ secure way to support 1) passwords (including one time passwords), 2) public key (including smartcard) and some form of extension mechanism to allow people to plug in biometric. I would prefer to co-opt existing schemes rather than co-opt a meta-negotiation scheme. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 16 22:29:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyhXJ-0007RN-Qe; Mon, 16 Jan 2006 22:29:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyhXA-0007OH-FT for dix@megatron.ietf.org; Mon, 16 Jan 2006 22:29:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09775 for ; Mon, 16 Jan 2006 22:28:00 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyhfB-0000pS-8C for dix@ietf.org; Mon, 16 Jan 2006 22:37:43 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0H3TDT1024771 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 16 Jan 2006 19:29:14 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A91A@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A91A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10225249-5156-452C-BC77-4E660C748495@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Mon, 16 Jan 2006 19:29:08 -0800 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, John Merrells Subject: [dix] Re: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 16-Jan-06, at 7:00 PM, Hallam-Baker, Phillip wrote: >> If a site wants my email address, my blog URL, a link to my >> buddy icon etc. SAML is more horse power than I need to >> automate the exchange of that identity data. The use of SAML >> requires an XML parser. Name / value pairs are all that are >> required to move this simple data. > > OK we can simplify things massively for a very small subset - where > the > data being asserted does not have to be trustworthy. I would argue that it is likely a much larger subset then you suspect for online transactions. > >> I like the Apache IPR terms myself. > > The Apache license is a copyright license, not a patent license, there > are different issues. What the IPR holders are trying to do here is to > establish a GNU like poison pill that requires other vendors who might > make IPR claims to offer equivalent royalty free terms. > > The Apache group participated in the W3C process that led to the > development of their IPR terms. I was referring to the patent licenses in the copyright licenses. > >> I think there is more to identity exchange then those two >> points. I break it down as such: >> >> 1) Discovery: negotiation between the parties on how to >> communicate and capabilities >> >> 2) Authentication: the user proving who they as you discuss above >> >> 3) Attribute exchange: retrieving one or more attributes. In >> essence a query. I think there should also be a way to store >> attributes. >> >> 4) Attribute schema: the method of describing the >> attribute(s) to be exchanged >> >> 5) Verification: the process of checking if one or more >> attributes are "trustworthy" >> >> I think there is lots of stuff that solves (2). I think there >> are some standards for the others, but it is not all well >> glued together as you mention. > > That makes things a lot clearer. > > If we can solve 1 & 2 we have an 80% solution for the blog single sign > on problem. We can take it to a 90% solution by adding limited support > for attributes. We can expect organic growth to take it the rest of > the > way using SAML and third party issued assertions. > > I would strongly suggest people look at the power of DNS SRV > records wrt > discovery (point 1). I like DNS SRV. There are simpler discovery processes though that put control where people feel they have control. > > As far as negotiation is concerned I tend to favor single round 'best > offer schemes' over attempts at multi-step convergence such as was > attempted in PEP etc. agreed > > As far as authentication goes I think we need to have _a_ secure > way to > support 1) passwords (including one time passwords), 2) public key > (including smartcard) and some form of extension mechanism to allow > people to plug in biometric. I would prefer to co-opt existing schemes > rather than co-opt a meta-negotiation scheme. I still don't think that we need to worry about that. I see Authentication as a conversation between the user and their agent. The agent may be a website or their own machine or their phone. This likely will be clearer to you when you see bits. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 05:54:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyoU0-0006Dm-17; Tue, 17 Jan 2006 05:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyoTy-0006Ca-R7 for dix@megatron.ietf.org; Tue, 17 Jan 2006 05:54:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04700 for ; Tue, 17 Jan 2006 05:53:10 -0500 (EST) Message-Id: <200601171053.FAA04700@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyoc5-0000wa-IR for dix@ietf.org; Tue, 17 Jan 2006 06:02:58 -0500 Received: from sureshmobile (c-71-197-228-188.hsd1.wa.comcast.net[71.197.228.188]) by comcast.net (rwcrmhc14) with SMTP id <200601171054240140021nt3e>; Tue, 17 Jan 2006 10:54:24 +0000 From: "Suresh Venkatraman" To: "'Dick Hardt'" , "'Hallam-Baker, Phillip'" Subject: RE: [dix] Re: attribute assertions Date: Tue, 17 Jan 2006 02:54:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <10225249-5156-452C-BC77-4E660C748495@sxip.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYbFsJRfL87sRx9RYK0VCocxwxYvAAOS9Tw X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: dix@ietf.org, 'John Merrells' X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >> I would strongly suggest people look at the power of DNS SRV >> records wrt >> discovery (point 1). > I like DNS SRV. There are simpler discovery processes though that put > control where people feel they have control. I think this should be a given, but is then a new protocol in order to describe such a service in a DNS SRV record? _Service._Proto.Name TTL Class SRV Priority Weight Port Target >> As far as authentication goes I think we need to have _a_ secure >> way to >> support 1) passwords (including one time passwords), 2) public key >> (including smartcard) and some form of extension mechanism to allow >> people to plug in biometric. I would prefer to co-opt existing schemes >> rather than co-opt a meta-negotiation scheme. >> > I still don't think that we need to worry about that. I see > Authentication as a conversation between the user and their agent. > The agent may be a website or their own machine or their phone. This > likely will be clearer to you when you see bits. I'd prefer decoupling authentication/identity from its use by services which require authentication and maintain authorization info (HTTP or SIP). My assumption is that SSO will work across all services, not just for browser-based apps. The scenario I'm thinking of would be something like this: A UA asserts an identity to the phone system to log-in using some yet to be described identity exchange mechanism. Later, when you get a new phone system, you just plug it into the existing framework. The user logs on and continues without having to rebuild password information. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Monday, January 16, 2006 7:29 PM To: Hallam-Baker, Phillip Cc: dix@ietf.org; John Merrells Subject: [dix] Re: attribute assertions On 16-Jan-06, at 7:00 PM, Hallam-Baker, Phillip wrote: >> If a site wants my email address, my blog URL, a link to my >> buddy icon etc. SAML is more horse power than I need to >> automate the exchange of that identity data. The use of SAML >> requires an XML parser. Name / value pairs are all that are >> required to move this simple data. > > OK we can simplify things massively for a very small subset - where > the > data being asserted does not have to be trustworthy. I would argue that it is likely a much larger subset then you suspect for online transactions. > >> I like the Apache IPR terms myself. > > The Apache license is a copyright license, not a patent license, there > are different issues. What the IPR holders are trying to do here is to > establish a GNU like poison pill that requires other vendors who might > make IPR claims to offer equivalent royalty free terms. > > The Apache group participated in the W3C process that led to the > development of their IPR terms. I was referring to the patent licenses in the copyright licenses. > >> I think there is more to identity exchange then those two >> points. I break it down as such: >> >> 1) Discovery: negotiation between the parties on how to >> communicate and capabilities >> >> 2) Authentication: the user proving who they as you discuss above >> >> 3) Attribute exchange: retrieving one or more attributes. In >> essence a query. I think there should also be a way to store >> attributes. >> >> 4) Attribute schema: the method of describing the >> attribute(s) to be exchanged >> >> 5) Verification: the process of checking if one or more >> attributes are "trustworthy" >> >> I think there is lots of stuff that solves (2). I think there >> are some standards for the others, but it is not all well >> glued together as you mention. > > That makes things a lot clearer. > > If we can solve 1 & 2 we have an 80% solution for the blog single sign > on problem. We can take it to a 90% solution by adding limited support > for attributes. We can expect organic growth to take it the rest of > the > way using SAML and third party issued assertions. > > I would strongly suggest people look at the power of DNS SRV > records wrt > discovery (point 1). I like DNS SRV. There are simpler discovery processes though that put control where people feel they have control. > > As far as negotiation is concerned I tend to favor single round 'best > offer schemes' over attempts at multi-step convergence such as was > attempted in PEP etc. agreed > > As far as authentication goes I think we need to have _a_ secure > way to > support 1) passwords (including one time passwords), 2) public key > (including smartcard) and some form of extension mechanism to allow > people to plug in biometric. I would prefer to co-opt existing schemes > rather than co-opt a meta-negotiation scheme. I still don't think that we need to worry about that. I see Authentication as a conversation between the user and their agent. The agent may be a website or their own machine or their phone. This likely will be clearer to you when you see bits. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 06:21:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyotb-0006z7-GD; Tue, 17 Jan 2006 06:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyotZ-0006sq-Ig for dix@megatron.ietf.org; Tue, 17 Jan 2006 06:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07101 for ; Tue, 17 Jan 2006 06:19:36 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eyp1f-0002DW-HS for dix@ietf.org; Tue, 17 Jan 2006 06:29:24 -0500 Received: (qmail invoked by alias); 17 Jan 2006 11:20:46 -0000 Received: from xdsl-87-78-71-21.netcologne.de (EHLO [192.168.1.67]) [87.78.71.21] by mail.gmx.net (mp032) with SMTP; 17 Jan 2006 12:20:46 +0100 X-Authenticated: #29516787 Message-ID: <43CCD30C.8060407@gmx.net> Date: Tue, 17 Jan 2006 12:20:44 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [dix] A draft is needed X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org hi all, i went through the previous discussions on the mailing list and i have to conclude that i am not sure what you would like to accomplish. could you please write a draft to give us a better idea what you would like to do? be as specific as possible. for example, if you state that saml is too complex then you might want to justify where you see the complexity. ciao hannes _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 10:03:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EysMk-0007EN-Ic; Tue, 17 Jan 2006 10:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EysMc-0007Dc-P2 for dix@megatron.ietf.org; Tue, 17 Jan 2006 10:03:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21867 for ; Tue, 17 Jan 2006 10:01:48 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EysUj-0003cq-Vu for dix@ietf.org; Tue, 17 Jan 2006 10:11:39 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0HF3AeR006002; Tue, 17 Jan 2006 07:03:11 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 07:03:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2006 07:03:08 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A92F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: attribute assertions Thread-Index: AcYbFjo7Rdhv1BJpS+mZt38b2ul6NwAYG14w From: "Hallam-Baker, Phillip" To: "Dick Hardt" X-OriginalArrivalTime: 17 Jan 2006 15:03:10.0855 (UTC) FILETIME=[21C98170:01C61B77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org, John Merrells Subject: [dix] RE: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: Dick Hardt [mailto:dick@sxip.com]=20 > I like DNS SRV. There are simpler discovery processes though=20 > that put =20 > control where people feel they have control. I am utterly unconvinced by the URI based proposals. They are too cumbersome to be practical or usable for the ordinary user. Usability has to be the priority, not providing the illusion of control. The DNS is the discovery mechanism for the Internet. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 11:02:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytHp-0001CS-1X; Tue, 17 Jan 2006 11:02:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EytHm-0001Bb-UE for dix@megatron.ietf.org; Tue, 17 Jan 2006 11:02:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26653 for ; Tue, 17 Jan 2006 11:00:54 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EytPt-0005ah-DI for dix@ietf.org; Tue, 17 Jan 2006 11:10:45 -0500 Received: from morpheus.openfoundations.com ([65.96.246.196]) by comcast.net (sccrmhc13) with ESMTP id <2006011716020001300o88jee>; Tue, 17 Jan 2006 16:02:00 +0000 Received: from localhost (localhost [127.0.0.1]) by morpheus.openfoundations.com (Postfix) with ESMTP id 7F4A8194F6; Tue, 17 Jan 2006 12:11:35 -0500 (EST) Received: from morpheus.openfoundations.com ([127.0.0.1]) by localhost (morpheus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17901-03; Tue, 17 Jan 2006 12:10:59 -0500 (EST) Received: from [127.0.0.1] (morpheus [192.168.0.101]) by morpheus.openfoundations.com (Postfix) with ESMTP id 03103194F5; Tue, 17 Jan 2006 12:10:58 -0500 (EST) Message-ID: <43CD14CA.5080601@openfoundations.com> Date: Tue, 17 Jan 2006 11:01:14 -0500 From: Peter Buonora User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [dix] A draft is needed References: <43CCD30C.8060407@gmx.net> In-Reply-To: <43CCD30C.8060407@gmx.net> X-Virus-Scanned: amavisd-new at openfoundations.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2077632043==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2077632043== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070201000901090309080200" This is a cryptographically signed message in MIME format. --------------ms070201000901090309080200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I agree. It is great that people are sharing all of their ideas, but it seems there is not enough focus on the specifics. So far the discussion has spanned such a wide range of issues from probability based security and rewriting SAML to authentication and attribute models. What exactly is the group honing in on and can everyone agree on it? It would also help to have a visual mapping that shows what piece of the identity puzzle DIX will standardize and how it will fit into the modern identity system. Thanks, Peter Hannes Tschofenig wrote: > hi all, > > i went through the previous discussions on the mailing list and > i have to conclude that i am not sure what you would like to accomplish. > > could you please write a draft to give us a better idea what you would > like to do? be as specific as possible. for example, if you state that > saml is too complex then you might want to justify where you see the > complexity. > > ciao > hannes > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix --------------ms070201000901090309080200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFTCC AuUwggJOoAMCAQICAw+mUTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEzMTIzNzA2WhcNMDYxMDEzMTIzNzA2 WjBOMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSswKQYJKoZIhvcNAQkBFhxw YnVvbm9yYUBvcGVuZm91bmRhdGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAsRfCWMYSST8eBTQhkFBU0KaHHVh/769BR/k4EQS7nwg3cxC0B29ML/VKNy9PvQty gD69vgHqzwVQbzz7ssHEEF1271vv6b/06dEArrMpaxdLJA+UR+2FMWC8WXr0qVCnwA8BQ7Wm 85f7zKylQhWe6RFdVzkNSR35/07aNK87ibgBlnV4RwrQSzHWltgi+1ir4GmkBw+HbnbYWgXg M4/IyWlliQaGlOQW93yhDrYibIlO6a6bEvGKlym5mO4eCUBK4AlbUytWW0OtX31iZ/FamGGE VUktptQRmL2Apk/6YS7LRqAKwYjak0dGpxI5d083a04/h3kib46O8EBlocQ5twIDAQABozkw NzAnBgNVHREEIDAegRxwYnVvbm9yYUBvcGVuZm91bmRhdGlvbnMuY29tMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEEBQADgYEAnzy8VIE/Gc+2N0m//o5uqTttGTEgE+zuGMpkjwFLnmBh N+F9S6yZaj8APnQ/RIAhbtsG6kSaqN1CrSYNR3l2MyLTjDrk5AFN5ijAVvx94vsyrXGqHXQC T9UuKO8RxrrDXzucok+RiofnmGZH2s47qEyaTbvcWVubLnfACPSdQpIwggLlMIICTqADAgEC AgMPplEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBMB4XDTA1MTAxMzEyMzcwNloXDTA2MTAxMzEyMzcwNlowTjEfMB0GA1UE AxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjErMCkGCSqGSIb3DQEJARYccGJ1b25vcmFAb3Bl bmZvdW5kYXRpb25zLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALEXwljG Ekk/HgU0IZBQVNCmhx1Yf++vQUf5OBEEu58IN3MQtAdvTC/1SjcvT70LcoA+vb4B6s8FUG88 +7LBxBBddu9b7+m/9OnRAK6zKWsXSyQPlEfthTFgvFl69KlQp8APAUO1pvOX+8yspUIVnukR XVc5DUkd+f9O2jSvO4m4AZZ1eEcK0Esx1pbYIvtYq+BppAcPh2522FoF4DOPyMlpZYkGhpTk Fvd8oQ62ImyJTumumxLxipcpuZjuHglASuAJW1MrVltDrV99YmfxWphhhFVJLabUEZi9gKZP +mEuy0agCsGI2pNHRqcSOXdPN2tOP4d5Im+OjvBAZaHEObcCAwEAAaM5MDcwJwYDVR0RBCAw HoEccGJ1b25vcmFAb3BlbmZvdW5kYXRpb25zLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAJ88vFSBPxnPtjdJv/6Obqk7bRkxIBPs7hjKZI8BS55gYTfhfUusmWo/AD50 P0SAIW7bBupEmqjdQq0mDUd5djMi04w65OQBTeYowFb8feL7Mq1xqh10Ak/VLijvEca6w187 nKJPkYqH55hmR9rOO6hMmk273Flbmy53wAj0nUKSMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG 9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1os iRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XR xSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFs RnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ cml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+ whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfb J3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPplEwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDYwMTE3MTYwMTE0WjAjBgkqhkiG9w0BCQQxFgQU3TPqVnHJ5Xjt osrfwQEdGavaZjwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAE MWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+m UTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgMPplEwDQYJKoZIhvcNAQEBBQAEggEAgcdcG7vhmVQ55f5FPvJtQV5k am4pT4C5HrriamKOz08KLDUATBOFeESZdphryT5UDu6QMVA8ceSIiWGkYfEQvWRgMjL8/hQl KrTyVS5VxBYLyo1HVbOSHAy+J03IvIswGAM1AnDCufDWxZCJhrnSUTE8NmwBNU9nuAGCZh/e v8XnoM1rgKFIZsLJ8CRi0hqNkQZYwLGnKJn0i7a7JmIDMqY+ABmm6Aew4pmxCGq1wQYW6dSy TD+lUMxiCvRp9kKZZqdRfNFmXl6XLSrTPQN5MgB+tnXj/2cKYO0DCTOQnRVEFhROTGnx2TK0 PIQLlQn4nO9fdXIF6NKCNrIxIDs8WgAAAAAAAA== --------------ms070201000901090309080200-- --===============2077632043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============2077632043==-- From dix-bounces@ietf.org Tue Jan 17 11:45:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytxp-00049T-S1; Tue, 17 Jan 2006 11:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eytxo-00049O-4C for dix@megatron.ietf.org; Tue, 17 Jan 2006 11:45:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29542 for ; Tue, 17 Jan 2006 11:44:18 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyu5w-0006vU-IW for dix@ietf.org; Tue, 17 Jan 2006 11:54:09 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0HGjRXH018814; Tue, 17 Jan 2006 08:45:27 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 08:45:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] A draft is needed Date: Tue, 17 Jan 2006 08:45:26 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787A970@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] A draft is needed Thread-Index: AcYbf42qnPlNetNnQRWbHAncS2tXrAABPiPg From: "Hallam-Baker, Phillip" To: "Peter Buonora" , "Hannes Tschofenig" X-OriginalArrivalTime: 17 Jan 2006 16:45:27.0216 (UTC) FILETIME=[6B57E300:01C61B85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org =20 > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Hello, >=20 > I agree. It is great that people are sharing all of their=20 > ideas, but it seems there is not enough focus on the=20 > specifics. So far the discussion has spanned such a wide=20 > range of issues from probability based security and rewriting=20 > SAML to authentication and attribute models. What exactly is=20 > the group honing in on and can everyone agree on it? >=20 > It would also help to have a visual mapping that shows what=20 > piece of the identity puzzle DIX will standardize and how it=20 > will fit into the modern identity system. I think that we need to get a bit more convergence before asking everyone to put their proposals on the table. I would rather avoid putting a counter-proposal on the table if we can arrive at a consensus beforehand. I also need to complete a bit of due dilligence. Having had people in the past read my proposals and then go out and patent them as their own I am anxious to preclude that possibility this time. I am pretty sure that there is prior art but I need to be sure we have locked down all the essential steps so we can ensure that the system is in fact open and unencumbered. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 12:22:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuXW-0006do-Cc; Tue, 17 Jan 2006 12:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuXU-0006dY-Ae for dix@megatron.ietf.org; Tue, 17 Jan 2006 12:22:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02232 for ; Tue, 17 Jan 2006 12:21:11 -0500 (EST) Received: from exprod6og4.obsmtp.com ([64.18.1.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eyufc-00083v-GO for dix@ietf.org; Tue, 17 Jan 2006 12:31:02 -0500 Received: from source ([192.150.20.142]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 17 Jan 2006 09:22:25 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0HHMOFX026710 for ; Tue, 17 Jan 2006 09:22:25 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k0HHM3sS017810 for ; Tue, 17 Jan 2006 09:22:23 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 09:24:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2006 09:22:14 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> In-Reply-To: <200601171053.FAA04700@ietf.org> Thread-Topic: Request for replying to emails Thread-Index: AcYbFsJRfL87sRx9RYK0VCocxwxYvAAOS9TwAA4fPSA= From: "Duane Nickull" Cc: X-OriginalArrivalTime: 17 Jan 2006 17:24:08.0938 (UTC) FILETIME=[D3328CA0:01C61B8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [dix] Request for replying to emails X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org All: I get around 600 emails every 24 hours and find it difficult to wade through them. Before you hit "reply to all", please think about whether or not the individuals are also on the list. I am getting two copies of some emails. Thank you. Duane ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ *******************************=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 12:22:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuXW-0006eD-LI; Tue, 17 Jan 2006 12:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuXU-0006dZ-Am for dix@megatron.ietf.org; Tue, 17 Jan 2006 12:22:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02233 for ; Tue, 17 Jan 2006 12:21:11 -0500 (EST) Received: from exprod6og1.obsmtp.com ([64.18.1.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eyufc-00083w-H1 for dix@ietf.org; Tue, 17 Jan 2006 12:31:03 -0500 Received: from source ([192.150.11.134]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 17 Jan 2006 09:22:26 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0HHM4Yc010449 for ; Tue, 17 Jan 2006 09:22:04 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k0HHM3sU017810 for ; Tue, 17 Jan 2006 09:22:24 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 09:24:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: attribute assertions Date: Tue, 17 Jan 2006 09:24:09 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E4527FCA@namail3.corp.adobe.com> In-Reply-To: <200601171053.FAA04700@ietf.org> Thread-Topic: [dix] Re: attribute assertions Thread-Index: AcYbFsJRfL87sRx9RYK0VCocxwxYvAAOS9TwAA4RVAA= From: "Duane Nickull" Cc: X-OriginalArrivalTime: 17 Jan 2006 17:24:09.0157 (UTC) FILETIME=[D353F750:01C61B8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org "I'd prefer decoupling authentication/identity from its use by services which require authentication and maintain authorization info (HTTP or SIP). My assumption is that SSO will work across all services, not just for browser-based apps." I *very* highly concur. No one should introduce unnecessary dependencies. That would be (architecturally) bad IMO. Duane Nickull ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ *******************************=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 12:31:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyugU-00011k-3P; Tue, 17 Jan 2006 12:31:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyugS-00011f-Te for dix@megatron.ietf.org; Tue, 17 Jan 2006 12:31:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02918 for ; Tue, 17 Jan 2006 12:30:28 -0500 (EST) Received: from s3.cableone.net ([24.116.0.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyuoc-0008KW-8r for dix@ietf.org; Tue, 17 Jan 2006 12:40:19 -0500 Received: from [192.168.168.10] (unverified [24.119.163.152]) by S3.cableone.net (CableOne SMTP Service S3) with ESMTP id 43318152 for ; Tue, 17 Jan 2006 10:57:05 -0700 Message-ID: <43CD29EE.7040809@Royer.com> Date: Tue, 17 Jan 2006 10:31:26 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dix@ietf.org Subject: Re: [dix] Request for replying to emails References: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> In-Reply-To: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> Content-Type: multipart/mixed; boundary="------------080406080800050203080709" X-SpamDetect: **: 2.000000 Content: cid=309(2.0) =2.0 X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 0, First 28, in=101, out=89, spam=0 Known=true X-External-IP: 24.119.163.152 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dix@ietf.org List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --------------080406080800050203080709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Perhaps the list administrator can set the Reply-To to be set back to the list? I try to remember to do this manually when posting to lists. Duane Nickull wrote: > All: > > I get around 600 emails every 24 hours and find it difficult to wade > through them. Before you hit "reply to all", please think about whether > or not the individuals are also on the list. I am getting two copies of > some emails. > > Thank you. > > Duane > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080406080800050203080709 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------080406080800050203080709 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --------------080406080800050203080709-- From dix-bounces@ietf.org Tue Jan 17 12:59:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyv6z-0008KU-RH; Tue, 17 Jan 2006 12:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyv6y-0008KP-K4 for dix@megatron.ietf.org; Tue, 17 Jan 2006 12:59:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04940 for ; Tue, 17 Jan 2006 12:57:51 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvF8-0000m4-6N for dix@ietf.org; Tue, 17 Jan 2006 13:07:43 -0500 Received: from [192.168.1.110] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0HHx3cj046928 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 Jan 2006 09:59:04 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787A92F@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787A92F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7963F47B-6FCE-4D79-88BF-E8A349EDE836@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Tue, 17 Jan 2006 09:59:02 -0800 To: dix@ietf.org X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [dix] Re: attribute assertions X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 17-Jan-06, at 7:03 AM, Hallam-Baker, Phillip wrote: >> From: Dick Hardt [mailto:dick@sxip.com] > >> I like DNS SRV. There are simpler discovery processes though >> that put >> control where people feel they have control. > > I am utterly unconvinced by the URI based proposals. They are too > cumbersome to be practical or usable for the ordinary user. Given that we are still talking about the Charter, I am surprised at such an absolute stance. I would have thought you would be more open minded Phillip. Did you not have your morning coffee before making this post? :-) > > Usability has to be the priority, not providing the illusion of > control. Agreed > The DNS is the discovery mechanism for the Internet. What about HTTP Accept headers? That is discovery ... ... but we are way off of subject now, which is assertions ... -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 13:13:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvKG-00034P-Ng; Tue, 17 Jan 2006 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvKE-00032i-Un for dix@megatron.ietf.org; Tue, 17 Jan 2006 13:12:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05817 for ; Tue, 17 Jan 2006 13:11:33 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvSO-0001Ah-IT for dix@ietf.org; Tue, 17 Jan 2006 13:21:25 -0500 Received: from [66.80.0.9] (dhcp-9.danastreet.live555.com [66.80.0.9]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0HIC4xF047478 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 Jan 2006 10:12:49 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> References: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Request for replying to emails Date: Tue, 17 Jan 2006 10:12:48 -0800 To: dix@ietf.org X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 17-Jan-06, at 9:22 AM, Duane Nickull wrote: > I get around 600 emails every 24 hours and find it difficult to wade > through them. Before you hit "reply to all", please think about > whether > or not the individuals are also on the list. I am getting two > copies of > some emails. Reply-To was set to the individual poster... I've switched that so that Reply-To is now to the list. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 13:24:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvV5-0005VN-Cb; Tue, 17 Jan 2006 13:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvV2-0005VC-UR for dix@megatron.ietf.org; Tue, 17 Jan 2006 13:24:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06693 for ; Tue, 17 Jan 2006 13:22:43 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyvdC-0001Zd-Ov for dix@ietf.org; Tue, 17 Jan 2006 13:32:36 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id D9D1049BF80 for ; Tue, 17 Jan 2006 11:24:12 -0700 (MST) Message-ID: <43CD364C.9080106@jabber.org> Date: Tue, 17 Jan 2006 11:24:12 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Request for replying to emails References: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2073103743==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2073103743== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010902000109010808030007" This is a cryptographically signed message in MIME format. --------------ms010902000109010808030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > > On 17-Jan-06, at 9:22 AM, Duane Nickull wrote: > >> I get around 600 emails every 24 hours and find it difficult to wade >> through them. Before you hit "reply to all", please think about whether >> or not the individuals are also on the list. I am getting two copies of >> some emails. > > Reply-To was set to the individual poster... I've switched that so that > Reply-To is now to the list. Dear god please let us not start a thread on the evils of Reply-To Munging, shall we? (That said, my understanding is that IETF policy is to forbid Reply-To Munging for WG lists.) Peter --------------ms010902000109010808030007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTE3MTgyNDEyWjAjBgkqhkiG9w0BCQQxFgQU6fej1GgiEIV2vK0B PLKF5xTzdIgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAINPAhuZmifxDiI7/mBdXUpLBQVd7wwv dHDnHYlDg0Mb0UcYRimei/J+nfXOywsRsw4L2IERQpcrIhbqG4LriMvO2sqHlnLw2GKu7N10 5iHPapS7408iAYbe+UbI/m/mfiYePW7Jl33UKvo/SHdON65/5WPelnqUXfeSdoSaApWXyvBj gPsqv8f0G0zWsUcTpmEsGM6pXkB1l/3maERqlubmPJW81cXmMKjV4van5juDtmj91w2aMKXp mO87NBmF+efpamSAVyshMUYEt1MmCB3R1aGum5VKfGa306eCKIwb70slTMCPks+56DXFa9Qb WHBk8cVYESVXMdyqKPEJ024AAAAAAAA= --------------ms010902000109010808030007-- --===============2073103743== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============2073103743==-- From dix-bounces@ietf.org Tue Jan 17 13:28:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvZ1-0006IU-Er; Tue, 17 Jan 2006 13:28:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvYz-0006Gy-Mu for dix@megatron.ietf.org; Tue, 17 Jan 2006 13:28:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06920 for ; Tue, 17 Jan 2006 13:26:48 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyvh9-0001h9-HX for dix@ietf.org; Tue, 17 Jan 2006 13:36:40 -0500 Received: from [66.80.0.9] (dhcp-9.danastreet.live555.com [66.80.0.9]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0HIS3h0048146 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 Jan 2006 10:28:04 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43CD364C.9080106@jabber.org> References: <63C6921B571CC740BF472C356B1291E4527FC9@namail3.corp.adobe.com> <43CD364C.9080106@jabber.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Request for replying to emails Date: Tue, 17 Jan 2006 10:27:56 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 17-Jan-06, at 10:24 AM, Peter Saint-Andre wrote: > Dear god please let us not start a thread on the evils of Reply-To > Munging, shall we? > > (That said, my understanding is that IETF policy is to forbid Reply- > To Munging for WG lists.) Peter, Yeah, I'm starting to regret it already. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 13:44:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvoX-0001id-SY; Tue, 17 Jan 2006 13:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyvoX-0001iX-4a for dix@megatron.ietf.org; Tue, 17 Jan 2006 13:44:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07966 for ; Tue, 17 Jan 2006 13:42:51 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyvwg-0002BV-Nd for dix@ietf.org; Tue, 17 Jan 2006 13:52:44 -0500 Received: from [66.80.0.9] (dhcp-9.danastreet.live555.com [66.80.0.9]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0HIi6o7048851 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 Jan 2006 10:44:07 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43CCD30C.8060407@gmx.net> References: <43CCD30C.8060407@gmx.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C2D4977-A458-47C6-83E0-79C85CE072C7@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] A draft is needed Date: Tue, 17 Jan 2006 10:43:57 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 17-Jan-06, at 3:20 AM, Hannes Tschofenig wrote: > could you please write a draft to give us a better idea what you > would like to do? I'm currently working on an individual submission internet-draft that documents how we at Sxip Identity have implemented a 'digital identity exchange' protocol'. Note that this is an 'individual' document, rather than a 'working group' document. We are publishing this to inform the discussion on the mailing list, and as input to a BOF (should one be arranged for the next IETF meeting). John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 17:07:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyyzV-0007zh-KU; Tue, 17 Jan 2006 17:07:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyyxW-0007Hv-4T for dix@megatron.ietf.org; Tue, 17 Jan 2006 17:05:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29059 for ; Tue, 17 Jan 2006 17:04:21 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyz5d-0002m7-Qg for dix@ietf.org; Tue, 17 Jan 2006 17:14:14 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0HM5Tb3057615 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 Jan 2006 14:05:30 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) To: Digital Identity Exchange Message-Id: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> Content-Type: multipart/mixed; boundary=Apple-Mail-13-314537480 From: John Merrells Date: Tue, 17 Jan 2006 14:05:27 -0800 X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.2 (/) X-Scan-Signature: a144737bbd61dd3158f2aaea1b7465c6 X-Mailman-Approved-At: Tue, 17 Jan 2006 17:07:48 -0500 Subject: [dix] draft-merrells-dix-01 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --Apple-Mail-13-314537480 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit DIX-ers, Here's an individual submission of a draft specification of a 'Digital Identity eXchange' protocol. This should further clarify the constrained scope we envisage for this group. As ever, your comments will be most gratefully received. Please take care though to be clear about what your comments apply to: the proposed charter (charter), this individual submission (draft- merrells), an alternative individual draft (draft-xxx), or to the ultimate output of a working group (um, draft-ietf?). John --Apple-Mail-13-314537480 Content-Type: text/plain; x-unix-mode=0755; name="draft-merrells-dix-01.txt" Content-Disposition: attachment; filename=draft-merrells-dix-01.txt Content-Transfer-Encoding: quoted-printable J. Merrells= =20 Internet Draft Sxip Identit= y=20 Expires: July 2006 January 17, 200= 6=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 DIX: Digital Identity Exchange Protocol=20 draft-merrells-dix-01.txt=20 Status of this Memo=20 By submitting this Internet-Draft, each author represents that=20= =20=20=20=20=20=20 any applicable patent or other IPR claims of which he or she is=20= =20=20=20=20=20=20 aware have been or will be disclosed, and any of which he or she=20= =20=20=20=20=20=20 becomes aware will be disclosed, in accordance with Section 6 of=20= =20=20=20=20=20=20 BCP 79.=20 Internet-Drafts are working documents of the Internet Engineering= =20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six mont= hs=20 and may be updated, replaced, or obsoleted by other documents at an= y=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 This Internet-Draft will expire on July 17, 2006.=20 Copyright Notice=20 Copyright (C) The Internet Society (2006). All Rights Reserved.=20 Abstract=20 DIX is an Internet scale protocol for exchanging identity informati= on=20 between endpoints. The protocol architecture maintains a separation= =20 of control between all parties of the exchange and supports both=20 compartmentalized and anonymous identities.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 1= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 Conventions used in this document=20 In examples, "C:" and "S:" indicate lines sent by the client and=20 server respectively.=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",= =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thi= s=20 document are to be interpreted as described in RFC-2119 [RFC2119].= =20 Table of Contents=20 =20=20=20=20=20=20 1. Introduction...................................................3= =20 2. Definitions....................................................3= =20 2.1. User......................................................3= =20 2.2. Identity Data.............................................3= =20 2.3. Persona...................................................3= =20 2.4. Homesite..................................................3= =20 2.5. Membersite................................................4= =20 2.6. Dumb Client...............................................4= =20 3. Overview.......................................................4= =20 3.1. Transport Bindings........................................4= =20 3.2. Names and Types...........................................4= =20 3.2.1. URLs and URIs........................................5= =20 3.2.2. Site Paths...........................................5= =20 3.2.3. Site Endpoint URL....................................5= =20 3.2.4. Persona URL..........................................6= =20 3.2.5. Site Document........................................6= =20 3.2.6. DIX URI Namespace....................................6= =20 4. Information Model..............................................7= =20 4.1. Definitions...............................................7= =20 4.2. Properties................................................7= =20 5. Capabilities...................................................8= =20 5.1. Capability Definition.....................................8= =20 5.2. Capability Families.......................................8= =20 5.3. Capability URI............................................8= =20 5.4. Service Capability........................................9= =20 5.5. Property Capability.......................................9= =20 5.6. Capability Discovery and Negotiation......................9= =20 5.7. Capability Resolution.....................................9= =20 5.8. Capability Revisions.....................................10= =20 5.9. Defined Capability Families..............................10= =20 5.9.1. DIX Capabilities....................................10= =20 5.10. Protocol................................................10= =20 5.10.1. Discovery Process..................................11= =20 5.10.2. Exchange Process...................................14= =20 5.10.3. Verification Process...............................24= =20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 2= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 6. Security Considerations.......................................27= =20 6.1.1. HTTP and HTTPS......................................27= =20 6.1.2. Man in the Middle:..................................27= =20 7. Acknowledgments...............................................28= =20 References.......................................................29= =20 7.1. Normative References.....................................29= =20 7.2. Informative References...................................29= =20 Author's Addresses...............................................29= =20 Intellectual Property Statement..................................29= =20 Disclaimer of Validity...........................................30= =20 Copyright Statement..............................................30= =20 Acknowledgment...................................................30= =20 =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20 1. Introduction=20 This document specifies a protocol for the exchange of identity=20 information.=20=20 2. Definitions=20 2.1. User=20 A person with a digital identity who participates in DIX based=20 identity information exchanges using their client software, typical= ly=20 a web browser.=20=20 2.2. Identity Data=20 A property of a digital identity in which the Property Name and=20 Property Value are represented as a name-value pair.=20 2.3. Persona=20 A user can have multiple personas as part of their identity. For=20 example, a user might have a work persona and a home persona. A=20 persona is a subset of the user's identity data.=20=20 2.4. Homesite=20 The User's agent (either a website or an application) responsible f= or=20 authenticating and identifying the user, providing a repository for= =20 their identity data, and releasing that data (with user consent) to= =20 other sites via the user's client.=20=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 3= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 2.5. Membersite=20 A site that requests identity data from a Homesite via the user's= =20 client.=20=20 2.6. Dumb Client=20 A regular web browser without any knowledge of the DIX protocol.=20 3. Overview=20 The core of the DIX protocol is a set of procedures for discovery o= f=20 a Homesite, exchange of identity information, and verification of= =20 that exchange. Without drilling into too many details, this is a=20 general description of the DIX protocol.=20 The User browses to a Membersite. The Membersite discovers the User= 's=20 Homesite and its capabilities. The Membersite then sends a request= =20 for identity information to the Homesite through the User's client.= =20 The Homesite processes the request, prompting the User for consent= =20 and returns a response, again through the User's client. The=20 Membersite then checks integrity of the response and verifies it wi= th=20 the Homesite.=20 3.1. Transport Bindings=20 The protocol messages could be moved over many alternative transpor= t=20 mechanisms. For example, HTTP, SMTP, or XMPP. Even within a single= =20 transport layer messages could be moved in alternative ways.=20=20 This document only details a binding for HTTP. The messages are mov= ed=20 via HTTP POST. [RFC2616]=20 For the simple usage profile discussed here we're interested in=20 moving messages over HTTP(S). In this document, wherever HTTP is=20 mentioned HTTPS can be used as an alternative to provide greater=20 confidentiality and integrity.=20=20 3.2. Names and Types=20 Some aspects of the protocol, the names and types of things, are=20 important enough that they need to be discussed ahead of the=20 protocol.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 4= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 3.2.1. URLs and URIs=20 Throughout this protocol specification there are many things of typ= e=20 URI. These must all be normalized to ensure they can be easily=20 compared. RFC 2396bis describes URI normalization. [RFC2396BIS]=20 3.2.2. Site Paths=20 A Membersite or Homesite is referred to via its Path, which is a=20 domain name and path. Since the Path is anchored within the domain= =20 name system we are assured that the name has the property of being= =20 unique.=20 3.2.2.1. Membersite Path=20 This is the unique identifier for the Membersite, and must contain = a=20 domain name. The Homesite uses this to provide a more seamless=20 experience to the user on subsequent visits to the Membersite, and = is=20 the ID used in Membersite identity verification.=20 For example: membersite.com/, or membersite.com/shopping/.=20 3.2.2.2. Homesite Path=20 A unique name for a Homesite that a user can remember so they can= =20 type it in. The Homesite Path is used to discover the Endpoint URL= =20 and Capabilities of a Homesite.=20=20 For convenience, when a user presents their Homesite Path, the=20 software should make every effort to transform the Homesite Path in= to=20 a canonical URL. Termed the Homesite URL. For example, the user=20 should be able to type in google.com, amazon.com, yahoo.com,=20 sxip.com, ford.com, or whatever and have the system discover the=20 rest.=20=20 For example: homesite.com/, or homesite.com/~dick/.=20 3.2.3. Site Endpoint URL=20 Membersites and Homesites provide endpoints for protocol messages t= o=20 be sent to. These are specified as URLs, and over HTTP the messages= =20 are received via HTTP POST=20 3.2.3.1. Membersite Endpoint URL=20 A Membersite may have multiple Endpoint URLs, as such the Membersit= e=20 Endpoint URL must not be used as a unique identifier for a=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 5= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 Membersite. The Membersite Endpoint URL must contain the Membersite= =20 Path.=20 3.2.3.2. Homesite Endpoint URL=20 As well as specifying an endpoint, this is used as a unique=20 identifier for the Homesite.=20=20 3.2.4. Persona URL=20 A Persona URL is the identifier for a persona. In the simple profil= e=20 the Persona URL is a URL that can be resolved to a web page owned b= y=20 the User. We term this the Persona URL.=20 3.2.5. Site Document=20 The Homesite URL and the Persona URL reference Documents that conta= in=20 marked up data for inspection by Membersites.=20 3.2.5.1. Persona Document=20 The Persona Document delegates authority for the Persona URL to a= =20 Homesite. [See Delegation Tag]=20 3.2.5.2. Homesite Document=20 The Homesite Document advertises the Endpoint URL and Capabilities = of=20 the Homesite. [See Homesite Tag]=20 3.2.6. DIX URI Namespace=20 To ensure protocol extensibility we reuse the same naming scheme=20 throughout the protocol for multiple purposes. All names are URIs.= =20=20 The generic URI syntax is as follows.=20 uri =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]=20 hier-part =3D "//" authority path-abempty=20=20 / path-absolute=20 / path-rootless=20 / path-empty=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 6= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 For a DIX URI, the protocol scheme used is 'dix'. (Note that this= =20 has not been registered with IANA, but we will resolve this during= =20 the IETF standardization process.)=20 dix-uri =3D "dix" ":" hier-part [ "?" query ] [ "#" fragment ]=20 Extensibility stems from the authority. Anyone with a registered=20 domain name can create DIX URI Names using their own domain name as= =20 the authority in the URI.=20 The DIX protocol uses DIX URI Names for:=20 o Capability Names=20 o Property References=20 o Message Parameters=20 o Constant Values=20 4. Information Model=20 4.1. Definitions=20 A homesite has a set of user accounts.=20 An account has a set of personas.=20 A persona has a set of properties.=20 A property has a property name and property value.=20 A property name is a path.=20 A property value is a UTF-8 string.=20 A path is of the form 1*( "/" 1*ALPHA ). For example:=20 '/sxip.net/contact/name/first'.=20 4.2. Properties=20 The property name is used for both referring to a property in a que= ry=20 expression [See Fetch Request Message], and for referring to the=20 associated type information. [See Fetch Request][See Capabilities]= =20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 7= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5. Capabilities=20 5.1. Capability Definition=20 A capability is a service or a property: a service offered by a sit= e=20 to other sites, or a property supported by a site. Sites advertise= =20 their capabilities to enable capability discovery and negotiation= =20 with other sites.=20=20 5.2. Capability Families=20 A capability family is a set of capabilities. The capability family= =20 mechanism is provided to reduce the number of capabilities that a= =20 site needs to advertise. Otherwise, over time, as the number of=20 capabilities supported increases, the number of capabilities=20 advertised could become unmanageable; the solution offered here is = to=20 roll a set of them into a family.=20 5.3. Capability URI=20 A capability is represented as a Capability URI, which is a DIX URI= =20 Name, with some restrictions.=20 capability_uri =3D "dix:/" [ "/" authority "/" ] capability "#"=20 revision=20 capability =3D 1*ALPHA=20 revision =3D 1*DIGIT=20 The Capability URI is restricted in that after the optional=20 authority, the path contains a single step, which is the capability= =20 name, and always includes a fragment, which is the capability=20 revision number.=20 The optional authority denotes whether the capability is a DIX, or= =20 Non-DIX capability. DIX capabilities have no domain name. For=20 example, 'dix:/core#1'. Non-DIX capabilities do have a domain name.= =20 For example, 'dix://sxip.net/simple#1'.=20 The revision number encoded as the URI fragment allows a recipient = to=20 determine if a particular revision of a capability is supported. [S= ee=20 Capability Revisions.]=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 8= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5.4. Service Capability=20 Service capabilities represent a service provided by the site.=20 Example: dix://crypto-doodes.com/dongle#5'. (This was invented for= =20 this example, but hopefully you get the idea.)=20 5.5. Property Capability=20 Property capabilities represent a property supported by a site.=20 Example: dix://sxip.net/namePerson/first=20 5.6. Capability Discovery and Negotiation=20 Homesites advertise their capabilities in the Homesite Tag of their= =20 Homesite Document. [See Homesite Document][See Homesite Tag].=20 Membersites read this document to discover the capabilities of the= =20 Homesite. A Membersite treats the Homesite capabilities as a hint o= f=20 the services offered and the properties supported.=20 Membersite may provide its capabilities to a Homesite within a=20 request message. The Homesite treats the Membersite capabilities as= a=20 hint.=20 5.7. Capability Resolution=20 A Capability URI can be converted into a resolvable URL. The docume= nt=20 fragment referenced describes the capability. There are two=20 anticipated use cases for resolving capabilities. Firstly, it is=20 expected that programming tools will resolve capabilities to aid=20 programmers in development of sites. Secondly, Homesites could use= =20 this mechanism for automatic update of capability revisions.=20 The Capability URI is converted to a URL by replacing the 'dix'=20 protocol scheme with the 'http' protocol scheme. The document=20 fragment retrieved contains a list of capabilities. For example, th= e=20 capability URI 'dix://sxip.net/simple#1' can be converted to the UR= L=20 'http://sxip.net/simple#1' and resolved.=20 In the case of a DIX capability, where there is no domain name=20 provided, the domain name used is a well-known, standards body name= .=20 Currently it is 'dixs.org'. So, for example, the DIX capability=20 'dix:/core#1', would become the resolvable URL,=20 'http://dixs.org/core#1'.=20 Note that 'dixs.org' is currently operated by Sxip Identity. Once D= IX=20 has progressed further within the IETF it is anticipated that this= =20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 9= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 resolution service will most likely be changed to some well-known= =20 community owned naming registry.=20 The URL references a document fragment. That schema of that fragmen= t=20 is not currently defined.=20 5.8. Capability Revisions=20 A capability revision is a positive integer value that always=20 increases when there is a revision of a capability; as such=20 capabilities are always backwardly compatible. This allows capabili= ty=20 definitions to be accretive so functionality can be extended withou= t=20 breaking existing functionality.=20 For example, the capability URL 'http://sxip.net/simple#34' would= =20 reference where revision '34' of the 'simple' capability is defined= .=20 From that point in the document onwards is what is included in=20 'dix://sxip.net/simple#34'.=20 Capability revisions are always added to the top of the capability= =20 definition file, so that everything from that fragment onwards is= =20 what defines that revision of the capability.=20=20 The revision fragment allows families of capabilities to be rapidly= =20 extended without breaking existing applications.=20 5.9. Defined Capability Families=20 The following DIX capability families are currently defined. A DIX= =20 capability family is represented by a DIX URI. Third-party=20 authorities are able to define their own capability families if the= y=20 wish.=20 5.9.1. DIX Capabilities=20 5.9.1.1. dix:/core#1=20 Core DIX protocol capabilities. The simple usage profile. Our=20 assumptions are: low security, low risk identity transaction, data = is=20 moving over HTTP(S), low risk from replay attack. Supports: Homesit= e,=20 Membersite, and Persona URL.=20 5.10. Protocol=20 In the simple usage profile the participants in the protocol are: t= he=20 User's Client, a Homesite, a Membersite, and the site that hosts th= e=20 Persona URL.=20=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 10= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 The protocol proceeds in three stages: Discovery, Exchange, and=20 Verification. We walk through each in turn.=20 5.10.1. Discovery Process=20 The goal of the discovery process is to determine the capabilities = of=20 the user's Homesite.=20=20 A dumb client can use a cookie.=20 5.10.1.1. Membersite Cookie (Dumb Client)=20 Once a user has visited a Membersite and identified the name of the= ir=20 Homesite that Membersite can cookie the user with their choice of= =20 Homesite, so that it can be filled in automatically for them in the= =20 future.=20 Also, the name of the text control used by the Membersite to collec= t=20 the user's Homesite Path should be the consistent and well-known na= me=20 'dix:/homesite'. The name of the text control is defined to ensure= =20 the benefit to the user of a browser's automated form filling=20 functionality.=20=20 5.10.1.2. User Prompt=20 The Membersite first attempts to determine the Homesite Path from a= =20 Membersite cookie. It then returns a web page to the user's client.= =20 The web page contains a form that includes a text control named=20 'dix:/homesite' for the Homesite Path and an adjacent 'login' butto= n.=20 If known the Homsite Path is provided as the value of the text=20 control. The form also includes the parameters for a fetch-request= =20 message. The parameters include the request message parameters and= =20 queries for any identity data the Membersite requires. [See Request= =20 Message for details.]=20 The attributes of the FORM tag are:=20 o CLASS attribute must contain 'DIX', which denotes to a smart=20 client that the form was generated by a DIX aware Membersite.=20 o ACTION attribute is the Membersite Endpoint URL.=20 o METHOD attribute is 'POST'.=20 The value of the FORM tag includes at least two INPUT tags, one a= =20 text control, the other a button control.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 11= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 The attributes of the text control INPUT tag are:=20 o TYPE attribute is 'TEXT'.=20 o NAME attribute is 'dix:/homesite'.=20 o VALUE attribute is the user's Homesite Path, if known by the=20 Membersite.=20 The attribute of the button control INPUT tag are:=20 o TYPE attribute is 'SUBMIT'.=20 o VALUE attribute is 'login'.=20 The attributes of the hidden INPUT tags for the message parameters= =20 are:=20 o TYPE attribute is 'HIDDEN'.=20 o NAME attribute is the message parameter name.=20 o VALUE attribute is the message parameter value.=20=20 Here's an example:=20 =20 =20 =20 =20 =20 Processing of the form by the client differs between smart and dumb= =20 clients.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 12= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5.10.1.3. Dumb Client Form Processing=20 When a dumb client receives a page containing this form the user is= =20 presented with a text control with an adjacent 'sxip in' button. If= =20 the user has previously visited the Membersite, and the Membersite= =20 has stored the user's Homesite Path in a cookie, then the Membersit= e=20 can suggest a value for the text control. Otherwise, the user will= =20 have to type in their Homesite Path, and potentially their browser= =20 will auto-complete it after a few key strokes.=20 When the user clicks on the 'sxip in' button the form is posted to= =20 the Membersite Endpoint URL. The Membersite should accept a shorten= ed=20 form of URL from the user and make every effort to transform it int= o=20 a canonical URL. The Membersite then performs the Homesite Inspecti= on=20 process.=20=20 5.10.1.4. Homesite Inspection=20 The Membersite must now determine the Endpoint URL and the=20 Capabilities of the User's Homesite. The Membersite uses the Homesi= te=20 Tag Inspection Algorithm to discover the Homesite Tag.=20 The Membersite uses the Homesite URL to fetch the Homesite Document= =20 to inspect it for the Homesite Tag to discover the Endpoint URL and= =20 Capabilities of the Homesite.=20 The Membersite constructs a URL, based on the Homesite URL, to the= =20 well-known file 'dix.html' in the site's root directory. If the fil= e=20 is not found then the Membersite resolves the URL of the site's roo= t=20 document, '/'. Note that the Membersite must follow any redirects. = If=20 found the document retrieved is examined for the Homesite Tag.=20 The Homesite Tag is used to specify the Endpoint URL and Capabiliti= es=20 of a Homesite. The HTML LINK tag is used for this. The LINK tag is= =20 appropriate because it is a document reference that is not to be=20 traversed by an end user. The requirements are:=20 o Use the LINK tag, which MUST occur in the HEAD section of the=20 returned document.=20=20=20=20 o The LINK REL attribute MUST have value 'dix:/homesite'.=20 o The LINK HREF attribute MUST have value of the Homesite's Endpoi= nt=20 URL.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 13= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 o The LINK CLASS attribute contains the capabilities of the=20 Homesite, space separated.=20 Here's an example=20 =20 The reason there are options for where the Homesite Tag is located = is=20 that the User may or may not have access rights to one of these=20 files.=20=20 5.10.1.5. Membersite's Discovery Algorithm=20 To discover the Homesite Endpoint URL and Capabilities the Membersi= te=20 follows the following procedure.=20 1. Prompt user to enter the Homesite Path.=20 2. Look in Homesite root for dix.html and extract Endpoint URL and= =20 capabilities.=20 3. If not found, then look in Homesite root page and extract Endpoi= nt=20 URL and capabilities.=20 Upon failure the Membersite should inform the user and jump to step= 1=20 to prompt the user.=20 If successful the Membersite has now determined the Endpoint URL an= d=20 capabilities of the user's Homesite.=20 The Membersite uses the Homesite capabilities to determine if the= =20 Homesite supports the requisite capabilities for the identity data= =20 exchange. For example, a financial Membersite might require that th= e=20 Homesite use a specific two-factor device to authenticate the User.= =20 In this case the Membersite would check that the Homesite=20 capabilities discovered included the capability named 'dix://crypto- doodes.com/dongle#5'. (Invented for this example.)=20 5.10.2. Exchange Process=20 The exchange process occurs once the MS has discovered the Endpoint= =20 URL and the capabilities of the Homesite. Messages are exchanged=20 between the Membersite and the Homesite via the User's client. This= =20 section describes the protocol flow that occurs and the messages th= at=20 are transferred between the participants.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 14= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5.10.2.1. Protocol Flow=20 To set the context for the following description, the user's client= =20 sends a HTTP GET to a Membersite, and the Membersite performs the= =20 Homesite discovery procedure.=20=20 The Membersite sends a fetch-request message to the Homesite throug= h=20 the User's client via a redirected HTTP POST to their Homesite=20 Endpoint URL using JavaScript to autosubmit the form.=20 The Homesite checks the integrity of the fetch-request message by= =20 checking that the Membersite Endpoint URL contains the Membersite= =20 Path.=20=20 The Homesite creates a fetch-response message. A Signature is=20 included that is generated from a Digest of the message.=20=20 Membersite receives the fetch-response message and verifies the=20 message.=20 5.10.2.2. Digest Generation=20 The digest function is used to generate a digest for a message. It= =20 takes as input a canonicalized representation of the message.=20=20= =20 Digest =3D D ( C ( M ) )=20=20 Where, M is the fetch-response message excluding th'dix:/signature'= =20 message parameter, C is the canonicalization function (defined=20 below), and D is the digest function.=20 Since the Homesite and Membersite must be able to generate=20 interchangeable digests they both must implement the same digest=20 function. We specify that both must implement the SHA-1 algorithm.= =20 [SHA]=20 5.10.2.3. Signature Generation=20 The signature function is used to generate a signature for a messag= e.=20 Since the signature generation function need only be known by the= =20 Homesite, and not the Membersite, the nature of this function is=20 implementation defined. It should however have the properties of=20 protecting the message from alteration.=20 A suggested implementation of a signature function would be to use= =20 the SHA1 algorithm, which takes as input a digest of the message an= d=20 a secret known only to the Homesite.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 15= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 Signature =3D T ( S + Digest )=20=20 Where, Digest is message digest (defined above), S is the Homesite= =20 Secret, T is the signature generation function, and '+' means strin= g=20 concatentation.=20 A suggested secret would be a random sequence of bytes. For the SHA= 1=20 algorithm an appropriate length would be 80 to 160 bits.=20 5.10.2.4. FORM Auto Submission=20 Form submission could be automated in the following way:=20 =20 =20
=20 =20 .=20 .=20 .=20 etc=20 =20=20=20=20=20=20=20=20=20 =20
=20 =20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 16= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 =20 =20 5.10.2.5. Messages=20 A message is a list of name-value pairs, which are represented here= =20 as '=3D'. A name or value could begin with a well-know= n=20 escape sequence that denotes that the thing is protocol oriented an= d=20 that extra processing is required. The escape sequence is the=20 character sequence 'dix:/'.=20 The escaped thing is extensible via a namespace mechanism. If the= =20 escape sequence is followed by another forward slash character, '/'= ,=20 then the following domain name denotes the namespace within which t= he=20 following name belongs. For example, a name in the 'sxip.net' domai= n=20 would begin with the sequence, 'dix://sxip.net', so the name 'foo'= =20 would be 'dix://sxip.net/foo'.=20 In a message there are three possible forms of a name-value pair:= =20 5.10.2.5.1. Message Parameter=20 Request: dix:/=3D=20 Response: dix:/=3D=20 Description: Protocol specific. Requires processing by the Membersi= te=20 or Homesite.=20 5.10.2.5.2. Data Request / Response=20 Request: =3Ddix:/=20 Response: =20 Description: Homesite processes query and returns resultant value= =20 5.10.2.5.3. Data=20 Request: =20 Response: =20 Description: D ata is passed through. This could be used for sessio= n=20 tracking.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 17= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5.10.2.5.4. Grammar=20 The above is rewritten as a formal grammar below:=20 Parameter =3D MessageParameter=20 / DataRequest=20=20 / Data=20 MessageParameter =3D Escape Name "=3D" Value=20 DataRequest =3D Name "=3D" Escape Query=20 Data =3D Name "=3D" Value=20 Escape =3D "dix:/"=20 Query =3D Path=20 Path =3D 1*( "/" Name )=20=20 Name =3D 1*ALPHA=20 Value =3D *CHAR=20=20 5.10.2.6. Messages over HTTP POST=20 Protocol messages are passed over HTTP as a HTML FORM that is POSTe= d=20 to the recipient's endpoint URL.=20 For example:=20 =20 =20 =20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 18= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 =20 =20 =20 5.10.2.7. Message Canonicalization=20 This algorithm performs message canonicalization before computation= =20 of a digest, by default with the SHA-1 algorithm.=20 For each name-value pair within the message, with the exception of= =20 the signature parameter, treat as a series of bytes, remove any=20 trailing linefeed or carriage return characters. Note that the '=3D= '=20 character between the name and value is retained. If message=20 parameter names or values are url-encoded, they must be decoded, mo= st=20 web frameworks do this automatically. Then sort the name value-pair= s=20 in byte value order and concatenate them for passing through the=20 digest function.=20 5.10.2.8. Fetch Request Message Parameters=20 A fetch request message is sent from the Membersite to the Homesite= ,=20 via the User's Client. Its purpose is to request that the Homesite= =20 authenticate the user and to return the property values of the=20 properties requested. Note that a fetch request need not actually= =20 request any attribute values, its purpose then is just to=20 authenticate the user.=20 dix:/message-type, required: 'dix:/fetch-request'=20 dix:/message-datetime, optional: A UTC datetime. The Homesite can u= se=20 this as a simple way to detect a message replay security attack. Th= e=20 Homesite would have a policy about how old a message is acceptable.= =20 For example, a couple of minutes. This assumes roughly synchronized= =20 clocks at the sites, which is a deployment issue.=20 dix:/message-id, optional: A nonce. [RFC2617]=20 Optional for support of static forms and dumb Membersites who can't= =20 generate a nonce.=20 An implementation of a Membersite could set to a high resolution=20 date/time stamp. Because the data is passing over HTTP any more=20 effort on replay attack prevention is useless.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 19= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 dix:/membersite-url, required: The Membersite Endpoint URL for the= =20 Homesite to POST the fetch-response message to. This URL must inclu= de=20 the Membersite Path, otherwise the message is invalid. Note that th= e=20 URL could include return data. The code at this URL is expected to= =20 perform the Verification Process.=20 dix:/membersite-path, required: The Membersite Path. The Membersite= =20 Endpoint URL must include the Membersite Path, otherwise the messag= e=20 is invalid.=20 dix:/membersite-name, recommended: The display name for the=20 Membersite.=20 dix:/signature, optional: The Membersite provides the Homesite with= a=20 signature, so that the Homesite can directly verify with the=20 Membersite that the request message did come from the Membersite.= =20 [See Verification Process for details.] The value of the name-value= =20 pair is encoded as lower-case hex without any leading characters,= =20 such as '0x'.=20 dix:/membersite-accept, recommended: The Membersite can optionally= =20 provide the capabilities that it supports. The Homesite can then=20 tailor its response to the appropriate capability revisions.=20 dix:/authentication-age, optional: An integer value, which is a=20 number of seconds. If the user has not authenticated with the=20 Homesite since (current time - seconds) then the Homesite must re- authenticate the user. A value of 0 is taken to mean that the=20 Homesite must always re-authenticate the user.=20 dix:/membersite-explanation, optional: A textual description of why= =20 the Membersite is making the request. Intended for display to the= =20 user by the Homesite.=20 dix:/membersite-cancel-url, optional: The value URL the Homesite=20 should return the user to should they cancel the operation.=20 dix:/required, optional: The Membersite can specify that a requeste= d=20 property is required. This means that the Homesite should inform th= e=20 user that the property is required. There is expected to be a=20 corresponding query for the property. For example:=20=20 dix:/required=3Dfname=20 fname=3D dix://sxip.net/contact/name/first=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 20= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 dix:/if-available, optional: The Membersite can specify that the=20 Homesite should only prompt the user for the property if the proper= ty=20 is available. For example:=20=20 dix:/if-available=3Dfname=20 fname=3D dix://sxip.net/contact/name/first=20 =3Ddix:/persona-url, optional: If present, the Membersite is= =20 requesting the Persona URL. This is the unique identifier for the= =20 user's selected persona. The Homesite must authenticate the user. T= he=20 Membersite need not ask for the Persona URL if it only requires som= e=20 identity data for filling in a form.=20 =3Ddix:/multiple-personal-url, optional: TBD=20 =3Ddix:/, optional: A request for a property= =20 value. The property is referenced by its property name and its valu= e=20 is returned assigned to the name provided in the request. For=20 example:=20 fname=3Ddix://sxip.net/contact/name/first=20 lname=3Ddix://sxip.net/contact/name/last=20 =3D, optional: Pass through data. For example,=20 session=3DF39E-4810-B3C8-B237=20 5.10.2.9. Fetch Response Message Parameters=20 Sent by the Homesite to the Membersite, via the User's Client, in= =20 response to a Fetch Request Message.=20 dix:/message-type, required: 'dix:/fetch-response'=20 dix:/message-datetime, required: A UTC datetime. The Membersite use= s=20 this as a simple way to detect a message replay security attack. Th= e=20 Membersite would have a policy about how old a message is acceptabl= e.=20 For example, a couple of minutes. This assumes roughly synchronized= =20 clocks at the sites, which is a deployment issue.=20 dix:/message-id, required: The message-id if provided in the reques= t.=20 dix:/signature, optional: The Homesite sends a signature to the=20 Membersite for use in verifying the response message.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 21= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 dix:/homesite-url, required: The Homesite Endpoint URL. This is the= =20 endpoint the Membersite can use for verifying the response message= =20 with the Homesite and also can be used by the Membersite as a uniqu= e=20 identifier for Homesite.=20 dix:/homesite-name, optional: A textual name for the Homesite.=20 Intended for display to the user.=20 dix:/status-success, required: Status code. 'dix:/true' is returned= =20 if the Homesite has successfully authenticated the user. 'dix:/fals= e'=20 if the user could not be authenticated. And, 'dix:/unknown' if an= =20 error of some kind occurred.=20 dix:/status-message, optional: Human readable status message.=20 =3D, if requested: The Persona URL. The response= =20 from the request parameter '=3Ddix:/persona-url'.=20 =3D, if requested: The value is a property value for a= =20 requested property.=20 5.10.2.10. Membersite's Fetch Exchange Algorithm=20 1. Create fetch request message.=20 2. Store message state. State management by the Membersite is=20 implementation dependent. If dix:/message-id is provided then th= e=20 Membersite should store the nonce to ensure that a message has n= ot=20 been replayed. For example, in a cookie, in a secure way.=20=20 3. Send fetch request message.=20 4. Receive fetch response message.=20 5. Verify fetch response message.=20 5.10.2.11. Homesite's Fetch Exchange Algorithm=20 1. Receive fetch request messsge.=20 2. Verify fetch request message.=20=20 3. User interaction.=20 4. Create fetch response message, creating the 'dix:/signature'=20 message parameter.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 22= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5. Send fetch response message.=20 5.10.2.12. Store Request Message Parameters=20 Sent from the Membersite to the Homesite, via the User's Client.=20 dix:/message-type, required: 'dix:/store-request'=20 dix:/message-datetime, optional: As fetch request message.=20 dix:/message-id, optional: As fetch request message.=20 dix:/membersite-url, required: As fetch request message.=20 dix:/membersite-path, required: As fetch request message.=20 dix:/membersite-name, recommended: As fetch request message.=20 1dix:/signature, required: As fetch request message.=20 dix:/membersite-accept, recommended: As fetch request message.=20 dix:/membersite-cancel-url, optional: As fetch request message.=20 dix:/persona-url=3Dvalue, optional: As the Membersite most likely k= nows=20 the Persona URL of the user the Membersite can optionally provide= =20 that to the Homesite so that the identity data can be stored with= =20 that Persona.=20 dix:/=3D, optional: The identity data to stor= e at=20 the Homesite.=20 =3D, optional: Pass through data. For example,=20 session=3DF39E-4810-B3C8-B237=20 5.10.2.13. Store Response Message Parameters=20 Sent by the Homesite to the Membersite, via the User's Client, in= =20 response to a Store Request Message.=20 dix:/message-type, required: 'dix:/store-response'=20 dix:/message-datetime, required: As fetch response message.=20 dix:/message-id, optional: As fetch response message.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 23= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 dix:/signature, optional: The Homesite optionally provides the=20 Membersite with a signature, so that the Membersite can directly=20 verify with the Homesite that the request message did come from the= =20 Homesite. [See Verification Process for details.]=20 dix:/homesite-url, required: As fetch response message.=20 dix:/homesite-name, optional: As fetch response message.=20 dix:/status-success, optional: As fetch response message.=20 dix:/status-message, optional: As fetch response message.=20 5.10.2.14. Membersite's Store Exchange Algorithm=20 1. Create store request message.=20 2. Store message state. State management by the Membersite is=20 implementation dependent. If dix:/message-id provided then the= =20 Membersite should store the nonce to ensure that a message has n= ot=20 been replayed. For example, in a cookie, in a secure way.=20=20 3. Send store request message.=20 4. Receive store response message.=20 5. Verify store response message.=20 5.10.2.15. Homesite's Store Exchange Algorithm=20 1. Receive store request messsge.=20 2. Verify store request message.=20=20 3. User interaction.=20 4. Create store response message, creating the 'dix:/signature'=20 message parameter.=20 5. Send store response message.=20 5.10.3. Verification Process=20 The verification process occurs after the Membersite receives a=20 response message. The purpose of the verification process is to=20 ensure that the response has not been tampered with and was indeed= =20 sent by the Homesite the response message claims it is from.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 24= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 5.10.3.1. Protocol Flow=20 Upon receiving the fetch-response message the Membersite checks the= =20 integrity of the message by checking the correctness of the nonce.= =20 If a Persona URL is returned then the Membersite then checks that t= he=20 Homesite URL is authoritative for the Persona URL. The Membersite= =20 achieves this by fetching the Persona Document and inspecting it fo= r=20 the Delegation Tag. The Delegation Tag provides a list of Homesites= =20 that are authoritative for that persona. The Homesite URL must be= =20 within that list for the Homesite to be authoritative over the=20 persona, otherwise the fetch-response message is invalid. [See=20 Delegation Tag section.]=20 To verify the integrity of the fetch-response message the Membersit= e=20 constructs a verify message that is sent to the Homesite. In the= =20 verify message is the Signature from the fetch-response message, an= d=20 a message Digest computed by the Membersite. [See Digest Generation= .]=20 [See Security Considerations for why this is done.]=20 Upon receipt of the verify-request message the Homesite performs a= =20 comparison between the Signature provided and the result of computi= ng=20 a signature. [See Signature Generation.] A response containing=20 'dix:/true' is returned if they match, and 'dix:/false' if not. [Se= e=20 Security Considerations for why this is done.]=20 5.10.3.2. Delegation Tag=20 The delegation tag is used to specify the set of Homesites that are= =20 authoritative for a persona. The HTML LINK tag is used for this. Th= e=20 LINK tag is appropriate because it is a document reference that is= =20 not to be traversed by an end user. There could be many of these= =20 delegation tags. The requirements are:=20 o Use the LINK tag, which MUST occur in the HEAD section of the=20 returned document.=20=20=20=20 o The LINK REL attribute MUST indicate that this is of type=20 "dix:/homesite-path".=20 o The LINK HREF attribute MUST contain the Homesite Path that is= =20 authoritative for the Persona.=20 Here's an example=20 =20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 25= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 = =20 5.10.3.3. Verify Request Message=20 Sent by a Membersite directly to a Homesite. The message parameters= =20 are:=20 dix:/message-type, required: 'dix:/verify-request'=20 dix:/signature, required: The response signature from the response= =20 message being verified.=20 dix:/digest, required: The digest of the response message being=20 verified. Created using the Digest Generation algorithm.=20 5.10.3.4. Verify Response Message=20 The body of the response is of content-type text/plain and contains= a=20 single DIX URI. The grammar for the body is.=20 verify_response =3D ( "dix:/true" / "dix:/false" / "dix:/unknown" )= =20 CRLF *CHAR=20 The meaning of the response is described in the following table. Th= e=20 response must be followed by a Newline character, and all subsequen= t=20 characters are to be ignored by the recipient. This could optionall= y=20 be human readable text to aide the user or developer.=20 The possible responses are:=20 dix:/true: Message passed verification check.=20 dix:/false: Message failed verification check.=20 dix:/unknown: Message could not be verified. Could be due to=20 communications errors, system errors, service unavailability, etc.= =20 5.10.3.5. Membersite's Verification Algorithm=20 1. Receive fetch-response message from Homesite.=20 2. Check that the datetime provide in 'dix:/message-datetime' is=20 within the message age policy.=20 3. Check the nonce provided in 'dix:/message-id' is correct.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 26= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 4. Check that 'dix:/homesite-url' is authoritative for the=20 'dix:/persona-url'.=20 5. Create verify message, using the Digest Generation algorithm to= =20 create the value for 'dix:/digest', and the 'dix:/signature' fro= m=20 the fetch-response message.=20 6. Send verify request message to Homesite.=20 7. Receive verify response message.=20 5.10.3.6. Homesite's Verification Algorithm=20 1. Receive verify request message from Membersite.=20 2. Compute comparison signature based on 'dix:/digest-sha1' provide= d.=20 Compare with 'dix:/signature'.=20 3. Create verify response with the body text being 'dix:/true',=20 'dix:/false', or 'dix:/unknown.=20 6. Security Considerations=20 6.1.1. HTTP and HTTPS=20 Persona URLs and Homesite URLs could use the HTTPS protocol scheme,= =20 which would provide more security.=20 6.1.2. Man in the Middle:=20=20 6.1.2.1. Message Replay=20 The 'dix:/message-id' fetch-request message parameter provided by t= he=20 Membersite serves as a nonce, which guards against a reply attack,= =20 assuming proper implementation by the Membersite.=20 6.1.2.2. Message Alteration=20 When a Membersite receives a fetch-response message it resolves the= =20 Persona URL provided to get a document that contains a persona=20 delegation tag which provides a set of Homesites that are=20 authoritative for that persona. If the fetch-response message=20 contains a Homesite URL that is not found in that set then the=20 message is not valid. The Membersite then verifies the response=20 message by sending a verify request message to the Homesite=20 containing the digest from the fetch-response message.=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 27= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 If a MITM were to change the Homesite URL then the message would be= =20 found to be invalid. If a MITM were to change the Persona URL then= =20 the digest would be found invalid by the Homesite. If the MITM were= =20 to change both the Persona URL and the Homesite URL then the MITM= =20 will be changing the identifier so can't compromise the original=20 identity.=20 7. Acknowledgments=20 The engineering team at Sxip Identity Corporation.=20=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 28= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 References=20 7.1. Normative References=20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for= =20 Syntax Specifications: ABNF", RFC 2234, Internet Mail=20 Consortium and Demon Internet Ltd., November 1997.=20 [RFC2396BIS] Uniform Resource Identifiers (URI): Generic Syntax,=20 http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html=20 [RFC2617] HTTP Authentication: Basic and Digest Access=20 Authentication, http://www.ietf.org/rfc/rfc2617.txt=20 [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.=20 [RFC2616] Hypertext Transfer Protocol -- HTTP/1.1:=20 http://www.ietf.org/rfc/rfc2616.txt=20 7.2. Informative References=20 =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20 Author's Addresses=20 John Merrells=20 Sxip Identity Corporation=20 Suite 206 - 55 Water St=20 Vancouver, BC=20 Canada V6B 1A1=20 =20=20=20=20=20=20=20=20=20=20=20=20 Email: merrells@sxip.com=20 =20=20=20=20=20=20=20=20=20 Intellectual Property Statement=20 The IETF takes no position regarding the validity or scope of any= =20 Intellectual Property Rights or other rights that might be claimed = to=20 pertain to the implementation or use of the technology described in= =20 this document or the extent to which any license under such rights= =20 might or might not be available; nor does it represent that it has= =20 made any independent effort to identify any such rights. Informati= on=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 29= ]=20 =0C Internet-Draft Digital Identity Exchange Protocol January 200= 6=20 =20=20=20=20=20=20=20=20=20 on the procedures with respect to rights in RFC documents can be=20 found in BCP 78 and BCP 79.=20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use = of=20 such proprietary rights by implementers or users of this=20 specification can be obtained from the IETF on-line IPR repository = at=20 http://www.ietf.org/ipr.=20 The IETF invites any interested party to bring to its attention any= =20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement= =20 this standard. Please address the information to the IETF at=20 ietf-ipr@ietf.org=20 Disclaimer of Validity=20 This document and the information contained herein are provided on = an=20 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESEN= TS=20 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET= =20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,= =20 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.= =20 Copyright Statement=20 Copyright (C) The Internet Society (2006).=20 This document is subject to the rights, licenses and restrictions= =20 contained in BCP 78, and except as set forth therein, the authors= =20 retain all their rights.=20 Acknowledgment=20 Funding for the RFC Editor function is currently provided by the=20 Internet Society.=20 =20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20 =20=20=20=20=20=20 Merrells Expires July 17, 2006 [Page 30= ]=20 =0C --Apple-Mail-13-314537480 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-13-314537480-- From dix-bounces@ietf.org Tue Jan 17 17:39:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyzTx-0007Y9-IK; Tue, 17 Jan 2006 17:39:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyzTv-0007Y1-Bl for dix@megatron.ietf.org; Tue, 17 Jan 2006 17:39:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01453 for ; Tue, 17 Jan 2006 17:37:50 -0500 (EST) Message-Id: <200601172237.RAA01453@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyzc7-0003rB-HA for dix@ietf.org; Tue, 17 Jan 2006 17:47:44 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc11) with SMTP id <2006011722390201300cj7kje>; Tue, 17 Jan 2006 22:39:02 +0000 From: "Suresh Venkatraman" To: Subject: RE: [dix] Re: attribute assertions Date: Tue, 17 Jan 2006 14:38:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7963F47B-6FCE-4D79-88BF-E8A349EDE836@sxip.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYbj8/35PR8W4NUT+6VUB9LzwJQwAAJgkRw X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > What about HTTP Accept headers? That is discovery... "HTTP-Accept" is for discovery of acceptable media types within a particular HTTP session. Like the example from RFC 2616: Accept: audio/*; q=0.2, audio/basic DNS SRV is specifically built for service discoverability, like MX records are used to discover mail servers. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Tuesday, January 17, 2006 9:59 AM To: dix@ietf.org Subject: [dix] Re: attribute assertions On 17-Jan-06, at 7:03 AM, Hallam-Baker, Phillip wrote: >> From: Dick Hardt [mailto:dick@sxip.com] > >> I like DNS SRV. There are simpler discovery processes though >> that put >> control where people feel they have control. > > I am utterly unconvinced by the URI based proposals. They are too > cumbersome to be practical or usable for the ordinary user. Given that we are still talking about the Charter, I am surprised at such an absolute stance. I would have thought you would be more open minded Phillip. Did you not have your morning coffee before making this post? :-) > > Usability has to be the priority, not providing the illusion of > control. Agreed > The DNS is the discovery mechanism for the Internet. What about HTTP Accept headers? That is discovery ... ... but we are way off of subject now, which is assertions ... -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 21:49:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3Ng-0002nm-Ul; Tue, 17 Jan 2006 21:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3Ng-0002nQ-Bb for dix@megatron.ietf.org; Tue, 17 Jan 2006 21:49:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25005 for ; Tue, 17 Jan 2006 21:47:38 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez3Vu-0005ok-HM for dix@ietf.org; Tue, 17 Jan 2006 21:57:35 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0I2mvCJ008611 for ; Tue, 17 Jan 2006 18:48:57 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 18:48:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: attribute assertions Date: Tue, 17 Jan 2006 18:48:55 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787AA67@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Re: attribute assertions Thread-Index: AcYbj8/35PR8W4NUT+6VUB9LzwJQwAAJgkRwAAjCmlA= From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 18 Jan 2006 02:48:56.0936 (UTC) FILETIME=[BA04AE80:01C61BD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > > What about HTTP Accept headers? That is discovery... >=20 > "HTTP-Accept" is for discovery of acceptable media types=20 > within a particular HTTP session. Like the example from RFC 2616: >=20 > Accept: audio/*; q=3D0.2, audio/basic The terminology used in the HTTP spec describes it as a negotiation protocol, there are negotiation mechanisms for content type and encoding. It is important to keep to the established terminology as there are people on the IESG who will pick it to pieces otherwise. > DNS SRV is specifically built for service discoverability,=20 > like MX records are used to discover mail servers. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 21:59:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3Xn-0004vP-2p; Tue, 17 Jan 2006 21:59:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3Xl-0004tQ-8c for dix@megatron.ietf.org; Tue, 17 Jan 2006 21:59:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25690 for ; Tue, 17 Jan 2006 21:58:02 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez3fz-000673-8o for dix@ietf.org; Tue, 17 Jan 2006 22:08:00 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0I2xGXl069371 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 Jan 2006 18:59:17 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AA67@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787AA67@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Re: attribute assertions Date: Tue, 17 Jan 2006 18:59:10 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 17-Jan-06, at 6:48 PM, Hallam-Baker, Phillip wrote: >> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > >>> What about HTTP Accept headers? That is discovery... >> >> "HTTP-Accept" is for discovery of acceptable media types >> within a particular HTTP session. Like the example from RFC 2616: >> >> Accept: audio/*; q=0.2, audio/basic > > The terminology used in the HTTP spec describes it as a negotiation > protocol, there are negotiation mechanisms for content type and > encoding. > > It is important to keep to the established terminology as there are > people on the IESG who will pick it to pieces otherwise. Good point. I would add Negotiation then as another part of the process, separate from Discovery. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 17 23:04:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez4Yv-0002Lg-FK; Tue, 17 Jan 2006 23:04:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez4Yt-0002La-SD for dix@megatron.ietf.org; Tue, 17 Jan 2006 23:04:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00199 for ; Tue, 17 Jan 2006 23:03:17 -0500 (EST) Message-Id: <200601180403.XAA00199@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez4h9-00088x-Vs for dix@ietf.org; Tue, 17 Jan 2006 23:13:16 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc12) with SMTP id <2006011804043301400crh91e>; Wed, 18 Jan 2006 04:04:33 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Tue, 17 Jan 2006 20:04:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYb21mAbqMH58oCS06fkYNQOtV94wAAYlmw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org OK - so, at a high-level, what areas, in the "proper terminology", can we say are or are not part of DIX? Off the top of my head and in no particular order: * Location Discovery (of the ID-Service) * Validation (of the ID-Service) * Negotiation (Content, Encoding, Language, Security, Algorithms) * Common Identity Scheme (URI's, URL's, XRI's, etc.) * Identity Authentication (e.g. one-time passwords, digest, pki, etc.) * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML? * Bindings (HTTP, SMTP, SIP, etc.) * Security Layers - Compatible with by TLS, SASL, BEEP, etc.? * Federation (Unifying the Namespace) Many of these areas are already addressed by existing RFC's and can be folded into the DIX framework (when one exists). In addition has anyone come up with a list of use cases for DIX? Thanks. Suresh -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Tuesday, January 17, 2006 6:59 PM To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions On 17-Jan-06, at 6:48 PM, Hallam-Baker, Phillip wrote: >> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > >>> What about HTTP Accept headers? That is discovery... >> >> "HTTP-Accept" is for discovery of acceptable media types >> within a particular HTTP session. Like the example from RFC 2616: >> >> Accept: audio/*; q=0.2, audio/basic > > The terminology used in the HTTP spec describes it as a negotiation > protocol, there are negotiation mechanisms for content type and > encoding. > > It is important to keep to the established terminology as there are > people on the IESG who will pick it to pieces otherwise. Good point. I would add Negotiation then as another part of the process, separate from Discovery. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 11:22:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzG5C-0002HL-HG; Wed, 18 Jan 2006 11:22:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzG5B-0002HG-2U for dix@megatron.ietf.org; Wed, 18 Jan 2006 11:22:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00849 for ; Wed, 18 Jan 2006 11:21:22 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzGDX-0008W2-Ff for dix@ietf.org; Wed, 18 Jan 2006 11:31:27 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0IGMdk9024674 for ; Wed, 18 Jan 2006 08:22:39 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 08:22:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 08:22:38 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787AA94@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Re: attribute assertions Thread-Index: AcYb21mAbqMH58oCS06fkYNQOtV94wAAYlmwABoek6A= From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 18 Jan 2006 16:22:39.0159 (UTC) FILETIME=[6654B470:01C61C4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I think that we need to provide a ready to run proposal not the equivalent of DIY flat pack furniture. Security negotiation protocols are a very bad idea, in almost all cases the result is that the security of the system is the security of the weakest link in the chain. We really need to be selecting components that work together, not designing a system that panders to every legacy idea out there. BEEP for example, zero traction in the commercial Web Services world, negligible traction in the open source world, should be moved to historical. Same goes for XML-RPC.=20 One of the hazzards of standards processes is having another group that has no deployment momentum capture your proposal and insist on turning it into their deployment vehicle. The BEEP author tried to do this to SACRED. The DNS people tried with MARID and will try again with DKIM.=20 Network protocol standards have very strong network effects, unless we are dealling with emerging protocols (SAML for example) the winner should be clear. I don't think we should deliberately preclude alternatives, but we do need to have a 'must implement' profile that provides compatibility. I would add format of the identifier at the top of the list. The design of the identifier will affect everything else. =20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Suresh Venkatraman > Sent: Tuesday, January 17, 2006 11:04 PM > To: 'Digital Identity Exchange' > Subject: RE: [dix] Re: attribute assertions >=20 > OK - so, at a high-level, what areas, in the "proper=20 > terminology", can we say are or are not part of DIX? Off the=20 > top of my head and in no particular > order: >=20 > * Location Discovery (of the ID-Service) > * Validation (of the ID-Service) > * Negotiation (Content, Encoding, Language, Security, Algorithms) > * Common Identity Scheme (URI's, URL's, XRI's, etc.) > * Identity Authentication (e.g. one-time passwords, digest, pki, etc.) > * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML? > * Bindings (HTTP, SMTP, SIP, etc.) > * Security Layers - Compatible with by TLS, SASL, BEEP, etc.? > * Federation (Unifying the Namespace) >=20 > Many of these areas are already addressed by existing RFC's=20 > and can be folded into the DIX framework (when one exists). =20 > In addition has anyone come up with a list of use cases for=20 > DIX? Thanks. >=20 > Suresh >=20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Dick Hardt > Sent: Tuesday, January 17, 2006 6:59 PM > To: Digital Identity Exchange > Subject: Re: [dix] Re: attribute assertions >=20 >=20 > On 17-Jan-06, at 6:48 PM, Hallam-Baker, Phillip wrote: >=20 > >> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > > > >>> What about HTTP Accept headers? That is discovery... > >> > >> "HTTP-Accept" is for discovery of acceptable media types within a=20 > >> particular HTTP session. Like the example from RFC 2616: > >> > >> Accept: audio/*; q=3D0.2, audio/basic > > > > The terminology used in the HTTP spec describes it as a negotiation=20 > > protocol, there are negotiation mechanisms for content type and=20 > > encoding. > > > > It is important to keep to the established terminology as there are=20 > > people on the IESG who will pick it to pieces otherwise. >=20 > Good point. >=20 > I would add Negotiation then as another part of the process,=20 > separate from Discovery. >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 14:35:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ5w-0006rw-P5; Wed, 18 Jan 2006 14:35:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJ5v-0006rr-FP for dix@megatron.ietf.org; Wed, 18 Jan 2006 14:35:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16455 for ; Wed, 18 Jan 2006 14:34:21 -0500 (EST) Message-Id: <200601181934.OAA16455@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJEJ-0006oR-Fe for dix@ietf.org; Wed, 18 Jan 2006 14:44:27 -0500 Received: from sureshmobile (dsl231-036-190.sea1.dsl.speakeasy.net[216.231.36.190]) by comcast.net (rwcrmhc14) with SMTP id <20060118193536014001el6te>; Wed, 18 Jan 2006 19:35:36 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 11:35:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AA94@MOU1WNEXMB04.vcorp.ad.vrsn.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYb21mAbqMH58oCS06fkYNQOtV94wAAYlmwABoek6AABIRDcA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > Security negotiation protocols are a very bad idea, in almost all cases > the result is that the security of the system is the security of the > weakest link in the chain. We really need to be selecting components > that work together, not designing a system that panders to every legacy > idea out there. I'm not suggesting that DIX tackles the security problem; what I am suggesting is that whatever mechanisms are chosen for DIX cannot preclude the use of existing ready-to-run security layers such as TLS, SASL mechanisms, or digest-authentication. OTOH, if security is not given any consideration then we might as well quit now. > BEEP for example, zero traction in the commercial Web Services world, > negligible traction in the open source world, should be moved to > historical. Same goes for XML-RPC. I agree - anything that has zero traction today should not be included. I'm am also of the same mind as far as building something that can be implemented today and work across multiple services, both entrenched (HTTP) and emerging (SIP). Currently there's a big fight between SAML and WS-Federation, I think we have to choose one to make this work (SAML), but leave the exchange language extensible. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, January 18, 2006 8:23 AM To: Digital Identity Exchange Subject: RE: [dix] Re: attribute assertions I think that we need to provide a ready to run proposal not the equivalent of DIY flat pack furniture. Security negotiation protocols are a very bad idea, in almost all cases the result is that the security of the system is the security of the weakest link in the chain. We really need to be selecting components that work together, not designing a system that panders to every legacy idea out there. BEEP for example, zero traction in the commercial Web Services world, negligible traction in the open source world, should be moved to historical. Same goes for XML-RPC. One of the hazzards of standards processes is having another group that has no deployment momentum capture your proposal and insist on turning it into their deployment vehicle. The BEEP author tried to do this to SACRED. The DNS people tried with MARID and will try again with DKIM. Network protocol standards have very strong network effects, unless we are dealling with emerging protocols (SAML for example) the winner should be clear. I don't think we should deliberately preclude alternatives, but we do need to have a 'must implement' profile that provides compatibility. I would add format of the identifier at the top of the list. The design of the identifier will affect everything else. > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > Behalf Of Suresh Venkatraman > Sent: Tuesday, January 17, 2006 11:04 PM > To: 'Digital Identity Exchange' > Subject: RE: [dix] Re: attribute assertions > > OK - so, at a high-level, what areas, in the "proper > terminology", can we say are or are not part of DIX? Off the > top of my head and in no particular > order: > > * Location Discovery (of the ID-Service) > * Validation (of the ID-Service) > * Negotiation (Content, Encoding, Language, Security, Algorithms) > * Common Identity Scheme (URI's, URL's, XRI's, etc.) > * Identity Authentication (e.g. one-time passwords, digest, pki, etc.) > * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML? > * Bindings (HTTP, SMTP, SIP, etc.) > * Security Layers - Compatible with by TLS, SASL, BEEP, etc.? > * Federation (Unifying the Namespace) > > Many of these areas are already addressed by existing RFC's > and can be folded into the DIX framework (when one exists). > In addition has anyone come up with a list of use cases for > DIX? Thanks. > > Suresh > > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > Behalf Of Dick Hardt > Sent: Tuesday, January 17, 2006 6:59 PM > To: Digital Identity Exchange > Subject: Re: [dix] Re: attribute assertions > > > On 17-Jan-06, at 6:48 PM, Hallam-Baker, Phillip wrote: > > >> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > > > >>> What about HTTP Accept headers? That is discovery... > >> > >> "HTTP-Accept" is for discovery of acceptable media types within a > >> particular HTTP session. Like the example from RFC 2616: > >> > >> Accept: audio/*; q=0.2, audio/basic > > > > The terminology used in the HTTP spec describes it as a negotiation > > protocol, there are negotiation mechanisms for content type and > > encoding. > > > > It is important to keep to the established terminology as there are > > people on the IESG who will pick it to pieces otherwise. > > Good point. > > I would add Negotiation then as another part of the process, > separate from Discovery. > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 14:55:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJPA-0004r8-RB; Wed, 18 Jan 2006 14:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJP9-0004r3-Ji for dix@megatron.ietf.org; Wed, 18 Jan 2006 14:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18123 for ; Wed, 18 Jan 2006 14:54:13 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJXW-0007WV-Ez for dix@ietf.org; Wed, 18 Jan 2006 15:04:20 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 3E7E849C92E for ; Wed, 18 Jan 2006 12:55:35 -0700 (MST) Message-ID: <43CE9D36.4010201@jabber.org> Date: Wed, 18 Jan 2006 12:55:34 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions References: <200601181934.OAA16455@ietf.org> In-Reply-To: <200601181934.OAA16455@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1759363231==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1759363231== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030705030808020403050609" This is a cryptographically signed message in MIME format. --------------ms030705030808020403050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Suresh Venkatraman wrote: > I'm not suggesting that DIX tackles the security problem; what I am > suggesting is that whatever mechanisms are chosen for DIX cannot preclude > the use of existing ready-to-run security layers such as TLS, SASL > mechanisms, or digest-authentication. OTOH, if security is not given any > consideration then we might as well quit now. > I agree - anything that has zero traction today should not be included. I'm > am also of the same mind as far as building something that can be > implemented today and work across multiple services, both entrenched (HTTP) > and emerging (SIP). Currently there's a big fight between SAML and > WS-Federation, I think we have to choose one to make this work (SAML), but > leave the exchange language extensible. Given that XMPP (RFC 3920) is built atop TLS and SASL, it might be a good option for the transport protocol. But I'm biased. Peter --------------ms030705030808020403050609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTE4MTk1NTM0WjAjBgkqhkiG9w0BCQQxFgQUHngS8SMSAzZnIp1g DhzABofuOtwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAKjnvpnjoxPPWYKA4ZJSCxDCwH61ie4H FQ9dx7Bb4xWvXlQ2jE4kPJ2utoSybF4MLYMgTVrIUrhJ1pBTwDKtReol1agiZxnso5WYeoKK FNgKn1Ec04UyaRx3n4tO61z1e6c6Naq4kwIpCjmGpmUR1FeIgidSwmlNn+PSigpy9zfxfkN7 +ooifuIKBUViUuYq15uMLeBLW8MhYQao3y5+1SuFnnryp4adoFQ0meu5ZwgE9YWJpYtoF5LZ 9XkTNLMYVffMwug2WTbJyJRBUG05gI87lZuyYJRSa63U9qhhs7NBElUEeiYynEqY6MTO8efJ uUojYw2ESsHMWY4x3E/JLbUAAAAAAAA= --------------ms030705030808020403050609-- --===============1759363231== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1759363231==-- From dix-bounces@ietf.org Wed Jan 18 15:01:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJUc-0006bZ-QY; Wed, 18 Jan 2006 15:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJUc-0006ar-85 for dix@megatron.ietf.org; Wed, 18 Jan 2006 15:01:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18645 for ; Wed, 18 Jan 2006 14:59:52 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJcx-0007ju-Gz for dix@ietf.org; Wed, 18 Jan 2006 15:09:58 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0IK138g099258 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 12:01:04 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43CE9D36.4010201@jabber.org> References: <200601181934.OAA16455@ietf.org> <43CE9D36.4010201@jabber.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <193D0035-E647-42AE-AAEF-CE2627EF5C00@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 12:00:56 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 11:55 AM, Peter Saint-Andre wrote: > >> I agree - anything that has zero traction today should not be >> included. I'm >> am also of the same mind as far as building something that can be >> implemented today and work across multiple services, both >> entrenched (HTTP) >> and emerging (SIP). Currently there's a big fight between SAML and >> WS-Federation, I think we have to choose one to make this work >> (SAML), but >> leave the exchange language extensible. > > Given that XMPP (RFC 3920) is built atop TLS and SASL, it might be > a good option for the transport protocol. But I'm biased. In the ID that John Merrells posted, HTTP is the transport being discussed. No reason for DIX to not run on XMPP or SIP. Would be *good* objectives for that to be possible. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 15:22:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJpL-0004cD-4X; Wed, 18 Jan 2006 15:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJpJ-0004c6-JG for dix@megatron.ietf.org; Wed, 18 Jan 2006 15:22:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20428 for ; Wed, 18 Jan 2006 15:21:15 -0500 (EST) Message-Id: <200601182021.PAA20428@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJxh-00005U-8U for dix@ietf.org; Wed, 18 Jan 2006 15:31:22 -0500 Received: from sureshmobile (dsl231-036-190.sea1.dsl.speakeasy.net[216.231.36.190]) by comcast.net (rwcrmhc12) with SMTP id <2006011820222801400cs496e>; Wed, 18 Jan 2006 20:22:29 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 12:22:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <193D0035-E647-42AE-AAEF-CE2627EF5C00@sxip.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYcaf2wcAEuovUGQ7mxzAIp+GgMQgAAQ7yg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > In the ID that John Merrells posted, HTTP is the transport being > discussed. > No reason for DIX to not run on XMPP or SIP. Would be *good* > objectives for that to be possible. I'd say there are quite a few options available: (1) Create DIX as a transport independent protocol and spec bindings for multiple protocols (HTTP, SIP, XMPP, etc.). This is what the Merrell draft proposes. (2) Make DIX protocol specific, let's say by adding extension methods to HTTP - this might be a bad idea as we could get lumped into the Network/HTTP working group. Just throwing it out there... (3) Create a separate request/response protocol for DIX taking into account the specific needs of identity exchange, authentication, etc. This would need bindings for multiple protocols as well to ensure interop. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Wednesday, January 18, 2006 12:01 PM To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions On 18-Jan-06, at 11:55 AM, Peter Saint-Andre wrote: > >> I agree - anything that has zero traction today should not be >> included. I'm >> am also of the same mind as far as building something that can be >> implemented today and work across multiple services, both >> entrenched (HTTP) >> and emerging (SIP). Currently there's a big fight between SAML and >> WS-Federation, I think we have to choose one to make this work >> (SAML), but >> leave the exchange language extensible. > > Given that XMPP (RFC 3920) is built atop TLS and SASL, it might be > a good option for the transport protocol. But I'm biased. In the ID that John Merrells posted, HTTP is the transport being discussed. No reason for DIX to not run on XMPP or SIP. Would be *good* objectives for that to be possible. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 15:32:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJz9-0006i3-TC; Wed, 18 Jan 2006 15:32:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJz8-0006hy-Uf for dix@megatron.ietf.org; Wed, 18 Jan 2006 15:32:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21121 for ; Wed, 18 Jan 2006 15:31:24 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzK7X-0000O1-GK for dix@ietf.org; Wed, 18 Jan 2006 15:41:31 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 126BF49C985 for ; Wed, 18 Jan 2006 13:32:54 -0700 (MST) Message-ID: <43CEA5F5.7060004@jabber.org> Date: Wed, 18 Jan 2006 13:32:53 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions References: <200601182021.PAA20428@ietf.org> In-Reply-To: <200601182021.PAA20428@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1089497598==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1089497598== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030006040909020107070204" This is a cryptographically signed message in MIME format. --------------ms030006040909020107070204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Suresh Venkatraman wrote: >> In the ID that John Merrells posted, HTTP is the transport being >> discussed. > >> No reason for DIX to not run on XMPP or SIP. Would be *good* >> objectives for that to be possible. > > I'd say there are quite a few options available: > > (1) Create DIX as a transport independent protocol and spec bindings for > multiple protocols (HTTP, SIP, XMPP, etc.). This is what the Merrell draft > proposes. That always seems like a good idea to me. Peter --------------ms030006040909020107070204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTE4MjAzMjUzWjAjBgkqhkiG9w0BCQQxFgQUgTr6GWXs8DKYbYRr PA/rHCuaII4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAGfCynvGBIqkGh89Lvjk8Q5nSjMcIIdZ v0T8CBII0sdXzqsDXSo9PiADcHeYa9ox5LiXY3AhDpFPYpVNkHCRDzgxPbV4BOOHKLYDS5fJ /yGkc76Njo0VRSsQZfhNi5NQlUiSLJ1GVBWiv97Ciz5S6OoM7FDB5458AvbpXNWLDhDG+5H0 D3qolHVeopCQwgt9yvsXcPFEwMmettJjxyvqCREsAtoU/DidCx6AOes24k6CLcO5xEKj5phh 9Q6fN54FDx4nKRgbnPrNZB3/Y0pCfhS42MeZMoyzeCkDuygMXEdyyiXb9EQNQPe39PMnACeI GdJIhsb1MzpHFQKU+9A2TTQAAAAAAAA= --------------ms030006040909020107070204-- --===============1089497598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1089497598==-- From dix-bounces@ietf.org Wed Jan 18 16:55:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLGz-0007dd-8u; Wed, 18 Jan 2006 16:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLGx-0007ca-CO for dix@megatron.ietf.org; Wed, 18 Jan 2006 16:55:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11992 for ; Wed, 18 Jan 2006 16:53:51 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLPF-000098-2m for dix@ietf.org; Wed, 18 Jan 2006 17:03:57 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0ILt0UH003739 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 13:55:00 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601182021.PAA20428@ietf.org> References: <200601182021.PAA20428@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1643BAF5-1A80-4464-918F-3F91CE302C91@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 13:54:55 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 12:22 PM, Suresh Venkatraman wrote: > (1) Create DIX as a transport independent protocol and spec > bindings for > multiple protocols (HTTP, SIP, XMPP, etc.). This is what the > Merrell draft > proposes. Yep, the proposed charter details two documents: 'DIX Protocol' and 'DIX over HTTP'. If people want to work on others that'd be great. XMPP looks like a great option. SIP too, but I don't personally have any experience of working with it. If there's anyone on the list with an intersection of interests between SIP and DIX who wants to liaise between the groups... or author a 'DIX over SIP' draft that'd be cool. > (2) Make DIX protocol specific, let's say by adding extension > methods to > HTTP - this might be a bad idea as we could get lumped into the > Network/HTTP > working group. Just throwing it out there... I think that the HTTP-AUTH group would be the right place for this conversation. > (3) Create a separate request/response protocol for DIX taking into > account > the specific needs of identity exchange, authentication, etc. This > would > need bindings for multiple protocols as well to ensure interop. Sounds like (1) to me. How's that different? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 16:57:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLIw-0000Lf-Ds; Wed, 18 Jan 2006 16:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLIv-0000Ko-3o for dix@megatron.ietf.org; Wed, 18 Jan 2006 16:57:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12882 for ; Wed, 18 Jan 2006 16:55:54 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLRI-0000VU-0e for dix@ietf.org; Wed, 18 Jan 2006 17:06:02 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0ILvD46020145 for ; Wed, 18 Jan 2006 13:57:13 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 13:57:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 13:57:12 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787AB2E@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Re: attribute assertions Thread-Index: AcYb21mAbqMH58oCS06fkYNQOtV94wAAYlmwABoek6AABIRDcAAIPsoA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 18 Jan 2006 21:57:13.0676 (UTC) FILETIME=[23ACE8C0:01C61C7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Suresh Venkatraman > I'm not suggesting that DIX tackles the security problem;=20 > what I am suggesting is that whatever mechanisms are chosen=20 > for DIX cannot preclude the use of existing ready-to-run=20 > security layers such as TLS, SASL mechanisms, or=20 > digest-authentication. OTOH, if security is not given any=20 > consideration then we might as well quit now. It sounds reasonable, what I want to avoid is a situation like WiFi where the access points support three different authentication mechanisms equally poorly. > > BEEP for example, zero traction in the commercial Web=20 > Services world,=20 > > negligible traction in the open source world, should be moved to=20 > > historical. Same goes for XML-RPC. >=20 > I agree - anything that has zero traction today should not be=20 > included. I'm am also of the same mind as far as building=20 > something that can be implemented today and work across=20 > multiple services, both entrenched (HTTP) and emerging (SIP).=20 I would suggest that as far as the charter is concerned it should commit to providing an HTTP binding and allow a SIP binding to be specified. The reason for this is that SIP politics are not entirely concentrated at the IETF. SIP hooks into the telephone network and there is a major culture gap between Internet engineers and phone system engineers. It is very difficult to get the two talking - even when they both work in the same company. It is probably easier to get the critical mass in the SIP area by demonstrating the effectiveness of the system in the HTTP world first. > Currently there's a big fight between SAML and WS-Federation,=20 > I think we have to choose one to make this work (SAML), but=20 > leave the exchange language extensible.=20 They are both emerging protocols. I do not think that there is much overlap in the area of attributes. There is an overlap in other parts of the SAML spec. Ultimately the problem of attributes comes down to defining a common vocabulary of terms. SAML and WS-Federation both provide only mechanism. Its like having RFC822 syntax without someone saying that there is a To header and a From header etc. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 17:02:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLOI-0002Z3-U7; Wed, 18 Jan 2006 17:02:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLOI-0002Yy-FY for dix@megatron.ietf.org; Wed, 18 Jan 2006 17:02:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14061 for ; Wed, 18 Jan 2006 17:01:27 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLWh-0000zG-TL for dix@ietf.org; Wed, 18 Jan 2006 17:11:36 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0IM2rml029744 for ; Wed, 18 Jan 2006 14:02:53 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 14:02:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 14:02:52 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3787AB39@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Re: attribute assertions Thread-Index: AcYcafxHNCiaz6GuTQqr2n0WDYKQXwAEDBtQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 18 Jan 2006 22:02:52.0957 (UTC) FILETIME=[EDE714D0:01C61C7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Dick Hardt > On 18-Jan-06, at 11:55 AM, Peter Saint-Andre wrote: >=20 > > > >> I agree - anything that has zero traction today should not be=20 > >> included. I'm am also of the same mind as far as building=20 > something=20 > >> that can be implemented today and work across multiple=20 > services, both=20 > >> entrenched (HTTP) and emerging (SIP). Currently there's a=20 > big fight=20 > >> between SAML and WS-Federation, I think we have to choose=20 > one to make=20 > >> this work (SAML), but leave the exchange language extensible. > > > > Given that XMPP (RFC 3920) is built atop TLS and SASL, it=20 > might be a=20 > > good option for the transport protocol. But I'm biased. >=20 > In the ID that John Merrells posted, HTTP is the transport=20 > being discussed. >=20 > No reason for DIX to not run on XMPP or SIP. Would be *good*=20 > objectives for that to be possible. There are different levels of commitment that can be expressed in a charter: * XMPP and SIP support are deliverables with specified milestones * XMPP and SIP support are optional deliverables * Proving the possibility of XMPP and SIP support is a deliverable * Discussion of XMPP and SIP is out of scope I definitely think we do not want the last option. On the other hand I would be nervous about specifying milestones at this point. I think that we need to be sure we have convinced ourselves that the ideas can be applied to SIP and XMPP. I regard that type of test as being essential to make sure that we have the base architecture right, I would suggest doing that even if we did not intend to actually realize that support. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 17:07:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLSM-0000is-Sg; Wed, 18 Jan 2006 17:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLSL-0000h7-V2 for dix@megatron.ietf.org; Wed, 18 Jan 2006 17:07:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14645 for ; Wed, 18 Jan 2006 17:05:38 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLal-0001Et-4x for dix@ietf.org; Wed, 18 Jan 2006 17:15:47 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0IM6uIs004270 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 14:06:57 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AB39@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3787AB39@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E28721F-713F-43EC-B3CD-8A53B7E563AC@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 14:06:52 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 2:02 PM, Hallam-Baker, Phillip wrote: > There are different levels of commitment that can be expressed in a > charter: > > * XMPP and SIP support are deliverables with specified milestones > * XMPP and SIP support are optional deliverables > * Proving the possibility of XMPP and SIP support is a deliverable > * Discussion of XMPP and SIP is out of scope > > I definitely think we do not want the last option. On the other hand I > would be nervous about specifying milestones at this point. > > I think that we need to be sure we have convinced ourselves that the > ideas can be applied to SIP and XMPP. I regard that type of test as > being essential to make sure that we have the base architecture > right, I > would suggest doing that even if we did not intend to actually realize > that support. I think that the proposed charter reflects this statement: "Any solution should support multiple transport layers, but it is anticipated that this working group will focus on a HTTP based solution. " John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 17:18:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLdN-0002CB-8f; Wed, 18 Jan 2006 17:18:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLdL-0002C6-Tm for dix@megatron.ietf.org; Wed, 18 Jan 2006 17:18:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15683 for ; Wed, 18 Jan 2006 17:17:00 -0500 (EST) Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLlk-0001f3-Fx for dix@ietf.org; Wed, 18 Jan 2006 17:27:09 -0500 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CACB7142277 for ; Wed, 18 Jan 2006 14:18:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <1643BAF5-1A80-4464-918F-3F91CE302C91@sxip.com> References: <200601182021.PAA20428@ietf.org> <1643BAF5-1A80-4464-918F-3F91CE302C91@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <408f14cb87e70a5c6e7dcef2a56328d2@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 14:18:17 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org For certain parts of this ecosystem, more transports is not better. Forgive me if this is already obvious to others (and correct me if I'm wrong)... For the client --> content server communication, more transports is better as "single sign on" vision is to work for email, IM, Web, voice and other applications -- so in the long run this would work with the application protocols that clients already use. For the client --> authentication server communication, a low number of transports is highly desirable, so that an arbitrary client has a good chance of working against authentication servers from different providers. However there may be need for more than one, and we may be able to make that work by saying that an auth server implementing such-and-such a spec MUST implement all the required transports For all other pieces between servers, a low number of transports is desirable as well, particularly because you can model the content server as a kind of client against the authentication server or other servers; the content server might be deployed by 3rd parties and small shops, and not be under the same IT as the authority servers. lisa On Jan 18, 2006, at 1:54 PM, John Merrells wrote: > > On 18-Jan-06, at 12:22 PM, Suresh Venkatraman wrote: > >> (1) Create DIX as a transport independent protocol and spec bindings >> for >> multiple protocols (HTTP, SIP, XMPP, etc.). This is what the Merrell >> draft >> proposes. > > Yep, the proposed charter details two documents: 'DIX Protocol' and > 'DIX > over HTTP'. If people want to work on others that'd be great. > > XMPP looks like a great option. > > SIP too, but I don't personally have any experience of working with > it. If > there's anyone on the list with an intersection of interests between > SIP > and DIX who wants to liaise between the groups... or author a 'DIX over > SIP' draft that'd be cool. > >> (2) Make DIX protocol specific, let's say by adding extension methods >> to >> HTTP - this might be a bad idea as we could get lumped into the >> Network/HTTP >> working group. Just throwing it out there... > > I think that the HTTP-AUTH group would be the right place for this > conversation. > >> (3) Create a separate request/response protocol for DIX taking into >> account >> the specific needs of identity exchange, authentication, etc. This >> would >> need bindings for multiple protocols as well to ensure interop. > > Sounds like (1) to me. How's that different? > > John > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 17:36:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLuh-0006Rz-Lb; Wed, 18 Jan 2006 17:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLuf-0006Rn-F3 for dix@megatron.ietf.org; Wed, 18 Jan 2006 17:36:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16922 for ; Wed, 18 Jan 2006 17:34:54 -0500 (EST) Message-Id: <200601182234.RAA16922@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzM35-0002G8-7N for dix@ietf.org; Wed, 18 Jan 2006 17:45:03 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc13) with SMTP id <20060118223608015009mns6e>; Wed, 18 Jan 2006 22:36:09 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 14:35:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <408f14cb87e70a5c6e7dcef2a56328d2@osafoundation.org> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYcfevZ6EZ7pWmNRcKpiL2t5UEOlwAAJ2VA X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >>> (3) Create a separate request/response protocol for DIX taking into >>> account >>> the specific needs of identity exchange, authentication, etc. This >>> would >>> need bindings for multiple protocols as well to ensure interop. >> >> Sounds like (1) to me. How's that different? > > For the client --> authentication server communication, a low number of > transports is highly desirable, so that an arbitrary client has a good > chance of working against authentication servers from different > providers. However there may be need for more than one, and we may be > able to make that work by saying that an auth server implementing > such-and-such a spec MUST implement all the required transports That was kind of why I brought up the third option, however unlikely it seemed to introduce a new protocol. Of course the overhead of building yet another protocol may be too much given the proposed timeline. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Lisa Dusseault Sent: Wednesday, January 18, 2006 2:18 PM To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions For certain parts of this ecosystem, more transports is not better. Forgive me if this is already obvious to others (and correct me if I'm wrong)... For the client --> content server communication, more transports is better as "single sign on" vision is to work for email, IM, Web, voice and other applications -- so in the long run this would work with the application protocols that clients already use. For the client --> authentication server communication, a low number of transports is highly desirable, so that an arbitrary client has a good chance of working against authentication servers from different providers. However there may be need for more than one, and we may be able to make that work by saying that an auth server implementing such-and-such a spec MUST implement all the required transports For all other pieces between servers, a low number of transports is desirable as well, particularly because you can model the content server as a kind of client against the authentication server or other servers; the content server might be deployed by 3rd parties and small shops, and not be under the same IT as the authority servers. lisa On Jan 18, 2006, at 1:54 PM, John Merrells wrote: > > On 18-Jan-06, at 12:22 PM, Suresh Venkatraman wrote: > >> (1) Create DIX as a transport independent protocol and spec bindings >> for >> multiple protocols (HTTP, SIP, XMPP, etc.). This is what the Merrell >> draft >> proposes. > > Yep, the proposed charter details two documents: 'DIX Protocol' and > 'DIX > over HTTP'. If people want to work on others that'd be great. > > XMPP looks like a great option. > > SIP too, but I don't personally have any experience of working with > it. If > there's anyone on the list with an intersection of interests between > SIP > and DIX who wants to liaise between the groups... or author a 'DIX over > SIP' draft that'd be cool. > >> (2) Make DIX protocol specific, let's say by adding extension methods >> to >> HTTP - this might be a bad idea as we could get lumped into the >> Network/HTTP >> working group. Just throwing it out there... > > I think that the HTTP-AUTH group would be the right place for this > conversation. > >> (3) Create a separate request/response protocol for DIX taking into >> account >> the specific needs of identity exchange, authentication, etc. This >> would >> need bindings for multiple protocols as well to ensure interop. > > Sounds like (1) to me. How's that different? > > John > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 17:43:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzM1B-0003cO-Cr; Wed, 18 Jan 2006 17:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzM1B-0003U5-18 for dix@megatron.ietf.org; Wed, 18 Jan 2006 17:43:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17372 for ; Wed, 18 Jan 2006 17:41:34 -0500 (EST) Message-Id: <200601182241.RAA17372@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzM9W-0002Ta-Ej for dix@ietf.org; Wed, 18 Jan 2006 17:51:43 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc12) with SMTP id <2006011822424601400crfcde>; Wed, 18 Jan 2006 22:42:46 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 14:42:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AB2E@MOU1WNEXMB04.vcorp.ad.vrsn.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYb21mAbqMH58oCS06fkYNQOtV94wAAYlmwABoek6AABIRDcAAIPsoAAAHgNiA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > Ultimately the problem of attributes comes down to defining a common > vocabulary of terms. SAML and WS-Federation both provide only mechanism. > Its like having RFC822 syntax without someone saying that there is a To > header and a From header etc. I'm in complete agreement. I don't want to end up with yet another identity protocol with the over-the-wire portion left in limbo. The solution that gets developed by the proposed DIX WG should be deployable when it is ratified (or before). -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, January 18, 2006 1:57 PM To: Digital Identity Exchange Subject: RE: [dix] Re: attribute assertions > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > Behalf Of Suresh Venkatraman > I'm not suggesting that DIX tackles the security problem; > what I am suggesting is that whatever mechanisms are chosen > for DIX cannot preclude the use of existing ready-to-run > security layers such as TLS, SASL mechanisms, or > digest-authentication. OTOH, if security is not given any > consideration then we might as well quit now. It sounds reasonable, what I want to avoid is a situation like WiFi where the access points support three different authentication mechanisms equally poorly. > > BEEP for example, zero traction in the commercial Web > Services world, > > negligible traction in the open source world, should be moved to > > historical. Same goes for XML-RPC. > > I agree - anything that has zero traction today should not be > included. I'm am also of the same mind as far as building > something that can be implemented today and work across > multiple services, both entrenched (HTTP) and emerging (SIP). I would suggest that as far as the charter is concerned it should commit to providing an HTTP binding and allow a SIP binding to be specified. The reason for this is that SIP politics are not entirely concentrated at the IETF. SIP hooks into the telephone network and there is a major culture gap between Internet engineers and phone system engineers. It is very difficult to get the two talking - even when they both work in the same company. It is probably easier to get the critical mass in the SIP area by demonstrating the effectiveness of the system in the HTTP world first. > Currently there's a big fight between SAML and WS-Federation, > I think we have to choose one to make this work (SAML), but > leave the exchange language extensible. They are both emerging protocols. I do not think that there is much overlap in the area of attributes. There is an overlap in other parts of the SAML spec. Ultimately the problem of attributes comes down to defining a common vocabulary of terms. SAML and WS-Federation both provide only mechanism. Its like having RFC822 syntax without someone saying that there is a To header and a From header etc. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 17:53:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMBU-0007WK-Jj; Wed, 18 Jan 2006 17:53:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMBS-0007UO-Kh for dix@megatron.ietf.org; Wed, 18 Jan 2006 17:53:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18061 for ; Wed, 18 Jan 2006 17:52:15 -0500 (EST) Message-Id: <200601182252.RAA18061@ietf.org> Received: from [216.148.227.153] (helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzMJr-0002oP-J2 for dix@ietf.org; Wed, 18 Jan 2006 18:02:24 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc13) with SMTP id <20060118225331015009mf71e>; Wed, 18 Jan 2006 22:53:31 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 14:53:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AB39@MOU1WNEXMB04.vcorp.ad.vrsn.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYcafxHNCiaz6GuTQqr2n0WDYKQXwAEDBtQAAGa3pA= X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > I think that we need to be sure we have convinced ourselves that the > ideas can be applied to SIP and XMPP. I regard that type of test as > being essential to make sure that we have the base architecture right, I > would suggest doing that even if we did not intend to actually realize > that support. I would argue that SIP and XMPP, as protocols built for user or identity-based communications, are exceptionally well suited to take advantage of a common identity solution. I'm not arguing against the use of HTTP as the spec'd binding, but I would push for bindings in these other protocols as well, even if only in draft form. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, January 18, 2006 2:03 PM To: Digital Identity Exchange Subject: RE: [dix] Re: attribute assertions > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On > Behalf Of Dick Hardt > On 18-Jan-06, at 11:55 AM, Peter Saint-Andre wrote: > > > > >> I agree - anything that has zero traction today should not be > >> included. I'm am also of the same mind as far as building > something > >> that can be implemented today and work across multiple > services, both > >> entrenched (HTTP) and emerging (SIP). Currently there's a > big fight > >> between SAML and WS-Federation, I think we have to choose > one to make > >> this work (SAML), but leave the exchange language extensible. > > > > Given that XMPP (RFC 3920) is built atop TLS and SASL, it > might be a > > good option for the transport protocol. But I'm biased. > > In the ID that John Merrells posted, HTTP is the transport > being discussed. > > No reason for DIX to not run on XMPP or SIP. Would be *good* > objectives for that to be possible. There are different levels of commitment that can be expressed in a charter: * XMPP and SIP support are deliverables with specified milestones * XMPP and SIP support are optional deliverables * Proving the possibility of XMPP and SIP support is a deliverable * Discussion of XMPP and SIP is out of scope I definitely think we do not want the last option. On the other hand I would be nervous about specifying milestones at this point. I think that we need to be sure we have convinced ourselves that the ideas can be applied to SIP and XMPP. I regard that type of test as being essential to make sure that we have the base architecture right, I would suggest doing that even if we did not intend to actually realize that support. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 18:09:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMQs-0003Zp-SA; Wed, 18 Jan 2006 18:09:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMQs-0003Za-In for dix@megatron.ietf.org; Wed, 18 Jan 2006 18:09:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18949 for ; Wed, 18 Jan 2006 18:08:13 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzMZH-0003FF-8f for dix@ietf.org; Wed, 18 Jan 2006 18:18:20 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0IN9S0Y006770 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 15:09:28 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601180403.XAA00199@ietf.org> References: <200601180403.XAA00199@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77574739-4B2C-45AA-AE97-AE8BFE38D62E@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 15:09:24 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 17-Jan-06, at 8:04 PM, Suresh Venkatraman wrote: > OK - so, at a high-level, what areas, in the "proper terminology", > can we > say are or are not part of DIX? Off the top of my head and in no > particular > order: I'll have a crack at this. Would be interested to hear what others think. > * Location Discovery (of the ID-Service) In scope. In general a relying party can't do much without discovery in the system somewhere. In draft-merrells-dix-01 (dmd1) we just ask the user, and then optionally cookie the user... so I think it can be done in a very simple way. > * Validation (of the ID-Service) I'm not sure what that means. Sounds a bit like trust. If so I think we can make that out of scope as multiple trust models could be applied and there are existing mechanisms for achieving that. In dmd1 the membersite relies upon the user to trust their homesite. > * Negotiation (Content, Encoding, Language, Security, Algorithms) In scope. In dmd1 was have 'capabilities', which are used to represent these things and advertise them between membersites and homesites. > * Common Identity Scheme (URI's, URL's, XRI's, etc.) In scope. In dmd1 we have the Persona URL as the identifier. > * Identity Authentication (e.g. one-time passwords, digest, pki, etc.) Out of scope for how authentication is done... but in scope for how a membersite might require a certain level of authentication to be performed In dmd1 we don't specify any authentication mechanisms and we have the capabilities for declaring how auth could be done... and we have some thoughts around how a membersite could make assertions about its requirements. > * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML? I'm not sure what that is. How someone identifies themselves? In that there's an assertion that they've authenticated as a certain identifier. In scope... but I'd generalize it to exchange of attributes and claims. dmd1 has messages for fetching and storing 'properties'. > * Bindings (HTTP, SMTP, SIP, etc.) In scope. dmd1 constrains itself to HTTP. > * Security Layers - Compatible with by TLS, SASL, BEEP, etc.? Um... In and Out of scope. TLS - In, but I think that's an issue for the transport binding. BEEP - In, but again that's a transport binding thing. I loved it. After working on LDAP(S) IO code I really loved it. SASL - Out... I think... last time I looked that was a framework/api for dropping authentication mechanisms into... but I may not be totally up to date on that. That's an identity authentication thing, so out of scope from my point of view. > * Federation (Unifying the Namespace) Out of scope. > Many of these areas are already addressed by existing RFC's and can be > folded into the DIX framework (when one exists). Our general goal has been/should be to reuse as much as possible, and add only what is necessary to meet the requirements... > In addition has anyone > come up with a list of use cases for DIX? Thanks. Bob had a stab at it on this list, but beyond that the use cases are mostly being talked about in other communities. A draft that documented the driving use cases would be a good thing, but not essential if the community here believes there is a real problem to solve and this is the way to solve it. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 18:20:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMbQ-0000R5-7n; Wed, 18 Jan 2006 18:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMbN-0000PY-Vo for dix@megatron.ietf.org; Wed, 18 Jan 2006 18:20:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19796 for ; Wed, 18 Jan 2006 18:19:04 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzMjn-0003dS-QF for dix@ietf.org; Wed, 18 Jan 2006 18:29:12 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0INKKSO007170 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 15:20:21 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601182241.RAA17372@ietf.org> References: <200601182241.RAA17372@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 15:20:16 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 2:42 PM, Suresh Venkatraman wrote: >> Ultimately the problem of attributes comes down to defining a common >> vocabulary of terms. SAML and WS-Federation both provide only >> mechanism. >> Its like having RFC822 syntax without someone saying that there is >> a To >> header and a From header etc. > > I'm in complete agreement. I don't want to end up with yet another > identity > protocol with the over-the-wire portion left in limbo. The solution > that > gets developed by the proposed DIX WG should be deployable when it is > ratified (or before). In the dmd1 terminology do you mean the parameters of the message or the property names? dmd1 specifies the message parameters in detail. Does this meet your deployability metric? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 20:41:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOnR-0002xw-Cs; Wed, 18 Jan 2006 20:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOnQ-0002w7-Dt for dix@megatron.ietf.org; Wed, 18 Jan 2006 20:41:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04599 for ; Wed, 18 Jan 2006 20:39:38 -0500 (EST) Message-Id: <200601190139.UAA04599@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzOvp-0001QF-Ka for dix@ietf.org; Wed, 18 Jan 2006 20:49:48 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc11) with SMTP id <2006011901400901300cj83ge>; Thu, 19 Jan 2006 01:40:09 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 17:39:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYchE/+1v8VfHCTRIiXjg8VJQ5drQAEvCng In-Reply-To: <77574739-4B2C-45AA-AE97-AE8BFE38D62E@sxip.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >> * Validation (of the ID-Service) > > I'm not sure what that means. Sounds a bit like trust. If so I think we > can make that out of scope as multiple trust models could be applied > and there are existing mechanisms for achieving that. > > In dmd1 the membersite relies upon the user to trust their homesite. The question was validation of the ID-server or "homesite" in DMD1 terminology; as in does DIX provide a mechanism to validate or assert that the "homesite" is in fact who/what it says it is. This is probably outside the scope of DIX and is better left to the TLS/SSL layer. > Out of scope for how authentication is done... but in scope for how > a membersite might require a certain level of authentication to be > performed > > In dmd1 we don't specify any authentication mechanisms and we > have the capabilities for declaring how auth could be done... and > we have some thoughts around how a membersite could make > assertions about its requirements. Is there a specific reason why negotiating the authentication mechanism should not be part of the protocol? Is it assumed that authentication will be addressed in the particular binding (HTTP, etc.)? We wouldn't need to make one up, just allow choice from the existing authentication schemes. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of John Merrells Sent: Wednesday, January 18, 2006 3:09 PM To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions On 17-Jan-06, at 8:04 PM, Suresh Venkatraman wrote: > OK - so, at a high-level, what areas, in the "proper terminology", > can we > say are or are not part of DIX? Off the top of my head and in no > particular > order: I'll have a crack at this. Would be interested to hear what others think. > * Location Discovery (of the ID-Service) In scope. In general a relying party can't do much without discovery in the system somewhere. In draft-merrells-dix-01 (dmd1) we just ask the user, and then optionally cookie the user... so I think it can be done in a very simple way. > * Validation (of the ID-Service) I'm not sure what that means. Sounds a bit like trust. If so I think we can make that out of scope as multiple trust models could be applied and there are existing mechanisms for achieving that. In dmd1 the membersite relies upon the user to trust their homesite. > * Negotiation (Content, Encoding, Language, Security, Algorithms) In scope. In dmd1 was have 'capabilities', which are used to represent these things and advertise them between membersites and homesites. > * Common Identity Scheme (URI's, URL's, XRI's, etc.) In scope. In dmd1 we have the Persona URL as the identifier. > * Identity Authentication (e.g. one-time passwords, digest, pki, etc.) Out of scope for how authentication is done... but in scope for how a membersite might require a certain level of authentication to be performed In dmd1 we don't specify any authentication mechanisms and we have the capabilities for declaring how auth could be done... and we have some thoughts around how a membersite could make assertions about its requirements. > * Identifier Exchange (Claims, Mappings, etc.) - Addressed in SAML? I'm not sure what that is. How someone identifies themselves? In that there's an assertion that they've authenticated as a certain identifier. In scope... but I'd generalize it to exchange of attributes and claims. dmd1 has messages for fetching and storing 'properties'. > * Bindings (HTTP, SMTP, SIP, etc.) In scope. dmd1 constrains itself to HTTP. > * Security Layers - Compatible with by TLS, SASL, BEEP, etc.? Um... In and Out of scope. TLS - In, but I think that's an issue for the transport binding. BEEP - In, but again that's a transport binding thing. I loved it. After working on LDAP(S) IO code I really loved it. SASL - Out... I think... last time I looked that was a framework/api for dropping authentication mechanisms into... but I may not be totally up to date on that. That's an identity authentication thing, so out of scope from my point of view. > * Federation (Unifying the Namespace) Out of scope. > Many of these areas are already addressed by existing RFC's and can be > folded into the DIX framework (when one exists). Our general goal has been/should be to reuse as much as possible, and add only what is necessary to meet the requirements... > In addition has anyone > come up with a list of use cases for DIX? Thanks. Bob had a stab at it on this list, but beyond that the use cases are mostly being talked about in other communities. A draft that documented the driving use cases would be a good thing, but not essential if the community here believes there is a real problem to solve and this is the way to solve it. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 20:55:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzP1P-0004Mq-RM; Wed, 18 Jan 2006 20:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzP1O-0004MU-IM for dix@megatron.ietf.org; Wed, 18 Jan 2006 20:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05980 for ; Wed, 18 Jan 2006 20:54:04 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzP9n-00022Q-MK for dix@ietf.org; Wed, 18 Jan 2006 21:04:14 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0J1tHDs013318 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 17:55:17 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: quoted-printable Message-Id: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Wed, 18 Jan 2006 17:55:10 -0800 X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Subject: [dix] draft proposed charter - consensus? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org 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 Scott Hollenbeck Mailing Lists: General Discussion: dix@ietf.org To Subscribe: dix-request@ietf.org 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=20=20 Exchange protocol. DIX is an Internet scale protocol for exchanging=20=20 identity information between endpoints. The protocol architecture=20=20 maintains a separation of control between all parties of the exchange=20=20 and supports both compartmentalized and anonymous identities. Problem Statement The success of the Internet has led to a multitude of online=20=20 information sources and services. A consequence of this has been the=20=20 increasing demand for users to identify themselves and to provide=20=20 information about them. The user is currently bearing the burden of=20=20 managing their authentication credentials and is repeatedly having to=20=20 provide their identity information. For example, signing in to web=20=20 pages and completing user registration forms. An illustrative example would be a website that accepts user=20=20 generated content. A significant problem exists today that these=20=20 sites attract the attention of spammers. Upon submission the site=20=20 needs to determine both the identity of the submitter and that they=20=20 are of good standing in the community. In other words, the site=20=20 requires the reputation of the submitter. This is not possible=20=20 without a protocol to identify a user across multiple sites and to=20=20 move that reputation data around. Goal The goal of this group is to specify a protocol for moving identity=20=20 information between parties and a system architecture that enables=20=20 the development of software agents to manage a user=92s identity=20=20 information. Method An identity information exchange should involve just three parties:=20=20 the user, their agent, and a relying party. The user=92s agent is where=20= =20 they authenticate themselves and a repository where they store their=20=20 identity information, and the relying party is an entity requesting=20=20 identity information. The protocol should be both simple and secure. Simple meaning that=20=20 minimal modifications should be required to the user=92s software and=20=20 the relying party=92s software to participate in an identity=20=20 information exchange. The protocol should be inherently scalable,=20=20 requiring no centralized services, beyond those that already exist,=20=20 in order to operate. The security of a protocol is well understood within the IETF to be=20=20 the assurance of confidentiality and integrity of any transferred=20=20 information. But, in the context of digital identity we wish to also=20=20 be assured that user agents and relying parties maintain user privacy. Any solution should support multiple transport layers, but it is=20=20 anticipated that this working group will focus on a HTTP based=20=20 solution. In this case the user=92s software is a web browser, to which=20= =20 no modifications should be required, and the relying party would be a=20=20 website. Continuing with the theme of simplicity a website should=20=20 require minimal changes to support identity information exchange. For=20=20 example, a web form could receive information the same way that a=20=20 user would provide it, as if they typed it into the form themselves. In moving identity information between parties it is expected that=20=20 the messages of the protocol will include elements that bind property=20=20 names and values to digital identities. How a digital identity is=20=20 referred to is an important consideration. The properties an=20=20 identifier could have are that it allows the user to concurrently=20=20 maintain multiple personas, that it could allow for a separation=20=20 between the digital identity and the identifier and that it allow for=20=20 separation between the identifier and the user=92s agent. In the=20=20 interests of flexibility and interoperability we would suggest that=20=20 the identifier be a string of characters. This working group may=20=20 consider current best practice of what that string might be. For=20=20 example, a URL or a UUID. Work In Scope A user-centric, simple, secure, interoperable protocol for digital=20=20 identity information exchange. An advanced work item for this working group would be consideration=20=20 of how this protocol could operate over web services protocols (e.g.=20=20 SOAP, XML-RPC, REST), or interoperate with existing web services=20=20 protocols for security information (e.g. WS-Trust). The group must be=20=20 careful not to preclude interoperation at a later date. Although the data that represents the identity information is=20=20 expected to be opaque it is worth mentioning that the data could be=20=20 raw attributes of the digital identity, or could be third party=20=20 claims. A third party claim is signed by an authoritative source so=20=20 that the relying party can be assured of its authenticity. The=20=20 benefit of third party claims, as supported by this protocol, is that=20=20 the separation of claim acquisition from claim presentation provides=20=20 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 =96 BOF meeting June 2006 =96 First DIX Protocol Internet Draft June 2006 =96 First DIX HTTP Transport Binding Internet Draft July 2006 =96 Working Group meeting November 2006 =96 Working Group meeting December 2006 =96 Request Last Call for DIX Protocol December 2006 =96 Request Last Call for DIX HTTP Transport Binding March 2007 =96 Working Group meeting April 2007 =96 Submit DIX Protocol to IESG for consideration as=20=20 Proposed Standard April 2007 =96 Submit DIX HTTP Transport Binding to IESG for=20=20 consideration as Proposed Standard _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 21:08:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPEB-0001Fq-N4; Wed, 18 Jan 2006 21:08:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPEB-0001E0-2w for dix@megatron.ietf.org; Wed, 18 Jan 2006 21:08:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07021 for ; Wed, 18 Jan 2006 21:07:16 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzPMb-0002Tb-2Q for dix@ietf.org; Wed, 18 Jan 2006 21:17:26 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0J28adQ013647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 18:08:37 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601190139.UAA04599@ietf.org> References: <200601190139.UAA04599@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0FC97CC6-8579-4962-9C16-4F843463457E@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 18:08:25 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 5:39 PM, Suresh Venkatraman wrote: > The question was validation of the ID-server or "homesite" in DMD1 > terminology; as in does DIX provide a mechanism to validate or > assert that > the "homesite" is in fact who/what it says it is. This is probably > outside > the scope of DIX and is better left to the TLS/SSL layer. I think so. In dmd1 we have message verification, which just checks that a msg was sent from who says they sent them... which is no more secure than DNS. If you want assertions about the server identity then that's something you could layer on top. I think of that as 'Trust' though, maybe you don't. > >> Out of scope for how authentication is done... but in scope for how >> a membersite might require a certain level of authentication to be >> performed >> >> In dmd1 we don't specify any authentication mechanisms and we >> have the capabilities for declaring how auth could be done... and >> we have some thoughts around how a membersite could make >> assertions about its requirements. > > Is there a specific reason why negotiating the authentication > mechanism > should not be part of the protocol? Is it assumed that > authentication will > be addressed in the particular binding (HTTP, etc.)? We wouldn't > need to > make one up, just allow choice from the existing authentication > schemes. I think that it is part of the protocol. I'm saying that we don't define any authentication mechanisms, but we do allow the parties to say which they can do, and which they are willing to accept. In dmd1 a HS advertises it's capabilities, which might include the authentication mechanisms it supports, and a MS can decide whether to accept assertions from that HS or not. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 22:17:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQIX-00081m-6Q; Wed, 18 Jan 2006 22:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQIV-00081h-VS for dix@megatron.ietf.org; Wed, 18 Jan 2006 22:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11548 for ; Wed, 18 Jan 2006 22:15:49 -0500 (EST) Message-Id: <200601190315.WAA11548@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzQQv-0004ak-UT for dix@ietf.org; Wed, 18 Jan 2006 22:26:00 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc13) with SMTP id <20060119031700015009m87oe>; Thu, 19 Jan 2006 03:17:00 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 19:16:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYcnVDwqkuUuMivQyye+P6ogpDaqAAByfgg In-Reply-To: <0FC97CC6-8579-4962-9C16-4F843463457E@sxip.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > I think that it is part of the protocol. I'm saying that we don't define > any authentication mechanisms, but we do allow the parties to > say which they can do, and which they are willing to accept. > > In dmd1 a HS advertises it's capabilities, which might include > the authentication mechanisms it supports, and a MS can > decide whether to accept assertions from that HS or not. In DMD1 (Section 5.10.1.5) there is mention of an authentication requirement scenario but it kind of leaves negotiation out of the discussion. Unless you mean that member sites individually dictate authentication requirements every time a fetch-request is made? DMD1: dix://crypto-doodes.com/dongle#5 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of John Merrells Sent: Wednesday, January 18, 2006 6:08 PM To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions On 18-Jan-06, at 5:39 PM, Suresh Venkatraman wrote: > The question was validation of the ID-server or "homesite" in DMD1 > terminology; as in does DIX provide a mechanism to validate or > assert that > the "homesite" is in fact who/what it says it is. This is probably > outside > the scope of DIX and is better left to the TLS/SSL layer. I think so. In dmd1 we have message verification, which just checks that a msg was sent from who says they sent them... which is no more secure than DNS. If you want assertions about the server identity then that's something you could layer on top. I think of that as 'Trust' though, maybe you don't. > >> Out of scope for how authentication is done... but in scope for how >> a membersite might require a certain level of authentication to be >> performed >> >> In dmd1 we don't specify any authentication mechanisms and we >> have the capabilities for declaring how auth could be done... and >> we have some thoughts around how a membersite could make >> assertions about its requirements. > > Is there a specific reason why negotiating the authentication > mechanism > should not be part of the protocol? Is it assumed that > authentication will > be addressed in the particular binding (HTTP, etc.)? We wouldn't > need to > make one up, just allow choice from the existing authentication > schemes. I think that it is part of the protocol. I'm saying that we don't define any authentication mechanisms, but we do allow the parties to say which they can do, and which they are willing to accept. In dmd1 a HS advertises it's capabilities, which might include the authentication mechanisms it supports, and a MS can decide whether to accept assertions from that HS or not. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 22:27:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQSR-0002gq-0m; Wed, 18 Jan 2006 22:27:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQSP-0002gi-0U for dix@megatron.ietf.org; Wed, 18 Jan 2006 22:27:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12268 for ; Wed, 18 Jan 2006 22:26:01 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzQap-00050F-Ry for dix@ietf.org; Wed, 18 Jan 2006 22:36:13 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0J3RIx9015453 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 19:27:19 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601190315.WAA11548@ietf.org> References: <200601190315.WAA11548@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <260C35DA-B2AD-4926-9C91-1C2ECC4035BF@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: attribute assertions Date: Wed, 18 Jan 2006 19:27:12 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 7:16 PM, Suresh Venkatraman wrote: >> I think that it is part of the protocol. I'm saying that we don't >> define >> any authentication mechanisms, but we do allow the parties to >> say which they can do, and which they are willing to accept. >> >> In dmd1 a HS advertises it's capabilities, which might include >> the authentication mechanisms it supports, and a MS can >> decide whether to accept assertions from that HS or not. > > In DMD1 (Section 5.10.1.5) there is mention of an authentication > requirement > scenario but it kind of leaves negotiation out of the discussion. > Unless you > mean that member sites individually dictate authentication > requirements > every time a fetch-request is made? > > DMD1: dix://crypto-doodes.com/dongle#5 Yes and No. Yes the Membersite does it, but No it's not per message. It's per MS/HS relationship. When the MS discovers the HS capabilities (by pulling the HS Document and looking for the Homesite Tag) it can make a determination of whether the HS supports appropriate authentication methods or not. A per message solution is possible thus: In a fetch request the MS requests a claim from the HS that the authentication was performed using a particular method. DMD1 facilitates this, but doesn't define what property the MS would ask for, or what the claim would actually look like. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 23:03:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzR0n-0006HI-QU; Wed, 18 Jan 2006 23:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzR0m-0006HD-0l for dix@megatron.ietf.org; Wed, 18 Jan 2006 23:03:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14827 for ; Wed, 18 Jan 2006 23:01:32 -0500 (EST) Message-Id: <200601190401.XAA14827@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzR9E-0006A8-9r for dix@ietf.org; Wed, 18 Jan 2006 23:11:44 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc14) with SMTP id <20060119040249014001dsjoe>; Thu, 19 Jan 2006 04:02:49 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft proposed charter - consensus? Date: Wed, 18 Jan 2006 20:02:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYcm8eM8yaBLlFPQoSYRHJN79L+EgAC0EFA In-Reply-To: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org 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: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] 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 Scott Hollenbeck Mailing Lists: General Discussion: dix@ietf.org To Subscribe: dix-request@ietf.org 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 dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 18 23:30:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzRR3-00078p-AD; Wed, 18 Jan 2006 23:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzRR0-00078g-QX for dix@megatron.ietf.org; Wed, 18 Jan 2006 23:30:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16670 for ; Wed, 18 Jan 2006 23:28:38 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzRZR-00072g-Ag for dix@ietf.org; Wed, 18 Jan 2006 23:38:50 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0J4Tsx6016870 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 20:29:55 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601190401.XAA14827@ietf.org> References: <200601190401.XAA14827@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AF66666-5D4F-4518-BB1D-ED459931FAC5@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Wed, 18 Jan 2006 20:29:46 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 8:02 PM, Suresh Venkatraman wrote: > 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. On vocabulary... I don't mind what things are called just that we agree on what they are... which could be an endless debate. I used the terminology from this lexicon... even though I don't agree with all their definitions... http://www.identitygang.org/Lexicon Scenarios... There's aren't any in the charter. I think there's one example. I felt that one illustrative one would make the document more accessible. > Reputation Data - We should clarify this within the scenario... I'm happy to remove it... as the rest of the text is fine without it. A reasonable work item for a working group would be to document a set of motivating use cases to inform the decisions of the group. Would that be preferable? > 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. A good example for a draft. I'm sure others on the list have good ideas too. Not sure what we'd call this: 'Use Cases'? Or who'd write it? I'm kinda swamped myself. Suresh? Anyone? > Not to discount logging into weblogs but > non-HTTP scenarios are just as important. This protocol should not be > service specific. The draft proposed charter makes that clear doesn't it? "Any solution should support multiple transport layers, but it is anticipated that this working group will focus on a HTTP based solution. " How would you change that statement? > The HTTP binding spec is separate from the protocol spec (core). I > would > suggest removing this section of the charter (it's another scenario): I think we have to say there's going to be at least one transport... and HTTP is the most obvious one. I could call out this piece of text so that it's clear that it applies to the HTTP transport binding. > >> 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: I think that it is. Are you asking for an in-scope statement to that effect? >> The mechanisms by which authentication and authorization are >> performed. To me negotiation and mechanism are different things. Perhaps we are misunderstanding each other. For example: Authentication Mechanism: username / password Authentication Negotiation: HS to MS: 'I can authenticate using mechanisms: username-password, 2- factor device, dna test' MS to HS: 'Please authenticate the user with mechanism: 2-factor device.' Does that clarify that out of scope statement? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 00:16:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzS3f-0002xH-Gi; Thu, 19 Jan 2006 00:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzS3d-0002wk-Ph for dix@megatron.ietf.org; Thu, 19 Jan 2006 00:10:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19194 for ; Thu, 19 Jan 2006 00:08:34 -0500 (EST) Message-Id: <200601190508.AAA19194@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzSC6-0008PX-Up for dix@ietf.org; Thu, 19 Jan 2006 00:18:47 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc13) with SMTP id <20060119050951015009mbh6e>; Thu, 19 Jan 2006 05:09:51 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft proposed charter - consensus? Date: Wed, 18 Jan 2006 21:09:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYcsTKUE186Juj6T0uAxgFjBDvEGQAAhNmw In-Reply-To: <3AF66666-5D4F-4518-BB1D-ED459931FAC5@sxip.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > Scenarios... There's aren't any in the charter. I think there's one > example. > I felt that one illustrative one would make the document more > accessible. Yes, I meant examples - "For example, signing in to web pages and completing user registration forms." > A reasonable work item for a working group would be to document a set of > motivating use cases to inform the decisions of the group. Would that be > preferable? A use case document is a good for keeping the proposed WG on track - like the following for p2p-sip: http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.txt > To me negotiation and mechanism are different things. Perhaps we are > misunderstanding each other. For example: > > Authentication Mechanism: > > username / password > > Authentication Negotiation: > > HS to MS: 'I can authenticate using mechanisms: username-password, 2- > factor device, dna test' > MS to HS: 'Please authenticate the user with mechanism: 2-factor > device.' > Does that clarify that out of scope statement? Yes it does. I was looking at a couple of charters when I stated "simplicity" although the proper term may be clarity: http://www.xmpp.org/wg-charter.html http://www.ietf.org/html.charters/manet-charter.html -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of John Merrells Sent: Wednesday, January 18, 2006 8:30 PM To: Digital Identity Exchange Subject: Re: [dix] draft proposed charter - consensus? On 18-Jan-06, at 8:02 PM, Suresh Venkatraman wrote: > 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. On vocabulary... I don't mind what things are called just that we agree on what they are... which could be an endless debate. I used the terminology from this lexicon... even though I don't agree with all their definitions... http://www.identitygang.org/Lexicon Scenarios... There's aren't any in the charter. I think there's one example. I felt that one illustrative one would make the document more accessible. > Reputation Data - We should clarify this within the scenario... I'm happy to remove it... as the rest of the text is fine without it. A reasonable work item for a working group would be to document a set of motivating use cases to inform the decisions of the group. Would that be preferable? > 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. A good example for a draft. I'm sure others on the list have good ideas too. Not sure what we'd call this: 'Use Cases'? Or who'd write it? I'm kinda swamped myself. Suresh? Anyone? > Not to discount logging into weblogs but > non-HTTP scenarios are just as important. This protocol should not be > service specific. The draft proposed charter makes that clear doesn't it? "Any solution should support multiple transport layers, but it is anticipated that this working group will focus on a HTTP based solution. " How would you change that statement? > The HTTP binding spec is separate from the protocol spec (core). I > would > suggest removing this section of the charter (it's another scenario): I think we have to say there's going to be at least one transport... and HTTP is the most obvious one. I could call out this piece of text so that it's clear that it applies to the HTTP transport binding. > >> 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: I think that it is. Are you asking for an in-scope statement to that effect? >> The mechanisms by which authentication and authorization are >> performed. To me negotiation and mechanism are different things. Perhaps we are misunderstanding each other. For example: Authentication Mechanism: username / password Authentication Negotiation: HS to MS: 'I can authenticate using mechanisms: username-password, 2- factor device, dna test' MS to HS: 'Please authenticate the user with mechanism: 2-factor device.' Does that clarify that out of scope statement? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 00:23:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzSGX-0007ff-DX; Thu, 19 Jan 2006 00:23:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzSGV-0007fJ-VJ for dix@megatron.ietf.org; Thu, 19 Jan 2006 00:23:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19976 for ; Thu, 19 Jan 2006 00:21:54 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzSOw-0000LQ-Ri for dix@ietf.org; Thu, 19 Jan 2006 00:32:05 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0J5N8hE029618 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2006 21:23:09 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601190508.AAA19194@ietf.org> References: <200601190508.AAA19194@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BB86E86-9098-434E-B1BD-A19C45AB7C1D@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Wed, 18 Jan 2006 21:23:07 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 18-Jan-06, at 9:09 PM, Suresh Venkatraman wrote: > A use case document is a good for keeping the proposed WG on track > - like > the following for p2p-sip: > > http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.txt A nice piece of work. We did something similar in the LDUP WG. Should a use case draft be added to the charter milestones? I think it's worthy, but want to make sure there's sufficient interest from the group, and someone willing to step up to editing the draft. > I was looking at a couple of charters when I stated "simplicity" > although > the proper term may be clarity: > > http://www.xmpp.org/wg-charter.html > http://www.ietf.org/html.charters/manet-charter.html I could wordsmith the text so that the word 'simple' isn't used, but it seems like a worthy overriding goal to me. Maybe if I drill into what simple means? Simplicity in the order of... for the user, for the relying party, and finally for the agent implementor. (I think I offered that up an other email to this list earlier in the week.) (BTW: I agree that Agent and User Agent is unfortunate naming...) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 08:29:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZr1-0003kD-DZ; Thu, 19 Jan 2006 08:29:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZr0-0003jz-8E for dix@megatron.ietf.org; Thu, 19 Jan 2006 08:29:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22722 for ; Thu, 19 Jan 2006 08:28:03 -0500 (EST) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzZzT-0007dP-P9 for dix@ietf.org; Thu, 19 Jan 2006 08:38:20 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CB7B133C3F for ; Thu, 19 Jan 2006 13:29:09 +0000 (GMT) Message-ID: <43CF93AE.6010403@algroup.co.uk> Date: Thu, 19 Jan 2006 13:27:10 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft proposed charter - consensus? References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> In-Reply-To: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org John Merrells wrote: > An identity information exchange should involve just three parties: the > user, their agent, and a relying party. The user=92s agent is where the= y > authenticate themselves and a repository where they store their identit= y > information, and the relying party is an entity requesting identity > information. This seems overly prescriptive. In particular, it would appear to exclude any kind of temporary certificate. It also excludes proxies. Oh, and the case where authentication occurs elsewhere. --=20 http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 11:32:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzciH-0005Dp-HS; Thu, 19 Jan 2006 11:32:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzciF-0005Dk-IL for dix@megatron.ietf.org; Thu, 19 Jan 2006 11:32:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05021 for ; Thu, 19 Jan 2006 11:31:12 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezcqn-0004yL-Pa for dix@ietf.org; Thu, 19 Jan 2006 11:41:31 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id k0JGWRHp003757 for ; Thu, 19 Jan 2006 16:32:27 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 11:30:35 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Jan 2006 16:30:35 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 19 Jan 2006 11:32:26 -0500 Subject: Re: [dix] draft proposed charter - consensus? From: Peter Davis To: Digital Identity Exchange Message-ID: Thread-Topic: [dix] draft proposed charter - consensus? Thread-Index: AcYdFe6HLOwEGYkJEdq6NAANk3jHKA== In-Reply-To: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 19 Jan 2006 16:30:35.0069 (UTC) FILETIME=[AC688ED0:01C61D15] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > 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=B9s identity > information. Perhaps you mean management of the exchange of user attributes and authentication states between parties. 'managing identities' implies to my read as a sw which manages the storage of user data >=20 > Method >=20 > An identity information exchange should involve just three parties: > the user, their agent, and a relying party. The user=B9s 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. +1 on Ben's comment wrt this paragraph >=20 > 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=B9s software is a web browser, to which > no modifications should be required, Well, it's an HTTP client. > and the relying party would be a > website. Well, it's an HTTP aware server, which listens for HTPP messages. > 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. >=20 > 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=B9s 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. How about simply that it is in scope to establish a 'uniform addressing mechanism', such as a URI. =20 > Goals and Milestones: >=20 > March 2006 =AD BOF meeting Definitely need use cases milestone, IMHO =3Dpeterd _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 13:02:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eze75-0000KP-1k; Thu, 19 Jan 2006 13:02:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eze73-0000IP-QN for dix@megatron.ietf.org; Thu, 19 Jan 2006 13:02:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11795 for ; Thu, 19 Jan 2006 13:00:55 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzeFa-0007wG-3M for dix@ietf.org; Thu, 19 Jan 2006 13:11:13 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JI26Ck048647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 10:02:07 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43CF93AE.6010403@algroup.co.uk> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 10:01:58 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 5:27 AM, Ben Laurie wrote: > John Merrells wrote: >> An identity information exchange should involve just three=20=20 >> parties: the >> user, their agent, and a relying party. The user=92s agent is where=20= =20 >> they >> authenticate themselves and a repository where they store their=20=20 >> identity >> information, and the relying party is an entity requesting identity >> information. > > This seems overly prescriptive. In particular, it would appear to > exclude any kind of temporary certificate. It also excludes=20=20 > proxies. Oh, > and the case where authentication occurs elsewhere. Hey Ben, would you take the time to write up simple use cases for=20=20 your three points so that we (or at least I) can understand them? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 14:45:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezfig-0006TC-Ip; Thu, 19 Jan 2006 14:45:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezfif-0006T7-6m for dix@megatron.ietf.org; Thu, 19 Jan 2006 14:45:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21167 for ; Thu, 19 Jan 2006 14:43:50 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzfrE-0002s3-Qe for dix@ietf.org; Thu, 19 Jan 2006 14:54:10 -0500 Received: from [66.80.0.7] (dhcp-7.danastreet.live555.com [66.80.0.7]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JJj62w053407 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 11:45:08 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <7F9845D3-000E-474C-9822-0AB515F23589@sxip.com> Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 11:45:00 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> Goals and Milestones: >> >> March 2006 =96 BOF meeting > > Definitely need use cases milestone, IMHO There seems to be plenty of support for this. I've added a 'Dix Use Cases ID' milestone. John =20=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 14:54:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfrM-0001t7-QI; Thu, 19 Jan 2006 14:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfrL-0001rS-Hd for dix@megatron.ietf.org; Thu, 19 Jan 2006 14:54:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21731 for ; Thu, 19 Jan 2006 14:52:48 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezfzv-000387-9f for dix@ietf.org; Thu, 19 Jan 2006 15:03:08 -0500 Received: from [66.80.0.7] (dhcp-7.danastreet.live555.com [66.80.0.7]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JJs5WA053816 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 11:54:06 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <7AC79753-6E85-447A-9C04-A1B43F3E4546@sxip.com> Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 11:53:58 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> >> 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=92s software is a web browser, to which >> no modifications should be required, > Well, it's an HTTP client. > >> and the relying party would be a >> website. > > Well, it's an HTTP aware server, which listens for HTPP messages. Rewritten this paragraph so that it's more formal: Any solution should support multiple transport layers, but it is=20=20 anticipated that this working group will focus on a HTTP based=20=20 solution. In this case the user=92s software is a HTTP client, to which=20= =20 no modifications should be required, and the relying party would be a=20=20 HTTP server. Continuing with the theme of simplicity a HTTP server=20=20 should require minimal changes to support identity information=20=20 exchange. For example, a HTML form could receive information the same=20=20 way that a user would provide it, as if they typed it into the form=20=20 themselves. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 15:07:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg3k-00052u-Dq; Thu, 19 Jan 2006 15:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg3j-00052p-5t for dix@megatron.ietf.org; Thu, 19 Jan 2006 15:07:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22628 for ; Thu, 19 Jan 2006 15:05:36 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgCJ-0003Y1-0U for dix@ietf.org; Thu, 19 Jan 2006 15:15:56 -0500 Received: from [66.80.0.7] (dhcp-7.danastreet.live555.com [66.80.0.7]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JK6rJd054338 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 12:06:53 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <994C3820-8371-4896-9F55-280276DF94CF@sxip.com> Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 12:06:46 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> 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=92s identity >> information. > Perhaps you mean management of the exchange of user attributes and > authentication states between parties. 'managing identities'=20=20 > implies to my > read as a sw which manages the storage of user data A subtle point, but a good one. It will enable 'storage of', but that's not the only thing, and not the main thing. How about... "The goal of this group is to specify a protocol for moving identity=20=20 information between parties and a system architecture that enables=20=20 the development of software agents to manage _the_exchange_of_ a=20=20 user=92s identity information." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 15:17:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgDe-0000A9-O1; Thu, 19 Jan 2006 15:17:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgDd-000093-5Y for dix@megatron.ietf.org; Thu, 19 Jan 2006 15:17:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23452 for ; Thu, 19 Jan 2006 15:15:50 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgME-0003rv-4S for dix@ietf.org; Thu, 19 Jan 2006 15:26:10 -0500 Received: from [66.80.0.7] (dhcp-7.danastreet.live555.com [66.80.0.7]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JKH8ce054587 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 12:17:08 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 12:17:00 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> 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=92s 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. > > How about simply that it is in scope to establish a 'uniform=20=20 > addressing > mechanism', such as a URI. To which piece of the above does that apply? The last three sentences? The term 'addressing' worries me a little. That might just be a knee jerk reaction from me though, based on my LDAP experience. A key aspect of any information/data model is the separation between addressing things and identifying things. In LDAP the DN was both, which caused me lots of pain trying to solve the distribution and replication problems... which lead to adding the entryUUID attribute, so that we had immutable names for entries.... (I could ramble on for hours about that...) I'd be happier with 'uniform naming mechanism', which could be a URI... people may want something other than an URI. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 15:46:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezgg3-0007Cs-J4; Thu, 19 Jan 2006 15:46:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezgg1-0007Cj-V7 for dix@megatron.ietf.org; Thu, 19 Jan 2006 15:46:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25565 for ; Thu, 19 Jan 2006 15:45:10 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezgoc-0004qF-OJ for dix@ietf.org; Thu, 19 Jan 2006 15:55:31 -0500 Received: from [66.80.0.7] (dhcp-7.danastreet.live555.com [66.80.0.7]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JKkStx055512 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 12:46:28 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Thu, 19 Jan 2006 12:46:21 -0800 X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Subject: [dix] draft of proposed charter (#2) X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Reworked to take into account the comments received so far. There's=20=20 still a couple of outstanding comments... and am waiting for those threads to=20=20 close out... today I hope :-) John ---- Proposed Charter for DIX Working Group Digital Identity Exchange - DIX Chairs TBD Applciations Area Director(s): Ted Hardie Scott Hollenbeck Mailing Lists: General Discussion: dix@ietf.org To Subscribe: dix-request@ietf.org 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=20=20 Exchange protocol. DIX is an Internet scale protocol for exchanging=20=20 identity information between endpoints. The protocol architecture=20=20 maintains a separation of control between all parties of the exchange=20=20 and supports both compartmentalized and anonymous identities. Problem Statement The success of the Internet has led to a multitude of online=20=20 information sources and services. A consequence of this has been the=20=20 increasing demand for users to identify themselves and to provide=20=20 information about them. The user is currently bearing the burden of=20=20 managing their authentication credentials and is repeatedly having to=20=20 provide their identity information. For example, signing in to web=20=20 pages and completing user registration forms. Goal The goal of this group is to specify a protocol for moving identity=20=20 information between parties and a system architecture that enables=20=20 the development of software agents to manage the exchange of a user=92s=20= =20 identity information. Method An identity information exchange should involve just three parties:=20=20 the user, their agent, and a relying party. The user=92s agent is where=20= =20 they authenticate themselves and a repository where they store their=20=20 identity information, and the relying party is an entity requesting=20=20 identity information. The protocol should be both simple and secure. Simple meaning that=20=20 minimal modifications should be required to the user=92s software and=20=20 the relying party=92s software to participate in an identity=20=20 information exchange. The protocol should be inherently scalable,=20=20 requiring no centralized services, beyond those that already exist,=20=20 in order to operate. The security of a protocol is well understood within the IETF to be=20=20 the assurance of confidentiality and integrity of any transferred=20=20 information. But, in the context of digital identity we wish to also=20=20 be assured that user=92s agents and relying parties maintain user privacy. Any solution should support multiple transport layers, including, but=20=20 not limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that=20=20 this working group will initially focus on a HTTP based solution. In moving identity information between parties it is expected that=20=20 the messages of the protocol will include elements that bind property=20=20 names and values to digital identities. How a digital identity is=20=20 referred to is an important consideration. The properties an=20=20 identifier could have are that it allows the user to concurrently=20=20 maintain multiple personas, that it could allow for a separation=20=20 between the digital identity and the identifier and that it allow for=20=20 separation between the identifier and the user=92s agent. In the=20=20 interests of flexibility and interoperability we would suggest that=20=20 the identifier be a string of characters. This working group may=20=20 consider current best practice of what that string might be. For=20=20 example, a URI, a URL or a UUID. Work In Scope A user-centric, simple, secure, interoperable protocol for digital=20=20 identity information exchange. An advanced work item for this working group would be consideration=20=20 of how this protocol could operate over web services protocols (e.g.=20=20 SOAP, XML-RPC, REST), or interoperate with existing web services=20=20 protocols for security information (e.g. WS-Trust). The group must be=20=20 careful not to preclude interoperation at a later date. Although the data that represents the identity information is=20=20 expected to be opaque it is worth mentioning that the data could be=20=20 raw attributes of the digital identity, or could be third party=20=20 claims. A third party claim is signed by an authoritative source so=20=20 that the relying party can be assured of its authenticity. The=20=20 benefit of third party claims, as supported by this protocol, is that=20=20 the separation of claim acquisition from claim presentation provides=20=20 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. The schema and type system for identity information. Internet Drafts The Working Group anticipates the authoring of at least three=20=20 Internet Drafts, two of which are expected to be Standards Track=20=20 documents. DIX Use Cases =96 A catalogue of DIX protocol use cases to illustrate=20=20 the problem being solved and to inform the decision making of the=20=20 Working group. For example, an illustrative use case would be a=20=20 website that accepts user generated content. A significant problem=20=20 exists today that these sites attract the attention of spammers. The=20=20 DIX protocol would allow that website to determine the identity of=20=20 the submitter. A potential solution to the spam problem would be for=20=20 the website to check that the submitter is of good standing in their=20=20 community. In other words, the website would request the reputation=20=20 of the submitter. The DIX protocol would allow that reputation data=20=20 to be built up, aggregated, and moved between around. DIX Protocol =96 A description of the DIX protocol. DIX HTTP Transport Binding =96 How the DIX protocol will be mapped down=20= =20 onto HTTP as a transport layer. In this case the user=92s software is a=20= =20 HTTP client, to which no modifications should be required, and the=20=20 relying party would be a HTTP server. Continuing with the theme of=20=20 simplicity a HTTP server should require minimal changes to support=20=20 identity information exchange. For example, a HTML form could receive=20=20 information the same way that a user would provide it, as if they=20=20 typed it into the form themselves. Goals and Milestones: March 2006 =96 BOF meeting April 2006 =96 DIX Use Cases Internet Draft June 2006 =96 First DIX Protocol Internet Draft June 2006 =96 First DIX HTTP Transport Binding Internet Draft July 2006 =96 Working Group meeting November 2006 =96 Working Group meeting December 2006 =96 Request Last Call for DIX Protocol December 2006 =96 Request Last Call for DIX HTTP Transport Binding March 2007 =96 Working Group meeting April 2007 =96 Submit DIX Protocol to IESG for consideration as=20=20 Proposed Standard April 2007 =96 Submit DIX HTTP Transport Binding to IESG for=20=20 consideration as Proposed Standard _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 17:04:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhtG-0002VJ-08; Thu, 19 Jan 2006 17:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhtE-0002VE-D6 for dix@megatron.ietf.org; Thu, 19 Jan 2006 17:04:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01278 for ; Thu, 19 Jan 2006 17:02:52 -0500 (EST) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezi1p-0007Nq-9k for dix@ietf.org; Thu, 19 Jan 2006 17:13:14 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 00CA833C1C for ; Thu, 19 Jan 2006 22:04:13 +0000 (GMT) Message-ID: <43D00C67.8080807@algroup.co.uk> Date: Thu, 19 Jan 2006 22:02:15 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft proposed charter - consensus? References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> In-Reply-To: <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Dick Hardt wrote: > On 19-Jan-06, at 5:27 AM, Ben Laurie wrote: >=20 >> John Merrells wrote: >>> An identity information exchange should involve just three parties: t= he >>> user, their agent, and a relying party. The user=92s agent is where t= hey >>> authenticate themselves and a repository where they store their ident= ity >>> information, and the relying party is an entity requesting identity >>> information. >> >> This seems overly prescriptive. In particular, it would appear to >> exclude any kind of temporary certificate. It also excludes proxies. O= h, >> and the case where authentication occurs elsewhere. >=20 > Hey Ben, would you take the time to write up simple use cases for your > three points so that we (or at least I) can understand them? Temporary certificate This is to satisfy the minimality requirement. User has cert including date of birth, say, and wants to prove he's over 21. So, he (or his agent) shows the cert to some CA that produces a temporary cert for him saying he's over 21, which he or his agent then shows to the relying part= y. Note that this only half gets you unlinkability if the certs are anything conventional because the CA can link the permanent and temporary certs. The CA is, of course, a fourth party in the transaction. Proxy Not sure exactly what to say about this, except that a proxy could sit between any of these parties, and the language above assumes that it can do so both transparently and securely. Which may not be so (that is, it may have to be non-transparent to remain secure) if it adds functionality, like caching, or anonymising. Authentication Elsewhere It may turn out that for whatever reason I have to use multiple agents, so I'd like to authenticate them via my meta-agent. Unlinkably. Cheers, Ben. --=20 http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 17:16:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi53-0006xB-4K; Thu, 19 Jan 2006 17:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi51-0006w6-GU for dix@megatron.ietf.org; Thu, 19 Jan 2006 17:16:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02420 for ; Thu, 19 Jan 2006 17:15:03 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EziDa-0007nz-Qu for dix@ietf.org; Thu, 19 Jan 2006 17:25:25 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0JMGJ8c058062 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 14:16:20 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D00C67.8080807@algroup.co.uk> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 14:16:12 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 2:02 PM, Ben Laurie wrote: > Dick Hardt wrote: >> On 19-Jan-06, at 5:27 AM, Ben Laurie wrote: >> >>> John Merrells wrote: >>>> An identity information exchange should involve just three=20=20 >>>> parties: the >>>> user, their agent, and a relying party. The user=92s agent is=20=20 >>>> where they >>>> authenticate themselves and a repository where they store their=20=20 >>>> identity >>>> information, and the relying party is an entity requesting identity >>>> information. >>> >>> This seems overly prescriptive. In particular, it would appear to >>> exclude any kind of temporary certificate. It also excludes=20=20 >>> proxies. Oh, >>> and the case where authentication occurs elsewhere. >> >> Hey Ben, would you take the time to write up simple use cases for=20=20 >> your >> three points so that we (or at least I) can understand them? > > Temporary certificate > > This is to satisfy the minimality requirement. User has cert including > date of birth, say, and wants to prove he's over 21. So, he (or his > agent) shows the cert to some CA that produces a temporary cert for=20=20 > him > saying he's over 21, which he or his agent then shows to the=20=20 > relying party. > > Note that this only half gets you unlinkability if the certs are > anything conventional because the CA can link the permanent and > temporary certs. > > The CA is, of course, a fourth party in the transaction. I understand this one. > > Proxy > > Not sure exactly what to say about this, except that a proxy could sit > between any of these parties, and the language above assumes that=20=20 > it can > do so both transparently and securely. Which may not be so (that=20=20 > is, it > may have to be non-transparent to remain secure) if it adds > functionality, like caching, or anonymising. I understand what you are saying here as well (proxy has a number of=20=20 meanings) > > Authentication Elsewhere > > It may turn out that for whatever reason I have to use multiple=20=20 > agents, > so I'd like to authenticate them via my meta-agent. Unlinkably. I would say that the meta-agent is your agent. I think that John's identity exchange description above needs fleshed=20=20 out some more. The obvious missing party that *may* be in the transaction is a 3rd=20=20 party making a claim about the user, that is part of the transaction=20=20 when viewed holistically. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 17:26:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EziEa-0001k6-NT; Thu, 19 Jan 2006 17:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EziEY-0001jz-HN for dix@megatron.ietf.org; Thu, 19 Jan 2006 17:26:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03365 for ; Thu, 19 Jan 2006 17:24:55 -0500 (EST) Message-Id: <200601192224.RAA03365@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EziNA-0008BE-DL for dix@ietf.org; Thu, 19 Jan 2006 17:35:16 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc14) with SMTP id <20060119222611014001dnm5e>; Thu, 19 Jan 2006 22:26:11 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 14:25:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYdObTIGBV3mJM+QPGnwCbrjus0gwACzYew In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > 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. Suggested Change: The protocol should be both simple to implement and secure. > Any solution should support multiple transport layers, including, but > not limited to: HTTP, SOAP, XMPP, and SIP. Not to quibble but I don't consider SOAP to be a transport protocol but a messaging protocol. OTOH I could see SOAP, as a message envelope format, to be used within one of the mentioned transport protocols. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of John Merrells Sent: Thursday, January 19, 2006 12:46 PM To: Digital Identity Exchange Subject: [dix] draft of proposed charter (#2) Reworked to take into account the comments received so far. There's still a couple of outstanding comments... and am waiting for those threads to close out... today I hope :-) John ---- Proposed Charter for DIX Working Group Digital Identity Exchange - DIX Chairs TBD Applciations Area Director(s): Ted Hardie Scott Hollenbeck Mailing Lists: General Discussion: dix@ietf.org To Subscribe: dix-request@ietf.org 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. 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 the exchange of 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's agents and relying parties maintain user privacy. Any solution should support multiple transport layers, including, but not limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this working group will initially focus on a HTTP based solution. 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 URI, 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. The schema and type system for identity information. Internet Drafts The Working Group anticipates the authoring of at least three Internet Drafts, two of which are expected to be Standards Track documents. DIX Use Cases - A catalogue of DIX protocol use cases to illustrate the problem being solved and to inform the decision making of the Working group. For example, an illustrative use case would be a website that accepts user generated content. A significant problem exists today that these sites attract the attention of spammers. The DIX protocol would allow that website to determine the identity of the submitter. A potential solution to the spam problem would be for the website to check that the submitter is of good standing in their community. In other words, the website would request the reputation of the submitter. The DIX protocol would allow that reputation data to be built up, aggregated, and moved between around. DIX Protocol - A description of the DIX protocol. DIX HTTP Transport Binding - How the DIX protocol will be mapped down 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 relying 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. Goals and Milestones: March 2006 - BOF meeting April 2006 - DIX Use Cases Internet Draft 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 dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 20:27:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezl3v-0008Jz-GX; Thu, 19 Jan 2006 20:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezl3t-0008Jm-Pl for dix@megatron.ietf.org; Thu, 19 Jan 2006 20:27:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18932 for ; Thu, 19 Jan 2006 20:26:07 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlCW-00067N-FV for dix@ietf.org; Thu, 19 Jan 2006 20:36:29 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K1ROY0066382 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 17:27:24 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601192224.RAA03365@ietf.org> References: <200601192224.RAA03365@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0031F2C8-6858-4AB7-8A01-859C74502565@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 17:27:22 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 2:25 PM, Suresh Venkatraman wrote: >> 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. > > Suggested Change: The protocol should be both simple to implement and > secure. Doesn't the following sentence mean 'simple to implement' though? And so change that to.... 'Simple to implement' 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. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 20:29:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezl5J-0008W0-S3; Thu, 19 Jan 2006 20:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezl5I-0008V9-7o for dix@megatron.ietf.org; Thu, 19 Jan 2006 20:29:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19083 for ; Thu, 19 Jan 2006 20:27:33 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlDu-0006BI-HS for dix@ietf.org; Thu, 19 Jan 2006 20:37:56 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K1Su81066412 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 17:28:56 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601192224.RAA03365@ietf.org> References: <200601192224.RAA03365@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 17:28:54 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 2:25 PM, Suresh Venkatraman wrote: >> Any solution should support multiple transport layers, including, but >> not limited to: HTTP, SOAP, XMPP, and SIP. > > Not to quibble but I don't consider SOAP to be a transport protocol > but a > messaging protocol. OTOH I could see SOAP, as a message envelope > format, to > be used within one of the mentioned transport protocols. How about... "Any solution should support multiple transport and messaging protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. " ...? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 20:38:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlEC-0003FE-4R; Thu, 19 Jan 2006 20:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlEB-0003Es-Db for dix@megatron.ietf.org; Thu, 19 Jan 2006 20:38:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19836 for ; Thu, 19 Jan 2006 20:36:44 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlMl-0006Ud-Hi for dix@ietf.org; Thu, 19 Jan 2006 20:47:06 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K1bwuO066772 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 17:37:59 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <0031F2C8-6858-4AB7-8A01-859C74502565@sxip.com> References: <200601192224.RAA03365@ietf.org> <0031F2C8-6858-4AB7-8A01-859C74502565@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 17:37:57 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 5:27 PM, John Merrells wrote: > > On 19-Jan-06, at 2:25 PM, Suresh Venkatraman wrote: > >>> 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. >> >> Suggested Change: The protocol should be both simple to implement and >> secure. > > Doesn't the following sentence mean 'simple to implement' though? > And so change that to.... > > 'Simple to implement' 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. (replying to my own post - sigh how sad) Making it scan... "Simple in terms of implementation in that minimal modifications should be required to the user's software and the relying party's software to participate in an identity information exchange." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 20:49:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlPG-0006gO-SY; Thu, 19 Jan 2006 20:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlPF-0006gJ-LF for dix@megatron.ietf.org; Thu, 19 Jan 2006 20:49:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20865 for ; Thu, 19 Jan 2006 20:48:10 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlXs-0006w9-Br for dix@ietf.org; Thu, 19 Jan 2006 20:58:33 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K1nQGf067122 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 17:49:27 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <290875BB-DE54-4E96-B02A-AEC26215F94F@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 17:49:21 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 2:16 PM, Dick Hardt wrote: >> Temporary certificate >> >> This is to satisfy the minimality requirement. User has cert >> including >> date of birth, say, and wants to prove he's over 21. So, he (or his >> agent) shows the cert to some CA that produces a temporary cert >> for him >> saying he's over 21, which he or his agent then shows to the >> relying party. >> >> Note that this only half gets you unlinkability if the certs are >> anything conventional because the CA can link the permanent and >> temporary certs. >> >> The CA is, of course, a fourth party in the transaction. > > I understand this one. I think of that as two transactions. One to acquire the claim, the other to present the claim, even if the claim if thrown away after it's presented. But I can see why my wording appears to exclude that. >> >> Proxy >> >> Not sure exactly what to say about this, except that a proxy could >> sit >> between any of these parties, and the language above assumes that >> it can >> do so both transparently and securely. Which may not be so (that >> is, it >> may have to be non-transparent to remain secure) if it adds >> functionality, like caching, or anonymising. > > I understand what you are saying here as well (proxy has a number > of meanings) Yeah... I just assumed that was part of the infrastructure that the protocol ran over... so I should call that out. >> >> Authentication Elsewhere >> >> It may turn out that for whatever reason I have to use multiple >> agents, >> so I'd like to authenticate them via my meta-agent. Unlinkably. > > I would say that the meta-agent is your agent. Yeah. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 21:09:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezlib-0005z3-Ua; Thu, 19 Jan 2006 21:09:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezlia-0005yG-F7 for dix@megatron.ietf.org; Thu, 19 Jan 2006 21:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22714 for ; Thu, 19 Jan 2006 21:08:09 -0500 (EST) Received: from toad.mtbrook.bozemanpass.com ([69.145.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlrC-0007hF-Gk for dix@ietf.org; Thu, 19 Jan 2006 21:18:32 -0500 Received: from [69.145.82.218] (unknown [69.145.82.218]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id A27D8110394 for ; Thu, 19 Jan 2006 18:08:59 -0800 (PST) Message-ID: <43D0463F.6020500@boreham.org> Date: Thu, 19 Jan 2006 19:09:03 -0700 From: David Boreham User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) References: <200601192224.RAA03365@ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david_list@boreham.org, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > "Any solution should support multiple transport and messaging > protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. " I've been wondering about the semantics behind this thread. To me, this means things like 'I want my SIP phone to party with this new widely deployed identidy framework'. Is that the same as 'support SIP as a transport' ? I'm not sure, since for example you might want to use existing protocol already used in SIP for authentication, but have the PBX (or whatever is being the SIP gateway) use DIX. In that case the PBX would use HTTP transport, wouldn't it ? Put another way, is this statement above the same as saying 'support user agents or clients using multiple ... protocols... ' ? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 21:39:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmBH-0008MT-ES; Thu, 19 Jan 2006 21:39:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmBG-0008L6-0p for dix@megatron.ietf.org; Thu, 19 Jan 2006 21:39:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25255 for ; Thu, 19 Jan 2006 21:37:46 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmJs-0000Bx-Sk for dix@ietf.org; Thu, 19 Jan 2006 21:48:10 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K2cwPi068627 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 19 Jan 2006 18:38:59 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D0463F.6020500@boreham.org> References: <200601192224.RAA03365@ietf.org> <43D0463F.6020500@boreham.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 18:38:56 -0800 To: david_list@boreham.org, Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 6:09 PM, David Boreham wrote: >> "Any solution should support multiple transport and messaging >> protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. " > > I've been wondering about the semantics behind this thread. > To me, this means things like 'I want my SIP phone to party with this > new widely deployed identidy framework'. Is that the same as > 'support SIP as a transport' ? I'm not sure, since for example you > might want to use existing protocol already used in SIP for > authentication, but have the PBX (or whatever is being the SIP > gateway) > use DIX. In that case the PBX would use HTTP transport, > wouldn't it ? Good question. I didn't bring up SIP as a transport myself, but to me this means that I might want to send DIX messages over SIP. Why would I do that... we'd need a use case... not really knowing anything about SIP i'm not very well qualified to say ... but I might be on a call to a call center and they ask me to prove something about me... right now they ask a bunch of questions... SSN, MMN, DOB... with DIX over SIP they might be able to send the request to my client and assuming it had the appropriate interface (ie capabilities) it could ask me if i wanted to reveal that identity information... i'd click yes and it'd be revealed. Which sounds quite nice to me. > Put another way, is this statement above the same as saying > 'support user agents or clients using multiple ... protocols... ' ? It's a given to me that any agent or client could implement any protocols it wanted to.... so i'm not trying to say that. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 21:43:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmF6-0000zZ-Lf; Thu, 19 Jan 2006 21:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmF5-0000zH-R8 for dix@megatron.ietf.org; Thu, 19 Jan 2006 21:43:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25545 for ; Thu, 19 Jan 2006 21:41:44 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmNk-0000JB-A1 for dix@ietf.org; Thu, 19 Jan 2006 21:52:08 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K2h8t2068995 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 19 Jan 2006 18:43:08 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D0463F.6020500@boreham.org> References: <200601192224.RAA03365@ietf.org> <43D0463F.6020500@boreham.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 18:43:06 -0800 To: david_list@boreham.org, Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 6:09 PM, David Boreham wrote: >> "Any solution should support multiple transport and messaging >> protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. " "Any solution should allow DIX messages to be carried over multiple alternative transport and messaging protocols, including, but not limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this working group will initially focus on a HTTP based solution." Hmm, almost as much weaseling as a legal document. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 21:48:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmJw-0002g0-2v; Thu, 19 Jan 2006 21:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmJv-0002fv-CQ for dix@megatron.ietf.org; Thu, 19 Jan 2006 21:48:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25834 for ; Thu, 19 Jan 2006 21:46:44 -0500 (EST) Message-Id: <200601200246.VAA25834@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmSZ-0000Qq-0G for dix@ietf.org; Thu, 19 Jan 2006 21:57:08 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc14) with SMTP id <20060120024759014001dteoe>; Fri, 20 Jan 2006 02:48:00 +0000 From: "Suresh Venkatraman" To: , "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 18:47:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYdZrb0I4v25gIKTN+iSCLPO6VyawAAjAng In-Reply-To: <43D0463F.6020500@boreham.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > To me, this means things like 'I want my SIP phone to party with this > new widely deployed identidy framework'. It could mean that your SIP phone authenticates itself before registering with a SIP proxy or making a call. The proxy could then verify such claims via the identity framework before making the connection. Or you could choose two-levels of authentication - but that kind of defeats the purpose of decoupling identity from services. > Is that the same as 'support SIP as a transport'? In the scenario above SIP could be used as the transport for the identity transactions. > I'm not sure, since for example you might want to use existing protocol > already used in SIP for authentication, but have the PBX (or whatever is > being the SIP gateway) use DIX. The same argument can be made for HTTP as with SIP, after all the authentication headers are the same. The SIP RFC leverages the HTTP/1.1 specification for syntax and semantics (WWW-Authenticate, Proxy-Authenticate, etc.). You're arguing in terms of the PSTN world and the current implementations of SIP that facilitate VoIP within those boundaries. There's certainly no limitation in the RFC for the scenario above. > Put another way, is this statement above the same as saying > 'support user agents or clients using multiple ... protocols... ' ? The point is not to the limit the types of UA's that support DIX based on the transport protocol. Every protocol binding is optional in the end. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of David Boreham Sent: Thursday, January 19, 2006 6:09 PM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) > "Any solution should support multiple transport and messaging > protocols, including but not limited to: HTTP, SOAP, XMPP, and SIP. " I've been wondering about the semantics behind this thread. To me, this means things like 'I want my SIP phone to party with this new widely deployed identidy framework'. Is that the same as 'support SIP as a transport' ? I'm not sure, since for example you might want to use existing protocol already used in SIP for authentication, but have the PBX (or whatever is being the SIP gateway) use DIX. In that case the PBX would use HTTP transport, wouldn't it ? Put another way, is this statement above the same as saying 'support user agents or clients using multiple ... protocols... ' ? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 21:49:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmLA-0003Lz-BO; Thu, 19 Jan 2006 21:49:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmL8-0003Lu-WC for dix@megatron.ietf.org; Thu, 19 Jan 2006 21:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25928 for ; Thu, 19 Jan 2006 21:47:58 -0500 (EST) Received: from eastrmmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmTk-0000T9-7Z for dix@ietf.org; Thu, 19 Jan 2006 21:58:22 -0500 Received: from charger ([68.100.55.187]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060120024921.VKYA14098.eastrmmtao05.cox.net@charger> for ; Thu, 19 Jan 2006 21:49:21 -0500 From: "Scott Hollenbeck" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 21:49:15 -0500 Message-ID: <000f01c61d6c$1a2b8110$0623520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: Thread-Index: AcYda4LPZbUgatBESpa4rZS7OI0zDgAADg8Q X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > -----Original Message----- > From: John Merrells [mailto:merrells@sxip.com] > Sent: Thursday, January 19, 2006 9:43 PM > To: david_list@boreham.org; Digital Identity Exchange > Subject: Re: [dix] draft of proposed charter (#2) > > > On 19-Jan-06, at 6:09 PM, David Boreham wrote: > > >> "Any solution should support multiple transport and messaging > >> protocols, including but not limited to: HTTP, SOAP, XMPP, > and SIP. " > > > "Any solution should allow DIX messages to be carried over > multiple alternative transport and messaging protocols, > including, but not limited to: HTTP, SOAP, XMPP, and SIP. It > is anticipated that this working group will initially focus > on a HTTP based solution." > > Hmm, almost as much weaseling as a legal document. John, I would suggest that your charter should describe a need to specify at least one "mandatory to implement" transport/messaging protocol to ensure a minimal level of interoperability. I don't care if you use weasel words now to avoid picking one at charter time, but you should commit to settling on one. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 22:00:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmVj-0006wh-UC; Thu, 19 Jan 2006 22:00:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmVh-0006v4-UD for dix@megatron.ietf.org; Thu, 19 Jan 2006 22:00:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26592 for ; Thu, 19 Jan 2006 21:58:54 -0500 (EST) Message-Id: <200601200258.VAA26592@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmeM-0000oG-GB for dix@ietf.org; Thu, 19 Jan 2006 22:09:18 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc11) with SMTP id <2006012003001101300cjf8ue>; Fri, 20 Jan 2006 03:00:11 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 18:59:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYda4LPZbUgatBESpa4rZS7OI0zDgAADg8QAAAsGBA= In-Reply-To: <000f01c61d6c$1a2b8110$0623520a@charger> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > John, I would suggest that your charter should describe a need to specify > at least one "mandatory to implement" transport/messaging protocol to > ensure a minimal level of interoperability. I don't care if you use > weasel words now to avoid picking one at charter time, but you should > commit to settling on one. I agree and disagree - the core of DIX will be transport independent. The only spec'd binding in the charter is for HTTP, therefore there is a "minimal level of interoperability" for the first set of implementations by virtue of having only one spec'd binding. After that there will be specs for other bindings and there's no reason why different identity realms can't implement their own bindings or all the bindings (HTTP - Web Apps, SIP - VoIP, XMPP - IM, etc,). -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Scott Hollenbeck Sent: Thursday, January 19, 2006 6:49 PM To: 'Digital Identity Exchange' Subject: RE: [dix] draft of proposed charter (#2) > -----Original Message----- > From: John Merrells [mailto:merrells@sxip.com] > Sent: Thursday, January 19, 2006 9:43 PM > To: david_list@boreham.org; Digital Identity Exchange > Subject: Re: [dix] draft of proposed charter (#2) > > > On 19-Jan-06, at 6:09 PM, David Boreham wrote: > > >> "Any solution should support multiple transport and messaging > >> protocols, including but not limited to: HTTP, SOAP, XMPP, > and SIP. " > > > "Any solution should allow DIX messages to be carried over > multiple alternative transport and messaging protocols, > including, but not limited to: HTTP, SOAP, XMPP, and SIP. It > is anticipated that this working group will initially focus > on a HTTP based solution." > > Hmm, almost as much weaseling as a legal document. John, I would suggest that your charter should describe a need to specify at least one "mandatory to implement" transport/messaging protocol to ensure a minimal level of interoperability. I don't care if you use weasel words now to avoid picking one at charter time, but you should commit to settling on one. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 22:10:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmfH-0000aQ-TA; Thu, 19 Jan 2006 22:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmfG-0000ZE-28 for dix@megatron.ietf.org; Thu, 19 Jan 2006 22:10:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27284 for ; Thu, 19 Jan 2006 22:08:46 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezmnu-0001AG-GR for dix@ietf.org; Thu, 19 Jan 2006 22:19:10 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K3A50N069631 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 19:10:05 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601200258.VAA26592@ietf.org> References: <200601200258.VAA26592@ietf.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 19:10:03 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 6:59 PM, Suresh Venkatraman wrote: >> John, I would suggest that your charter should describe a need to >> specify >> at least one "mandatory to implement" transport/messaging protocol to >> ensure a minimal level of interoperability. I don't care if you use >> weasel words now to avoid picking one at charter time, but you should >> commit to settling on one. > > I agree and disagree - the core of DIX will be transport > independent. The > only spec'd binding in the charter is for HTTP, therefore there is a > "minimal level of interoperability" for the first set of > implementations by > virtue of having only one spec'd binding. After that there will be > specs for > other bindings and there's no reason why different identity realms > can't > implement their own bindings or all the bindings (HTTP - Web Apps, > SIP - > VoIP, XMPP - IM, etc,). I think Scott's point is that we mandate that the parties must implement one particular binding. I'm uneasy about this because there may be use cases where it doesn't make sense. There's two pieces to the protocol. agent to user - DIX over X user to relying party - DIX over Y In the internet phone use case we we're just talking about, X could be HTTP and Y could be SIP. So we can't really mandate that all three parties implement either HTTP or SIP. Hmm... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 22:34:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezn2X-0000Jz-7P; Thu, 19 Jan 2006 22:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezn2W-0000Jo-2p for dix@megatron.ietf.org; Thu, 19 Jan 2006 22:34:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28881 for ; Thu, 19 Jan 2006 22:32:48 -0500 (EST) Message-Id: <200601200332.WAA28881@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EznB9-0001rD-3U for dix@ietf.org; Thu, 19 Jan 2006 22:43:13 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc14) with SMTP id <20060120033403014001dmhfe>; Fri, 20 Jan 2006 03:34:03 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Thu, 19 Jan 2006 19:33:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYdbxIqurPV8jpFRl2v6vSdKVUDggAAqzmQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > I think Scott's point is that we mandate that the parties must > implement one particular binding. That's the part I was disagreeing with. I was just trying to pointing out that the first spec'd binding, HTTP, would allow for DIX to build traction and that we did not need to have a "mandatory" binding. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of John Merrells Sent: Thursday, January 19, 2006 7:10 PM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) On 19-Jan-06, at 6:59 PM, Suresh Venkatraman wrote: >> John, I would suggest that your charter should describe a need to >> specify >> at least one "mandatory to implement" transport/messaging protocol to >> ensure a minimal level of interoperability. I don't care if you use >> weasel words now to avoid picking one at charter time, but you should >> commit to settling on one. > > I agree and disagree - the core of DIX will be transport > independent. The > only spec'd binding in the charter is for HTTP, therefore there is a > "minimal level of interoperability" for the first set of > implementations by > virtue of having only one spec'd binding. After that there will be > specs for > other bindings and there's no reason why different identity realms > can't > implement their own bindings or all the bindings (HTTP - Web Apps, > SIP - > VoIP, XMPP - IM, etc,). I think Scott's point is that we mandate that the parties must implement one particular binding. I'm uneasy about this because there may be use cases where it doesn't make sense. There's two pieces to the protocol. agent to user - DIX over X user to relying party - DIX over Y In the internet phone use case we we're just talking about, X could be HTTP and Y could be SIP. So we can't really mandate that all three parties implement either HTTP or SIP. Hmm... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 23:12:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezndw-00069c-Ri; Thu, 19 Jan 2006 23:12:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezndu-00069X-Dq for dix@megatron.ietf.org; Thu, 19 Jan 2006 23:12:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02389 for ; Thu, 19 Jan 2006 23:11:25 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EznmX-0003GP-D4 for dix@ietf.org; Thu, 19 Jan 2006 23:21:50 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K4Cgrb070866 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 20:12:43 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <290875BB-DE54-4E96-B02A-AEC26215F94F@sxip.com> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> <290875BB-DE54-4E96-B02A-AEC26215F94F@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 20:12:40 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On the topic of three parties.... I think this covers the case of=20=20 authoritative sources of claims... and the possibility of proxy=20=20 services... "An identity information exchange should involve just three principal=20=20 parties: the user, their agent, and a third party. The user=92s agent=20=20 is where they authenticate themselves and a repository where they=20=20 store their identity information and the third party is a relying=20=20 party requesting identity information or an authoritative source=20=20 providing identity information. Non-principal parties may participate=20=20 in an information exchange by providing facilitating services, such=20=20 as proxying or caching." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 23:36:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezo0M-0007LZ-T5; Thu, 19 Jan 2006 23:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezo0K-0007LO-JC for dix@megatron.ietf.org; Thu, 19 Jan 2006 23:36:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03770 for ; Thu, 19 Jan 2006 23:34:36 -0500 (EST) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezo8y-0003uR-VV for dix@ietf.org; Thu, 19 Jan 2006 23:45:02 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id BD59C33C1C for ; Fri, 20 Jan 2006 04:36:01 +0000 (GMT) Message-ID: <43D0683B.9050908@algroup.co.uk> Date: Fri, 20 Jan 2006 04:34:03 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft proposed charter - consensus? References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Dick Hardt wrote: > > On 19-Jan-06, at 2:02 PM, Ben Laurie wrote: >> Authentication Elsewhere >> >> It may turn out that for whatever reason I have to use multiple agents, >> so I'd like to authenticate them via my meta-agent. Unlinkably. > > I would say that the meta-agent is your agent. Err, you have made the agent the place where you authenticate and the place where your stuff is stored, so you might like to, but you can't. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 19 23:55:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzoIw-0004qJ-9r; Thu, 19 Jan 2006 23:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzoIu-0004os-20 for dix@megatron.ietf.org; Thu, 19 Jan 2006 23:55:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05167 for ; Thu, 19 Jan 2006 23:53:47 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzoRY-0004cP-Am for dix@ietf.org; Fri, 20 Jan 2006 00:04:13 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K4t6aY071625 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 20:55:06 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D0683B.9050908@algroup.co.uk> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> <43D0683B.9050908@algroup.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DD2F2ED-E59C-4BC8-8D55-F85E087B0A58@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 20:55:04 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 8:34 PM, Ben Laurie wrote: > Dick Hardt wrote: >> >> On 19-Jan-06, at 2:02 PM, Ben Laurie wrote: >>> Authentication Elsewhere >>> >>> It may turn out that for whatever reason I have to use multiple >>> agents, >>> so I'd like to authenticate them via my meta-agent. Unlinkably. >> >> I would say that the meta-agent is your agent. > > Err, you have made the agent the place where you authenticate and the > place where your stuff is stored, so you might like to, but you can't. mmm... how about I add agency as a non-principal party... "Non-principal parties may participate in an information exchange by providing facilitating services, such as proxying, caching or agency." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 01:23:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzpgG-0008IK-IX; Fri, 20 Jan 2006 01:23:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzpgD-0008Df-EK for dix@megatron.ietf.org; Fri, 20 Jan 2006 01:23:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10434 for ; Fri, 20 Jan 2006 01:21:58 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezpop-0006zr-AR for dix@ietf.org; Fri, 20 Jan 2006 01:32:20 -0500 Received: from [192.168.1.106] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K6NBkW074241 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 22:23:12 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D0683B.9050908@algroup.co.uk> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> <43D0683B.9050908@algroup.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <062C16E3-8C12-4129-A877-EB1A44542C56@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 22:23:08 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 8:34 PM, Ben Laurie wrote: > Dick Hardt wrote: >> >> On 19-Jan-06, at 2:02 PM, Ben Laurie wrote: >>> Authentication Elsewhere >>> >>> It may turn out that for whatever reason I have to use multiple >>> agents, >>> so I'd like to authenticate them via my meta-agent. Unlinkably. >> >> I would say that the meta-agent is your agent. > > Err, you have made the agent the place where you authenticate and the > place where your stuff is stored, so you might like to, but you can't. Picky, picky -- and correct. Both are acting as agent though are they not? You may have your stuff stored in a few places. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 02:07:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqMe-0004pz-LN; Fri, 20 Jan 2006 02:07:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqMc-0004pt-JD for dix@megatron.ietf.org; Fri, 20 Jan 2006 02:07:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13963 for ; Fri, 20 Jan 2006 02:05:47 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzqVF-00008I-0x for dix@ietf.org; Fri, 20 Jan 2006 02:16:10 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Fri, 20 Jan 2006 00:06:53 -0700 Message-Id: <43D0D92F.A648.00B6.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Fri, 20 Jan 2006 00:05:59 -0700 From: "Haripriya S" To: "Digital Identity Exchange" Subject: Re: [dix] draft proposed charter - consensus? References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> à In-Reply-To: à Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I think the original wording - 'relying party' is more appropriate than 'third party' because a third-party does not actually tell me that the party has is a required entity in this transaction. Thanks, Haripriya S. >>> merrells@sxip.com 01/20/06 9:42 am >>> On the topic of three parties.... I think this covers the case of authoritative sources of claims... and the possibility of proxy services... "An identity information exchange should involve just three principal parties: the user, their agent, and a third party. The user's agent is where they authenticate themselves and a repository where they store their identity information and the third party is a relying party requesting identity information or an authoritative source providing identity information. Non- principal parties may participate in an information exchange by providing facilitating services, such as proxying or caching." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 02:24:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezqdh-0001l1-PF; Fri, 20 Jan 2006 02:24:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezqdf-0001jZ-0j for dix@megatron.ietf.org; Fri, 20 Jan 2006 02:24:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15321 for ; Fri, 20 Jan 2006 02:23:24 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzqmK-0000jO-Jn for dix@ietf.org; Fri, 20 Jan 2006 02:33:50 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K7OeG9075861 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 23:24:41 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D0D92F.A648.00B6.0@novell.com> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X <43D0D92F.A648.00B6.0@novell.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 23:24:39 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 11:05 PM, Haripriya S wrote: > I think the original wording - 'relying party' is more appropriate > than > 'third party' because a third-party does not actually tell me that the > party has is a required entity in this transaction. Yeah, 'relying party' was good, but as Ben pointed out (and Peter supported) that it didn't really cover the case of a party providing the user with some identity information, either an attribute value assertion or a digitally signed claim. A 'relying party', by the Identity Gang lexicon is a consumer rather than a producer of identity information. They use the term 'claimant' for something that creates claims.... I don't really like that very much, so wrote 'authoritative source' instead. Hopefully that explains why I'm proposing that change. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 02:37:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqpX-0006CW-Ht; Fri, 20 Jan 2006 02:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqpV-0006AI-Uu for dix@megatron.ietf.org; Fri, 20 Jan 2006 02:37:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16133 for ; Fri, 20 Jan 2006 02:35:39 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzqyA-00015L-SH for dix@ietf.org; Fri, 20 Jan 2006 02:46:05 -0500 Received: from [192.168.1.106] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K7atqi076162 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 23:36:55 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X <43D0D92F.A648.00B6.0@novell.com> <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <375741E0-AC6A-46AD-8C15-93CC704F8F97@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 23:36:52 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 11:24 PM, John Merrells wrote: > > On 19-Jan-06, at 11:05 PM, Haripriya S wrote: > >> I think the original wording - 'relying party' is more appropriate >> than >> 'third party' because a third-party does not actually tell me that >> the >> party has is a required entity in this transaction. > > Yeah, 'relying party' was good, but as Ben pointed out (and Peter > supported) that it didn't really cover the case of a party providing > the user with some identity information, either an attribute value > assertion or a digitally signed claim. A 'relying party', by the > Identity > Gang lexicon is a consumer rather than a producer of identity > information. They use the term 'claimant' for something that > creates claims.... I don't really like that very much, so wrote > 'authoritative source' instead. Hopefully that explains why I'm > proposing that change. I'm confused. Relying Party = Membersite Authorative Source = 3rd party = Authorative Site _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 02:40:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezqsu-0007ar-Ow; Fri, 20 Jan 2006 02:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezqst-0007am-Tm for dix@megatron.ietf.org; Fri, 20 Jan 2006 02:40:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16334 for ; Fri, 20 Jan 2006 02:39:09 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezr1Z-0001Ae-18 for dix@ietf.org; Fri, 20 Jan 2006 02:49:35 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K7eV7v076335 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 23:40:32 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <375741E0-AC6A-46AD-8C15-93CC704F8F97@sxip.com> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X <43D0D92F.A648.00B6.0@novell.com> <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> <375741E0-AC6A-46AD-8C15-93CC704F8F97@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 23:40:30 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 11:36 PM, Dick Hardt wrote: > I'm confused. > > Relying Party = Membersite > > Authorative Source = 3rd party = Authorative Site Yes, but I think that the same protocol can be used between the user's agent (homesite) and a relying party (membersite) or authoritative source (authoritative site). John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 02:44:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqwI-0008Lr-6X; Fri, 20 Jan 2006 02:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqwH-0008Kr-9u for dix@megatron.ietf.org; Fri, 20 Jan 2006 02:44:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16525 for ; Fri, 20 Jan 2006 02:42:38 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezr4y-0001G9-A5 for dix@ietf.org; Fri, 20 Jan 2006 02:53:04 -0500 Received: from [192.168.1.106] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K7hugQ076429 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 23:43:57 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X <43D0D92F.A648.00B6.0@novell.com> <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> <375741E0-AC6A-46AD-8C15-93CC704F8F97@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 23:43:54 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 11:40 PM, John Merrells wrote: > > On 19-Jan-06, at 11:36 PM, Dick Hardt wrote: > >> I'm confused. >> >> Relying Party = Membersite >> >> Authorative Source = 3rd party = Authorative Site > > Yes, but I think that the same protocol can be used between the > user's agent (homesite) and a relying party (membersite) or > authoritative source (authoritative site). When going from HS -> AS, the AS is really a MS. When going from AS -> HS (store), then it is an AS, and at that time is party to the transaction I think there is BIG value to us in AS being 3rd party and MS NOT being 3rd party -- as it clearly makes the AS not be part of the primary transaction -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 02:56:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezr8g-0003wx-AC; Fri, 20 Jan 2006 02:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezr8e-0003v7-3T for dix@megatron.ietf.org; Fri, 20 Jan 2006 02:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17838 for ; Fri, 20 Jan 2006 02:55:21 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzrHH-0001iK-5O for dix@ietf.org; Fri, 20 Jan 2006 03:05:47 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0K7ud8v076705 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Jan 2006 23:56:39 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X <43D0D92F.A648.00B6.0@novell.com> <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> <375741E0-AC6A-46AD-8C15-93CC704F8F97@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <261DF14E-5DC1-4DF5-B4FA-9A9F4F9A4B07@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Thu, 19 Jan 2006 23:56:37 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 11:43 PM, Dick Hardt wrote: > > On 19-Jan-06, at 11:40 PM, John Merrells wrote: > >> >> On 19-Jan-06, at 11:36 PM, Dick Hardt wrote: >> >>> I'm confused. >>> >>> Relying Party = Membersite >>> >>> Authorative Source = 3rd party = Authorative Site >> >> Yes, but I think that the same protocol can be used between the >> user's agent (homesite) and a relying party (membersite) or >> authoritative source (authoritative site). > > When going from HS -> AS, the AS is really a MS. > > When going from AS -> HS (store), then it is an AS, and at that > time is party to the transaction > > I think there is BIG value to us in AS being 3rd party and MS NOT > being 3rd party -- as it clearly makes the AS not be part of the > primary transaction Ah yes, 'Third Party' is commonly taken to refer to a party outside the transaction whom has given the first party something for presentation to the second party. Goodness this is fun. I'll ponder on an agreeable term for the second party. Oh, maybe that's the term? Maybe we define FP, SP, and TP... 1P, 2P, 3P... where 1P is the user's agent, 2P is the relying party, and 3P is the authoritative source. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 06:24:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzuNr-00050r-96; Fri, 20 Jan 2006 06:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzuNp-00050Y-L5 for dix@megatron.ietf.org; Fri, 20 Jan 2006 06:24:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02366 for ; Fri, 20 Jan 2006 06:23:17 -0500 (EST) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzuWU-0008F6-GS for dix@ietf.org; Fri, 20 Jan 2006 06:33:46 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4480034055 for ; Fri, 20 Jan 2006 11:24:38 +0000 (GMT) Message-ID: <43D0C800.5020802@algroup.co.uk> Date: Fri, 20 Jan 2006 11:22:40 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft proposed charter - consensus? References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> <43CF93AE.6010403@algroup.co.uk> <8333CCF0-C659-42F7-BBFB-8DEC91C895EF@sxip.com> <43D00C67.8080807@algroup.co.uk> <43D0683B.9050908@algroup.co.uk> <062C16E3-8C12-4129-A877-EB1A44542C56@sxip.com> In-Reply-To: <062C16E3-8C12-4129-A877-EB1A44542C56@sxip.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Dick Hardt wrote: > > On 19-Jan-06, at 8:34 PM, Ben Laurie wrote: > >> Dick Hardt wrote: >>> >>> On 19-Jan-06, at 2:02 PM, Ben Laurie wrote: >>>> Authentication Elsewhere >>>> >>>> It may turn out that for whatever reason I have to use multiple agents, >>>> so I'd like to authenticate them via my meta-agent. Unlinkably. >>> >>> I would say that the meta-agent is your agent. >> >> Err, you have made the agent the place where you authenticate and the >> place where your stuff is stored, so you might like to, but you can't. > > Picky, picky -- and correct. Both are acting as agent though are they > not? You may have your stuff stored in a few places. That was my point, but the proposal limits you to one. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 07:11:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezv7N-0003wt-R8; Fri, 20 Jan 2006 07:11:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezv7M-0003wD-42 for dix@megatron.ietf.org; Fri, 20 Jan 2006 07:11:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06901 for ; Fri, 20 Jan 2006 07:10:19 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzvG4-0001iZ-Mn for dix@ietf.org; Fri, 20 Jan 2006 07:20:49 -0500 Received: from dul1shollenbl1 ([::ffff:68.100.55.187]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Fri, 20 Jan 2006 07:10:45 -0500 id 01588075.43D0D345.0000509E From: "Scott Hollenbeck" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 07:12:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200601200332.WAA28881@ietf.org> Thread-Index: AcYdbxIqurPV8jpFRl2v6vSdKVUDggAAqzmQABIirWA= Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > -----Original Message----- > From: Suresh Venkatraman [mailto:sureshven@gmail.com] > Sent: Thursday, January 19, 2006 10:34 PM > To: 'Digital Identity Exchange' > Subject: RE: [dix] draft of proposed charter (#2) > > > I think Scott's point is that we mandate that the parties must > > implement one particular binding. > > That's the part I was disagreeing with. I was just trying to > pointing out > that the first spec'd binding, HTTP, would allow for DIX to > build traction > and that we did not need to have a "mandatory" binding. What's the difference between "first spec'd binding" as you used those words above and "mandatory" as I described? My point is that a working group is going to have to craft a spec that allows two implementations to interoperate. If someone implements something using http, and someone else does something different (and the specs allow both) such that they don't interoperate, then there is going to be a problem. The foundation that allows interoperability MUST be specified in the charter. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 09:47:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxXw-0003cm-1V; Fri, 20 Jan 2006 09:47:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxXu-0003bi-CW for dix@megatron.ietf.org; Fri, 20 Jan 2006 09:47:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18168 for ; Fri, 20 Jan 2006 09:45:55 -0500 (EST) Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezxge-0006bb-BJ for dix@ietf.org; Fri, 20 Jan 2006 09:56:25 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id k0KEkvsa005743; Fri, 20 Jan 2006 14:46:57 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 09:45:04 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 14:45:04 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 09:46:56 -0500 Subject: Re: [dix] draft of proposed charter (#2) From: Peter Davis To: Digital Identity Exchange , Message-ID: Thread-Topic: [dix] draft of proposed charter (#2) Thread-Index: AcYd0Fv3mj9DAInDEdq6NAANk3jHKA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jan 2006 14:45:04.0177 (UTC) FILETIME=[1950DA10:01C61DD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/19/2006 9:38 PM, "John Merrells" wrote: > ... but I might be on a call to a call center and they ask me to > prove something about me... right now they ask a bunch of > questions... SSN, MMN, DOB... with DIX over SIP they might > be able to send the request to my client and assuming it > had the appropriate interface (ie capabilities) it could ask > me if i wanted to reveal that identity information... i'd click > yes and it'd be revealed. Which sounds quite nice to me. SIP presently has means to 'prove' the identity of the calling party sip-identity [1] which supplies a new header (and some hash/signing). While it is presently in ID, it is header to RFC editor queue. It would be for the SIP WG to draft a binding of 'dix' with sip-identity, IMHO. At least for the purposes laid out in the above use case. =peterd (http://public.xdi.org/=peterd) [1] http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 09:54:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxfD-00062y-RE; Fri, 20 Jan 2006 09:54:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzxfC-00062H-Co for dix@megatron.ietf.org; Fri, 20 Jan 2006 09:54:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18980 for ; Fri, 20 Jan 2006 09:53:27 -0500 (EST) Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezxnw-0006v3-B7 for dix@ietf.org; Fri, 20 Jan 2006 10:03:57 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id k0KEshsa005993 for ; Fri, 20 Jan 2006 14:54:43 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 09:52:50 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 14:52:50 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 09:54:42 -0500 Subject: Re: [dix] draft proposed charter - consensus? From: Peter Davis To: Digital Identity Exchange Message-ID: Thread-Topic: [dix] draft proposed charter - consensus? Thread-Index: AcYd0XG5sDgFGYnEEdq6NAANk3jHKA== In-Reply-To: <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jan 2006 14:52:50.0325 (UTC) FILETIME=[2F296450:01C61DD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/20/2006 2:24 AM, "John Merrells" wrote: > A 'relying party', by the Identity > Gang lexicon is a consumer rather than a producer of identity > information. They use the term 'claimant' for something that > creates claims.... I don't really like that very much, so wrote > 'authoritative source' instead. Hopefully that explains why I'm > proposing that change. > s/authoritative source/asserting party/ It's up to the relying party to decide how ' authoritative' the claim is =peterd (http://public.xdi.org/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 10:37:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKO-0003kU-0v; Fri, 20 Jan 2006 10:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKM-0003k9-Dl for dix@megatron.ietf.org; Fri, 20 Jan 2006 10:37:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22700 for ; Fri, 20 Jan 2006 10:35:58 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyT4-0008VN-DB for dix@ietf.org; Fri, 20 Jan 2006 10:46:29 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0KFbDQH016397 for ; Fri, 20 Jan 2006 15:37:13 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 10:35:20 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 15:35:20 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 10:37:12 -0500 Subject: Re: [dix] draft proposed charter - consensus? From: Peter Davis To: Digital Identity Exchange Message-ID: Thread-Topic: [dix] draft proposed charter - consensus? Thread-Index: AcYd12GkoEx2KInKEdq6NAANk3jHKA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Jan 2006 15:35:20.0631 (UTC) FILETIME=[1F433470:01C61DD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/19/2006 3:17 PM, "John Merrells" wrote: >=20 > On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >=20 >>> 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=B9s 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. >>=20 >> How about simply that it is in scope to establish a 'uniform >> addressing >> mechanism', such as a URI. >=20 > To which piece of the above does that apply? The last three sentences? Yeah, the identifier part. >=20 > The term 'addressing' worries me a little. That might just be a knee > jerk reaction from me though, based on my LDAP experience. But that is what you get whenever you make a string (even opaque) in some namespace. When I give my dog a name, it's really just virgil.peterdavis (using, at least, a DNS like delegation notation). This WG should not invent new identifiers. Use one of the (too) many we've got already. =20 But I agree wrt the terms use here. s/address/identifier/; but we'll get both in the end. With the identifier alice, when asserted by foo, you kind= a always end up with an address alice@foo (or if you prefer alice!fred ;-) > A > key aspect of any information/data model is the separation between > addressing things and identifying things. In LDAP the DN was > both, which caused me lots of pain trying to solve the distribution > and replication problems... which lead to adding the entryUUID > attribute, so that we had immutable names for entries.... > (I could ramble on for hours about that...) Yes, I fully agree. We tend to overload the identifier with other duties. =20 > I'd be happier with 'uniform naming mechanism', which could be a > URI... people may want something other than an URI. >=20 That works too. =3Dpeterd (http://public.xdi.org/=3Dpeterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 10:39:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyMM-0004eZ-LB; Fri, 20 Jan 2006 10:39:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyML-0004eT-PD for dix@megatron.ietf.org; Fri, 20 Jan 2006 10:39:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23151 for ; Fri, 20 Jan 2006 10:38:02 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyV5-0000EZ-NU for dix@ietf.org; Fri, 20 Jan 2006 10:48:33 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0KFdIQH016541 for ; Fri, 20 Jan 2006 15:39:18 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 10:37:25 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 15:37:25 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 10:39:15 -0500 Subject: Re: [dix] draft proposed charter - consensus? From: Peter Davis To: Digital Identity Exchange Message-ID: Thread-Topic: [dix] draft proposed charter - consensus? Thread-Index: AcYd16r16cnxmonKEdq6NAANk3jHKA== In-Reply-To: <994C3820-8371-4896-9F55-280276DF94CF@sxip.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Jan 2006 15:37:25.0488 (UTC) FILETIME=[69AEDF00:01C61DD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/19/2006 3:06 PM, "John Merrells" wrote: >=20 > On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >=20 >>> 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=B9s identity >>> information. >=20 >> Perhaps you mean management of the exchange of user attributes and >> authentication states between parties. 'managing identities' >> implies to my >> read as a sw which manages the storage of user data >=20 > A subtle point, but a good one. It will enable 'storage of', but that's > not the only thing, and not the main thing. How about... >=20 > "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 _the_exchange_of_ a > user=B9s identity information." Yes, improved. =3Dpeterd (http://public.xdi.org/=3Dpeterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 10:53:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyZv-0004Wc-QP; Fri, 20 Jan 2006 10:53:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyZu-0004WK-V1 for dix@megatron.ietf.org; Fri, 20 Jan 2006 10:53:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24675 for ; Fri, 20 Jan 2006 10:52:03 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezyif-0000rU-EB for dix@ietf.org; Fri, 20 Jan 2006 11:02:34 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0KFrKQH017565 for ; Fri, 20 Jan 2006 15:53:20 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 10:51:27 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 15:51:27 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 10:53:19 -0500 From: Peter Davis To: Digital Identity Exchange Message-ID: Thread-Topic: To add to the charter Thread-Index: AcYd2aIF4MYBb4nMEdq6NAANk3jHKA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jan 2006 15:51:27.0898 (UTC) FILETIME=[5FCC6FA0:01C61DD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [dix] To add to the charter X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org We should add to the 'In Scope' section: This working group shall include in it's output, informational material which results from the assessment of existing specifications, and limitations or omissions which requires the production of additional specification(s). Which, I suppose, implies another deliverable. =peterd (http://public.xdi.org/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 11:27:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz6Z-0000fZ-IU; Fri, 20 Jan 2006 11:27:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz6X-0000aa-Rg for dix@megatron.ietf.org; Fri, 20 Jan 2006 11:27:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27225 for ; Fri, 20 Jan 2006 11:25:45 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzFI-0001ve-Ar for dix@ietf.org; Fri, 20 Jan 2006 11:36:17 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id D456D49D161 for ; Fri, 20 Jan 2006 09:27:02 -0700 (MST) Message-ID: <43D10F56.7080600@jabber.org> Date: Fri, 20 Jan 2006 09:27:02 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) References: <200601192224.RAA03365@ietf.org> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0323207748==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0323207748== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070204080808040203000008" This is a cryptographically signed message in MIME format. --------------ms070204080808040203000008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > > On 19-Jan-06, at 2:25 PM, Suresh Venkatraman wrote: > >>> Any solution should support multiple transport layers, including, but >>> not limited to: HTTP, SOAP, XMPP, and SIP. >> >> Not to quibble but I don't consider SOAP to be a transport protocol but a >> messaging protocol. OTOH I could see SOAP, as a message envelope >> format, to >> be used within one of the mentioned transport protocols. > > How about... > > "Any solution should support multiple transport and messaging protocols, > including but not limited to: HTTP, SOAP, XMPP, and SIP. " I think Suresh's point was that SOAP is not a transport or messaging protocol, but a message format that can be carried over such protocols. E.g., there are (AFAIK) four transport/messaging bindings for SOAP: HTTP, SMTP, BEEP, and XMPP. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms070204080808040203000008 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIwMTYyNzAyWjAjBgkqhkiG9w0BCQQxFgQUm8cgQZNKMkhxUQS8 sJoe21BrxPkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAAWNVdcDldXFh5nbJh3eigZ+gxm5Coe0 FGs8u7JAAJr+9TLk7pylEThtKyDd3f3AuIj0+w+j8O2GLLdiovODFpd/MIeh/PvgSQ/Kjjl6 4rtdDqJq/WFfGXUXUd48zkfPltlYFlnE6/Gn7giSQLImoqBJ61eue0tqNlUaOso7z2nzunVW B8gqCZqPg7v0/rAjPWJr6bqJ66zOV/SU1eRw4E+oZDPlp02V/2JGUu8NjkJPKvPQIUyGpWsS HSq8G/CJ4b9cm0cKfxe+jPO7VGiDL+y3eggWOI8L89wAqFo8/bwc31fY4GAo/fUmbQdvqqvx NzGUdd3i6O/HolF9+Lcw2DYAAAAAAAA= --------------ms070204080808040203000008-- --===============0323207748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0323207748==-- From dix-bounces@ietf.org Fri Jan 20 11:51:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzTr-0002Lt-V3; Fri, 20 Jan 2006 11:51:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzTp-0002Ll-Rf for dix@megatron.ietf.org; Fri, 20 Jan 2006 11:51:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29366 for ; Fri, 20 Jan 2006 11:49:49 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezzca-0002rc-P6 for dix@ietf.org; Fri, 20 Jan 2006 12:00:22 -0500 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc13) with SMTP id <2006012016505601500af7age>; Fri, 20 Jan 2006 16:50:56 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> Content-Transfer-Encoding: 7bit From: Johannes Ernst Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 08:50:54 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On this note ... I haven't seen a lot of discussion so far why the IETF needs to get into identity standards. How does this group answer the question: it's not like we don't have a plethora of widely implemented identity and related standards already, why do we need another? I'd think that question needs to be answered crisply and convincingly in the charter. Personally, I can believe that there is some hitherto uncharted territory in identity land that the IETF could do something about, but I would also think that that territory needs to be marked in relationship to other territories by other initiatives, preferably with very little to zero overlap. I'd recommend that be done from the get-go, because otherwise dix just sets itself up for sniping. Cheers, Johannes. On Jan 20, 2006, at 7:53, Peter Davis wrote: > We should add to the 'In Scope' section: > > This working group shall include in it's output, informational > material > which results from the assessment of existing specifications, and > limitations or omissions which requires the production of additional > specification(s). > > Which, I suppose, implies another deliverable. > > =peterd (http://public.xdi.org/=peterd) > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 12:05:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzhR-0005we-Tf; Fri, 20 Jan 2006 12:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzhR-0005wZ-0G for dix@megatron.ietf.org; Fri, 20 Jan 2006 12:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00592 for ; Fri, 20 Jan 2006 12:03:52 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzqC-0003JZ-Kv for dix@ietf.org; Fri, 20 Jan 2006 12:14:25 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id BF18F49D1A4 for ; Fri, 20 Jan 2006 10:05:27 -0700 (MST) Message-ID: <43D11857.4070404@jabber.org> Date: Fri, 20 Jan 2006 10:05:27 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] To add to the charter References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> In-Reply-To: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2088265474==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2088265474== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000503000605060407020701" This is a cryptographically signed message in MIME format. --------------ms000503000605060407020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Johannes Ernst wrote: > On this note ... > > I haven't seen a lot of discussion so far why the IETF needs to get into > identity standards. How does this group answer the question: it's not > like we don't have a plethora of widely implemented identity and related > standards already, why do we need another? > > I'd think that question needs to be answered crisply and convincingly in > the charter. > > Personally, I can believe that there is some hitherto uncharted > territory in identity land that the IETF could do something about, but I > would also think that that territory needs to be marked in relationship > to other territories by other initiatives, preferably with very little > to zero overlap. I'd recommend that be done from the get-go, because > otherwise dix just sets itself up for sniping. +1 I expected the (pre-)I-D that John sent around to map out the lay of the land in the identity world, explain the gaps left by existing identity technologies, and define how the work product of a DIX WG would help to solve problems that cannnot be solved today. Did I miss that text? Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms000503000605060407020701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIwMTcwNTI3WjAjBgkqhkiG9w0BCQQxFgQUutWc1gitzgINywPO voJwRDfLIHMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBANFgOQ2OG50IBZ9CBhFoCb78eCZXN7uF W7cU3+cuyfAepE+8HJlliClPRzfO0XrHT9+cQA1HCiqsZNfJH7BhyIvNevj3SdNkaxeme15L qpiaROsjAy5yobCpdTrP/e8Sy2JZ6QP3Aglc36O6NTgJW9Sjk7H0QMWxntW7n7vLUGgHiemq GerR3AHVm7NRfgl9iG1lONI+NFhsEJxe9mgigwT8VLZ/x+/OFSH4jmbS7Cfxlmqvy/fuzIjn b3c6pk4Rrx5GER2/4ZAGszNbZdBqn2HEvbZeI7BrDzdeWW4Hp8vNqjaiswpWnZV+LwECGHXl Jy0l7SJqDolnuR1Hx4HUAT4AAAAAAAA= --------------ms000503000605060407020701-- --===============2088265474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============2088265474==-- From dix-bounces@ietf.org Fri Jan 20 12:33:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F008Q-0004Sv-Q9; Fri, 20 Jan 2006 12:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F008O-0004SZ-IS for dix@megatron.ietf.org; Fri, 20 Jan 2006 12:33:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03502 for ; Fri, 20 Jan 2006 12:31:43 -0500 (EST) Message-Id: <200601201731.MAA03502@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00H8-0004VI-E3 for dix@ietf.org; Fri, 20 Jan 2006 12:42:16 -0500 Received: from sureshmobile (c-67-170-82-35.hsd1.wa.comcast.net[67.170.82.35]) by comcast.net (rwcrmhc12) with SMTP id <2006012017330001400dmh4se>; Fri, 20 Jan 2006 17:33:00 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 09:32:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYdbxIqurPV8jpFRl2v6vSdKVUDggAAqzmQABIirWAACrdqgA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > What's the difference between "first spec'd binding" as you used those > words above and "mandatory" as I described? My point is that a working > group is going to have to craft a spec that allows two implementations to > interoperate. If someone implements something using http, and someone > else does something different (and the specs allow both) such that they > don't interoperate, then there is going to be a problem. The foundation > that allows interoperability MUST be specified in the charter. I'm arguing that the foundation for interoperation is the DIX protocol and not the binding to a specific transport protocol (HTTP). By making a particular binding "mandatory" for all implementations, you are potentially limiting future choices. For instance, would I be forced to implement HTTP in all XMPP and SIP clients and proxies even though XMPP and SIP bindings may exist? And that begs the question - why HTTP? -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Scott Hollenbeck Sent: Friday, January 20, 2006 4:13 AM To: 'Digital Identity Exchange' Subject: RE: [dix] draft of proposed charter (#2) > -----Original Message----- > From: Suresh Venkatraman [mailto:sureshven@gmail.com] > Sent: Thursday, January 19, 2006 10:34 PM > To: 'Digital Identity Exchange' > Subject: RE: [dix] draft of proposed charter (#2) > > > I think Scott's point is that we mandate that the parties must > > implement one particular binding. > > That's the part I was disagreeing with. I was just trying to > pointing out > that the first spec'd binding, HTTP, would allow for DIX to > build traction > and that we did not need to have a "mandatory" binding. What's the difference between "first spec'd binding" as you used those words above and "mandatory" as I described? My point is that a working group is going to have to craft a spec that allows two implementations to interoperate. If someone implements something using http, and someone else does something different (and the specs allow both) such that they don't interoperate, then there is going to be a problem. The foundation that allows interoperability MUST be specified in the charter. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 12:40:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00FR-0008Qb-BN; Fri, 20 Jan 2006 12:40:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00FQ-0008QH-Ho for dix@megatron.ietf.org; Fri, 20 Jan 2006 12:40:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04123 for ; Fri, 20 Jan 2006 12:39:00 -0500 (EST) Message-Id: <200601201739.MAA04123@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00OB-0004ks-R1 for dix@ietf.org; Fri, 20 Jan 2006 12:49:33 -0500 Received: from sureshmobile (c-67-170-82-35.hsd1.wa.comcast.net[67.170.82.35]) by comcast.net (rwcrmhc14) with SMTP id <200601201740160140024ea5e>; Fri, 20 Jan 2006 17:40:16 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 09:39:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYd3mRWaPSRe24gRIKA3S+KJXuS4gACU9rA In-Reply-To: <43D10F56.7080600@jabber.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > I think Suresh's point was that SOAP is not a transport or messaging > protocol, but a message format that can be carried over such protocols. > E.g., there are (AFAIK) four transport/messaging bindings for SOAP: > HTTP, SMTP, BEEP, and XMPP. Yes, that was my point. It's a bit tricky since in RFC 3288, SOAP is mentioned as a XML-based messaging protocol. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Friday, January 20, 2006 8:27 AM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) John Merrells wrote: > > On 19-Jan-06, at 2:25 PM, Suresh Venkatraman wrote: > >>> Any solution should support multiple transport layers, including, but >>> not limited to: HTTP, SOAP, XMPP, and SIP. >> >> Not to quibble but I don't consider SOAP to be a transport protocol but a >> messaging protocol. OTOH I could see SOAP, as a message envelope >> format, to >> be used within one of the mentioned transport protocols. > > How about... > > "Any solution should support multiple transport and messaging protocols, > including but not limited to: HTTP, SOAP, XMPP, and SIP. " I think Suresh's point was that SOAP is not a transport or messaging protocol, but a message format that can be carried over such protocols. E.g., there are (AFAIK) four transport/messaging bindings for SOAP: HTTP, SMTP, BEEP, and XMPP. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 12:48:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00Mk-0002fc-Iy; Fri, 20 Jan 2006 12:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00Mj-0002dN-Og for dix@megatron.ietf.org; Fri, 20 Jan 2006 12:48:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04721 for ; Fri, 20 Jan 2006 12:46:33 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00VV-00051S-1O for dix@ietf.org; Fri, 20 Jan 2006 12:57:06 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 8E41849D281 for ; Fri, 20 Jan 2006 10:48:07 -0700 (MST) Message-ID: <43D12257.8080804@jabber.org> Date: Fri, 20 Jan 2006 10:48:07 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) References: <200601201739.MAA04123@ietf.org> In-Reply-To: <200601201739.MAA04123@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0909822834==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0909822834== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010008060301030003060607" This is a cryptographically signed message in MIME format. --------------ms010008060301030003060607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Suresh Venkatraman wrote: >> I think Suresh's point was that SOAP is not a transport or messaging >> protocol, but a message format that can be carried over such protocols. >> E.g., there are (AFAIK) four transport/messaging bindings for SOAP: >> HTTP, SMTP, BEEP, and XMPP. > > Yes, that was my point. It's a bit tricky since in RFC 3288, SOAP is > mentioned as a XML-based messaging protocol. That text is still in RFC 4227 but I think we should depend on the SOAP specs to correctly characterize what SOAP is. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms010008060301030003060607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIwMTc0ODA3WjAjBgkqhkiG9w0BCQQxFgQUA/vwW8FOP+QSjdpp EYVTq8ovQYswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAJ0/PwNgGlzwpBOfO8GlSsxughwy2EmO y74TR6IkNoJsrkIhwZ/XE9HVIqNLGgGuc1k3yaVnBNqVvR8Op5SrsNC0/3TNoCSiS6jQQSLC NOt5XMQ1V0t6clifK8RH5u/YAWR8FUpJeAmpgoJMoE8F3FSC78poz//OPO/0eQX5Dj7qpqHD hR8UOET/ObHgCMKgnXbKE8C2+6p3Xg5EjkY0DQvXOsY8rZAWqt8P3kCgHVC1Ybbco+H2NEU0 DfiyarteKA76CVljZ7sXti9oM2Bq+7NxUteK8skkczYREUa1QSuyYEenSx9tSILb6wmFxfJY IaX1qNPMIr38NBMjP/ISDT8AAAAAAAA= --------------ms010008060301030003060607-- --===============0909822834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0909822834==-- From dix-bounces@ietf.org Fri Jan 20 13:26:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00xs-0001UB-Iv; Fri, 20 Jan 2006 13:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00xs-0001U6-0j for dix@megatron.ietf.org; Fri, 20 Jan 2006 13:26:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07989 for ; Fri, 20 Jan 2006 13:24:55 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F016b-0006OC-VK for dix@ietf.org; Fri, 20 Jan 2006 13:35:29 -0500 Received: from dul1shollenbl1 ([::ffff:68.100.55.187]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Fri, 20 Jan 2006 13:25:24 -0500 id 01588081.43D12B14.000014E3 From: "Scott Hollenbeck" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 13:27:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200601201731.MAA03502@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcYdbxIqurPV8jpFRl2v6vSdKVUDggAAqzmQABIirWAACrdqgAACU1Ug Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > -----Original Message----- > From: Suresh Venkatraman [mailto:sureshven@gmail.com] > Sent: Friday, January 20, 2006 12:33 PM > To: 'Digital Identity Exchange' > Subject: RE: [dix] draft of proposed charter (#2) > > > What's the difference between "first spec'd binding" as you > used those > > words above and "mandatory" as I described? My point is > that a working > > group is going to have to craft a spec that allows two > implementations to > > interoperate. If someone implements something using http, > and someone > > else does something different (and the specs allow both) > such that they > > don't interoperate, then there is going to be a problem. > The foundation > > that allows interoperability MUST be specified in the charter. > > I'm arguing that the foundation for interoperation is the DIX > protocol and > not the binding to a specific transport protocol (HTTP). By making a > particular binding "mandatory" for all implementations, you > are potentially > limiting future choices. For instance, would I be forced to > implement HTTP > in all XMPP and SIP clients and proxies even though XMPP and > SIP bindings > may exist? And that begs the question - why HTTP? OK, I agree with the "why HTTP" question. That's one you guys need to figure out. I'm telling you now, though, that a charter that does not describe at least one method to produce interoperable implementations will not be approved by the IESG. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 13:40:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01BN-0005aU-Pp; Fri, 20 Jan 2006 13:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01BM-0005a7-Hg for dix@megatron.ietf.org; Fri, 20 Jan 2006 13:40:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09125 for ; Fri, 20 Jan 2006 13:38:53 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F01K8-0006t7-IC for dix@ietf.org; Fri, 20 Jan 2006 13:49:25 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0KIe8QH029206 for ; Fri, 20 Jan 2006 18:40:08 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 13:38:15 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jan 2006 18:38:15 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 20 Jan 2006 13:40:06 -0500 Subject: Re: [dix] draft of proposed charter (#2) From: Peter Davis To: Digital Identity Exchange Message-ID: Thread-Topic: [dix] draft of proposed charter (#2) Thread-Index: AcYdbxIqurPV8jpFRl2v6vSdKVUDggAAqzmQABIirWAACrdqgAACU1UgAACeer0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jan 2006 18:38:15.0264 (UTC) FILETIME=[ACA74E00:01C61DF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >> >> I'm arguing that the foundation for interoperation is the DIX >> protocol and >> not the binding to a specific transport protocol (HTTP). By making a >> particular binding "mandatory" for all implementations, you >> are potentially >> limiting future choices. For instance, would I be forced to >> implement HTTP >> in all XMPP and SIP clients and proxies even though XMPP and >> SIP bindings >> may exist? And that begs the question - why HTTP? > > OK, I agree with the "why HTTP" question. That's one you guys need to > figure out. I'm telling you now, though, that a charter that does not > describe at least one method to produce interoperable implementations will > not be approved by the IESG. If you really want this to be a compossible identity framework, than perhaps the path sought is really 2 drafts. One for the core specification, the other for the particular transport binding the wg feels is most likely to see adoption (or has unfulfilled requirements), which may be HTTP . It also allows other specs to incorporate nicely into some new transport. =peterd (http://public.xdi.org/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 14:19:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01mp-0003I6-MO; Fri, 20 Jan 2006 14:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01mn-0003HO-RV for dix@megatron.ietf.org; Fri, 20 Jan 2006 14:19:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11978 for ; Fri, 20 Jan 2006 14:17:35 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F01va-00089S-7g for dix@ietf.org; Fri, 20 Jan 2006 14:28:07 -0500 Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 20 Jan 2006 14:18:16 -0500 id 01588082.43D1377B.00001DE7 Message-ID: <43D13790.9050001@thinkingcat.com> Date: Fri, 20 Jan 2006 14:18:40 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable To: Digital Identity Exchange Subject: Re: [dix] draft proposed charter - consensus? References: In-Reply-To: X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.52.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org It is clearer, but I think the charter still needs to be clearer about what is meant by "digital identity". Is the purpose to be able to access *any* stored data about a person, or *specific* stored data? In many regards, saying "any" is easier; sort out the format for expressing attribute/values, and you're done. However, then there are issues of interoperability (is there a minimum set of identity data that is mandatory to provide?). And, if it is "any", then how is this not a directory service with additional labelling (addresses/names/identifiers) on top? Leslie. Peter Davis wrote: > On 1/19/2006 3:06 PM, "John Merrells" wrote: > > >>On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> >> >>>>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=B9s identity >>>>information. >> >>>Perhaps you mean management of the exchange of user attributes and >>>authentication states between parties. 'managing identities' >>>implies to my >>>read as a sw which manages the storage of user data >> >>A subtle point, but a good one. It will enable 'storage of', but that'= s >>not the only thing, and not the main thing. How about... >> >>"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 _the_exchange_of_ a >>user=B9s identity information." > > > Yes, improved. > > =3Dpeterd (http://public.xdi.org/=3Dpeterd) > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 14:47:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02EA-0005tD-GL; Fri, 20 Jan 2006 14:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02E8-0005sb-Cn for dix@megatron.ietf.org; Fri, 20 Jan 2006 14:47:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14230 for ; Fri, 20 Jan 2006 14:45:49 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02Mu-0000d5-Hi for dix@ietf.org; Fri, 20 Jan 2006 14:56:21 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KJl5uE099199 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 11:47:06 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75C206A6-36F6-4E1D-80CB-916F1D80368C@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 11:46:58 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 6:46 AM, Peter Davis wrote: > On 1/19/2006 9:38 PM, "John Merrells" wrote: >> ... but I might be on a call to a call center and they ask me to >> prove something about me... right now they ask a bunch of >> questions... SSN, MMN, DOB... with DIX over SIP they might >> be able to send the request to my client and assuming it >> had the appropriate interface (ie capabilities) it could ask >> me if i wanted to reveal that identity information... i'd click >> yes and it'd be revealed. Which sounds quite nice to me. > > SIP presently has means to 'prove' the identity of the calling party > sip-identity [1] which supplies a new header (and some hash/ > signing). While > it is presently in ID, it is header to RFC editor queue. Hey.... you sniped off my caveat... 'not really knowing anything about SIP i'm not very well qualified to say...', pout ;-) > It would be for the SIP WG to draft a binding of 'dix' with sip- > identity, > IMHO. At least for the purposes laid out in the above use case. Yep. Transport bindings should be done in the WG that makes most sense for that transport. Some WGs have wound down of course, which would mean doing them in DIX, or spinning up a new group. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 14:48:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Fk-0006aF-7x; Fri, 20 Jan 2006 14:48:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Fh-0006XC-V9 for dix@megatron.ietf.org; Fri, 20 Jan 2006 14:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14342 for ; Fri, 20 Jan 2006 14:47:26 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02OT-0000gK-F5 for dix@ietf.org; Fri, 20 Jan 2006 14:57:59 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0KJmiqZ022630 for ; Fri, 20 Jan 2006 14:48:44 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0KJmh126140 for ; Fri, 20 Jan 2006 14:48:43 -0500 Received: from [172.16.25.141] (dhcp-172-16-25-141.sfbay.redhat.com [172.16.25.141]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0KJmchD005689 for ; Fri, 20 Jan 2006 14:48:39 -0500 Message-ID: <43D13E96.2000303@redhat.com> Date: Fri, 20 Jan 2006 11:48:38 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> In-Reply-To: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [dix] dmd01: persona-url, data X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1853571835==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1853571835== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060802010101010702000408" This is a cryptographically signed message in MIME format. --------------ms060802010101010702000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > > DIX-ers, > > Here's an individual submission of a draft specification of a > 'Digital Identity eXchange' protocol. The draft identifies the user via a persona url, and there is a parameter in the fetch request that may request the persona url (and another which requests multiple persona urls). To clarify, the intention is that after/during homesite user authentication that the persona-url is resolved for the homesite i.e. that the user chooses the persona-url at some point or alternatively it is chosen for them by the homesite based on their local credentials. To clarify further - it is not a requirement that this persona-url be resolvable in any meaningful sense other than as an arbitrary identifier. Also, what responsibilities does the homesite have for the validity of the information supplied? Should it only return information from a trusted source or is it acceptable to ask the user for data it doesn't know about? Should this be a protocol level decision? Assuming some level of trust has been established between the homesite and the membersite it might be useful to be able to specify this on an individual attribute basis. Or maybe I am way off base here, and the intent is that the homesite gives what it can and it is up to the homesite to get the rest, possibly resulting in a store-request? -- Pete --------------ms060802010101010702000408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjAxMjAxOTQ4MzhaMCMGCSqGSIb3DQEJBDEWBBQyLTp6k51U28jx XhoXl4+eQhCxWTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAy9Fpk8xGpXM5FqMX10aI20UjKncPlk0EsknyAQQUZzT9bReL6gh2ugiWDbKt L2HVPW9GwzsjOHimPuy7Yx61DnlD0WwafzRbaAek0WSPiI/uDb/LNyfpX3Y+wk7Q+5ls4rcM XbWznwzy6yCCTA/OYLfI0HV4GLHk98V+44qX6+or0f8M/2esNv/YDMrBk9LX8vpw2Wkf2ZUg XGg4OXUsPNLVvwJOt4HaJ61Ml6+h7NCpUxaR+OGeIwkl+yrB8qfNi11voA38gcDzd4p0tuFf R0OJtAEtcUfNYCsAgo7qn2JjuO3a0dyGo9TfMGSwYE1SY43XmF6CxyPzIaJG/8rNqAAAAAAA AA== --------------ms060802010101010702000408-- --===============1853571835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1853571835==-- From dix-bounces@ietf.org Fri Jan 20 14:50:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Gn-0006vR-9l; Fri, 20 Jan 2006 14:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Gm-0006v7-3Z for dix@megatron.ietf.org; Fri, 20 Jan 2006 14:50:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14416 for ; Fri, 20 Jan 2006 14:48:33 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02PZ-0000ih-Gy for dix@ietf.org; Fri, 20 Jan 2006 14:59:05 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KJnwP3099395 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 11:49:58 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 11:49:51 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 4:12 AM, Scott Hollenbeck wrote: >> That's the part I was disagreeing with. I was just trying to >> pointing out >> that the first spec'd binding, HTTP, would allow for DIX to >> build traction >> and that we did not need to have a "mandatory" binding. > > What's the difference between "first spec'd binding" as you used > those words > above and "mandatory" as I described? My point is that a working > group is > going to have to craft a spec that allows two implementations to > interoperate. If someone implements something using http, and > someone else > does something different (and the specs allow both) such that they > don't > interoperate, then there is going to be a problem. The foundation > that > allows interoperability MUST be specified in the charter. I understand your point and am working on addressing it. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 14:54:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02LY-0000Yc-4j; Fri, 20 Jan 2006 14:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02LW-0000Xg-GU for dix@megatron.ietf.org; Fri, 20 Jan 2006 14:54:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14716 for ; Fri, 20 Jan 2006 14:53:27 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02UI-0000rO-PY for dix@ietf.org; Fri, 20 Jan 2006 15:04:00 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KJsiOS099607 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 11:54:45 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D12257.8080804@jabber.org> References: <200601201739.MAA04123@ietf.org> <43D12257.8080804@jabber.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65D361CD-E8CE-433C-8F41-4BAE01EA0409@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 11:54:37 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 9:48 AM, Peter Saint-Andre wrote: > Suresh Venkatraman wrote: >>> I think Suresh's point was that SOAP is not a transport or >>> messaging protocol, but a message format that can be carried over >>> such protocols. >>> E.g., there are (AFAIK) four transport/messaging bindings for >>> SOAP: HTTP, SMTP, BEEP, and XMPP. >> Yes, that was my point. It's a bit tricky since in RFC 3288, SOAP is >> mentioned as a XML-based messaging protocol. > > That text is still in RFC 4227 but I think we should depend on the > SOAP specs to correctly characterize what SOAP is. How about... 'messaging formats and transports' "Any solution should allow DIX messages to be carried over multiple alternative messaging formats and transports, including, but not limited to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this working group will initially focus on a HTTP based solution." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 15:02:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Sa-0002n2-Uz; Fri, 20 Jan 2006 15:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02SS-0002lZ-MG for dix@megatron.ietf.org; Fri, 20 Jan 2006 15:02:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15129 for ; Fri, 20 Jan 2006 15:00:37 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02bG-00012S-0n for dix@ietf.org; Fri, 20 Jan 2006 15:11:10 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KK1tsq000152 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 12:01:56 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B11A43E-2A0B-4B41-B439-D28EB0C17F12@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 12:01:48 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 10:40 AM, Peter Davis wrote: > If you really want this to be a compossible identity framework, > than perhaps > the path sought is really 2 drafts. One for the core specification, > the > other for the particular transport binding the wg feels is most > likely to > see adoption (or has unfulfilled requirements), which may be > HTTP . It > also allows other specs to incorporate nicely into some new transport. That's the approach the charter is taking at the moment. In draft #2 I called out the expected documents that would come out of a WG and they're in the milestone section. Is the text not clear on that? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 15:03:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Te-00037E-7q; Fri, 20 Jan 2006 15:03:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02Td-000379-DI for dix@megatron.ietf.org; Fri, 20 Jan 2006 15:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15184 for ; Fri, 20 Jan 2006 15:01:50 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02cQ-00014c-PB for dix@ietf.org; Fri, 20 Jan 2006 15:12:23 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KK3F3S000276 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 12:03:15 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Fri, 20 Jan 2006 12:03:08 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 6:54 AM, Peter Davis wrote: > s/authoritative source/asserting party/ > > It's up to the relying party to decide how ' authoritative' the > claim is Ack. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 15:08:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02YJ-0004KN-NO; Fri, 20 Jan 2006 15:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02YI-0004Jx-Pt for dix@megatron.ietf.org; Fri, 20 Jan 2006 15:08:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15454 for ; Fri, 20 Jan 2006 15:06:37 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02h4-0001CC-49 for dix@ietf.org; Fri, 20 Jan 2006 15:17:10 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KK7o5j000504 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 12:07:51 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <261DF14E-5DC1-4DF5-B4FA-9A9F4F9A4B07@sxip.com> References: <7B5C7450-1F65-4EFE-9BC6-11D6A64D6C34@sxip.com> X <43D0D92F.A648.00B6.0@novell.com> <60843461-D191-44C7-8A36-5FA62DC50225@sxip.com> <375741E0-AC6A-46AD-8C15-93CC704F8F97@sxip.com> <261DF14E-5DC1-4DF5-B4FA-9A9F4F9A4B07@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Fri, 20 Jan 2006 12:07:43 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 19-Jan-06, at 11:56 PM, John Merrells wrote: > > Ah yes, 'Third Party' is commonly taken to refer to a party outside=20=20 > the transaction whom has given the first party something for=20=20 > presentation to the second party. Goodness this is fun. I'll ponder=20=20 > on an agreeable term for the second party. Oh, maybe that's the=20=20 > term? Maybe we define FP, SP, and TP... 1P, 2P, 3P... where 1P is=20=20 > the user's agent, 2P is the relying party, and 3P is the=20=20 > authoritative source. OK... We have principal and non-principal parties, which gets Ben his=20=20 useful intermediaries. And, now i use 'the other party' to refer to the party at the other=20=20 end... and then state clearly that it's either a relying party or an=20=20 asserting party. (Thanks Peter) "An identity information exchange should involve just three principal=20=20 parties: the user, their agent, and another party. The user=92s agent=20=20 is where they authenticate themselves and a repository where they=20=20 store their identity information and the other party is either a=20=20 relying party requesting identity information or an asserting party=20=20 providing identity information. Non-principal parties may participate=20=20 in an information exchange by providing facilitating services, such=20=20 as proxying, caching or agency." John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 15:18:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02hz-0000Xy-7k; Fri, 20 Jan 2006 15:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02hy-0000Xt-B7 for dix@megatron.ietf.org; Fri, 20 Jan 2006 15:18:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16105 for ; Fri, 20 Jan 2006 15:16:38 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02qh-0001Uf-J5 for dix@ietf.org; Fri, 20 Jan 2006 15:27:09 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KKHrSa000846 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 12:17:53 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Fri, 20 Jan 2006 12:17:46 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 7:37 AM, Peter Davis wrote: >> The term 'addressing' worries me a little. That might just be a knee >> jerk reaction from me though, based on my LDAP experience. > > But that is what you get whenever you make a string (even opaque) > in some > namespace. When I give my dog a name, it's really just > virgil.peterdavis > (using, at least, a DNS like delegation notation). Grumble... probably best as a beer based conversation. I award you one beer token for redemption at the Dallas IETF. > This WG should not invent new identifiers. Use one of the (too) > many we've > got already. Agree. > But I agree wrt the terms use here. s/address/identifier/; but > we'll get > both in the end. With the identifier alice, when asserted by foo, > you kinda > always end up with an address alice@foo (or if you prefer alice! > fred ;-) Good. > >> I'd be happier with 'uniform naming mechanism', which could be a >> URI... people may want something other than an URI. >> > > That works too. OK Was... 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 URI, a URL or a UUID. Is now... The identifier should be based on existing identifier and namespace mechanisms to ensure flexibility and interoperability, and the working group should consider current best practice. For example, a URI, a URL or a UUID. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 15:41:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0348-0000Jy-3i; Fri, 20 Jan 2006 15:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0346-0000Jt-OW for dix@megatron.ietf.org; Fri, 20 Jan 2006 15:40:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17576 for ; Fri, 20 Jan 2006 15:39:30 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03Cu-00028R-3H for dix@ietf.org; Fri, 20 Jan 2006 15:50:04 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KKem0E001524 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 12:40:49 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D13E96.2000303@redhat.com> References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] dmd01: persona-url, data Date: Fri, 20 Jan 2006 12:40:42 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 11:48 AM, Pete Rowley wrote: > The draft identifies the user via a persona url, and there is a > parameter in the fetch request that may request the persona url > (and another which requests multiple persona urls). To clarify, > the intention is that after/during homesite user authentication > that the persona-url is resolved for the homesite i.e. that the > user chooses the persona-url at some point or alternatively it is > chosen for them by the homesite based on their local credentials. > To clarify further - it is not a requirement that this persona-url > be resolvable in any meaningful sense other than as an arbitrary > identifier. Dmd1 defines the Persona URL to be a URL... so it's syntax is limited to that of a URL, so it's not totally arbitrary. Does it have to be resolvable? Well it's optional whether the Membersite fetches the Persona Page at the end of the Persona URL to check for the Delegation Tag to ensure that the Homesite stated in the fetch-response message really has been delegated authority to authenticate that Persona URL.... so in theory if the Membersite didn't do that then it wouldn't really be optional... but the Homesite doesn't know if the Membersite is going to perform that part of the Verification Process so it must provide a resolvable Persona URL for the user. Of course if that were a useful feature then we could have a capability for the Membersite to declare that it wasn't going to verify the Persona URL... Interesting question... Do you have a cunning idea that motivated that? Perhaps a use case for the DIX Use Case ID? > Also, what responsibilities does the homesite have for the validity > of the information supplied? None. Dmd1 doesn't cover claims, just permits them to be moved around. In the charter discussions we've said that an asserting party can make claims about an identity... which can be acquired by the user, stored in their agent, and presented to relying parties upon request. > Should it only return information from a trusted source or is it > acceptable to ask the user for data it doesn't know about? The Homesite can ask the user for self asserted attribute values. It's up to the Membersite whether self asserted attribute values or third party asserted attribute values are acceptable. It does this in the fetch request by listing the properties it requires... self asserted and third party asserted have different names. > Should this be a protocol level decision? MS decision, by the protocol facilitates it. > Assuming some level of trust has been established between the > homesite and the membersite it might be useful to be able to > specify this on an individual attribute basis. Indeed. The above explains how that happens I think. > Or maybe I am way off base here, and the intent is that the > homesite gives what it can and it is up to the homesite think you must mean membersite there. > to get the rest, possibly resulting in a store-request? Assuming the above change: Exactly! Cheers John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 15:47:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03AU-0002hx-Mq; Fri, 20 Jan 2006 15:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03AT-0002hq-Ig for dix@megatron.ietf.org; Fri, 20 Jan 2006 15:47:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17969 for ; Fri, 20 Jan 2006 15:46:06 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03JE-0002IO-Fz for dix@ietf.org; Fri, 20 Jan 2006 15:56:39 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 7901C4A169B for ; Fri, 20 Jan 2006 13:47:29 -0700 (MST) Message-ID: <43D14C5A.1060009@jabber.org> Date: Fri, 20 Jan 2006 13:47:22 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) References: <200601201739.MAA04123@ietf.org> <43D12257.8080804@jabber.org> <65D361CD-E8CE-433C-8F41-4BAE01EA0409@sxip.com> In-Reply-To: <65D361CD-E8CE-433C-8F41-4BAE01EA0409@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0080958892==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0080958892== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000705070908080408080502" This is a cryptographically signed message in MIME format. --------------ms000705070908080408080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > > On 20-Jan-06, at 9:48 AM, Peter Saint-Andre wrote: > >> Suresh Venkatraman wrote: >>>> I think Suresh's point was that SOAP is not a transport or messaging >>>> protocol, but a message format that can be carried over such protocols. >>>> E.g., there are (AFAIK) four transport/messaging bindings for SOAP: >>>> HTTP, SMTP, BEEP, and XMPP. >>> Yes, that was my point. It's a bit tricky since in RFC 3288, SOAP is >>> mentioned as a XML-based messaging protocol. >> >> That text is still in RFC 4227 but I think we should depend on the >> SOAP specs to correctly characterize what SOAP is. > > How about... > > 'messaging formats and transports' > > "Any solution should allow DIX messages to be carried over multiple > alternative messaging formats and transports, including, but not limited > to: HTTP, SOAP, XMPP, and SIP. It is anticipated that this working group > will initially focus on a HTTP based solution." I suggest leaving SOAP out of it. In what way will SOAP be a carrier for digital identity exchange? If SOAP will be an encapsulating format for digital identity data, then it will be transported using one of the SOAP bindings (HTTP, SMTP, BEEP, XMPP). But the same could be said of methods for encapsulating digital identity data in SAML, XHTML, Atom, or whatever else people dream up as a wrapper. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms000705070908080408080502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIwMjA0NzIyWjAjBgkqhkiG9w0BCQQxFgQU6GkRG+bS8zm6uHeL kvx8aaBQ3mcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAGGj99SdTM1Yfh1v72YRtt89JvoaGJoh wzXkGBRshwvPgUJU07AgJcP5z5wIY9471Xw9gFEpJn468H6JvavmR7cufqFPn+qbuHWQipj9 2ze5Hs+9l1YM+lJt3fObzWsBpFNBZJbqAXj4oap+a1NAg4quiDP3KhqCMr/xtashtqz/4mSp 9HeGtuiuql0j3JUGh0yPPJ7wJoQD0bOrNXX8kJ9cz5OvNXXTJPivCyOh/yQNeosouh3g5g/L knQPX3IYf5a1Ze63zthZysRNEGS9Hr9yUvfB51OTbMlurFpQ66TMKSuW5ADx5CDuacNXzKkC O+QS8cQFEVih8NRvARccTCUAAAAAAAA= --------------ms000705070908080408080502-- --===============0080958892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0080958892==-- From dix-bounces@ietf.org Fri Jan 20 16:17:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03cD-000385-Uw; Fri, 20 Jan 2006 16:16:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03cC-000376-ET for dix@megatron.ietf.org; Fri, 20 Jan 2006 16:16:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23592 for ; Fri, 20 Jan 2006 16:14:44 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03kw-0004ZU-HN for dix@ietf.org; Fri, 20 Jan 2006 16:25:18 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KLFw8O002703 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 13:15:59 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D14C5A.1060009@jabber.org> References: <200601201739.MAA04123@ietf.org> <43D12257.8080804@jabber.org> <65D361CD-E8CE-433C-8F41-4BAE01EA0409@sxip.com> <43D14C5A.1060009@jabber.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 13:15:52 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 12:47 PM, Peter Saint-Andre wrote: > I suggest leaving SOAP out of it. In what way will SOAP be a > carrier for digital identity exchange? If SOAP will be an > encapsulating format for digital identity data, then it will be > transported using one of the SOAP bindings (HTTP, SMTP, BEEP, > XMPP). But the same could be said of methods for encapsulating > digital identity data in SAML, XHTML, Atom, or whatever else people > dream up as a wrapper. Yes, very good point.... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 16:27:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03nI-0001WZ-1W; Fri, 20 Jan 2006 16:27:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03nG-0001WB-OL for dix@megatron.ietf.org; Fri, 20 Jan 2006 16:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27896 for ; Fri, 20 Jan 2006 16:26:09 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03w2-0006BO-22 for dix@ietf.org; Fri, 20 Jan 2006 16:36:42 -0500 Received: from [66.80.0.5] (dhcp-5.danastreet.live555.com [66.80.0.5]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KLRP1X003104 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 13:27:26 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 13:27:19 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 8:50 AM, Johannes Ernst wrote: > I haven't seen a lot of discussion so far why the IETF needs to get > into identity standards. How does this group answer the question: > it's not like we don't have a plethora of widely implemented > identity and related standards already, why do we need another? There was some discussion on this topic before you joined the list. > I'd think that question needs to be answered crisply and > convincingly in the charter. This was actually in the first charter written (draft #0 if you like) but we were advised that it didn't belong there, so I took it out. This is what it said... Why should the IETF be involved? The IETF's role is to provide an open venue and process within which disparate interests can come together to agree on an interoperable solution to this problem. There are multiple teams with the same motivations working on similar solutions. For example: Sxip, LID, OpenID, and Passel. We are driven by a desire to quickly solve a shared problem for the benefit of all. This is an Internet scale problem. Our work will benefit individuals with an online presence who are currently hampered by a lack of a ubiquitous and secure means to perform identity information exchange. We envisage that every website could become a relying party and every web browser could become a conduit for identity information. > Personally, I can believe that there is some hitherto uncharted > territory in identity land that the IETF could do something about, Actually we should be in unchartered territory at all. We should be just codifying existing practice. (As the statement above says...) > but I would also think that that territory needs to be marked in > relationship to other territories by other initiatives, preferably > with very little to zero overlap. I'd recommend that be done from > the get-go, because otherwise dix just sets itself up for sniping. I think we're fine so long as we focus on what the IETF is good at: Internet Scale, Decentralization, Bottom-up Initiatives, User Driven, Codification of Existing Practice, Engineering Focused, Rough Consensus and Running Code! Things that have been driving your efforts and ours... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 16:37:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03x8-00073M-Cj; Fri, 20 Jan 2006 16:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03x5-00072F-Jr for dix@megatron.ietf.org; Fri, 20 Jan 2006 16:37:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01660 for ; Fri, 20 Jan 2006 16:36:17 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F045p-0007Y7-Qe for dix@ietf.org; Fri, 20 Jan 2006 16:46:51 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0KLbP7T029674 for ; Fri, 20 Jan 2006 16:37:25 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0KLbO114146 for ; Fri, 20 Jan 2006 16:37:24 -0500 Received: from [172.16.25.141] (dhcp-172-16-25-141.sfbay.redhat.com [172.16.25.141]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0KLbKhD011828 for ; Fri, 20 Jan 2006 16:37:21 -0500 Message-ID: <43D15810.2050905@redhat.com> Date: Fri, 20 Jan 2006 13:37:20 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] dmd01: persona-url, data References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268208684==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1268208684== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020005070902080402060508" This is a cryptographically signed message in MIME format. --------------ms020005070902080402060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > Does it have to be resolvable? Well it's optional whether the > Membersite fetches the Persona Page at the end of the Persona URL to > check for the Delegation Tag to ensure that the Homesite stated in > the fetch-response message really has been delegated authority to > authenticate that Persona URL.... Isn't it the _user_ that delegates that authority by providing the homesite-url in the first place? And hasn't the membersite shown its willingness to do so by actually performing the function? And the proof that it did in fact perform the function is the next part of the verification process - ensuring it sent the fetch-response message. > Interesting question... Do you have a cunning idea that motivated > that? Perhaps a use case for the DIX Use Case ID? I am looking at how a DMD1 homesite can be implemented using an external data source / identity authority (say, an LDAP directory server) using existing http server features (apache). So purely from that view point I would like to avoid having to have a file for each "persona". > The Homesite can ask the user for self asserted attribute values. > > It's up to the Membersite whether self asserted attribute values or > third party asserted attribute values are acceptable. It does this in > the fetch request by listing the properties it requires... self > asserted and third party asserted have different names. > Different names? So, are you saying the sxip#1 capabilities only come from sxip and if I want to supply say, a user first name, from some other authority I would need to name the property differently? -- Pete --------------ms020005070902080402060508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjAxMjAyMTM3MjBaMCMGCSqGSIb3DQEJBDEWBBRumEAb+3XkNfMf 94cLtUpJ/ABmlzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAcWNixvGu3n/PQI3eg2bnXD6Xu00gVcpIsxNKV6loJE16DfLMmvagTbOyMG9/ OjmqYsyNKerspy5F3RPGh1y4ks0DQCDRHVrrJJqdz6cp4fam9EkYHCQrjAzYVBQuJuYSwC+w iGsIXKn02ihwOjaYSaLqPBxpOB1l+RkG/RhElvBRxGvX6ttm2alyL3oX+RDnfTv3sAbF+F+L i0plJLZlnNO6I01SQ0vVN6xlbeQoldKjvhhY+DbRte8ROKtpmuoPaqv60/4n6Tf+1M4y9C7P V7vtGm3xss73gwg65h/T5RFry1E90SMt7jRWnfnoopprvjSBJckEjXd6QM508A2U7gAAAAAA AA== --------------ms020005070902080402060508-- --===============1268208684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1268208684==-- From dix-bounces@ietf.org Fri Jan 20 17:25:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04hN-0007VV-1h; Fri, 20 Jan 2006 17:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04hK-0007U7-SU for dix@megatron.ietf.org; Fri, 20 Jan 2006 17:25:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06948 for ; Fri, 20 Jan 2006 17:24:06 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04q5-0001Mm-QR for dix@ietf.org; Fri, 20 Jan 2006 17:34:41 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0KMPJbK013121 for ; Fri, 20 Jan 2006 17:25:19 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0KMPH104572 for ; Fri, 20 Jan 2006 17:25:18 -0500 Received: from [172.16.25.141] (dhcp-172-16-25-141.sfbay.redhat.com [172.16.25.141]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0KMPDhD014643 for ; Fri, 20 Jan 2006 17:25:14 -0500 Message-ID: <43D16348.1080005@redhat.com> Date: Fri, 20 Jan 2006 14:25:12 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] dmd01: persona-url, data References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> <43D15810.2050905@redhat.com> In-Reply-To: <43D15810.2050905@redhat.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986784019==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1986784019== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070204040500020700020107" This is a cryptographically signed message in MIME format. --------------ms070204040500020700020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pete Rowley wrote: > John Merrells wrote: > >> Does it have to be resolvable? Well it's optional whether the >> Membersite fetches the Persona Page at the end of the Persona URL to >> check for the Delegation Tag to ensure that the Homesite stated in >> the fetch-response message really has been delegated authority to >> authenticate that Persona URL.... > > > Isn't it the _user_ that delegates that authority by providing the > homesite-url in the first place? And hasn't the membersite shown its > willingness to do so by actually performing ack s/membersite/homesite/ > the function? And the proof that it did in fact perform the function > is the next part of the verification process - ensuring it sent the > fetch-response message. > >> Interesting question... Do you have a cunning idea that motivated >> that? Perhaps a use case for the DIX Use Case ID? > > > I am looking at how a DMD1 homesite can be implemented using an > external data source / identity authority (say, an LDAP directory > server) using existing http server features (apache). So purely from > that view point I would like to avoid having to have a file for each > "persona". > >> The Homesite can ask the user for self asserted attribute values. >> >> It's up to the Membersite whether self asserted attribute values or >> third party asserted attribute values are acceptable. It does this >> in the fetch request by listing the properties it requires... self >> asserted and third party asserted have different names. >> > Different names? So, are you saying the sxip#1 capabilities only come > from sxip and if I want to supply say, a user first name, from some > other authority I would need to name the property differently? > > > >------------------------------------------------------------------------ > >_______________________________________________ >dix mailing list >dix@ietf.org >https://www1.ietf.org/mailman/listinfo/dix > > -- Pete --------------ms070204040500020700020107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjAxMjAyMjI1MTJaMCMGCSqGSIb3DQEJBDEWBBSwOBjQSpPpbLYw g6Gdvdg6sR+Q8zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAU290eqjI/HV3IIGmBeXUeQ2daLk8lnV7ADVjpMMQJFJE8qK2bT4JcUZ4TjnB x4lnxL/W4gdtX/YlRAgZ6vuODBUKi+bU6FNHIBAuLDGUdApsN0t33cZ7xof1L1MprW2vzWkQ RAWt2FukpGab0wWLfvHytRPQ0OJijFuF17tpdD4cFqIS4yapPvx+pW8WZEcC5wvsJ0YOHlYn zPWp2o58QijSZh8SjsSedzi3anZF5p57xy/M1RqRoIOkm3lIjGNINlfxp4DMGRYorE1+cZYk vcNg1ZFZeQ4YOn4GvlvtGuWHHtsMmYekn6ZcJf+p3+Kit/H1XTOvcq1T5tflGAOHUgAAAAAA AA== --------------ms070204040500020700020107-- --===============1986784019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1986784019==-- From dix-bounces@ietf.org Fri Jan 20 17:30:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04mA-0001Gu-Gc; Fri, 20 Jan 2006 17:30:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04m8-0001EY-G3 for dix@megatron.ietf.org; Fri, 20 Jan 2006 17:30:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07549 for ; Fri, 20 Jan 2006 17:29:04 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04us-0001dF-K3 for dix@ietf.org; Fri, 20 Jan 2006 17:39:39 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KMUHte006271 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 14:30:18 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D15810.2050905@redhat.com> References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> <43D15810.2050905@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <025B547C-2585-45E1-B37D-E6FB77D0777C@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] dmd01: persona-url, data Date: Fri, 20 Jan 2006 14:30:10 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 1:37 PM, Pete Rowley wrote: > John Merrells wrote: > >> Does it have to be resolvable? Well it's optional whether the >> Membersite fetches the Persona Page at the end of the Persona URL >> to check for the Delegation Tag to ensure that the Homesite >> stated in the fetch-response message really has been delegated >> authority to authenticate that Persona URL.... > > Isn't it the _user_ that delegates that authority by providing the > homesite-url in the first place? And hasn't the membersite shown > its willingness to do so by actually performing the function? And > the proof that it did in fact perform the function is the next part > of the verification process - ensuring it sent the fetch-response > message. The verification process has two steps: delegation check and message verification. Both are there to guard against different kinds of man- in-the-middle attacks. The security considerations calls those out. > >> Interesting question... Do you have a cunning idea that motivated >> that? Perhaps a use case for the DIX Use Case ID? > > I am looking at how a DMD1 homesite can be implemented using an > external data source / identity authority (say, an LDAP directory > server) using existing http server features (apache). So purely > from that view point I would like to avoid having to have a file > for each "persona". Ah, OK. Two options I think. 1) The user already has a page, to which there's a url, that's their persona url. The directory then has an attribute on the user's entry containing that persona url. The user then adds a delegation tag to their page delegating auth to your DS-as-a-HS server. 2) The user doesn't have a page, so your DA-as-a-HS effectively has to provide one. How about you provide a virtual page for each user... so everything below a base path is mapped onto the same simple page that just delegates auth to your server. That would make sense for an enterprise, since they own the enterprise.com domain that both the DS- as-a-HS runs on and where all the persona urls are hosted. > >> The Homesite can ask the user for self asserted attribute values. >> >> It's up to the Membersite whether self asserted attribute values >> or third party asserted attribute values are acceptable. It does >> this in the fetch request by listing the properties it >> requires... self asserted and third party asserted have different >> names. >> > Different names? So, are you saying the sxip#1 capabilities only > come from sxip and if I want to supply say, a user first name, from > some other authority I would need to name the property differently? With dmd1yes. The query mechanism is super brain dead simple... you can reference a property value and that's it. My name as a self asserted attribute value might be: dix:/central-naming-authority/name/first And, my name as a digitally signed third party attribute value might be dix:/central-naming-authority/signed/name/first or dix:/central-naming-authority/name/first.signed or something else. Or we could extend the query language to make this type part of the request, but I'm trying to avoid yet another query language... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 17:53:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0582-00031f-PU; Fri, 20 Jan 2006 17:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0581-0002zG-0h for dix@megatron.ietf.org; Fri, 20 Jan 2006 17:53:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09297 for ; Fri, 20 Jan 2006 17:51:40 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F05Go-0002P0-3K for dix@ietf.org; Fri, 20 Jan 2006 18:02:16 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KMqvB8007122 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 14:52:57 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D11857.4070404@jabber.org> References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> <43D11857.4070404@jabber.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A2D82C0-5ECC-48AB-8F05-4585EAAD3539@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 14:52:53 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 9:05 AM, Peter Saint-Andre wrote: > I expected the (pre-)I-D that John sent around to map out the lay > of the land in the identity world, explain the gaps left by > existing identity technologies, and define how the work product of > a DIX WG would help to solve problems that cannnot be solved today. > Did I miss that text? Bob wrote something along these lines when the list first started, and he made an eloquent delivery of the same statement at the meeting we had during the November IETF. [Before I get jumped on by an IETF lawyer... that was not an official IETF meeting... just happened to be held at the same time and was attended by IETF attendees.] I'll repost what he wrote. But, what he wrote was perhaps more of a problem statement as a use case. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 17:54:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0599-0004M2-Bn; Fri, 20 Jan 2006 17:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0598-0004Lt-9S for dix@megatron.ietf.org; Fri, 20 Jan 2006 17:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09370 for ; Fri, 20 Jan 2006 17:52:49 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F05Hw-0002RN-Sj for dix@ietf.org; Fri, 20 Jan 2006 18:03:25 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KMsFPJ007182 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 14:54:15 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Fwd: [dix] thoughts on "identity" and IETF Date: Fri, 20 Jan 2006 14:54:11 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Bob's thoughts.... Begin forwarded message: > From: "RL 'Bob' Morgan" > Date: November 9, 2005 3:05:14 PM PST (CA) > To: IETF DIX list > Subject: [dix] thoughts on "identity" and IETF > > > I have been somewhat involved in recent discussions regarding > "identity" (see http://www.identitygang.org/ and a zillion other > blogs and links), as well as a long-time IETF participant, so let > me toss out a brief personal view of what's going on here in hopes > it may provide context useful for some folks. > > Let me say up front that I don't necessarily agree with all the > positions I describe below, but am trying to express what many > people are saying and thinking. > > Many protocols developed in the IETF have served the needs of what > Dick Hardt calls "Identity 1.0", which might be characterized less > flamboyantly as "enterprise identity management". This term > includes several rather different technologies and processes, all > in support of the ability for the owners of services to control who > does what with their computing resources. I use the word > "enterprise" above intentionally, to reflect the fact that > traditionally the parties with interest and ability to control > access to resources have been organizations, usually large ones. > > So, for example, the domain of use of the IETF's LDAP protocol is > large directories containing entries for many users, operated by IT > staff in organizations that have an interest in the users whose > info is in those entries, and the applications that use those > directories. The domain of use of the IETF's Kerberos protocol is > similarly organizations with an interest in secure authentication > to a set of apps relying on an organizational KDC. Similar broad- > brush characterizations could be made of PKIX, TLS, SASL, features > like HTTP Basic/Digest authentication, probably other protocols and > features. > > Note that the scope of "identity" here includes several things. > One is maintenance of information about a person (or other entity), > including not just userid and password but potentially lots of > other information relevant to authorization, contact, perhaps other > purposes. Another is authentication, ie how a service knows "the > identity" of a client. Another is exchange of identity information > between parties, both at authentication time and at other times. > > Out in the world most people's experience of the Internet is of > course the Web, and most people's experience of "Identity 1.0" has > been via account setup and login to a vast array of web-based > services managed by organizations large (mostly) and small. There > have been some non-IETF standard/spec activities that attempt to > address the widely-observed usability problem of people having too > damn many usernames/passwords to remember, as well as security > problems based on that stuff. Perhaps the main one is the OASIS- > published SAML standard, which specifies how to do web sign-on and > attribute exchange. A somewhat similar activity is WS-Federation, > part of the WS-* spec set. These have been called "Identity 1.5" > because they permit some organizations to rely on other > organizations' identity management services, but the use cases > driving the designs are still organization-oriented. > > So is there something missing in the above stuff, some new > requirements requiring new stuff, ie "Identity 2.0"? I think the > people who say there is are motivated by the huge number of new > things that have happened on the web in the last few years. The > center of this is the blogging phenomenon. Maybe 20 million people > are now blogging. They're doing other things like putting lots of > photos online at Flickr, keeping their bookmarks on del.icio.us, > tracking tags on technorati, and zillions of other examples. They > are composing these services in myriad ways to create new > services. In sociological terms they are creating online > identities for themselves that they feel much more attachment to > than their organizational account, even their "my.foo.com" page at > one of the traditional portal sites. In Identity 1.0 terms they > are all becoming, or have an interest in becoming, both service > providers and identity providers, that is, they have an interest in > protecting their resources (in the canonical case of reducing blog > spam), and in leveraging their personal info to their millions of > peers. > > So now in addition to the tens or hundreds of thousands of > institutions with identity interest, there are tens of millions of > individuals. Many people are trying to figure out what they need > and respond to it. The SXIP technology is one among those, others > are OpenID, LID, Passel, and no doubt many others. For the most > part these approaches reject traditional identity management > protocols and systems; whether they should or should not is one of > the big questions. A key point is that the individual interest in > identity is much more about expression, ie ease of sharing and > discovery, than it is in control (ie, fancy security). Another key > point is individual control, the same sort of control people feel > over their personal domain name and its site, or their blog. Even > people who aren't radically anti-corporate like to feel in charge > of their own stuff. > > That's all I have time for now ... > > - RL "Bob" > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 18:10:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F05ON-0003Yn-6V; Fri, 20 Jan 2006 18:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F05OL-0003Xz-RK for dix@megatron.ietf.org; Fri, 20 Jan 2006 18:10:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10526 for ; Fri, 20 Jan 2006 18:08:33 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F05Wx-0002vZ-Cj for dix@ietf.org; Fri, 20 Jan 2006 18:18:56 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KN9fM4007936 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 15:09:42 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 15:09:37 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 7:53 AM, Peter Davis wrote: > We should add to the 'In Scope' section: > > This working group shall include in it's output, informational > material > which results from the assessment of existing specifications, and > limitations or omissions which requires the production of additional > specification(s). > > Which, I suppose, implies another deliverable. I wonder if this is really necessary. If we write up the use cases as a way of defining the problem and in a sense stating the requirements of a solution.... ...and you're suggesting that we then document why existing specifications don't satisfy those requirements. Hmm, I think we should think about it... but documenting it (and most probably getting into some huge arguments) seems like a lot of work to just justify what people are already doing anyway. I'd ask why it is that multiple groups of people have considered the existing specifications and concluded that they'd be better off with something else and gone of and specced and implemented it and started deploying it. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 18:12:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F05R2-0004UK-9q; Fri, 20 Jan 2006 18:12:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F05R1-0004U0-In for dix@megatron.ietf.org; Fri, 20 Jan 2006 18:12:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10637 for ; Fri, 20 Jan 2006 18:11:19 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F05Zp-0002zP-LH for dix@ietf.org; Fri, 20 Jan 2006 18:21:55 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0KNChvu008102 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 15:12:44 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35243121-EB0E-4A2F-B3FF-F0828F2DD78E@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 15:12:40 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 8:50 AM, Johannes Ernst wrote: > it's not like we don't have a plethora of widely implemented > identity and related standards already, why do we need another? > I'd think that question needs to be answered crisply and > convincingly in the charter. > Personally, I can believe that there is some hitherto uncharted > territory in identity land that the IETF could do something about, > but I would also think that that territory needs to be marked in > relationship to other territories by other initiatives, preferably > with very little to zero overlap. I'd recommend that be done from > the get-go, because otherwise dix just sets itself up for sniping. Johannes, Maybe I can politely turn the tables here and solicit your help. Why did you embark on LID, given the plethora out there....? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 19:15:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F06Pp-0005Ax-Ee; Fri, 20 Jan 2006 19:15:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F06Po-0005An-12 for dix@megatron.ietf.org; Fri, 20 Jan 2006 19:15:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14691 for ; Fri, 20 Jan 2006 19:14:07 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F06Yc-0004my-ER for dix@ietf.org; Fri, 20 Jan 2006 19:24:43 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0L0FUjC009900 for ; Fri, 20 Jan 2006 19:15:30 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0L0FU113410 for ; Fri, 20 Jan 2006 19:15:30 -0500 Received: from [172.16.25.141] (dhcp-172-16-25-141.sfbay.redhat.com [172.16.25.141]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0L0FShD020497 for ; Fri, 20 Jan 2006 19:15:29 -0500 Message-ID: <43D17D20.6080509@redhat.com> Date: Fri, 20 Jan 2006 16:15:28 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] dmd01: persona-url, data References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> <43D15810.2050905@redhat.com> <025B547C-2585-45E1-B37D-E6FB77D0777C@sxip.com> In-Reply-To: <025B547C-2585-45E1-B37D-E6FB77D0777C@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0882704587==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0882704587== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040809020201090009060008" This is a cryptographically signed message in MIME format. --------------ms040809020201090009060008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: >> Different names? So, are you saying the sxip#1 capabilities only come from sxip and if >> I want to supply say, a user first name, from some other authority I would need to >> name the property differently? > > With dmd1yes. The query mechanism is super brain dead simple... you > can reference a property value and that's it. > So, what is a home site to do if sxip attributes are requested? Run off to sxip.net with an intermediate request (utilizing a previously agreed trust), or send the user as a membersite with a fetch-request, fail the request? Seems to me that the membersite ought to be getting those attributes from sxip.net, who is acting as a home site, nobody else needs to be involved - not even the draft :) > > Or we could extend the query language to make this type part of the > request, but I'm trying to avoid yet another query language... Perhaps this is the missing dix#1 capabilities, but the benefits of this are substantially reduced if instead of identity silos, we end up with attribute silos. The example attributes that are sxip#1 in that document are prime candidates for dix#1, and sxip#1 if anything, should be a separate draft detailing that schema - and btw, where do the dix#1 capabilities fit into this model, who supplies those, or is dix#1 the (to come) common schema as I am hoping? I have to say I am not sold on the idea of compartmentalizing properties first by source. I would rather see a property type schema where the source of the property is not tied down, only its meaning. The source of the property can be disclosed (as a signature) for those membersites that care, then user supplied attributes may simply not be signed. In fact, in many common cases the source _will_ be the user anyway. dix use case: About 10 years ago I realized amazon basically had the monopoly on my book buying, then video buying, then whatever because the barrier for me was filling out another form with a bunch of details I don't have memorized. Nothing has changed in those 10 years. So, I want to go to Barnes and Noble and buy a book without filling out any forms, and without "joining" the website in any way, I want a one time transaction just like I get in a store, and given that I am authenticated with my homesite I want a one click transaction. All details supplied are no more or less trustworthy than those I would type in myself even if my browser were acting as the homesite. This doesn't work if I have amazon#1 properties and B&N want B&N#1 properties. It should be hard for that situation to arise, and the least path of resistance should be an ietf draft detailing the generic schema. -- Pete --------------ms040809020201090009060008 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjAxMjEwMDE1MjhaMCMGCSqGSIb3DQEJBDEWBBQCLyg9LlWtUc4w RmlP5DKiLPYB9TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAl5S2AbPkopOSisS2nGLocn305VmF9bcqMOy+l1ESMn3pqQ2hCb5f/j52QrQK +puq0TtlhUDwndD+GwASDSefq72Ir1gZ+hBrPNWCwAM3r+84K5GyFJ2aR7fM4Do8DZPfjung t2zVePrdEaJ+Sw2abEj779WTrjZyyXQHYkEypsrUeoSGr4yCG0MfsmLk7xmmj7/mYStbZbn0 /e6szbZoMJKUWNtg5xSqo1JQODLAraF26VsFOyEhNzP6Q7JAIQpfzfz4qX9jmbzSVHlUGKZA kOr6aNy9kzDqV1/s92YLAfneICb8Ni7mjPTd4S9PT204tXtfHwnyHBz0M9iiHeg9jAAAAAAA AA== --------------ms040809020201090009060008-- --===============0882704587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0882704587==-- From dix-bounces@ietf.org Fri Jan 20 19:45:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F06tB-0000Rx-Jb; Fri, 20 Jan 2006 19:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F06tA-0000RF-Hz for dix@megatron.ietf.org; Fri, 20 Jan 2006 19:45:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16904 for ; Fri, 20 Jan 2006 19:44:27 -0500 (EST) Message-Id: <200601210044.TAA16904@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F071z-0005fc-CF for dix@ietf.org; Fri, 20 Jan 2006 19:55:04 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc13) with SMTP id <2006012100454401500g0rboe>; Sat, 21 Jan 2006 00:45:45 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 16:45:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYd0Fv3mj9DAInDEdq6NAANk3jHKAAINZGQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > SIP presently has means to 'prove' the identity of the calling party sip > identity [1] which supplies a new header (and some hash/signing). While it > is presently in ID, it is header to RFC editor queue. > > It would be for the SIP WG to draft a binding of 'dix' with sip-identity, > IMHO. At least for the purposes laid out in the above use case. It's in the draft "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)". It assumes identity is defined for SIP, but is not cryptographically secure. From the draft: "The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context." "An identity, for the purposes of this document, is defined as a SIP URI, commonly a canonical address-of-record (AoR) employed to reach a user (such as 'sip:alice@atlanta.example.com')." "This document defines a new role for SIP entities called an authentication service." The draft is of course motivated by a need for authenticating identity but I worry about yet another separate but incompatible scheme for SIP. There is also a proposal to bind SAML to SIP titled "Using SAML for SIP". And from the SIP charter (http://www.ietf.org/html.charters/sip-charter.html): In addition to extending SIP as required to address these externally- derived requirements, the deliverables of the group include assuring capable security and privacy mechanisms within SIP and increasing the stability of the SIP specification. Specific deliverables toward these goals include: 1. Mechanisms for secure expression of identity in requests and responses. 3. Guidelines for use of existing security mechanisms such as TLS, IPsec, and certificates. 4. Guidelines for the use of descriptive techniques such as SAML (Security Association Markup Language) with SIP. Some future DIX binding for SIP will help add to the confusion. Of course it's par for the course to throw everything under the sun into SIP. And the charter actually states simplicity as its goal... I can't wait until every application or network WG has its own version of identity, none of which will interoperate. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Peter Davis Sent: Friday, January 20, 2006 6:47 AM To: Digital Identity Exchange; david_list@boreham.org Subject: Re: [dix] draft of proposed charter (#2) On 1/19/2006 9:38 PM, "John Merrells" wrote: > ... but I might be on a call to a call center and they ask me to > prove something about me... right now they ask a bunch of > questions... SSN, MMN, DOB... with DIX over SIP they might > be able to send the request to my client and assuming it > had the appropriate interface (ie capabilities) it could ask > me if i wanted to reveal that identity information... i'd click > yes and it'd be revealed. Which sounds quite nice to me. SIP presently has means to 'prove' the identity of the calling party sip-identity [1] which supplies a new header (and some hash/signing). While it is presently in ID, it is header to RFC editor queue. It would be for the SIP WG to draft a binding of 'dix' with sip-identity, IMHO. At least for the purposes laid out in the above use case. =peterd (http://public.xdi.org/=peterd) [1] http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 20:36:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F07gC-0001Ci-A9; Fri, 20 Jan 2006 20:36:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F07gB-0001CY-A1 for dix@megatron.ietf.org; Fri, 20 Jan 2006 20:36:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19488 for ; Fri, 20 Jan 2006 20:35:08 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F07p0-0006uS-I3 for dix@ietf.org; Fri, 20 Jan 2006 20:45:43 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L1aNWp012337 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 17:36:24 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D13790.9050001@thinkingcat.com> References: <43D13790.9050001@thinkingcat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Fri, 20 Jan 2006 17:36:22 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 11:18 AM, Leslie Daigle wrote: > It is clearer, but I think the charter still needs to be > clearer about what is meant by "digital identity". Is > the purpose to be able to access *any* stored data about > a person, or *specific* stored data? 'any'... but the relying party has to know the name of the thing it's asking for. > In many regards, saying "any" is easier; sort out the format > for expressing attribute/values, and you're done. Yes, that's been the plan so far. Other's can provide the names of the attributes and the syntax and semantics of the values. That could be done in the IETF, or in another standards body, or by industry consortia, or just be a free for all folksonomy kind of thing > However, > then there are issues of interoperability (is there a minimum > set of identity data that is mandatory to provide?). Mmm, I'd say 'no', but Scott might say 'yes'. I'm reluctant to end up down the schema rathole arguing over things like mobilephone versus cellphone... for example. > And, if it is "any", then how is this not a directory service > with additional labelling (addresses/names/identifiers) on top? I think that the DIX and LDAP information models will turn out to be very similar indeed. But I don't think that's what distinguishes user's agent from a directory service. In the directory centric model the user informs the relying party of their DS and the RP does a search against the DS for the user's attributes, perhaps using some credentials provided by the user, or with some credentials provided to the RP by the DS beforehand. In the user centric model the RP requests some data from the user who forwards the request to their agent, selecting the data items, providing consent for their release and then forwards them to the RP. Same parties, different protocol flow... with greater user privacy. Kim Cameron's 'Seven Identity Laws', make it pretty clear why the directory centric model doesn't work for digital identity, and explains why Microsoft Passport was not widely adopted outside of the MSN universe. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 20:50:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F07tz-0006TW-1f; Fri, 20 Jan 2006 20:50:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F07tx-0006Su-5S for dix@megatron.ietf.org; Fri, 20 Jan 2006 20:50:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20142 for ; Fri, 20 Jan 2006 20:49:21 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F082n-0007DT-JY for dix@ietf.org; Fri, 20 Jan 2006 20:59:58 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L1oeuw012865 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 17:50:40 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D17D20.6080509@redhat.com> References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> <43D15810.2050905@redhat.com> <025B547C-2585-45E1-B37D-E6FB77D0777C@sxip.com> <43D17D20.6080509@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] dmd01: persona-url, data Date: Fri, 20 Jan 2006 17:50:39 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 4:15 PM, Pete Rowley wrote: >> With dmd1yes. The query mechanism is super brain dead simple... >> you can reference a property value and that's it. >> > So, what is a home site to do if sxip attributes are requested? > Run off to sxip.net with an intermediate request (utilizing a > previously agreed trust), or send the user as a membersite with a > fetch-request, fail the request? Seems to me that the membersite > ought to be getting those attributes from sxip.net, who is acting > as a home site, nobody else needs to be involved - not even the > draft :) There's no connection between the names of the attributes and where the attribute values are actually stored. I can store 'dix://sxip.net/ name=john' anywhere I want to. The idea of the authority in the name is to provide anyone with a domain name their own piece of namespace to create whatever property names they want. >> Or we could extend the query language to make this type part of the >> request, but I'm trying to avoid yet another query language... > > Perhaps this is the missing dix#1 capabilities, but the benefits of > this are substantially reduced if instead of identity silos, we end > up with attribute silos. The example attributes that are sxip#1 in > that document are prime candidates for dix#1, and sxip#1 if > anything, should be a separate draft detailing that schema - and > btw, where do the dix#1 capabilities fit into this model, who > supplies those, or is dix#1 the (to come) common schema as I am > hoping? > > I have to say I am not sold on the idea of compartmentalizing > properties first by source. I think most of this comment was based on your misunderstanding above... so no silos.... > I would rather see a property type schema where the source of the > property is not tied down, only its meaning. The source of the > property can be disclosed (as a signature) for those membersites > that care, then user supplied attributes may simply not be signed. > In fact, in many common cases the source _will_ be the user anyway. That's exactly what I think we need and what I believe dmd1 enables. > dix use case: > > About 10 years ago I realized amazon basically had the monopoly on > my book buying, then video buying, then whatever because the > barrier for me was filling out another form with a bunch of details > I don't have memorized. Nothing has changed in those 10 years. > So, I want to go to Barnes and Noble and buy a book without filling > out any forms, and without "joining" the website in any way, I want > a one time transaction just like I get in a store, and given that I > am authenticated with my homesite I want a one click transaction. > All details supplied are no more or less trustworthy than those I > would type in myself even if my browser were acting as the homesite. > > This doesn't work if I have amazon#1 properties and B&N want B&N#1 > properties. It should be hard for that situation to arise, and the > least path of resistance should be an ietf draft detailing the > generic schema. Great example of the rathole I don't want this group to go down. There are various social models for working out agreements for the names of things. Standards bodies seem to be a pretty bad one. XML dodged this one quite nicely, creating a schema language and devolving the problem to those who cared most about resolving them. I don't really want to get too into this now though. Another great conversation best handled over a beer? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 22:16:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09FI-0004lT-Dp; Fri, 20 Jan 2006 22:16:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09FH-0004lO-87 for dix@megatron.ietf.org; Fri, 20 Jan 2006 22:16:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25177 for ; Fri, 20 Jan 2006 22:15:27 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F09O6-0000wT-U4 for dix@ietf.org; Fri, 20 Jan 2006 22:26:04 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L3GfSd015009 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 19:16:42 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 19:16:40 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 10:27 AM, Scott Hollenbeck wrote: > OK, I agree with the "why HTTP" question. That's one you guys need to > figure out. I'm telling you now, though, that a charter that does not > describe at least one method to produce interoperable > implementations will > not be approved by the IESG. I've been chewing this over all day: We can't mandate that the other party in the exchange implement DIX over a particular transport. It's an implementation decision between the user's client and the other party. We have the motivating use cases of a VOIP phone or IM client to illustrate this. We could mandate the transport between the user's client and their agent. HTTP perhaps... given its simplicity and ubiquity. I do hesitate though, because I'm sure there are use cases where that doesn't make sense. For example my agent might actually be built into my client so the transport is IPC or API. What use would that kind of agent be?... well it could just be a local replica of my agent in the internet. Hmm, is my local agent really just an agent of my agent and therefore a non-principal party to the exchange. Agh. What if my agent were on a USB key or a smart card? What would my transport be then... I'm not sure... I suppose it could be HTTP... We could state: "To ensure interoperability between implementations we mandate that the user's client and their agent must support at least DIX over HTTP." It's hard to be definitive about this without the use cases to refer to... I'd appreciate any comments you folk on the list have about this. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 22:23:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09Lh-0006Yv-IF; Fri, 20 Jan 2006 22:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09Lf-0006XW-Fl for dix@megatron.ietf.org; Fri, 20 Jan 2006 22:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25460 for ; Fri, 20 Jan 2006 22:22:03 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F09UU-00015a-GO for dix@ietf.org; Fri, 20 Jan 2006 22:32:41 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0L3NLiH027000 for ; Fri, 20 Jan 2006 22:23:21 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0L3NK115057 for ; Fri, 20 Jan 2006 22:23:20 -0500 Received: from [172.16.25.141] (dhcp-172-16-25-141.sfbay.redhat.com [172.16.25.141]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0L3NJhD029217 for ; Fri, 20 Jan 2006 22:23:19 -0500 Message-ID: <43D1A926.6030209@redhat.com> Date: Fri, 20 Jan 2006 19:23:18 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] dmd01: persona-url, data References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> <43D15810.2050905@redhat.com> <025B547C-2585-45E1-B37D-E6FB77D0777C@sxip.com> <43D17D20.6080509@redhat.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0280598567==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0280598567== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070408070602080305060402" This is a cryptographically signed message in MIME format. --------------ms070408070602080305060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > I think most of this comment was based on your misunderstanding > above... so no silos.... > My misunderstanding is based on the fact that the sxip attributes are in the document yet apparently only sxip.net can supply the values (no matter where they are stored). In that case I don't understand a) why they are documented since there does not appear to be point of interoperability (these are for your website?), b) why a homesite would need to explicitly "support" the sxip#1 capability and advertise that support, since for the homesite they are opaque attributes and it can either choose to allow the storage of opaque random attributes or not, and any one user either has those attributes or not - or is this a crude form of access control for homesite storage?, where is the capable in capability? and c) what exactly is the homesite expected to do to "tailor its response" when presented with the dix:/membersite-accept when it has no real knowledge of the attributes involved beyond what they are called (and presumably the membersite requests only what it does understand.) Sorry to bang on about this, but I am actually trying to cut code here :) >> I would rather see a property type schema where the source of the >> property is not tied down, only its meaning. The source of the >> property can be disclosed (as a signature) for those membersites >> that care, then user supplied attributes may simply not be signed. >> In fact, in many common cases the source _will_ be the user anyway. > > > That's exactly what I think we need and what I believe dmd1 enables. > What I mean by "meaning" is really the "universally understood meaning" - not one meaning that only one entity understands . Without universally understood meanings for a set of defined attributes dix would merely be a means to use somebody elses hard drive for data storage. There may be value in that for all parties, but the greater value is when everyone talks the same language, not just the same protocol. > There are various social models for working out agreements for the > names of things. None of which work terribly well once you switch on the computer, but I'll agree not to mention it again until you buy me a pint. -- Pete --------------ms070408070602080305060402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjAxMjEwMzIzMThaMCMGCSqGSIb3DQEJBDEWBBR6hcknMOuNejC7 Sx+JFpzFA8LiRDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAtFQTJpTCXfiLa1Asfi4bA0I1gkXaVWT9nOI0ZlKidVB/HePwsJPtsn0aRxig b1PACpby1k7uiPnt+IxBknDpHGg80IEMWmj+SvR1E9slAp4xCg00CSJi8UV+1pxbB5nIT9DO 04BNmT+BuOrWUiYgZ+SrO+f0oH4wd02qnX9MKp1mHPReVzdVYqeqY8w8oZyuP9bB69XqyCcc VmoldWW9N6vmxCGsUTBI/HMeijZJr5U0WZ9VxUhVU3txPNjWh6+BsA8byWy9+GvTq8ah3EkE eh0fG5GFWt1ssN1ty6P2m2pfRLmVe+YE2197L6zzLzD1dDGmjPlzxR0h66biUJOMtwAAAAAA AA== --------------ms070408070602080305060402-- --===============0280598567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0280598567==-- From dix-bounces@ietf.org Fri Jan 20 22:34:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09Vw-0001q7-IU; Fri, 20 Jan 2006 22:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09Vu-0001q2-L4 for dix@megatron.ietf.org; Fri, 20 Jan 2006 22:34:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25934 for ; Fri, 20 Jan 2006 22:32:38 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F09el-0001HQ-Vs for dix@ietf.org; Fri, 20 Jan 2006 22:43:16 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0L3XwXP029129 for ; Fri, 20 Jan 2006 22:33:58 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0L3Xu117661 for ; Fri, 20 Jan 2006 22:33:57 -0500 Received: from [172.16.25.141] (dhcp-172-16-25-141.sfbay.redhat.com [172.16.25.141]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0L3XphD029615 for ; Fri, 20 Jan 2006 22:33:53 -0500 Message-ID: <43D1AB9E.5070005@redhat.com> Date: Fri, 20 Jan 2006 19:33:50 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1701346110==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1701346110== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090107030209040801040803" This is a cryptographically signed message in MIME format. --------------ms090107030209040801040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > > On 20-Jan-06, at 10:27 AM, Scott Hollenbeck wrote: > >> OK, I agree with the "why HTTP" question. That's one you guys need to >> figure out. I'm telling you now, though, that a charter that does not >> describe at least one method to produce interoperable >> implementations will >> not be approved by the IESG. > > > I've been chewing this over all day: > > We can't mandate that the other party in the exchange implement Isn't the point of issue here that there needs to be documented a way to (stealing the words) "produce interoperable implementations" so that it can be shown that it _works_ by having "interoperable implementations" - this isn't a question of mandating anything, but codifying how using the protocol over one method of transport would work. > "To ensure interoperability between implementations we mandate > that the user's client and their agent must support at least DIX > over HTTP." > So rather than this, a document describing the protocol over, say, HTTP would be a deliverable. -- Pete --------------ms090107030209040801040803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjAxMjEwMzMzNTBaMCMGCSqGSIb3DQEJBDEWBBSm3c7bbNm/ZD91 tNlStuGfRBeCJjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAbDCkwsawelYY29UsQeQyxCyPit96RsY1YRp2Q31MAQIYJSahwKmj1040in74 CD1ex1jZBTS0+FmwV7QS+42R2ys+iOWic1469K8yzdPlL+IzcO6RzNg6Yuit/aT43CmEDPI7 5WQwZKSthgL1Fm5g+O+ZkGwhXNssVfI/6L6f6cNGKk/hSQuJK1OTKMz2KIRtu0EpZkAZwGzl 9xpw+F/CIGZqCRjEAB6OpA9+jRYcn1GrUgM5p46FlfmFZDaM+u3wIF2T3oGshNDOldUCuyBu 3kb+1ialnwJYd0H7amnQ3wif6we2Uwe+b9XKbFTkXKTF9sM+e/0+xZrGtfIBbeQSSgAAAAAA AA== --------------ms090107030209040801040803-- --===============1701346110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1701346110==-- From dix-bounces@ietf.org Fri Jan 20 22:56:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09rx-0001v7-0c; Fri, 20 Jan 2006 22:56:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09ru-0001s4-NF for dix@megatron.ietf.org; Fri, 20 Jan 2006 22:56:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27336 for ; Fri, 20 Jan 2006 22:55:22 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0A0k-0001tX-JP for dix@ietf.org; Fri, 20 Jan 2006 23:06:00 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L3uh0Z015722 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 19:56:44 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D1A926.6030209@redhat.com> References: <64D18371-9C29-416F-9813-D6F1D94111E5@sxip.com> <43D13E96.2000303@redhat.com> <43D15810.2050905@redhat.com> <025B547C-2585-45E1-B37D-E6FB77D0777C@sxip.com> <43D17D20.6080509@redhat.com> <43D1A926.6030209@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] dmd01: persona-url, data Date: Fri, 20 Jan 2006 19:56:41 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 7:23 PM, Pete Rowley wrote: > John Merrells wrote: > >> I think most of this comment was based on your misunderstanding >> above... so no silos.... >> > My misunderstanding is based on the fact that the sxip attributes > are in the document There are some example property names from the sxip.net authority, but you can use anything you want. I could publish the ones we've been using as another ID, or in an appendix of a revision of this ID... but I don't want to mandate that anyone should use them. It'd be nice if they did of course. > yet apparently only sxip.net can supply the values (no matter where > they are stored). Nope. What in dmd1 gives you that impression? It might be the capabilities definition stuff... only sxip.net can tell you the type information for that property name. > In that case I don't understand > > a) why they are documented since there does not appear to be point > of interoperability (these are for your website?), They're not, but could be. I could publish them as a document on sxip.org... then you could take a look at them and see if they make sense for your application. > b) why a homesite would need to explicitly "support" the sxip#1 > capability and advertise that support, since for the homesite they > are opaque attributes and it can either choose to allow the storage > of opaque random attributes or not, and any one user either has > those attributes or not - or is this a crude form of access control > for homesite storage?, where is the capable in capability? Well a capability is both services and properties. I think you mean why would a homesite want to advertise that it knew about a particular family of properties. But, yes. In a sense the Homesite is advertising what schema it knows about. It could choose to operate in such a way that it only stores properties that it knows about. Personally I think that'd suck. But, given a set of Homesites a Membersite could chose the one most appropriate for fetching or storing a particular property. Key to Homesite popularity will be the UI/UX and that will be strongly tied to what the properties are. As a user I'd want my DVD wish list at the Homesite with the best UX/UI for that rather than for the one with none at all. > and c) what exactly is the homesite expected to do to "tailor its > response" when presented with the dix:/membersite-accept when it > has no real knowledge of the attributes involved beyond what they > are called (and presumably the membersite requests only what it > does understand.) Accept is mostly for the services part of the capabilities. For example the authentication mechanisms used. Maybe the Membersite can say that it can deal with particular security tokens... > Sorry to bang on about this, but I am actually trying to cut code > here :) Which is why your questions are so excellent :) >> That's exactly what I think we need and what I believe dmd1 enables. >> > What I mean by "meaning" is really the "universally understood > meaning" - not one meaning that only one entity understands . > Without universally understood meanings for a set of defined > attributes dix would merely be a means to use somebody elses hard > drive for data storage. There may be value in that for all > parties, but the greater value is when everyone talks the same > language, not just the same protocol. Amen, and I refer you to our friends in the semantic web community.... However, people have over time come to agreement over what things are called. I think it's out of scope for this group what things are called, or even how people should come to agreement on that. It'll happen, but not here. Don't get me wrong I want this to happen... and I'll publish the names we're using in sxip.net... and I hope lots of people will use them. >> There are various social models for working out agreements for >> the names of things. > > None of which work terribly well once you switch on the computer, > but I'll agree not to mention it again until you buy me a pint. Sure, after that we can sort out the whole world peace and hunger thing too ;-) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 20 23:13:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0A8P-0008QA-ML; Fri, 20 Jan 2006 23:13:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0A8M-0008Q2-6u for dix@megatron.ietf.org; Fri, 20 Jan 2006 23:13:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28240 for ; Fri, 20 Jan 2006 23:12:21 -0500 (EST) Received: from [209.172.111.2] (helo=IPOfCard1.guest-tek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0AHC-0002Km-4R for dix@ietf.org; Fri, 20 Jan 2006 23:22:59 -0500 Received: from [172.16.1.2] (localhost.localdomain [127.0.0.1]) by IPOfCard1.guest-tek.com (8.11.6/8.11.6) with ESMTP id k0L4DX600462 for ; Fri, 20 Jan 2006 21:13:33 -0700 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <43D13790.9050001@thinkingcat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5876CF9B-698C-491D-B941-B7237A7A73F2@oracle.com> Content-Transfer-Encoding: 7bit From: Phil Hunt Subject: Re: [dix] draft proposed charter - consensus? Date: Fri, 20 Jan 2006 20:13:40 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org John Directory Centric Model doesn't work? I agree completely. Pretty amazing for an LDAP guy! However, I would argue strongly that both the directory repository (database or whatever) and the user centric model are needed. Example, you have your driver's license, but the government has a database that has all the details on all licenses issued and whether it is revoked and how many points you have lost (gee...starting to sound like PKI all over again ;-) ). Also, no matter what happens with directory or identity exchange, there will always be the application that has to store data. Where this all breaks down is what happens when the application needs to maintain context. In this sense, I'm worried about what happens when the user chooses to present a different credential each time. This actually makes life for the application programmer even more difficult. In the end he has to ask more questions like what is your social sec number or SIN. Hmmm....pretty soon we end up repeating history. The key is NOT to build a system that is 100% one way or the other. The huge uber directory definitely won't work. Neither will the "user" uber-card. What we need is an easy-to-use and manage and safe system that combines the 7-laws and the correct mix of technologies. Just like routers made it easy to inter-connect discreet networks into the huge global network we take for granted, we really need an ecosystem to link assertions and authorities in verifiable, portable, and secure ways. I think there are really two macro profiles to think about -- "Session" and "Storage" modes. Session mode is really where we see SAML, SXIP and others playing (the 2.0 team) - where one application wants to pass data or assertions on to another service with a portable assertion. The still important "storage mode" is where all the authoritative stores that comprise the permanent data goes to and comes from when the session based application needs to assert or consume something. Phil Hunt Note: These comments represent my own personal opinions and do not necessarily represent those of Oracle. On 20-Jan-06, at 5:36 PM, John Merrells wrote: > > On 20-Jan-06, at 11:18 AM, Leslie Daigle wrote: > >> It is clearer, but I think the charter still needs to be >> clearer about what is meant by "digital identity". Is >> the purpose to be able to access *any* stored data about >> a person, or *specific* stored data? > > 'any'... but the relying party has to know the name of > the thing it's asking for. > >> In many regards, saying "any" is easier; sort out the format >> for expressing attribute/values, and you're done. > > Yes, that's been the plan so far. Other's can provide the > names of the attributes and the syntax and semantics of > the values. That could be done in the IETF, or in another > standards body, or by industry consortia, or just be a > free for all folksonomy kind of thing > >> However, >> then there are issues of interoperability (is there a minimum >> set of identity data that is mandatory to provide?). > > Mmm, I'd say 'no', but Scott might say 'yes'. I'm reluctant > to end up down the schema rathole arguing over things > like mobilephone versus cellphone... for example. > >> And, if it is "any", then how is this not a directory service >> with additional labelling (addresses/names/identifiers) on top? > > I think that the DIX and LDAP information models will > turn out to be very similar indeed. But I don't think that's > what distinguishes user's agent from a directory service. > > In the directory centric model the user informs the > relying party of their DS and the RP does a search > against the DS for the user's attributes, perhaps > using some credentials provided by the user, or > with some credentials provided to the RP by the > DS beforehand. > > In the user centric model the RP requests some > data from the user who forwards the request to > their agent, selecting the data items, providing > consent for their release and then forwards them > to the RP. > > Same parties, different protocol flow... with greater > user privacy. Kim Cameron's 'Seven Identity Laws', > make it pretty clear why the directory centric model > doesn't work for digital identity, and explains why > Microsoft Passport was not widely adopted outside > of the MSN universe. > > John > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jan 21 00:04:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Avn-0002zp-S1; Sat, 21 Jan 2006 00:04:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Avl-0002yb-U0 for dix@megatron.ietf.org; Sat, 21 Jan 2006 00:04:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01249 for ; Sat, 21 Jan 2006 00:03:25 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0B4d-0003kV-GU for dix@ietf.org; Sat, 21 Jan 2006 00:14:03 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L54iYC017189 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 21:04:45 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <5876CF9B-698C-491D-B941-B7237A7A73F2@oracle.com> References: <43D13790.9050001@thinkingcat.com> <5876CF9B-698C-491D-B941-B7237A7A73F2@oracle.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E7B8E69-9D53-47EB-BA14-781A5659E826@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft proposed charter - consensus? Date: Fri, 20 Jan 2006 21:04:39 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 8:13 PM, Phil Hunt wrote: > John > > Directory Centric Model doesn't work? Well, I didn't make quite as bold a statement as that, but within the context of end users roaming about on Internet it hasn't helped them create a portable digital identity... > I agree completely. Pretty amazing for an LDAP guy! However, I > would argue strongly that both the directory repository (database > or whatever) and the user centric model are needed. Yes indeed. > Example, you have your driver's license, but the government has a > database that has all the details on all licenses issued and > whether it is revoked and how many points you have lost > (gee...starting to sound like PKI all over again ;-) ). Maybe not the best example, but if I were a government agency then the DCM might work for me because I have the connections and the expertise to establish the trust and federation relationships to make it work. But if I'm putting up website to be an intermediary between users and insurance companies then the UCM is probably better... I might ask the user to provide me with a claim that within a year they've held a clean license. The user might already have one... or they can go get one from the state government from where ever they reside. Much quicker and cheaper and possibly as realtime as needed to get an insurance quote... right now that's all self asserted... so this is better. > Also, no matter what happens with directory or identity exchange, > there will always be the application that has to store data. Where > this all breaks down is what happens when the application needs to > maintain context. Don't really grok that. They app can store it's session or user associated state local to itself, on the users client if it allows it (cookie), in it's own property in the agent (if the user allows it). (In dmd1 we even allow state to be added to the request message for return with the response message.) > In this sense, I'm worried about what happens when the user chooses > to present a different credential each time. Do you mean identifier? That's a good thing for the user. > This actually makes life for the application programmer even more > difficult. Makes no difference. Makes it harder for them to track the user across space and time, which is a good thing. If they want to do that they should negotiate it with the users like the supermarkets do in meat space. Customer tracking card for a 5% discount, sir? yes please don't mind if I do. > In the end he has to ask more questions like what is your social > sec number or SIN. Hmmm....pretty soon we end up repeating history. User's won't accept that, so app programmer won't do it. They'll have to offer the users something in return for tracking them. > The key is NOT to build a system that is 100% one way or the > other. The huge uber directory definitely won't work. Neither will > the "user" uber-card. Sure, horses for courses. > What we need is an easy-to-use and manage and safe system that > combines the 7-laws and the correct mix of technologies. Just like > routers made it easy to inter-connect discreet networks into the > huge global network we take for granted, we really need an > ecosystem to link assertions and authorities in verifiable, > portable, and secure ways. Here here. > I think there are really two macro profiles to think about -- > "Session" and "Storage" modes. Session mode is really where we > see SAML, SXIP and others playing (the 2.0 team) - where one > application wants to pass data or assertions on to another service > with a portable assertion. The still important "storage mode" is > where all the authoritative stores that comprise the permanent data > goes to and comes from when the session based application needs to > assert or consume something. Well yes, there's protocols, and there's endpoints.... that's pretty much a given. Do you work for a storage company Phil? :-P John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jan 21 00:08:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0AzS-0003pq-3m; Sat, 21 Jan 2006 00:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0AzQ-0003pc-F1 for dix@megatron.ietf.org; Sat, 21 Jan 2006 00:08:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01439 for ; Sat, 21 Jan 2006 00:07:12 -0500 (EST) Message-Id: <200601210507.AAA01439@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0B8H-0003q6-Pb for dix@ietf.org; Sat, 21 Jan 2006 00:17:51 -0500 Received: from sureshmobile (c-67-170-82-35.hsd1.wa.comcast.net[67.170.82.35]) by comcast.net (rwcrmhc11) with SMTP id <20060121050826013007lru9e>; Sat, 21 Jan 2006 05:08:27 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Fri, 20 Jan 2006 21:08:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYeO9Hl232JW8COSpy76K21kRj25wAC7hYg In-Reply-To: <43D1AB9E.5070005@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >> "To ensure interoperability between implementations we mandate >> that the user's client and their agent must support at least DIX >> over HTTP." >> > So rather than this, a document describing the protocol over, say, HTTP > would be a deliverable. Actually, this was already part of both proposals: Goals and Milestones: 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 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Pete Rowley Sent: Friday, January 20, 2006 7:34 PM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) John Merrells wrote: > > On 20-Jan-06, at 10:27 AM, Scott Hollenbeck wrote: > >> OK, I agree with the "why HTTP" question. That's one you guys need to >> figure out. I'm telling you now, though, that a charter that does not >> describe at least one method to produce interoperable >> implementations will >> not be approved by the IESG. > > > I've been chewing this over all day: > > We can't mandate that the other party in the exchange implement Isn't the point of issue here that there needs to be documented a way to (stealing the words) "produce interoperable implementations" so that it can be shown that it _works_ by having "interoperable implementations" - this isn't a question of mandating anything, but codifying how using the protocol over one method of transport would work. > "To ensure interoperability between implementations we mandate > that the user's client and their agent must support at least DIX > over HTTP." > So rather than this, a document describing the protocol over, say, HTTP would be a deliverable. -- Pete _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jan 21 01:08:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0BvV-0000se-CI; Sat, 21 Jan 2006 01:08:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0BvT-0000sZ-Cv for dix@megatron.ietf.org; Sat, 21 Jan 2006 01:08:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04124 for ; Sat, 21 Jan 2006 01:07:10 -0500 (EST) Received: from [216.148.227.153] (helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0C4L-0005AE-S1 for dix@ietf.org; Sat, 21 Jan 2006 01:17:50 -0500 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc13) with SMTP id <2006012106082601500gotnke>; Sat, 21 Jan 2006 06:08:26 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> Content-Type: multipart/mixed; boundary=Apple-Mail-548-602713477 Message-Id: <460C8C0D-2DA0-4D60-93C6-B3E2B03858B5@netmesh.us> From: Johannes Ernst Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 22:08:23 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --Apple-Mail-548-602713477 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hmmm ... so if you intend dix to be a place where a solution for interoperability is standardized of technologies like the ones you mention ... then: - it seems clear (to me at least) that other de-jure standards efforts largely do not apply ... that's good (and it answers a big part of my question, thank you) - but you also say that we should just be codifying existing practice ... which existing practice are you referring to? As far as I know, the only technology that makes some of the technologies you listed interoperate so far (and only partially, because SXIP is not involved) is YADIS... I have the proof right here on my machine that it works beautifully between LID and OpenID implementations of at least four different vendors already ... so I'm a little unclear what exactly are you proposing? Johannes Ernst NetMesh Inc. --Apple-Mail-548-602713477 Content-Type: image/gif; x-unix-mode=0666; name="lid.gif" Content-Disposition: inline; filename=lid.gif Content-Transfer-Encoding: base64 R0lGODlhJAAOAPcXMf////////////////////////////////////////////////////////// ///////////////////////////////exv/exv/exv/exv/exv/exv/exv/exv/exv/exv/exv/e xv/exv/exv/exv/exv/exv/exv/exv/exv/exv/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/O pf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1 hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+MQv+MQv+MQv+MQv+MQv+M Qv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv9jAP9jAP9j AP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAPfv 5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv 5/fv5/ethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPet hPethPethPethOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOda AOdaAOdaAOdaAOdaAOdaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZa ANZaANZaANZaANZaANZaANZaANZaAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZS AMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsx AHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAAAAACwAAAAAJAAOAAAIsgABCBy4 oqDBgwgTGhzIkOGKNRAjSpxIMaKqhg4ratwI8SLGhxGrALAwUSTJNSIHnoz4qyHIkCOpSTQp02Ql ICMpEqRo8tfMkT5FrggKoMrEli9/rpAJcynKmBBzHlVVsedPC0QtMJUqMR2AqlBhan06VqTRrgN9 /gQEpK1RmmR/mZzolaFaiCkHAiFbk+FKiHUbHqVGmDDEX9TUIi6MFqPAuxwjB3b8NZ3ly5gza7aM MSAAOw== --Apple-Mail-548-602713477 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit http://netmesh.info/jernst On Jan 20, 2006, at 13:27, John Merrells wrote: > On 20-Jan-06, at 8:50 AM, Johannes Ernst wrote: > >> I haven't seen a lot of discussion so far why the IETF needs to >> get into identity standards. How does this group answer the >> question: it's not like we don't have a plethora of widely >> implemented identity and related standards already, why do we need >> another? > > There was some discussion on this topic before you joined the list. > >> I'd think that question needs to be answered crisply and >> convincingly in the charter. > > This was actually in the first charter written (draft #0 if you > like) but > we were advised that it didn't belong there, so I took it out. This is > what it said... > > > Why should the IETF be involved? > > The IETF's role is to provide an open venue and process within > which disparate interests can come together to agree on an > interoperable solution to this problem. There are multiple teams > with the same motivations working on similar solutions. For > example: Sxip, LID, OpenID, and Passel. We are driven by a desire > to quickly solve a shared problem for the benefit of all. > > This is an Internet scale problem. Our work will benefit > individuals with an online presence who are currently hampered by a > lack of a ubiquitous and secure means to perform identity > information exchange. We envisage that every website could become a > relying party and every web browser could become a conduit for > identity information. > > >> Personally, I can believe that there is some hitherto uncharted >> territory in identity land that the IETF could do something about, > > Actually we should be in unchartered territory at all. We should be > just codifying existing practice. > (As the statement above says...) > >> but I would also think that that territory needs to be marked in >> relationship to other territories by other initiatives, preferably >> with very little to zero overlap. I'd recommend that be done from >> the get-go, because otherwise dix just sets itself up for sniping. > > I think we're fine so long as we focus on what the IETF is good at: > Internet Scale, Decentralization, Bottom-up Initiatives, User > Driven, Codification of Existing Practice, Engineering Focused, > Rough Consensus and Running Code! Things that have been driving > your efforts and ours... > > John > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-548-602713477 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-548-602713477-- From dix-bounces@ietf.org Sat Jan 21 01:13:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Bzi-0001gY-8x; Sat, 21 Jan 2006 01:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Bzg-0001gT-HU for dix@megatron.ietf.org; Sat, 21 Jan 2006 01:13:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04330 for ; Sat, 21 Jan 2006 01:11:31 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0C8Z-0005G8-HF for dix@ietf.org; Sat, 21 Jan 2006 01:22:11 -0500 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc11) with SMTP id <20060121061250013007j221e>; Sat, 21 Jan 2006 06:12:51 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <35243121-EB0E-4A2F-B3FF-F0828F2DD78E@sxip.com> References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> <35243121-EB0E-4A2F-B3FF-F0828F2DD78E@sxip.com> Content-Type: multipart/mixed; boundary=Apple-Mail-555-602976932 Message-Id: <892C0F0F-2782-4651-B121-748084E678BB@netmesh.us> From: Johannes Ernst Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 22:12:46 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --Apple-Mail-555-602976932 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > Johannes, > > Maybe I can politely turn the tables here and solicit your help. > > Why did you embark on LID, given the plethora out there....? Well, I think it's a lot easier to justify creating a new technology, than to justify that another standards body get involved in "2.0" of something that has been worked on as "1.x" by a bunch of other standards bodies who are alive and well. It seems the core of your argument needs to be that we have a case of discontinuous innovation here and that it would be unrealistic to assume that one could successfully branch off a new standards project from a standards effort that is nominally about the same subject, but architecturally is completely different. (think "Innovator's Dilemma") I think anybody who's ever worked in standards will wholeheartedly agree, and so this argument works (at least for me), in particular if it is brought up in context of LID, OpenID, YADIS, Passel, SXIP and the like which are clearly discontinuous innovations. It appears to me that such a project could be useful ... lots of "if's" here of course because the proof is in the pudding ... so I'm keen to learn more ;-) Johannes Ernst NetMesh Inc. --Apple-Mail-555-602976932 Content-Type: image/gif; x-unix-mode=0666; name="lid.gif" Content-Disposition: inline; filename=lid.gif Content-Transfer-Encoding: base64 R0lGODlhJAAOAPcXMf////////////////////////////////////////////////////////// ///////////////////////////////exv/exv/exv/exv/exv/exv/exv/exv/exv/exv/exv/e xv/exv/exv/exv/exv/exv/exv/exv/exv/exv/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/O pf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1 hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+MQv+MQv+MQv+MQv+MQv+M Qv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv9jAP9jAP9j AP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAPfv 5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv 5/fv5/ethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPet hPethPethPethOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOda AOdaAOdaAOdaAOdaAOdaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZa ANZaANZaANZaANZaANZaANZaANZaAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZS AMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsx AHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAAAAACwAAAAAJAAOAAAIsgABCBy4 oqDBgwgTGhzIkOGKNRAjSpxIMaKqhg4ratwI8SLGhxGrALAwUSTJNSIHnoz4qyHIkCOpSTQp02Ql ICMpEqRo8tfMkT5FrggKoMrEli9/rpAJcynKmBBzHlVVsedPC0QtMJUqMR2AqlBhan06VqTRrgN9 /gQEpK1RmmR/mZzolaFaiCkHAiFbk+FKiHUbHqVGmDDEX9TUIi6MFqPAuxwjB3b8NZ3ly5gza7aM MSAAOw== --Apple-Mail-555-602976932 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit http://netmesh.info/jernst --Apple-Mail-555-602976932 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-555-602976932-- From dix-bounces@ietf.org Sat Jan 21 01:45:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0CVE-0006E0-Dh; Sat, 21 Jan 2006 01:45:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0CLa-0002I7-OW for dix@megatron.ietf.org; Sat, 21 Jan 2006 01:35:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05210 for ; Sat, 21 Jan 2006 01:34:09 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0CQJ-0005iT-Lc for dix@ietf.org; Sat, 21 Jan 2006 01:40:33 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L6VCgQ019948 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 22:31:12 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <460C8C0D-2DA0-4D60-93C6-B3E2B03858B5@netmesh.us> References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> <460C8C0D-2DA0-4D60-93C6-B3E2B03858B5@netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] To add to the charter Date: Fri, 20 Jan 2006 22:31:09 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 10:08 PM, Johannes Ernst wrote: > - but you also say that we should just be codifying existing > practice ... which existing practice are you referring to? As I wrote in draft #0: 'For example: SXIP, LID, OpenID, and Passel.' I'm sure there's others. I saw mIDm on your site just now. > As far as I know, the only technology that makes some of the > technologies you listed interoperate so far (and only partially, > because SXIP is not involved) is YADIS... I have the proof right > here on my machine that it works beautifully between LID and OpenID > implementations of at least four different vendors already ... so > I'm a little unclear what exactly are you proposing? I don't think that we need a protocol to interoperate with other protocols. I think we need one protocol. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jan 21 03:21:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0DzY-0008IP-C7; Sat, 21 Jan 2006 03:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0DzX-0008IK-Ag for dix@megatron.ietf.org; Sat, 21 Jan 2006 03:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12461 for ; Sat, 21 Jan 2006 03:19:31 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0E8Q-0000TP-0u for dix@ietf.org; Sat, 21 Jan 2006 03:30:11 -0500 Received: from [10.0.1.2] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0L8KmbP021891 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 21 Jan 2006 00:20:49 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D1AB9E.5070005@redhat.com> References: <43D1AB9E.5070005@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Sat, 21 Jan 2006 00:20:46 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 20-Jan-06, at 7:33 PM, Pete Rowley wrote: >> We can't mandate that the other party in the exchange implement > > Isn't the point of issue here that there needs to be documented a > way to (stealing the words) "produce interoperable > implementations" so that it can be shown that it _works_ by having > "interoperable implementations" - this isn't a question of > mandating anything, but codifying how using the protocol over one > method of transport would work. Nope... Here's an illustration of the issue... Usually in a protocol definition there are only two parties, the client and the server. If some aspect of the protocol was optional say A or B then someone could implement a client that did A and someone else could produce a server that talked B. Compliant implementations but not interoperable. The solution is to mandate A and make B optional. But, we have a different situation. Three parties and two exchanges... Given parties A, B, and C where separate protocol exchanges can occur between parties A and B, and between parties B and C... I just don't think that every B has to be able to talk to every A and be able to talk to every C. This is probably easiest to state in first order predicate logic... Given parties A, B, and C where separate protocol exchanges can occur between parties A and B, and between parties B and C; it must hold that a single instance of a transitive relationship must exist between every A and some C through some B, and it must also hold that there is a reverse transitive relationship instance from every C to some A through some B, and that every B participates in one of those relationships... ohhh... that's a transitive closure. In other words: the transitive closure of all As includes all Cs through all Bs. Hence it matters not what the transport actually is, just that this constraint holds. I think that's a good argument against mandating a transport. What needs to be mandated to ensure interoperation is that... An A must be able to talk to a B. A B must be able to talk to an A and a C. A C must be able to talk to a B. I'll see about working that into charter style text tomorrow. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jan 21 05:38:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0G8b-0005gd-A2; Sat, 21 Jan 2006 05:38:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0G8Z-0005gY-Dr for dix@megatron.ietf.org; Sat, 21 Jan 2006 05:38:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21075 for ; Sat, 21 Jan 2006 05:36:59 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0GHU-0004P1-4H for dix@ietf.org; Sat, 21 Jan 2006 05:47:40 -0500 Received: (qmail invoked by alias); 21 Jan 2006 10:38:15 -0000 Received: from p54987E35.dip.t-dialin.net (EHLO [192.168.2.100]) [84.152.126.53] by mail.gmx.net (mp028) with SMTP; 21 Jan 2006 11:38:15 +0100 X-Authenticated: #29516787 Message-ID: <43D20F0E.3040505@gmx.net> Date: Sat, 21 Jan 2006 11:38:06 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dix@ietf.org, rlmorgan@washington.edu Subject: Re: Fwd: [dix] thoughts on "identity" and IETF References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org thank you bob for the clarifications and the history lesson. for the first time in the long mailing list discussion i got the impression that i understand what people want to accomplish ... John Merrells wrote: > > Bob's thoughts.... > > Begin forwarded message: > >> From: "RL 'Bob' Morgan" >> Date: November 9, 2005 3:05:14 PM PST (CA) >> To: IETF DIX list >> Subject: [dix] thoughts on "identity" and IETF >> >> >> I have been somewhat involved in recent discussions regarding >> "identity" (see http://www.identitygang.org/ and a zillion other >> blogs and links), as well as a long-time IETF participant, so let me >> toss out a brief personal view of what's going on here in hopes it >> may provide context useful for some folks. >> >> Let me say up front that I don't necessarily agree with all the >> positions I describe below, but am trying to express what many people >> are saying and thinking. >> >> Many protocols developed in the IETF have served the needs of what >> Dick Hardt calls "Identity 1.0", which might be characterized less >> flamboyantly as "enterprise identity management". This term includes >> several rather different technologies and processes, all in support >> of the ability for the owners of services to control who does what >> with their computing resources. I use the word "enterprise" above >> intentionally, to reflect the fact that traditionally the parties >> with interest and ability to control access to resources have been >> organizations, usually large ones. >> >> So, for example, the domain of use of the IETF's LDAP protocol is >> large directories containing entries for many users, operated by IT >> staff in organizations that have an interest in the users whose info >> is in those entries, and the applications that use those >> directories. The domain of use of the IETF's Kerberos protocol is >> similarly organizations with an interest in secure authentication to >> a set of apps relying on an organizational KDC. Similar broad- brush >> characterizations could be made of PKIX, TLS, SASL, features like >> HTTP Basic/Digest authentication, probably other protocols and features. >> >> Note that the scope of "identity" here includes several things. One >> is maintenance of information about a person (or other entity), >> including not just userid and password but potentially lots of other >> information relevant to authorization, contact, perhaps other >> purposes. Another is authentication, ie how a service knows "the >> identity" of a client. Another is exchange of identity information >> between parties, both at authentication time and at other times. >> >> Out in the world most people's experience of the Internet is of >> course the Web, and most people's experience of "Identity 1.0" has >> been via account setup and login to a vast array of web-based >> services managed by organizations large (mostly) and small. There >> have been some non-IETF standard/spec activities that attempt to >> address the widely-observed usability problem of people having too >> damn many usernames/passwords to remember, as well as security >> problems based on that stuff. Perhaps the main one is the OASIS- >> published SAML standard, which specifies how to do web sign-on and >> attribute exchange. A somewhat similar activity is WS-Federation, >> part of the WS-* spec set. These have been called "Identity 1.5" >> because they permit some organizations to rely on other >> organizations' identity management services, but the use cases >> driving the designs are still organization-oriented. >> >> So is there something missing in the above stuff, some new >> requirements requiring new stuff, ie "Identity 2.0"? I think the >> people who say there is are motivated by the huge number of new >> things that have happened on the web in the last few years. The >> center of this is the blogging phenomenon. Maybe 20 million people >> are now blogging. They're doing other things like putting lots of >> photos online at Flickr, keeping their bookmarks on del.icio.us, >> tracking tags on technorati, and zillions of other examples. They >> are composing these services in myriad ways to create new services. >> In sociological terms they are creating online identities for >> themselves that they feel much more attachment to than their >> organizational account, even their "my.foo.com" page at one of the >> traditional portal sites. In Identity 1.0 terms they are all >> becoming, or have an interest in becoming, both service providers and >> identity providers, that is, they have an interest in protecting >> their resources (in the canonical case of reducing blog spam), and in >> leveraging their personal info to their millions of peers. >> >> So now in addition to the tens or hundreds of thousands of >> institutions with identity interest, there are tens of millions of >> individuals. Many people are trying to figure out what they need and >> respond to it. The SXIP technology is one among those, others are >> OpenID, LID, Passel, and no doubt many others. For the most part >> these approaches reject traditional identity management protocols and >> systems; whether they should or should not is one of the big >> questions. A key point is that the individual interest in identity >> is much more about expression, ie ease of sharing and discovery, than >> it is in control (ie, fancy security). Another key point is >> individual control, the same sort of control people feel over their >> personal domain name and its site, or their blog. Even people who >> aren't radically anti-corporate like to feel in charge of their own >> stuff. >> >> That's all I have time for now ... >> >> - RL "Bob" >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> >> > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jan 22 11:24:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0i1T-0002yW-15; Sun, 22 Jan 2006 11:24:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0i1R-0002va-CI for dix@megatron.ietf.org; Sun, 22 Jan 2006 11:24:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29729 for ; Sun, 22 Jan 2006 11:23:28 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0iAa-0004Lp-T5 for dix@ietf.org; Sun, 22 Jan 2006 11:34:26 -0500 Received: by zproxy.gmail.com with SMTP id 9so766594nzo for ; Sun, 22 Jan 2006 08:24:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=a3TmRDftWMDgWLUWiRLc+g3oCPwyASKAjtqeDxClD20asX7Xp89K5WoGoqSkLxsZ/9ctjstbGu+y0TPGC0C2rq3QBh9D9oRZx8FgxO5g+0jysbSuhsJwlVoyLNcc0ox9gR9qIfPziGHRzm6r3DSr8UZHAXliEQG7da3ba5PF2/E= Received: by 10.36.160.1 with SMTP id i1mr3074094nze; Sun, 22 Jan 2006 08:24:54 -0800 (PST) Received: by 10.36.103.13 with HTTP; Sun, 22 Jan 2006 08:24:54 -0800 (PST) Message-ID: <320303060601220824he38aa3cka71f592e368bfe69@mail.gmail.com> Date: Sun, 22 Jan 2006 08:24:54 -0800 From: prasanta behera To: Digital Identity Exchange Subject: Re: Fwd: [dix] thoughts on "identity" and IETF In-Reply-To: <43D20F0E.3040505@gmx.net> MIME-Version: 1.0 References: <43D20F0E.3040505@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1003597204==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --===============1003597204== Content-Type: multipart/alternative; boundary="----=_Part_5747_25064155.1137947094598" ------=_Part_5747_25064155.1137947094598 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Will defining a new protocol be enough? One exercise may be to look at what elements are needed to support some of the discussions in thread (Ok - this is a slight digression to the DIX charter discussion). For example: - Common "Identity" Identifier - A protocol for exchanging information - ?? Thanks, /Prasanta ------=_Part_5747_25064155.1137947094598 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Will defining a new protocol be enough? One exercise may be to look at what elements are needed to support  some of the discussions in  thread (Ok - this is a slight digression to the DIX charter discussion).

For example:
- Common "Identity" Identifier
- A protocol for exchanging information
- ??

Thanks,
/Prasanta

------=_Part_5747_25064155.1137947094598-- --===============1003597204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1003597204==-- From dix-bounces@ietf.org Sun Jan 22 16:07:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mQW-0007tB-GQ; Sun, 22 Jan 2006 16:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mQU-0007qn-VA for dix@megatron.ietf.org; Sun, 22 Jan 2006 16:07:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17131 for ; Sun, 22 Jan 2006 16:05:38 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0mZh-0003oo-2Y for dix@ietf.org; Sun, 22 Jan 2006 16:16:38 -0500 Received: from [192.168.1.102] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0ML6u3I069913 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 22 Jan 2006 13:06:57 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <320303060601220824he38aa3cka71f592e368bfe69@mail.gmail.com> References: <43D20F0E.3040505@gmx.net> <320303060601220824he38aa3cka71f592e368bfe69@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] thoughts on "identity" and IETF Date: Sun, 22 Jan 2006 13:06:55 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 22-Jan-06, at 8:24 AM, prasanta behera wrote: > > Will defining a new protocol be enough? One exercise may be to look > at what elements are needed to support some of the discussions in > thread (Ok - this is a slight digression to the DIX charter > discussion). A new protocol will likely NOT be enough to solve the Identity 2.0 problem, but it is an important step, and is the type of thing that I understand as being in the scope of IETF. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jan 22 18:59:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0p7Q-0001fp-Td; Sun, 22 Jan 2006 18:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0p7P-0001fc-FY for dix@megatron.ietf.org; Sun, 22 Jan 2006 18:59:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28564 for ; Sun, 22 Jan 2006 18:58:06 -0500 (EST) Received: from smtp107.sbc.mail.mud.yahoo.com ([68.142.198.206]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0pGd-0000O4-79 for dix@ietf.org; Sun, 22 Jan 2006 19:09:08 -0500 Received: (qmail 30666 invoked from network); 22 Jan 2006 23:59:19 -0000 Received: from unknown (HELO elijah.joaquin.net) (jm-acm.no@sbcglobal.net@70.137.129.58 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 22 Jan 2006 23:59:19 -0000 Message-Id: <6.2.3.4.0.20060122155636.03f9b350@pop.netmesh.us> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 22 Jan 2006 15:58:31 -0800 To: Digital Identity Exchange From: Joaquin Miller Subject: Re: [dix] draft of proposed charter (#2) In-Reply-To: References: <43D1AB9E.5070005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joaquin Miller , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Very well put, John! This is the kind of thinking we need. And the kind of clear explication of the thinking that is essential for good progress. Cordially, Joaquin >Given parties A, B, and C where separate protocol exchanges can >occur between parties A and B, and between parties B and C... > >I just don't think that every B has to be able to talk to every A and >be able to talk to every C. > >This is probably easiest to state in first order predicate logic... > >Given parties A, B, and C where separate protocol exchanges can >occur between parties A and B, and between parties B and C; it >must hold that a single instance of a transitive relationship must exist >between every A and some C through some B, and it must also >hold that there is a reverse transitive relationship instance from >every C to some A through some B, and that every B participates >in one of those relationships... ohhh... that's a transitive closure. >In other words: the transitive closure of all As includes all Cs >through all Bs. Hence it matters not what the transport actually is, >just that this constraint holds. > >I think that's a good argument against mandating a transport. > >What needs to be mandated to ensure interoperation is that... > >An A must be able to talk to a B. >A B must be able to talk to an A and a C. >A C must be able to talk to a B. > >I'll see about working that into charter style text tomorrow. > >John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jan 22 23:03:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0svS-0004tX-Oh; Sun, 22 Jan 2006 23:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0svR-0004t6-Hk for dix@megatron.ietf.org; Sun, 22 Jan 2006 23:03:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12070 for ; Sun, 22 Jan 2006 23:02:00 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0t4g-0006Td-Tb for dix@ietf.org; Sun, 22 Jan 2006 23:13:04 -0500 Received: from [10.0.1.15] (c-24-5-183-103.hsd1.ca.comcast.net [24.5.183.103]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0N42dvc076851 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 22 Jan 2006 20:02:40 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <6.2.3.4.0.20060122155636.03f9b350@pop.netmesh.us> References: <43D1AB9E.5070005@redhat.com> <6.2.3.4.0.20060122155636.03f9b350@pop.netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Sun, 22 Jan 2006 20:02:38 -0800 To: Joaquin Miller , Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 22-Jan-06, at 3:58 PM, Joaquin Miller wrote: > Very well put, John! This is the kind of thinking we need. And > the kind of clear explication of the thinking that is essential for > good progress. Thanks , but I can't take all the credit, as I had help from my friend Mr. Cabernet Sauvignon. This evening's email lubricant is the cheeky little Ms. Merlot. Mmm, nice. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 10:58:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F145e-0004BN-US; Mon, 23 Jan 2006 10:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F145d-0004BD-IA for dix@megatron.ietf.org; Mon, 23 Jan 2006 10:58:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29411 for ; Mon, 23 Jan 2006 10:57:16 -0500 (EST) Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14Ez-000321-Mg for dix@ietf.org; Mon, 23 Jan 2006 11:08:27 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id F35FB4A1AE1 for ; Mon, 23 Jan 2006 08:58:35 -0700 (MST) Message-ID: <43D4FD2B.1070900@jabber.org> Date: Mon, 23 Jan 2006 08:58:35 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: Fwd: [dix] thoughts on "identity" and IETF References: <43D20F0E.3040505@gmx.net> In-Reply-To: <43D20F0E.3040505@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0891005372==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0891005372== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050707050009060903080006" This is a cryptographically signed message in MIME format. --------------ms050707050009060903080006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes Tschofenig wrote: > thank you bob for the clarifications and the history lesson. for the > first time in the long mailing list discussion i got the impression that > i understand what people want to accomplish ... Amusingly, that was the first substantive message sent to this list. :-) http://www.ietf.org/mail-archive/web/dix/current/msg00007.html Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms050707050009060903080006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIzMTU1ODM1WjAjBgkqhkiG9w0BCQQxFgQUr4qX3sqnpWy0XmCs 9VQR1EI0c88wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAF73Y+bhnLD/CUO33LgPgresSW5KDeYF wEVsj5F0CAlnZTkTGGpIO67Xa/bQ9IviF5WmX0A/Nyp5jHvBEURQUI+L8cJmQra+s+TxAApA ELXZz+SXrsSmaNLSNjCu5FFuNaO7MQOmjEENpeuBDyYXim5W9hTNDfNkLtkTtGFaRFpSM3nK Rz0Bzzsq5ZmEOMDOr51oKDA5j+mzvg6xY80hMrB7+1d1VaLv/0uCGbCo0TwRscVOjvAn0oS5 pg+x+h0WnGn4m0pxqft+Mrg2MyBUn8ISrzxxlHLCsY++AWmphBf7W01nQ/YWzY7yTnq+zgLf LRAON25PFq77Hgoh0kgDF+EAAAAAAAA= --------------ms050707050009060903080006-- --===============0891005372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0891005372==-- From dix-bounces@ietf.org Mon Jan 23 14:20:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Eb-0006ED-3c; Mon, 23 Jan 2006 14:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17EZ-0006E8-Rq for dix@megatron.ietf.org; Mon, 23 Jan 2006 14:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11085 for ; Mon, 23 Jan 2006 14:18:40 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F17Nw-0000rQ-0B for dix@ietf.org; Mon, 23 Jan 2006 14:29:54 -0500 Received: from [66.80.0.10] (dhcp-10.danastreet.live555.com [66.80.0.10]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0NJK4NK001911 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Jan 2006 11:20:04 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <2CB31C9F-3949-4ABF-80A7-72EC6E6C22C4@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Mon, 23 Jan 2006 11:19:58 -0800 X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [dix] use cases X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org If people want to offer up some use cases i'll wrangle them into an ID... (I'd rather somebody else did the editing on this draft though...) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 14:29:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17NW-0007V5-S6; Mon, 23 Jan 2006 14:29:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17NW-0007V0-1q for dix@megatron.ietf.org; Mon, 23 Jan 2006 14:29:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11489 for ; Mon, 23 Jan 2006 14:27:55 -0500 (EST) Received: from web88111.mail.re2.yahoo.com ([206.190.37.232]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F17Wu-00017e-43 for dix@ietf.org; Mon, 23 Jan 2006 14:39:09 -0500 Received: (qmail 91491 invoked by uid 60001); 23 Jan 2006 19:29:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=osm4iN758JPmzw2IqORh1728APpXMknwhoqLix1ZNVecXjT8hBCEpIPCiRp4/8og74/B3Meuxn+qsjJ50EccNP5ow+0ZazkWA6neeVdTaAzBHnZbriFktjupH2Zv6M9EqpG7JwAArotLUuoJJnKYFCnchyuB/FUZy7UveDfZNIY= ; Message-ID: <20060123192913.91489.qmail@web88111.mail.re2.yahoo.com> Received: from [72.1.215.180] by web88111.mail.re2.yahoo.com via HTTP; Mon, 23 Jan 2006 14:29:13 EST Date: Mon, 23 Jan 2006 14:29:13 -0500 (EST) From: James Benedict Subject: Re: [dix] use cases To: Digital Identity Exchange In-Reply-To: <2CB31C9F-3949-4ABF-80A7-72EC6E6C22C4@sxip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org If no one else volunteers, then i'll do it. I'm working on some use cases for myself anyways... still trying to get a picture in my head of exactly what this protocol is doing. I think in pretty (or at least ASCII) pictures :) -- James --- John Merrells wrote: > > If people want to offer up some use cases i'll > wrangle them into an > ID... > > (I'd rather somebody else did the editing on this > draft though...) > > John > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 14:32:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Qd-00081G-95; Mon, 23 Jan 2006 14:32:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Qc-00081B-8J for dix@megatron.ietf.org; Mon, 23 Jan 2006 14:32:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11662 for ; Mon, 23 Jan 2006 14:31:07 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F17a0-0001EW-37 for dix@ietf.org; Mon, 23 Jan 2006 14:42:21 -0500 Received: from [192.168.1.102] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0NJWR2A002895 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Jan 2006 11:32:28 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060123192913.91489.qmail@web88111.mail.re2.yahoo.com> References: <20060123192913.91489.qmail@web88111.mail.re2.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1FE8000A-D099-4081-AF2C-D724B8C24484@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] use cases Date: Mon, 23 Jan 2006 11:32:27 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Great to hear that James! I think it would be useful for us all to agree what a use case is. :-) On 23-Jan-06, at 11:29 AM, James Benedict wrote: > If no one else volunteers, then i'll do it. I'm > working on some use cases for myself anyways... still > trying to get a picture in my head of exactly what > this protocol is doing. > > I think in pretty (or at least ASCII) pictures :) > > -- > James > > --- John Merrells wrote: > >> >> If people want to offer up some use cases i'll >> wrangle them into an >> ID... >> >> (I'd rather somebody else did the editing on this >> draft though...) >> >> John >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 14:44:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17bo-0002Q5-9R; Mon, 23 Jan 2006 14:44:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17bn-0002Pt-0R for dix@megatron.ietf.org; Mon, 23 Jan 2006 14:44:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12386 for ; Mon, 23 Jan 2006 14:42:38 -0500 (EST) Received: from web88101.mail.re2.yahoo.com ([206.190.37.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F17l9-0001cD-Ek for dix@ietf.org; Mon, 23 Jan 2006 14:53:52 -0500 Received: (qmail 82731 invoked by uid 60001); 23 Jan 2006 19:43:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i15rLaxGl2E8Z8YyuUR075VJ7jAr/IJozh5TOtdPPE89x3IajNS4Bp1SoqxO3/l9jsIKBAIHLne9vLRSz59n9efP4VtSwnDxjxm9Af6mtpNzHxCuOzd4IlRKj1ciKgk/empXelOZQQaIB0ap0cAKkt3yHSia7CoIhJ0FH2p9gQw= ; Message-ID: <20060123194358.82729.qmail@web88101.mail.re2.yahoo.com> Received: from [72.1.215.180] by web88101.mail.re2.yahoo.com via HTTP; Mon, 23 Jan 2006 14:43:58 EST Date: Mon, 23 Jan 2006 14:43:58 -0500 (EST) From: James Benedict Subject: Re: [dix] use cases To: Digital Identity Exchange In-Reply-To: <1FE8000A-D099-4081-AF2C-D724B8C24484@sxip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 8bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Good question! Especially since we have a "chicken and egg" issue here. Personally, I'de like to see some "example executions" of the current draft to get a better understanding of how it works... and to spot potential issues. However, in the real (well, maybe ideal is a better word) software engineering world, the "use cases" would represent an expected "walk through" of the application functionality ... from which requirements would be derived ... then the applications, protocols, etc would be implemented. Interestingly enough, we already have the end-product. Hence, my interest in "examples" of the current draft. I'de rather take what we've got and analyse the "use cases" to determine suitability than to try to re-derive the draft from scratch, although some might disagree with me here :) Since you put out the question Dick, what do you propose? -- James --- Dick Hardt wrote: > Great to hear that James! > > I think it would be useful for us all to agree what > a use case is. :-) > > On 23-Jan-06, at 11:29 AM, James Benedict wrote: > > > If no one else volunteers, then i'll do it. I'm > > working on some use cases for myself anyways... > still > > trying to get a picture in my head of exactly what > > this protocol is doing. > > > > I think in pretty (or at least ASCII) pictures :) > > > > -- > > James > > > > --- John Merrells wrote: > > > >> > >> If people want to offer up some use cases i'll > >> wrangle them into an > >> ID... > >> > >> (I'd rather somebody else did the editing on this > >> draft though...) > >> > >> John > >> > >> > >> _______________________________________________ > >> dix mailing list > >> dix@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dix > >> > > > > > > _______________________________________________ > > dix mailing list > > dix@ietf.org > > https://www1.ietf.org/mailman/listinfo/dix > > > > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 15:00:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17rN-0007Nm-1i; Mon, 23 Jan 2006 15:00:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17rL-0007Nh-9C for dix@megatron.ietf.org; Mon, 23 Jan 2006 15:00:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13615 for ; Mon, 23 Jan 2006 14:58:44 -0500 (EST) Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F180i-0002DG-ED for dix@ietf.org; Mon, 23 Jan 2006 15:09:58 -0500 Received: from [192.168.101.89] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D061142269 for ; Mon, 23 Jan 2006 12:00:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] draft of proposed charter (#2) Date: Mon, 23 Jan 2006 12:00:02 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This email is getting closer to picking apart the different pieces of the network architecture for delegated authority and considering those pieces separately with respect to Scott's suggestion of certain "required to implement" transports. I think we need to take it further because each main line in the network diagram has to be considered separately. I'm going to use my own terms for the 3 parties here because my confusion about the official terms is an appropriate subject for a different mail but I can't quite bring myself to use them. Thus, my simplified network diagram which ignores proxies and optional bits like talking to directories Content Server---------| | | | Identity | Server | | Client---------| On Jan 20, 2006, at 7:16 PM, John Merrells wrote: > We can't mandate that the other party in the exchange implement > DIX over a particular transport. It's an implementation decision > between the user's client and the other party. We have the motivating > use cases of a VOIP phone or IM client to illustrate this. Here you're talking about the communication between the client and the content server in my diagram. That communication is almost outside the scope of DIX. It's the communication that already takes place over many, many protocols, not all of which DIX WG can tackle. My personal suggestion is that DIX should tackle HTTP and add a new Authorization header type and WWW-Authenticate capability token and associated parameters, and perhaps also tackle SASL for which I'm not qualified to suggest how. > > We could mandate the transport between the user's client and their > agent. HTTP perhaps... given its simplicity and ubiquity. I do > hesitate > though, because I'm sure there are use cases where that doesn't > make sense. For example my agent might actually be built into my > client so the transport is IPC or API. What use would that kind of > agent be?... well it could just be a local replica of my agent in the > internet. Hmm, is my local agent really just an agent of my agent > and therefore a non-principal party to the exchange. Agh. What if > my agent were on a USB key or a smart card? What would my > transport be then... I'm not sure... I suppose it could be HTTP... Now you're talking about the communication between client and identity server in my diagram. The identity server MUST support one or more well-known protocols such that if I'm implementing a client, I can count on being able to contact a standards-compliant identity server if I'm willing to do the work. Of course a client might go beyond that and implement other protocols to talk to the identity server -- even proprietary protocols -- but that would have to rely on capability discovery or provisioning in order to work. So let's say DIX required BEEP and HTTP (at random) as the REQUIRED TO IMPLEMENT transports for a compliant identity server. This doesn't necessarily solve all problems for all clients but it does make it clear what the client implementor has to do. > > We could state: > > "To ensure interoperability between implementations we mandate > that the user's client and their agent must support at least DIX > over HTTP." Yes, but even more important for the identity server to have required- to-implement transports. > It's hard to be definitive about this without the use cases to refer > to... I may be assuming the use cases, but I'll forge onward. The last major line in the network diagram is the communication between the identity server and the content server. Over this link, REQUIRED transports are crucial and can be kept, I suspect, to just one. All content servers that advertise support for DIX delegated authorization MUST be able to communicate with the identity server chosen by the client using this one transport. All identity servers that advertise compliance with DIX MUST be able to communicate with the content server chosen by the client using this one transport. A single mandatory transport is most crucial for this link because both the content server and identity server are chosen by the client or user, and the two servers commonly have no ability or opportunity to do any provisioning or setup, and can only negotiate over the wire after initially making some kind of blind connection in one of the two directions. Revisiting my simplistic network diagram: Content Server---------| = ONE TRANSPORT | | ANY = | Identity | Server | | Client---------| = ONE/TWO TRANSPORTS or configure/provision otherwise Lisa _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 15:12:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F182n-0001gK-Oy; Mon, 23 Jan 2006 15:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F182n-0001gF-5a for dix@megatron.ietf.org; Mon, 23 Jan 2006 15:12:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14559 for ; Mon, 23 Jan 2006 15:10:34 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18CA-0002hp-7g for dix@ietf.org; Mon, 23 Jan 2006 15:21:48 -0500 Received: from [192.168.1.102] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0NKBrx3005100 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Jan 2006 12:11:54 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060123194358.82729.qmail@web88101.mail.re2.yahoo.com> References: <20060123194358.82729.qmail@web88101.mail.re2.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E546CC6-D387-4BD0-BC4E-B417FF075BFE@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] use cases Date: Mon, 23 Jan 2006 12:11:52 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Well, my question was more of "What is a use case?" Is it a detailed "Detailed Scenario"? I retained Tim Bray of XML fame to assist me with documenting SXIP 1.0. His recommendation (which he and I executed on) was to write scenarios, where the user activity and what happens on the wire are discussed so that the reader can tie it all together. We wrote different scenarios so that the reader would be able to see enough facets of the protocol to understand it. The use of names and specific activities made it easy for the reader to grasp. I think this is a useful, but non-normative way to document a protocol. I think this might be too detailed. Here is a simple example of what I think a use case is: Sally wants to register at a website. She does some action that sends her to her software agent that manages her identity, that allows her to select which data she wants to release. When returning to the site later, Sally clicks on a button to log into the site. Sally is in control of what data was released to the site. Sally did not have to type in any of the data. Sally does not have new username and password for the site. -- Dick On 23-Jan-06, at 11:43 AM, James Benedict wrote: > Good question! Especially since we have a "chicken and > egg" issue here. Personally, I'de like to see some > "example executions" of the current draft to get a > better understanding of how it works... and to spot > potential issues. > > However, in the real (well, maybe ideal is a better > word) software engineering world, the "use cases" > would represent an expected "walk through" of the > application functionality ... from which requirements > would be derived ... then the applications, protocols, > etc would be implemented. > > Interestingly enough, we already have the end-product. > Hence, my interest in "examples" of the current > draft. I'de rather take what we've got and analyse the > "use cases" to determine suitability than to try to > re-derive the draft from scratch, although some might > disagree with me here :) > > Since you put out the question Dick, what do you > propose? > > -- > James > > --- Dick Hardt wrote: > >> Great to hear that James! >> >> I think it would be useful for us all to agree what >> a use case is. :-) >> >> On 23-Jan-06, at 11:29 AM, James Benedict wrote: >> >>> If no one else volunteers, then i'll do it. I'm >>> working on some use cases for myself anyways... >> still >>> trying to get a picture in my head of exactly what >>> this protocol is doing. >>> >>> I think in pretty (or at least ASCII) pictures :) >>> >>> -- >>> James >>> >>> --- John Merrells wrote: >>> >>>> >>>> If people want to offer up some use cases i'll >>>> wrangle them into an >>>> ID... >>>> >>>> (I'd rather somebody else did the editing on this >>>> draft though...) >>>> >>>> John >>>> >>>> >>>> _______________________________________________ >>>> dix mailing list >>>> dix@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dix >>>> >>> >>> >>> _______________________________________________ >>> dix mailing list >>> dix@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dix >>> >>> >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 15:22:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18Cv-0003ts-Cb; Mon, 23 Jan 2006 15:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F18Cu-0003ti-2N for dix@megatron.ietf.org; Mon, 23 Jan 2006 15:22:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15098 for ; Mon, 23 Jan 2006 15:21:01 -0500 (EST) Received: from web88109.mail.re2.yahoo.com ([206.190.37.210]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F18MI-0002yI-3P for dix@ietf.org; Mon, 23 Jan 2006 15:32:15 -0500 Received: (qmail 9962 invoked by uid 60001); 23 Jan 2006 20:22:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0ZroG8so9hl0ery+awCjvlHCEC+hbpJ7nzd/AiBBF36nheHkXjbjWJG5n2ilhzsfvUkRlNGpAp8NVfb8wofsxNR5vUokbgUHLVo70PELIJwBi7CVOlcEVguBmImaepfiVhxjMyG9Amou9a4HKgx0C3qGuvxmOaBoP4aIKW73sN8= ; Message-ID: <20060123202219.9960.qmail@web88109.mail.re2.yahoo.com> Received: from [72.1.215.180] by web88109.mail.re2.yahoo.com via HTTP; Mon, 23 Jan 2006 15:22:19 EST Date: Mon, 23 Jan 2006 15:22:19 -0500 (EST) From: James Benedict Subject: Re: [dix] use cases To: Digital Identity Exchange In-Reply-To: <4E546CC6-D387-4BD0-BC4E-B417FF075BFE@sxip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 8bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I agree with you, I'de rather see something a little less detailed. I still would prefer to see something less like a classic use case, and something more illustrative of the existing draft. John's already got something that (IMO) looks pretty good, I'de just like to see some use-cases for it; and i'm worried if we take the traditional "forget about prior art" attitude when we do use-cases, they'll set the process way back. So, can we agree? Something lightweight, with the intent to illustrate the existing draft to start? -- James --- Dick Hardt wrote: > Well, my question was more of "What is a use case?" > > Is it a detailed "Detailed Scenario"? > > I retained Tim Bray of XML fame to assist me with > documenting SXIP > 1.0. His recommendation (which he and I executed on) > was to write > scenarios, where the user activity and what happens > on the wire are > discussed so that the reader can tie it all > together. We wrote > different scenarios so that the reader would be able > to see enough > facets of the protocol to understand it. The use of > names and > specific activities made it easy for the reader to > grasp. I think > this is a useful, but non-normative way to document > a protocol. > > I think this might be too detailed. > > Here is a simple example of what I think a use case > is: > > Sally wants to register at a website. She does some > action that sends > her to her software agent that manages her identity, > that allows her > to select which data she wants to release. > When returning to the site later, Sally clicks on a > button to log > into the site. > > Sally is in control of what data was released to the > site. > Sally did not have to type in any of the data. > Sally does not have new username and password for > the site. > > -- Dick > > On 23-Jan-06, at 11:43 AM, James Benedict wrote: > > > Good question! Especially since we have a "chicken > and > > egg" issue here. Personally, I'de like to see > some > > "example executions" of the current draft to get a > > better understanding of how it works... and to > spot > > potential issues. > > > > However, in the real (well, maybe ideal is a > better > > word) software engineering world, the "use cases" > > would represent an expected "walk through" of the > > application functionality ... from which > requirements > > would be derived ... then the applications, > protocols, > > etc would be implemented. > > > > Interestingly enough, we already have the > end-product. > > Hence, my interest in "examples" of the current > > draft. I'de rather take what we've got and analyse > the > > "use cases" to determine suitability than to try > to > > re-derive the draft from scratch, although some > might > > disagree with me here :) > > > > Since you put out the question Dick, what do you > > propose? > > > > -- > > James > > > > --- Dick Hardt wrote: > > > >> Great to hear that James! > >> > >> I think it would be useful for us all to agree > what > >> a use case is. :-) > >> > >> On 23-Jan-06, at 11:29 AM, James Benedict wrote: > >> > >>> If no one else volunteers, then i'll do it. I'm > >>> working on some use cases for myself anyways... > >> still > >>> trying to get a picture in my head of exactly > what > >>> this protocol is doing. > >>> > >>> I think in pretty (or at least ASCII) pictures > :) > >>> > >>> -- > >>> James > >>> > >>> --- John Merrells wrote: > >>> > >>>> > >>>> If people want to offer up some use cases i'll > >>>> wrangle them into an > >>>> ID... > >>>> > >>>> (I'd rather somebody else did the editing on > this > >>>> draft though...) > >>>> > >>>> John > >>>> > >>>> > >>>> _______________________________________________ > >>>> dix mailing list > >>>> dix@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dix > >>>> > >>> > >>> > >>> _______________________________________________ > >>> dix mailing list > >>> dix@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dix > >>> > >>> > >> > >> > >> _______________________________________________ > >> dix mailing list > >> dix@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dix > >> > > > > > > _______________________________________________ > > dix mailing list > > dix@ietf.org > > https://www1.ietf.org/mailman/listinfo/dix > > > > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 16:55:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19eg-00078G-Vg; Mon, 23 Jan 2006 16:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19ed-00077w-Vf for dix@megatron.ietf.org; Mon, 23 Jan 2006 16:55:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24485 for ; Mon, 23 Jan 2006 16:53:46 -0500 (EST) Received: from exprod6og2.obsmtp.com ([64.18.1.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F19o3-0007P4-7t for dix@ietf.org; Mon, 23 Jan 2006 17:05:00 -0500 Received: from source ([192.150.11.134]) by exprod6ob2.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 23 Jan 2006 13:55:01 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0NLsaYc013390 for ; Mon, 23 Jan 2006 13:54:37 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k0NLsCsQ006510 for ; Mon, 23 Jan 2006 13:54:59 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 13:54:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] use cases Date: Mon, 23 Jan 2006 13:54:27 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E452806D@namail3.corp.adobe.com> In-Reply-To: <4E546CC6-D387-4BD0-BC4E-B417FF075BFE@sxip.com> Thread-Topic: [dix] use cases Thread-Index: AcYgWVp1NBt4j7xkQ9Kam5YT/owS1AACAPGg From: "Duane Nickull" To: "Digital Identity Exchange" X-OriginalArrivalTime: 23 Jan 2006 21:54:27.0968 (UTC) FILETIME=[94F8A000:01C62067] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This exact conversation has persisted in many groups. Myself and Matt Mackenzie built a patterns template to capture use cases and derive requirements from which to feed into development of specifications. The idea is to start capturing the high level business conversation then gradually refine it to a set of architectural patterns, expressed in UML notation, to speak to implementers (see line #176 for details). The architectural patterns metamodel is based on the works of Christopher Alexander and the infamous gang of four. The work is publicly, freely available at: http://www.nickull.net/work/MacKenzie-Nickull_ArchitecturalPatternsRefer enceModel-v0.91.pdf If this is relevant, we would consider donating this IP to IETF. Duane Nickull ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ *******************************=20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Dick Hardt Sent: Monday, January 23, 2006 12:12 PM To: Digital Identity Exchange Subject: Re: [dix] use cases Well, my question was more of "What is a use case?" Is it a detailed "Detailed Scenario"? I retained Tim Bray of XML fame to assist me with documenting SXIP =20 1.0. His recommendation (which he and I executed on) was to write =20 scenarios, where the user activity and what happens on the wire are =20 discussed so that the reader can tie it all together. We wrote =20 different scenarios so that the reader would be able to see enough =20 facets of the protocol to understand it. The use of names and =20 specific activities made it easy for the reader to grasp. I think =20 this is a useful, but non-normative way to document a protocol. I think this might be too detailed. Here is a simple example of what I think a use case is: Sally wants to register at a website. She does some action that sends =20 her to her software agent that manages her identity, that allows her =20 to select which data she wants to release. When returning to the site later, Sally clicks on a button to log =20 into the site. Sally is in control of what data was released to the site. Sally did not have to type in any of the data. Sally does not have new username and password for the site. -- Dick On 23-Jan-06, at 11:43 AM, James Benedict wrote: > Good question! Especially since we have a "chicken and > egg" issue here. Personally, I'de like to see some > "example executions" of the current draft to get a > better understanding of how it works... and to spot > potential issues. > > However, in the real (well, maybe ideal is a better > word) software engineering world, the "use cases" > would represent an expected "walk through" of the > application functionality ... from which requirements > would be derived ... then the applications, protocols, > etc would be implemented. > > Interestingly enough, we already have the end-product. > Hence, my interest in "examples" of the current > draft. I'de rather take what we've got and analyse the > "use cases" to determine suitability than to try to > re-derive the draft from scratch, although some might > disagree with me here :) > > Since you put out the question Dick, what do you > propose? > > -- > James > > --- Dick Hardt wrote: > >> Great to hear that James! >> >> I think it would be useful for us all to agree what >> a use case is. :-) >> >> On 23-Jan-06, at 11:29 AM, James Benedict wrote: >> >>> If no one else volunteers, then i'll do it. I'm >>> working on some use cases for myself anyways... >> still >>> trying to get a picture in my head of exactly what >>> this protocol is doing. >>> >>> I think in pretty (or at least ASCII) pictures :) >>> >>> -- >>> James >>> >>> --- John Merrells wrote: >>> >>>> >>>> If people want to offer up some use cases i'll >>>> wrangle them into an >>>> ID... >>>> >>>> (I'd rather somebody else did the editing on this >>>> draft though...) >>>> >>>> John >>>> >>>> >>>> _______________________________________________ >>>> dix mailing list >>>> dix@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dix >>>> >>> >>> >>> _______________________________________________ >>> dix mailing list >>> dix@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dix >>> >>> >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 17:02:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19la-0001BI-65; Mon, 23 Jan 2006 17:02:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19lY-00018x-Jz for dix@megatron.ietf.org; Mon, 23 Jan 2006 17:02:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25605 for ; Mon, 23 Jan 2006 17:00:54 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F19uu-0007r3-J1 for dix@ietf.org; Mon, 23 Jan 2006 17:12:08 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0NM29LM011576 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Jan 2006 14:02:09 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CD26AC0-7C76-47B1-807C-EB0124FFE0CB@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft of proposed charter (#2) Date: Mon, 23 Jan 2006 14:02:05 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 23-Jan-06, at 12:00 PM, Lisa Dusseault wrote: > I'm going to use my own terms for the 3 parties here because my > confusion about the official terms is an appropriate subject for a > different mail but I can't quite bring myself to use them. Yes, I'm not too fond of the 'identity gang' names. > Thus, my simplified network diagram which ignores proxies and > optional bits like talking to directories > > Content > Server---------| > | | > | Identity > | Server > | | > Client---------| OK >> We can't mandate that the other party in the exchange implement >> DIX over a particular transport. It's an implementation decision >> between the user's client and the other party. We have the motivating >> use cases of a VOIP phone or IM client to illustrate this. > > Here you're talking about the communication between the client and > the content server in my diagram. That communication is almost > outside the scope of DIX. It's the communication that already > takes place over many, many protocols, not all of which DIX WG can > tackle. Indeed. > My personal suggestion is that DIX should tackle HTTP That's my preference, but I wanted to leave the option open in case others wanted to tackle other protocols within this WG. > and add a new Authorization header type and WWW-Authenticate > capability token and associated parameters, That'd sounds like a good way to do it. > and perhaps also tackle SASL for which I'm not qualified to suggest > how. Me neither. >> We could mandate the transport between the user's client and their >> agent. HTTP perhaps... given its simplicity and ubiquity. I do >> hesitate >> though, because I'm sure there are use cases where that doesn't >> make sense. For example my agent might actually be built into my >> client so the transport is IPC or API. What use would that kind of >> agent be?... well it could just be a local replica of my agent in the >> internet. Hmm, is my local agent really just an agent of my agent >> and therefore a non-principal party to the exchange. Agh. What if >> my agent were on a USB key or a smart card? What would my >> transport be then... I'm not sure... I suppose it could be HTTP... > > Now you're talking about the communication between client and > identity server in my diagram. The identity server MUST support > one or more well-known protocols such that if I'm implementing a > client, I can count on being able to contact a standards-compliant > identity server if I'm willing to do the work. Of course a client > might go beyond that and implement other protocols to talk to the > identity server -- even proprietary protocols -- but that would > have to rely on capability discovery or provisioning in order to work. Yes. > So let's say DIX required BEEP and HTTP (at random) as the REQUIRED > TO IMPLEMENT transports for a compliant identity server. This > doesn't necessarily solve all problems for all clients but it does > make it clear what the client implementor has to do. Does a client have to be able to talk to every identity server in existence though. Maybe, but I'm not sure... that's what motivated me to start on the use cases. If I'm worrying for no reason then I'd be OK with mandating one transport for identity providers and clients. >> We could state: >> >> "To ensure interoperability between implementations we mandate >> that the user's client and their agent must support at least DIX >> over HTTP." > > Yes, but even more important for the identity server to have > required-to-implement transports. My terms confused you. The agent is the identity server, so I'm saying the same thing there. > >> It's hard to be definitive about this without the use cases to refer >> to... > > I may be assuming the use cases, but I'll forge onward. > > The last major line in the network diagram is the communication > between the identity server and the content server. Over this > link, REQUIRED transports are crucial and can be kept, I suspect, > to just one. All content servers that advertise support for DIX > delegated authorization MUST be able to communicate with the > identity server chosen by the client using this one transport. All > identity servers that advertise compliance with DIX MUST be able to > communicate with the content server chosen by the client using this > one transport. > > A single mandatory transport is most crucial for this link because > both the content server and identity server are chosen by the > client or user, and the two servers commonly have no ability or > opportunity to do any provisioning or setup, and can only negotiate > over the wire after initially making some kind of blind connection > in one of the two directions. > > Revisiting my simplistic network diagram: > > > Content > Server---------| = ONE TRANSPORT > | | > ANY = | Identity > | Server > | | > Client---------| = ONE/TWO TRANSPORTS or configure/provision > otherwise Yes - good point. I didn't include the protocol exchange between the content server and the identity server because I though there might be alternative solutions that didn't involve a direct connection. dmd1 does this to minimize the code and its complexity at the content server (it's some message handling and a hash function). But an alternative solution could do something more sophisticated. I had a private email from somebody who took much the same position. Does anyone else want to pitch in an opinion on this? John > > > > Lisa > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 17:41:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ANM-0004v6-2s; Mon, 23 Jan 2006 17:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ANK-0004tn-C6 for dix@megatron.ietf.org; Mon, 23 Jan 2006 17:41:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00690 for ; Mon, 23 Jan 2006 17:39:56 -0500 (EST) Message-Id: <200601232239.RAA00690@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AWg-0001HG-Mp for dix@ietf.org; Mon, 23 Jan 2006 17:51:08 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc11) with SMTP id <20060123224111m1100nkrl6e>; Mon, 23 Jan 2006 22:41:11 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] use cases Date: Mon, 23 Jan 2006 14:40:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20060123202219.9960.qmail@web88109.mail.re2.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYgW79JY1GVdSEvSj+BJs2FPGh/XQAEJN1Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org The term 'use case' has different meanings when discussing UML versus an internet protocol. The use case document may deal with more than one set of scenarios. I'll repost an example of a use case draft being used by the p2p sip group: http://www.ietf.org/internet-drafts/draft-bryan-sipping-p2p-usecases-00.txt -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of James Benedict Sent: Monday, January 23, 2006 12:22 PMh To: Digital Identity Exchange Subject: Re: [dix] use cases I agree with you, I'de rather see something a little less detailed. I still would prefer to see something less like a classic use case, and something more illustrative of the existing draft. John's already got something that (IMO) looks pretty good, I'de just like to see some use-cases for it; and i'm worried if we take the traditional "forget about prior art" attitude when we do use-cases, they'll set the process way back. So, can we agree? Something lightweight, with the intent to illustrate the existing draft to start? -- James --- Dick Hardt wrote: > Well, my question was more of "What is a use case?" > > Is it a detailed "Detailed Scenario"? > > I retained Tim Bray of XML fame to assist me with > documenting SXIP > 1.0. His recommendation (which he and I executed on) > was to write > scenarios, where the user activity and what happens > on the wire are > discussed so that the reader can tie it all > together. We wrote > different scenarios so that the reader would be able > to see enough > facets of the protocol to understand it. The use of > names and > specific activities made it easy for the reader to > grasp. I think > this is a useful, but non-normative way to document > a protocol. > > I think this might be too detailed. > > Here is a simple example of what I think a use case > is: > > Sally wants to register at a website. She does some > action that sends > her to her software agent that manages her identity, > that allows her > to select which data she wants to release. > When returning to the site later, Sally clicks on a > button to log > into the site. > > Sally is in control of what data was released to the > site. > Sally did not have to type in any of the data. > Sally does not have new username and password for > the site. > > -- Dick > > On 23-Jan-06, at 11:43 AM, James Benedict wrote: > > > Good question! Especially since we have a "chicken > and > > egg" issue here. Personally, I'de like to see > some > > "example executions" of the current draft to get a > > better understanding of how it works... and to > spot > > potential issues. > > > > However, in the real (well, maybe ideal is a > better > > word) software engineering world, the "use cases" > > would represent an expected "walk through" of the > > application functionality ... from which > requirements > > would be derived ... then the applications, > protocols, > > etc would be implemented. > > > > Interestingly enough, we already have the > end-product. > > Hence, my interest in "examples" of the current > > draft. I'de rather take what we've got and analyse > the > > "use cases" to determine suitability than to try > to > > re-derive the draft from scratch, although some > might > > disagree with me here :) > > > > Since you put out the question Dick, what do you > > propose? > > > > -- > > James > > > > --- Dick Hardt wrote: > > > >> Great to hear that James! > >> > >> I think it would be useful for us all to agree > what > >> a use case is. :-) > >> > >> On 23-Jan-06, at 11:29 AM, James Benedict wrote: > >> > >>> If no one else volunteers, then i'll do it. I'm > >>> working on some use cases for myself anyways... > >> still > >>> trying to get a picture in my head of exactly > what > >>> this protocol is doing. > >>> > >>> I think in pretty (or at least ASCII) pictures > :) > >>> > >>> -- > >>> James > >>> > >>> --- John Merrells wrote: > >>> > >>>> > >>>> If people want to offer up some use cases i'll > >>>> wrangle them into an > >>>> ID... > >>>> > >>>> (I'd rather somebody else did the editing on > this > >>>> draft though...) > >>>> > >>>> John > >>>> > >>>> > >>>> _______________________________________________ > >>>> dix mailing list > >>>> dix@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dix > >>>> > >>> > >>> > >>> _______________________________________________ > >>> dix mailing list > >>> dix@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dix > >>> > >>> > >> > >> > >> _______________________________________________ > >> dix mailing list > >> dix@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dix > >> > > > > > > _______________________________________________ > > dix mailing list > > dix@ietf.org > > https://www1.ietf.org/mailman/listinfo/dix > > > > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jan 23 20:05:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Ccs-0002vw-B2; Mon, 23 Jan 2006 20:05:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Ccq-0002vj-HV for dix@megatron.ietf.org; Mon, 23 Jan 2006 20:05:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20626 for ; Mon, 23 Jan 2006 20:04:06 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1CmF-0001Pb-UM for dix@ietf.org; Mon, 23 Jan 2006 20:15:22 -0500 Received: from [192.168.0.62] ([199.33.32.40]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0O15Hr4018953 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Jan 2006 17:05:25 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: quoted-printable Message-Id: <2F5B1B00-8163-4D3F-83C7-800F6213689A@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Mon, 23 Jan 2006 17:05:13 -0800 X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Subject: [dix] draft of proposed charter (#3) X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Added interoperability statement. Too general or too specific? Reworked the definition of the parties involved. Do you prefer those=20=20 terms? John ---- Proposed Charter for DIX Working Group Digital Identity Exchange - DIX Chairs TBD Applciations Area Director(s): Ted Hardie Scott Hollenbeck Mailing Lists: General Discussion: dix@ietf.org To Subscribe: dix-request@ietf.org 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=20=20 Exchange protocol. DIX is an Internet scale protocol for exchanging=20=20 identity information between endpoints. The protocol architecture=20=20 maintains a separation of control between all parties of the exchange=20=20 and supports both compartmentalized and anonymous identities. Problem Statement The success of the Internet has led to a multitude of online=20=20 information sources and services. A consequence of this has been the=20=20 increasing demand for users to identify themselves and to provide=20=20 information about them. The user is currently bearing the burden of=20=20 managing their authentication credentials and is repeatedly having to=20=20 provide their identity information. For example, signing in to web=20=20 pages and completing user registration forms. Goal The goal of this group is to specify a protocol for moving identity=20=20 information between parties and a system architecture that enables=20=20 the development of software agents to manage the exchange of a user=92s=20= =20 identity information. Method An identity information exchange involves two parties: the user, and=20=20 another party, either relying or asserting. A relying party requests=20=20 identity information and an asserting party provides identity=20=20 information. The identity information exchange protocol involves three principal=20=20 computing endpoints: the agent, the client, and the server. The agent=20=20 is where the user authenticates themselves and a repository where=20=20 they store their identity information. The client is the device the=20=20 user uses to initiate communication with the server and the server=20=20 requests or provides identity information. Non-principal endpoints=20=20 may participate in an information exchange by providing facilitating=20=20 services, such as proxying, caching or agency. The protocol should be both simple and secure. Simple in terms of=20=20 implementation in that minimal modifications should be required to=20=20 the user=92s software and the third party=92s software to participate in=20= =20 an identity information exchange. The protocol should be inherently=20=20 scalable, requiring no centralized services, beyond those that=20=20 already exist, in order to operate. The security of a protocol is well understood within the IETF to be=20=20 the assurance of confidentiality and integrity of any transferred=20=20 information. But, in the context of digital identity we wish to also=20=20 be assured that user=92s agents and the third parties maintain user=20=20 privacy. Any solution should allow DIX messages to be carried over multiple=20=20 alternative transports, including, but not limited to: HTTP, XMPP,=20=20 and SIP. It is anticipated that this working group will initially=20=20 focus on a HTTP based solution. In moving identity information between parties it is expected that=20=20 the messages of the protocol will include elements that bind property=20=20 names and values to digital identities. How a digital identity is=20=20 referred to is an important consideration. The properties an=20=20 identifier could have are that it allows the user to concurrently=20=20 maintain multiple personas, that it could allow for a separation=20=20 between the digital identity and the identifier and that it allow for=20=20 separation between the identifier and the user=92s agent. The identifier should be based on existing identifier and namespace=20=20 mechanisms to ensure flexibility and interoperability, and the=20=20 working group should consider current best practice. For example, a=20=20 URI, a URL or a UUID. Work In Scope A user-centric, simple, secure, interoperable protocol for digital=20=20 identity information exchange. An advanced work item for this working group would be consideration=20=20 of how this protocol could be used for web services protocols (e.g.=20=20 SOAP, XML-RPC, REST), or interoperate with existing web services=20=20 protocols for security information (e.g. WS-Trust). The group must be=20=20 careful not to preclude interoperation at a later date. Although the data that represents the identity information is=20=20 expected to be opaque it is worth mentioning that the data could be=20=20 raw attributes of the digital identity, or could be third party=20=20 claims. A third party claim is signed by an authoritative source so=20=20 that a relying party can be assured of its authenticity. The benefit=20=20 of third party claims, as supported by this protocol, is that the=20=20 separation of claim acquisition from claim presentation provides both=20=20 scalability and privacy benefits. Interoperation To ensure interoperability the DIX Working Group will specify=20=20 mandatory to implement transport bindings. An agent implementation=20=20 must implement the mandatory transport binding for communication with=20=20 both clients and servers. A client implementation must implement the=20=20 client to agent protocol. A server must implement the server to=20=20 agent protocol. The protocol used between the client and the server,=20=20 however, is application-dependent. 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. The schema and type system for identity information. Internet Drafts The Working Group anticipates the authoring of at least three=20=20 Internet Drafts, two of which are expected to be Standards Track=20=20 documents. DIX Use Cases =96 A catalogue of DIX protocol use cases to illustrate=20=20 the problem being solved and to inform the decision making of the=20=20 Working group. For example, an illustrative use case would be a=20=20 website that accepts user generated content. A significant problem=20=20 exists today that these sites attract the attention of spammers. The=20=20 DIX protocol would allow that website to determine the identity of=20=20 the submitter. A potential solution to the spam problem would be for=20=20 the website to check that the submitter is of good standing in their=20=20 community. In other words, the website would request the reputation=20=20 of the submitter. The DIX protocol would allow that reputation data=20=20 to be built up, aggregated, and moved between around. DIX Protocol =96 A description of the DIX protocol. DIX HTTP Transport Binding =96 How the DIX protocol will be mapped down=20= =20 onto HTTP as a transport layer. In this case the user=92s software is a=20= =20 HTTP client, to which no modifications should be required, and the=20=20 third party would be a HTTP server. Continuing with the theme of=20=20 simplicity a HTTP server should require minimal changes to support=20=20 identity information exchange. For example, a HTML form could receive=20=20 information the same way that a user would provide it, as if they=20=20 typed it into the form themselves. Goals and Milestones: March 2006 =96 BOF meeting April 2006 =96 DIX Use Cases Internet Draft June 2006 =96 First DIX Protocol Internet Draft June 2006 =96 First DIX HTTP Transport Binding Internet Draft July 2006 =96 Working Group meeting November 2006 =96 Working Group meeting December 2006 =96 Request Last Call for DIX Protocol December 2006 =96 Request Last Call for DIX HTTP Transport Binding March 2007 =96 Working Group meeting April 2007 =96 Submit DIX Protocol to IESG for consideration as=20=20 Proposed Standard April 2007 =96 Submit DIX HTTP Transport Binding to IESG for=20=20 consideration as Proposed Standard _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 07:23:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NCZ-0007oN-Eb; Tue, 24 Jan 2006 07:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NCY-0007oF-7s for dix@megatron.ietf.org; Tue, 24 Jan 2006 07:23:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06237 for ; Tue, 24 Jan 2006 07:21:39 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NM5-0007nE-0z for dix@ietf.org; Tue, 24 Jan 2006 07:33:02 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCMxXC012961 for ; Tue, 24 Jan 2006 13:22:59 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k0OCMxo3013629 for ; Tue, 24 Jan 2006 13:22:59 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 13:22:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2006 13:22:54 +0100 Message-ID: Thread-Topic: Next Steps Thread-Index: AcYgaMC7qAZ9VwN7TrqVzIkFLJNC8gAFZzRQ From: "Tschofenig, Hannes" To: "Digital Identity Exchange" X-OriginalArrivalTime: 24 Jan 2006 12:22:56.0927 (UTC) FILETIME=[E854C2F0:01C620E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: [dix] Next Steps X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org hi all,=20 i asked for a draft and received one: draft-merrells-dix-01.txt thanks. it was certainly interesting to read through it. bob has given a short overview of the history of the identity work. it also showed that there is already a lot of stuff out there.=20 i would like to know whether you plan to write one (or multiple documents) that contains - a short problem statement (why you need to start this work) - requirements (what new requirements are impacting your work; might be interesting with respect to the existing work) - scenarios (what are new scenarios you have in mind; otherwise reference other work here) - assumptions / framework (in the mailing list discussion i had the impression that the assumptions are very similar to those made in the saml websso profile)=20 - a discussion about the differences to the state-of-the-art (i am particuarly interested in this aspect because of the work on saml, liberty alliance, ws-federation, etc.) =20 thanks in advance.=20 ciao hannes _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 09:19:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1P1Y-0004SK-1Y; Tue, 24 Jan 2006 09:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1P1W-0004Ry-Ix for dix@megatron.ietf.org; Tue, 24 Jan 2006 09:19:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14681 for ; Tue, 24 Jan 2006 09:18:23 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1PB4-0003gT-G0 for dix@ietf.org; Tue, 24 Jan 2006 09:29:47 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0OEJgQH024674 for ; Tue, 24 Jan 2006 14:19:42 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 09:17:45 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jan 2006 14:17:45 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 24 Jan 2006 09:19:37 -0500 Subject: Re: [dix] draft of proposed charter (#2) From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: [dix] draft of proposed charter (#2) Thread-Index: AcYg8TSzcxcG6YzkEdqoTgANk3jHKA== In-Reply-To: <7B11A43E-2A0B-4B41-B439-D28EB0C17F12@sxip.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 14:17:45.0888 (UTC) FILETIME=[F278CA00:01C620F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/20/2006 3:01 PM, "John Merrells" wrote: > > On 20-Jan-06, at 10:40 AM, Peter Davis wrote: > >> 2 drafts. One for the core specification, the >> other for the particular transport binding the wg feels is most >> likely to see adoption (or has unfulfilled requirements), which may be >> HTTP > That's the approach the charter is taking at the moment. > In draft #2 I called out the expected documents that would > come out of a WG and they're in the milestone section. > Is the text not clear on that? More likely a case of the aging eyes ;-) 2 drafts +1 =peterd _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 09:29:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1PB6-00073s-RR; Tue, 24 Jan 2006 09:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1PB5-00072d-D9 for dix@megatron.ietf.org; Tue, 24 Jan 2006 09:29:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15365 for ; Tue, 24 Jan 2006 09:28:16 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1PKe-00042k-E4 for dix@ietf.org; Tue, 24 Jan 2006 09:39:40 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0OETcQH025205 for ; Tue, 24 Jan 2006 14:29:38 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 09:27:41 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jan 2006 14:27:41 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 24 Jan 2006 09:29:38 -0500 Subject: Re: [dix] To add to the charter From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: [dix] To add to the charter Thread-Index: AcYg8prs2XShlIzlEdqoTgANk3jHKA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 14:27:41.0857 (UTC) FILETIME=[55B27110:01C620F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/20/2006 6:09 PM, "John Merrells" wrote: > > On 20-Jan-06, at 7:53 AM, Peter Davis wrote: > >> We should add to the 'In Scope' section: >> >> This working group shall include in it's output, informational >> material >> which results from the assessment of existing specifications, and >> limitations or omissions which requires the production of additional >> specification(s). >> >> Which, I suppose, implies another deliverable. > > I wonder if this is really necessary. If we write up the use cases as a > way of defining the problem and in a sense stating the requirements > of a solution.... > > ...and you're suggesting that we then document why existing > specifications > don't satisfy those requirements. Yes, that is what I am suggesting. There are several specifications from SDOs today (and several that are not), that solve for _some of_ the use cases we may establish here. If we've identified use cases which are not supported with present specifications, great... We've identified areas of focus. > > Hmm, I think we should think about it... but documenting it (and most > probably getting into some huge arguments) seems like a lot of work > to just justify what people are already doing anyway. It seems the responsible thing to do as well. Ignoring prior work in the space (and in some cases, significant peer and security reviews) does not serve any useful purpose. > > I'd ask why it is that multiple groups of people have considered the > existing specifications and concluded that they'd be better off with > something else and gone of and specced and implemented it and > started deploying it. I'd ask the same question. RLBob post lends some clarity, but I'd be interested in hearing the use cases that 'multiple groups' identified, which were not fulfilled by existing work. (which informs the suggested 'review of prior work' above). =peterd (http://public.xdi.org/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 09:37:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1PIq-0000YT-QN; Tue, 24 Jan 2006 09:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1PIo-0000YH-UO for dix@megatron.ietf.org; Tue, 24 Jan 2006 09:37:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15946 for ; Tue, 24 Jan 2006 09:36:15 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1PSN-0004L8-15 for dix@ietf.org; Tue, 24 Jan 2006 09:47:40 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k0OEbaQH025721 for ; Tue, 24 Jan 2006 14:37:36 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 09:35:40 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jan 2006 14:35:40 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 24 Jan 2006 09:37:35 -0500 Subject: Re: [dix] draft of proposed charter (#2) From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: [dix] draft of proposed charter (#2) Thread-Index: AcYd0Fv3mj9DAInDEdq6NAANk3jHKAAINZGQAMChQKA= In-Reply-To: <200601210044.TAA16904@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 14:35:40.0333 (UTC) FILETIME=[72E415D0:01C620F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/20/2006 7:45 PM, "Suresh Venkatraman" wrote: >> SIP presently has means to 'prove' the identity of the calling party sip >> identity [1] which supplies a new header (and some hash/signing). While it >> is presently in ID, it is header to RFC editor queue. >> >> It would be for the SIP WG to draft a binding of 'dix' with sip-identity, >> IMHO. At least for the purposes laid out in the above use case. > > It's in the draft "Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP)". It assumes identity is defined for SIP, > but is not cryptographically secure. Which is true. SIP (without mechanisms such as SIP-identity) suffer the same authentication problems email does. Specifically, the ability for the UAC to forge the 'From' header. > > The draft is of course motivated by a need for authenticating identity but I > worry about yet another separate but incompatible scheme for SIP. There is > also a proposal to bind SAML to SIP titled "Using SAML for SIP". I am not suggesting a new scheme for SIP, others were suggesting SIP as another target transport. SIP-identity/SIP-SAML are there now. As I stated, it would be up to the SIP WG to determine if adding a 'dix' mechanism is a 'Good Thing' or not. > > Some future DIX binding for SIP will help add to the confusion. Yep. So we leave it up to them. > > > Of course it's par for the course to throw everything under the sun into > SIP. And the charter actually states simplicity as its goal... I can't wait > until every application or network WG has its own version of identity, none > of which will interoperate. > ;-) =peterd _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 12:34:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S3m-0005MD-Ms; Tue, 24 Jan 2006 12:34:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S3l-0005M4-9s for dix@megatron.ietf.org; Tue, 24 Jan 2006 12:34:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02961 for ; Tue, 24 Jan 2006 12:32:54 -0500 (EST) Message-Id: <200601241732.MAA02961@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1SDI-0003p3-LO for dix@ietf.org; Tue, 24 Jan 2006 12:44:20 -0500 Received: from sureshmobile (c-24-18-112-30.hsd1.wa.comcast.net[24.18.112.30]) by comcast.net (rwcrmhc12) with SMTP id <20060124173409m12008jvcje>; Tue, 24 Jan 2006 17:34:09 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] draft of proposed charter (#2) Date: Tue, 24 Jan 2006 09:33:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYd0Fv3mj9DAInDEdq6NAANk3jHKAAINZGQAMChQKAABOl0UA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >> It's in the draft "Enhancements for Authenticated Identity Management in >> the Session Initiation Protocol (SIP)". It assumes identity is defined >> for SIP, but is not cryptographically secure. > > Which is true. SIP (without mechanisms such as SIP-identity) suffer the > same authentication problems email does. Specifically, the ability for the > UAC to forge the 'From' header. SIP does not necessarily suffer from those problems, and the spec acknowledges this. Existing challenge/response mechanisms using digest could solve this problem given a well known SIP server for the UAC (SRV perhaps) w/ Certs. The spec acknowledges that other mechanisms exist but goes on to state lack of support from user-agents. IMO, lack of support is not a good reason to create another way of doing the same thing. >From the Spec: RFC3261 specifies a number of security mechanisms that can be employed by SIP UAs, including Digest, TLS and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves > I am not suggesting a new scheme for SIP, others were suggesting SIP as > another target transport. SIP-identity/SIP-SAML are there now. As I > stated, it would be up to the SIP WG to determine if adding a 'dix' > mechanism is a 'Good Thing' or not. The same can be said of any chosen transport protocol including HTTP. Are you suggesting that every protocol binding should be done by the existing working group? IMO, unless the DIX transport binding extends the particular transport protocol, it should be done by this group. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Peter Davis Sent: Tuesday, January 24, 2006 6:38 AM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) On 1/20/2006 7:45 PM, "Suresh Venkatraman" wrote: >> SIP presently has means to 'prove' the identity of the calling party sip >> identity [1] which supplies a new header (and some hash/signing). While it >> is presently in ID, it is header to RFC editor queue. >> >> It would be for the SIP WG to draft a binding of 'dix' with sip-identity, >> IMHO. At least for the purposes laid out in the above use case. > > It's in the draft "Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP)". It assumes identity is defined for SIP, > but is not cryptographically secure. Which is true. SIP (without mechanisms such as SIP-identity) suffer the same authentication problems email does. Specifically, the ability for the UAC to forge the 'From' header. > > The draft is of course motivated by a need for authenticating identity but I > worry about yet another separate but incompatible scheme for SIP. There is > also a proposal to bind SAML to SIP titled "Using SAML for SIP". I am not suggesting a new scheme for SIP, others were suggesting SIP as another target transport. SIP-identity/SIP-SAML are there now. As I stated, it would be up to the SIP WG to determine if adding a 'dix' mechanism is a 'Good Thing' or not. > > Some future DIX binding for SIP will help add to the confusion. Yep. So we leave it up to them. > > > Of course it's par for the course to throw everything under the sun into > SIP. And the charter actually states simplicity as its goal... I can't wait > until every application or network WG has its own version of identity, none > of which will interoperate. > ;-) =peterd _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 12:35:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S4L-0005gV-8S; Tue, 24 Jan 2006 12:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1S4J-0005gF-54 for dix@megatron.ietf.org; Tue, 24 Jan 2006 12:34:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03074 for ; Tue, 24 Jan 2006 12:33:29 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1SDr-0003qz-V8 for dix@ietf.org; Tue, 24 Jan 2006 12:44:54 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 24 Jan 2006 10:34:38 -0700 Message-Id: <43D60007.0A7A.00E4.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 24 Jan 2006 10:23:03 -0700 From: "Tom Doman" To: "Digital Identity Exchange" Subject: Re: [dix] draft proposed charter - consensus? References: <43D13790.9050001@thinkingcat.com> In-Reply-To: <43D13790.9050001@thinkingcat.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0051424767==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0051424767== Content-Type: multipart/alternative; boundary="=__PartF8DA6067.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF8DA6067.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, Leslie, taking your thought further, it makes me wonder, how does the = DIX protocol end up being much different from SAML? Dick, I know you like = to discount SAML due to RSA licensing issues (which is a very relevant = point), but I'd like to have you weigh in on the other material differences= you might anticipate in the DIX protocol itself. In other words, where = else do you think SAML is lacking or perhaps inappropriate for digital = identity information exchange? =20 Regards, Tom >>> leslie@thinkingcat.com 1/20/2006 12:18:40 pm >>> It is clearer, but I think the charter still needs to be clearer about what is meant by "digital identity". Is the purpose to be able to access *any* stored data about a person, or *specific* stored data? In many regards, saying "any" is easier; sort out the format for expressing attribute/values, and you're done. However, then there are issues of interoperability (is there a minimum set of identity data that is mandatory to provide?). And, if it is "any", then how is this not a directory service with additional labelling (addresses/names/identifiers) on top? Leslie. Peter Davis wrote: > On 1/19/2006 3:06 PM, "John Merrells" wrote: > > >>On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> >> >>>>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=B9s identity >>>>information. >> >>>Perhaps you mean management of the exchange of user attributes and >>>authentication states between parties. 'managing identities' >>>implies to my >>>read as a sw which manages the storage of user data >> >>A subtle point, but a good one. It will enable 'storage of', but that's >>not the only thing, and not the main thing. How about... >> >>"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 _the_exchange_of_ a >>user=B9s identity information." > > > Yes, improved. > > =3Dpeterd (http://public.xdi.org/=3Dpeterd) > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=__PartF8DA6067.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, Leslie, taking your thought further, it makes me wonder, how = does the DIX protocol end up being much different from SAML?  Dick, I = know you like to discount SAML due to RSA licensing issues (which is = a very relevant point), but I'd like to have you weigh in on the other = material differences you might anticipate in the DIX protocol itself. = In other words, where else do you think SAML is lacking or perhaps = inappropriate for digital identity information exchange?
 
Regards,
Tom

>>> leslie@thinkingcat.com 1/20/2006 12:18:40 pm = >>>

It is clearer, but I think the charter still needs to = be
clearer about what is meant by "digital identity".  Is
the = purpose to be able to access *any* stored data about
a person, or = *specific* stored data?

In many regards, saying "any" is easier; = sort out the format
for expressing attribute/values, and you're = done.  However,
then there are issues of interoperability (is = there a minimum
set of identity data that is mandatory to provide?).
=
And, if it is "any", then how is this not a directory service
with = additional labelling (addresses/names/identifiers) on top?

Leslie.
Peter Davis wrote:
> On 1/19/2006 3:06 PM, "John Merrells" = <merrells@sxip.com> wrote:
>
>
>>On 19-Jan-06, = at 8:32 AM, Peter Davis wrote:
>>
>>
>>>>T= he goal of this group is to specify a protocol for moving identity
>&= gt;>>information between parties and a system architecture that = enables
>>>>the development of software agents to manage a = user=B9s identity
>>>>information.
>>
>>&g= t;Perhaps you mean management of the exchange of user attributes and
>= ;>>authentication states between parties.  'managing identities'=
>>>implies to my
>>>read as a sw which manages = the storage of user data
>>
>>A subtle point, but a good = one. It will enable 'storage of', but that's
>>not the only = thing, and not the main thing. How about...
>>
>>"The = goal of this group is to specify a protocol for moving identity
>>= information between parties and a system architecture that enables
>&= gt;the development of software agents to manage _the_exchange_of_ = a
>>user=B9s identity information."
>
>
> Yes, = improved.
>
> =3Dpeterd  (http://public.xdi.org/=3Dpeterd)=
>
>
> _______________________________________________> dix mailing list
> dix@ietf.org
> https://www1.ietf.org/m= ailman/listinfo/dix
>

________________________________________= _______
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailma= n/listinfo/dix
--=__PartF8DA6067.0__=-- --===============0051424767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0051424767==-- From dix-bounces@ietf.org Tue Jan 24 12:57:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1SQK-0003En-Vo; Tue, 24 Jan 2006 12:57:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1SQJ-0003EW-Cx for dix@megatron.ietf.org; Tue, 24 Jan 2006 12:57:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04614 for ; Tue, 24 Jan 2006 12:56:13 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1SZt-0004dd-Rd for dix@ietf.org; Tue, 24 Jan 2006 13:07:38 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 24 Jan 2006 10:57:33 -0700 Message-Id: <43D605DE.0A7A.00E4.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 24 Jan 2006 10:47:58 -0700 From: "Tom Doman" To: "Digital Identity Exchange" Subject: Re: [dix] draft proposed charter - consensus? References: <43D13790.9050001@thinkingcat.com> <43D60007.0A7A.00E4.0@novell.com> In-Reply-To: <43D60007.0A7A.00E4.0@novell.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2077277789==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============2077277789== Content-Type: multipart/alternative; boundary="=__PartCBE9535E.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartCBE9535E.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Replying to myself here ... I'll have to reread the charter and get deeper = into the draft but, perhaps the intent here is not to worry about the data = model, just how to pass "whatever it is" around. =20 Tom >>> TDoman@novell.com 1/24/2006 10:23:03 am >>> Yes, Leslie, taking your thought further, it makes me wonder, how does the = DIX protocol end up being much different from SAML? Dick, I know you like = to discount SAML due to RSA licensing issues (which is a very relevant = point), but I'd like to have you weigh in on the other material differences= you might anticipate in the DIX protocol itself. In other words, where = else do you think SAML is lacking or perhaps inappropriate for digital = identity information exchange? =20 Regards, Tom >>> leslie@thinkingcat.com 1/20/2006 12:18:40 pm >>> It is clearer, but I think the charter still needs to be clearer about what is meant by "digital identity". Is the purpose to be able to access *any* stored data about a person, or *specific* stored data? In many regards, saying "any" is easier; sort out the format for expressing attribute/values, and you're done. However, then there are issues of interoperability (is there a minimum set of identity data that is mandatory to provide?). And, if it is "any", then how is this not a directory service with additional labelling (addresses/names/identifiers) on top? Leslie. Peter Davis wrote: > On 1/19/2006 3:06 PM, "John Merrells" wrote: > > >>On 19-Jan-06, at 8:32 AM, Peter Davis wrote: >> >> >>>>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=B9s identity >>>>information. >> >>>Perhaps you mean management of the exchange of user attributes and >>>authentication states between parties. 'managing identities' >>>implies to my >>>read as a sw which manages the storage of user data >> >>A subtle point, but a good one. It will enable 'storage of', but that's >>not the only thing, and not the main thing. How about... >> >>"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 _the_exchange_of_ a >>user=B9s identity information." > > > Yes, improved. > > =3Dpeterd (http://public.xdi.org/=3Dpeterd) > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=__PartCBE9535E.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Replying to myself here ... I'll have to reread the charter and get = deeper into the draft but, perhaps the intent here is not to = worry about the data model, just how to pass "whatever it is" around.
=
 
Tom

>>> TDoman@novell.com 1/24/2006 10:23:03 am = >>>
Yes, Leslie, taking your thought further, it makes me wonder, how = does the DIX protocol end up being much different from SAML?  Dick, I = know you like to discount SAML due to RSA licensing issues (which is = a very relevant point), but I'd like to have you weigh in on the other = material differences you might anticipate in the DIX protocol itself. = In other words, where else do you think SAML is lacking or perhaps = inappropriate for digital identity information exchange?
 
Regards,
Tom

>>> leslie@thinkingcat.com 1/20/2006 12:18:40 pm = >>>

It is clearer, but I think the charter still needs to = be
clearer about what is meant by "digital identity".  Is
the = purpose to be able to access *any* stored data about
a person, or = *specific* stored data?

In many regards, saying "any" is easier; = sort out the format
for expressing attribute/values, and you're = done.  However,
then there are issues of interoperability (is = there a minimum
set of identity data that is mandatory to provide?).
=
And, if it is "any", then how is this not a directory service
with = additional labelling (addresses/names/identifiers) on top?

Leslie.
Peter Davis wrote:
> On 1/19/2006 3:06 PM, "John Merrells" = <merrells@sxip.com> wrote:
>
>
>>On 19-Jan-06, = at 8:32 AM, Peter Davis wrote:
>>
>>
>>>>T= he goal of this group is to specify a protocol for moving identity
>&= gt;>>information between parties and a system architecture that = enables
>>>>the development of software agents to manage a = user=B9s identity
>>>>information.
>>
>>&g= t;Perhaps you mean management of the exchange of user attributes and
>= ;>>authentication states between parties.  'managing identities'=
>>>implies to my
>>>read as a sw which manages = the storage of user data
>>
>>A subtle point, but a good = one. It will enable 'storage of', but that's
>>not the only = thing, and not the main thing. How about...
>>
>>"The = goal of this group is to specify a protocol for moving identity
>>= information between parties and a system architecture that enables
>&= gt;the development of software agents to manage _the_exchange_of_ = a
>>user=B9s identity information."
>
>
> Yes, = improved.
>
> =3Dpeterd  (http://public.xdi.org/=3Dpeterd)=
>
>
> _______________________________________________> dix mailing list
> dix@ietf.org
> https://www1.ietf.org/m= ailman/listinfo/dix
>

________________________________________= _______
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailma= n/listinfo/dix
--=__PartCBE9535E.0__=-- --===============2077277789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============2077277789==-- From dix-bounces@ietf.org Tue Jan 24 13:37:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1T2g-0006ev-S4; Tue, 24 Jan 2006 13:37:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1T2f-0006en-LJ for dix@megatron.ietf.org; Tue, 24 Jan 2006 13:37:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07973 for ; Tue, 24 Jan 2006 13:35:51 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1TC6-0006Fd-BG for dix@ietf.org; Tue, 24 Jan 2006 13:47:17 -0500 Received: by wproxy.gmail.com with SMTP id i4so1251229wra for ; Tue, 24 Jan 2006 10:37:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=rvHaWjtsmNm833ri05WovB9+gcR0HIVn0jOhgJQ3M17OFPWIzr9zY2/7ak8s2u2Xb2eIcsLpqva+tCAjQxkHoDSnqDy6UUFe/Ft9CRowZZIm0rWL73rS6zmTLaO3Dsdcgjij33AYA5X69x2ywuhj1uWiLMnApsMssWPpbzN7o9I= Received: by 10.65.249.11 with SMTP id b11mr2563615qbs; Tue, 24 Jan 2006 10:37:05 -0800 (PST) Received: from ?10.0.1.4? ( [65.39.152.179]) by mx.gmail.com with ESMTP id d2sm3653796qbc.2006.01.24.10.37.03; Tue, 24 Jan 2006 10:37:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D605DE.0A7A.00E4.0@novell.com> References: <43D13790.9050001@thinkingcat.com> <43D60007.0A7A.00E4.0@novell.com> <43D605DE.0A7A.00E4.0@novell.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0026573D-4C89-4617-9AAF-7C4303E0AD2F@bryght.com> Content-Transfer-Encoding: 7bit From: Boris Mann Subject: Re: [dix] draft proposed charter - consensus? Date: Tue, 24 Jan 2006 10:37:01 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 24-Jan-06, at 9:47 AM, Tom Doman wrote: > Replying to myself here ... I'll have to reread the charter and get > deeper into the draft but, perhaps the intent here is not to worry > about the data model, just how to pass "whatever it is" around. Theoretically, DIX could be SAML-compliant, if passed the correct "whatever it is" around. -- Boris Mann > > >>> TDoman@novell.com 1/24/2006 10:23:03 am >>> > Yes, Leslie, taking your thought further, it makes me wonder, how > does the DIX protocol end up being much different from SAML? Dick, > I know you like to discount SAML due to RSA licensing issues (which > is a very relevant point), but I'd like to have you weigh in on the > other material differences you might anticipate in the DIX protocol > itself. In other words, where else do you think SAML is lacking or > perhaps inappropriate for digital identity information exchange? > > Regards, > Tom > > >>> leslie@thinkingcat.com 1/20/2006 12:18:40 pm >>> > > It is clearer, but I think the charter still needs to be > clearer about what is meant by "digital identity". Is > the purpose to be able to access *any* stored data about > a person, or *specific* stored data? > > In many regards, saying "any" is easier; sort out the format > for expressing attribute/values, and you're done. However, > then there are issues of interoperability (is there a minimum > set of identity data that is mandatory to provide?). > > And, if it is "any", then how is this not a directory service > with additional labelling (addresses/names/identifiers) on top? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 13:40:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1T5k-0007od-KE; Tue, 24 Jan 2006 13:40:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1T5j-0007mA-3M for dix@megatron.ietf.org; Tue, 24 Jan 2006 13:40:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08236 for ; Tue, 24 Jan 2006 13:39:00 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1TFJ-0006Mu-TL for dix@ietf.org; Tue, 24 Jan 2006 13:50:26 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 24 Jan 2006 11:40:20 -0700 Message-Id: <43D61214.D091.001C.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 24 Jan 2006 11:40:04 -0700 From: "Jim Sermersheim" To: "'Digital Identity Exchange'" Subject: Transports (was: RE: [dix] draft of proposed charter (#2)_ References: <200601241732.MAA02961@ietf.org> In-Reply-To: <200601241732.MAA02961@ietf.org> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266583031==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0266583031== Content-Type: multipart/alternative; boundary="=__Part1D3F8594.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part1D3F8594.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm likely tainting this with my own views , but it feels like what most people want is a protocol definition which at some level is transport independent. On top of that, bindings to HTTP would be defined. The HTTP bindings would be seen as the easiest route to interoperability. Bindings to other transports may be defined, but don't have to be within the charter of the DIX WG. Depending on how much work is involved in writing a binding spec, some kind of guidelines document for doing so might be necessary. How tightly coupled the transport-independent parts and HTTP-specific are defined to be is debatable. The more loosely coupled, the more re-work to dmd-01. Is this a fair general read? Jim >>> sureshven@gmail.com 1/24/06 10:33:43 am >>> >> It's in the draft "Enhancements for Authenticated Identity Management in >> the Session Initiation Protocol (SIP)". It assumes identity is defined >> for SIP, but is not cryptographically secure. > > Which is true. SIP (without mechanisms such as SIP-identity) suffer the > same authentication problems email does. Specifically, the ability for the > UAC to forge the 'From' header. SIP does not necessarily suffer from those problems, and the spec acknowledges this. Existing challenge/response mechanisms using digest could solve this problem given a well known SIP server for the UAC (SRV perhaps) w/ Certs. The spec acknowledges that other mechanisms exist but goes on to state lack of support from user-agents. IMO, lack of support is not a good reason to create another way of doing the same thing. >From the Spec: RFC3261 specifies a number of security mechanisms that can be employed by SIP UAs, including Digest, TLS and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves > I am not suggesting a new scheme for SIP, others were suggesting SIP as > another target transport. SIP-identity/SIP-SAML are there now. As I > stated, it would be up to the SIP WG to determine if adding a 'dix' > mechanism is a 'Good Thing' or not. The same can be said of any chosen transport protocol including HTTP. Are you suggesting that every protocol binding should be done by the existing working group? IMO, unless the DIX transport binding extends the particular transport protocol, it should be done by this group. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Peter Davis Sent: Tuesday, January 24, 2006 6:38 AM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) On 1/20/2006 7:45 PM, "Suresh Venkatraman" wrote: >> SIP presently has means to 'prove' the identity of the calling party sip >> identity [1] which supplies a new header (and some hash/signing). While it >> is presently in ID, it is header to RFC editor queue. >> >> It would be for the SIP WG to draft a binding of 'dix' with sip-identity, >> IMHO. At least for the purposes laid out in the above use case. > > It's in the draft "Enhancements for Authenticated Identity Management in the > Session Initiation Protocol (SIP)". It assumes identity is defined for SIP, > but is not cryptographically secure. Which is true. SIP (without mechanisms such as SIP-identity) suffer the same authentication problems email does. Specifically, the ability for the UAC to forge the 'From' header. > > The draft is of course motivated by a need for authenticating identity but I > worry about yet another separate but incompatible scheme for SIP. There is > also a proposal to bind SAML to SIP titled "Using SAML for SIP". I am not suggesting a new scheme for SIP, others were suggesting SIP as another target transport. SIP-identity/SIP-SAML are there now. As I stated, it would be up to the SIP WG to determine if adding a 'dix' mechanism is a 'Good Thing' or not. > > Some future DIX binding for SIP will help add to the confusion. Yep. So we leave it up to them. > > > Of course it's par for the course to throw everything under the sun into > SIP. And the charter actually states simplicity as its goal... I can't wait > until every application or network WG has its own version of identity, none > of which will interoperate. > ;-) =peterd _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=__Part1D3F8594.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm likely tainting this with my own views , but it feels like what = most people want is a protocol definition which at some level is = transport independent. On top of that, bindings to HTTP would be = defined. The HTTP bindings would be seen as the easiest route to = interoperability. Bindings to other transports may be defined, but don't = have to be within the charter of the DIX WG. Depending on how much work is = involved in writing a binding spec, some kind of guidelines document for = doing so might be necessary.
 
How tightly coupled the transport-independent parts and HTTP-specific = are defined to be is debatable. The more loosely coupled, the = more re-work to dmd-01.
 
Is this a fair general read?
 
Jim


>>> sureshven@gmail.com 1/24/06 10:33:43 am = >>>
>> It's in the draft "Enhancements for Authenticated = Identity Management in
>> the Session Initiation Protocol (SIP)". = It assumes identity is defined
>> for SIP, but is not cryptographi= cally secure.
>
> Which is true.  SIP (without mechanisms = such as SIP-identity) suffer the
> same authentication problems = email does. Specifically, the ability for the
> UAC to forge the = 'From' header.

SIP does not necessarily suffer from those problems, = and the spec
acknowledges this. Existing challenge/response mechanisms = using digest could
solve this problem given a well known SIP server for = the UAC (SRV perhaps)
w/ Certs. The spec acknowledges that other = mechanisms exist but goes on to
state lack of support from user-agents. = IMO, lack of support is not a good
reason to create another way of = doing the same thing.

>From the Spec:

RFC3261 specifies a = number of security mechanisms that can be
employed
by SIP UAs, = including Digest, TLS and S/MIME (implementations may
support other = security schemes as well). However, few SIP user
agents
today = support the end-user certificates necessary to authenticate
themselves
> I am not suggesting a new scheme for SIP, others were suggesting= SIP as
> another target transport.  SIP-identity/SIP-SAML are = there now.  As I
> stated, it would be up to the SIP WG to = determine if adding a 'dix'
> mechanism is a 'Good Thing' or = not.

The same can be said of any chosen transport protocol = including HTTP. Are
you suggesting that every protocol binding should = be done by the existing
working group? IMO, unless the DIX transport = binding extends the particular
transport protocol, it should be done by = this group.

-----Original Message-----
From: dix-bounces@ietf.or= g [mailto:dix-bounces@ietf.org] On Behalf Of Peter
Davis
Sent: = Tuesday, January 24, 2006 6:38 AM
To: Digital Identity Exchange = <dix@ietf.org>
Subject: Re: [dix] draft of proposed charter = (#2)

On 1/20/2006 7:45 PM, "Suresh Venkatraman" <sureshven@gmail.= com> wrote:

>> SIP presently has means to 'prove' the = identity of the calling party sip
>> identity [1] which supplies = a new header (and some hash/signing). While
it
>> is presently = in ID, it is header to RFC editor queue.
>>
>> It would = be for the SIP WG to draft a binding of 'dix' with sip-identity,
>>= ; IMHO. At least for the purposes laid out in the above use case.
> =
> It's in the draft "Enhancements for Authenticated Identity = Management in
the
> Session Initiation Protocol (SIP)". It = assumes identity is defined for
SIP,
> but is not cryptographicall= y secure.

Which is true.  SIP (without mechanisms such as = SIP-identity) suffer the
same authentication problems email does. = Specifically, the ability for the
UAC to forge the 'From' header.
>
> The draft is of course motivated by a need for authenticatin= g identity but
I
> worry about yet another separate but incompatib= le scheme for SIP. There is
> also a proposal to bind SAML to SIP = titled "Using SAML for SIP".

I am not suggesting a new scheme for = SIP, others were suggesting SIP as
another target transport.  = SIP-identity/SIP-SAML are there now.  As I
stated, it would be up = to the SIP WG to determine if adding a 'dix'
mechanism is a 'Good = Thing' or not.

>
> Some future DIX binding for SIP will = help add to the confusion.

Yep. So we leave it up to them.

&g= t;
> <sarcasm>
> Of course it's par for the course to = throw everything under the sun into
> SIP. And the charter actually = states simplicity as its goal... I can't
wait
> until every = application or network WG has its own version of identity,
none
> = of which will interoperate.
> </sarcasm>

;-)

=3Dp= eterd


_______________________________________________
dix = mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix<= BR>


_______________________________________________
dix = mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix<= BR>
--=__Part1D3F8594.0__=-- --===============0266583031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0266583031==-- From dix-bounces@ietf.org Tue Jan 24 13:52:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1THb-0002xp-De; Tue, 24 Jan 2006 13:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1THa-0002xk-MT for dix@megatron.ietf.org; Tue, 24 Jan 2006 13:52:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09071 for ; Tue, 24 Jan 2006 13:51:16 -0500 (EST) Message-Id: <200601241851.NAA09071@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1TR9-0006oW-Q4 for dix@ietf.org; Tue, 24 Jan 2006 14:02:42 -0500 Received: from sureshmobile (c-24-18-112-30.hsd1.wa.comcast.net[24.18.112.30]) by comcast.net (rwcrmhc11) with SMTP id <20060124185233m1100oihpte>; Tue, 24 Jan 2006 18:52:33 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: Transports (was: RE: [dix] draft of proposed charter (#2)_ Date: Tue, 24 Jan 2006 10:52:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <43D61214.D091.001C.0@novell.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYhFbpIBc3wlBPpQCOOugdaUaw9oAAAEY9A X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > I'm likely tainting this with my own views , but it feels like what = most=20 > people want=A0is a protocol definition which at some level is = transport > independent. On top of that, bindings to HTTP=A0would be defined. The = HTTP > bindings=A0would be seen as the easiest route to interoperability. = Bindings > to other transports may be defined, but don't have to be within the > charter of the DIX WG. Depending on how much work is involved in = writing a > binding spec, some kind of guidelines document for doing so might be > necessary. > ... > Is this a fair general read? I would be in agreement with this approach as it allows for immediate interoperability (HTTP) while maintaining flexibility in future binding implementations. ________________________________________ From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of = Jim Sermersheim Sent: Tuesday, January 24, 2006 10:40 AM To: 'Digital Identity Exchange' Subject: Transports (was: RE: [dix] draft of proposed charter (#2)_ I'm likely tainting this with my own views , but it feels like what most people want=A0is a protocol definition which at some level is transport independent. On top of that, bindings to HTTP=A0would be defined. The = HTTP bindings=A0would be seen as the easiest route to interoperability. = Bindings to other transports may be defined, but don't have to be within the charter = of the DIX WG. Depending on how much work is involved in writing a binding spec, some kind of guidelines document for doing so might be necessary. =A0 How tightly coupled the transport-independent parts and HTTP-specific = are defined to be is debatable. The more loosely coupled,=A0the = more=A0re-work to dmd-01. =A0 Is this a fair general read? =A0 Jim >>> sureshven@gmail.com 1/24/06 10:33:43 am >>> >> It's in the draft "Enhancements for Authenticated Identity Management = in >> the Session Initiation Protocol (SIP)". It assumes identity is = defined >> for SIP, but is not cryptographically secure. > > Which is true.=A0 SIP (without mechanisms such as SIP-identity) suffer = the > same authentication problems email does. Specifically, the ability for = the > UAC to forge the 'From' header. SIP does not necessarily suffer from those problems, and the spec acknowledges this. Existing challenge/response mechanisms using digest = could solve this problem given a well known SIP server for the UAC (SRV = perhaps) w/ Certs. The spec acknowledges that other mechanisms exist but goes on = to state lack of support from user-agents. IMO, lack of support is not a = good reason to create another way of doing the same thing. >From the Spec: RFC3261 specifies a number of security mechanisms that can be employed by SIP UAs, including Digest, TLS and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves > I am not suggesting a new scheme for SIP, others were suggesting SIP = as > another target transport.=A0 SIP-identity/SIP-SAML are there now.=A0 = As I > stated, it would be up to the SIP WG to determine if adding a 'dix' > mechanism is a 'Good Thing' or not. The same can be said of any chosen transport protocol including HTTP. = Are you suggesting that every protocol binding should be done by the = existing working group? IMO, unless the DIX transport binding extends the = particular transport protocol, it should be done by this group.=20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of = Peter Davis Sent: Tuesday, January 24, 2006 6:38 AM To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) On 1/20/2006 7:45 PM, "Suresh Venkatraman" wrote: >> SIP presently has means to 'prove' the identity of the calling party = sip >> identity [1] which supplies a new header (and some hash/signing). = While it >> is presently in ID, it is header to RFC editor queue. >>=20 >> It would be for the SIP WG to draft a binding of 'dix' with = sip-identity, >> IMHO. At least for the purposes laid out in the above use case. >=20 > It's in the draft "Enhancements for Authenticated Identity Management = in the > Session Initiation Protocol (SIP)". It assumes identity is defined for SIP, > but is not cryptographically secure. Which is true.=A0 SIP (without mechanisms such as SIP-identity) suffer = the same authentication problems email does. Specifically, the ability for = the UAC to forge the 'From' header. >=20 > The draft is of course motivated by a need for authenticating identity = but I > worry about yet another separate but incompatible scheme for SIP. = There is > also a proposal to bind SAML to SIP titled "Using SAML for SIP". I am not suggesting a new scheme for SIP, others were suggesting SIP as another target transport.=A0 SIP-identity/SIP-SAML are there now.=A0 As = I stated, it would be up to the SIP WG to determine if adding a 'dix' mechanism is a 'Good Thing' or not. >=20 > Some future DIX binding for SIP will help add to the confusion. Yep. So we leave it up to them. >=20 > > Of course it's par for the course to throw everything under the sun = into > SIP. And the charter actually states simplicity as its goal... I can't wait > until every application or network WG has its own version of identity, none > of which will interoperate. > ;-) =3Dpeterd _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 18:55:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y0f-0005jw-DY; Tue, 24 Jan 2006 18:55:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y0d-0005hW-L9 for dix@megatron.ietf.org; Tue, 24 Jan 2006 18:55:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17976 for ; Tue, 24 Jan 2006 18:54:05 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1YAG-00079P-FM for dix@ietf.org; Tue, 24 Jan 2006 19:05:33 -0500 Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id k0ONtKHr004671 for ; Tue, 24 Jan 2006 23:55:24 GMT Message-ID: <43D6BE60.5060004@neustar.biz> Date: Tue, 24 Jan 2006 15:55:12 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] To add to the charter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org John Merrells wrote: > > On 20-Jan-06, at 7:53 AM, Peter Davis wrote: >> We should add to the 'In Scope' section: >> >> This working group shall include in it's output, informational material >> which results from the assessment of existing specifications, and >> limitations or omissions which requires the production of additional >> specification(s). >> >> Which, I suppose, implies another deliverable. > > I wonder if this is really necessary. If we write up the use cases as a > way of defining the problem and in a sense stating the requirements > of a solution.... > > ...and you're suggesting that we then document why existing specifications > don't satisfy those requirements. > > I'd ask why it is that multiple groups of people have considered the > existing specifications and concluded that they'd be better off with > something else and gone of and specced and implemented it and > started deploying it. Simply because a variety of folks are re-inventing the wheel for a variety of reasons doesn't mean blindly doing it again is a reasonable thing to do. I can see why ad-hoc coalitions and/or company-driven efforts are doing such, but I don't think an SDO-based working group should do so, especially given the amount of prior related work in this area, as PeterD mentioned. Peter Davis wrote: > It seems the responsible thing to do as well. Ignoring prior work in the > space (and in some cases, significant peer and security reviews) does not > serve any useful purpose. agreed. Peter Davis continued: > I'd ask the same question. RLBob post lends some clarity, but I'd be > interested in hearing the use cases that 'multiple groups' identified, which > were not fulfilled by existing work. (which informs the suggested 'review of > prior work' above). Yep. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 18:55:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y0l-00061j-R9; Tue, 24 Jan 2006 18:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y0k-0005nC-Ue for dix@megatron.ietf.org; Tue, 24 Jan 2006 18:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17997 for ; Tue, 24 Jan 2006 18:54:09 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1YAL-00079e-Qp for dix@ietf.org; Tue, 24 Jan 2006 19:05:38 -0500 Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id k0ONtQHr004675 for ; Tue, 24 Jan 2006 23:55:30 GMT Message-ID: <43D6BE66.5030303@neustar.biz> Date: Tue, 24 Jan 2006 15:55:18 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Next Steps References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Tschofenig, Hannes wrote: > > i would like to know whether you plan to write one (or multiple > documents) that contains > - a short problem statement (why you need to start this work) > - requirements (what new requirements are impacting your work; might be > interesting with respect to the existing work) > - scenarios (what are new scenarios you have in mind; otherwise > reference other work here) > - assumptions / framework (in the mailing list discussion i had the > impression that the assumptions are very similar to those made in the > saml websso profile) > - a discussion about the differences to the state-of-the-art (i am > particuarly interested in this aspect because of the work on saml, > liberty alliance, ws-federation, etc.) +1 JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 18:57:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y2n-0007G1-29; Tue, 24 Jan 2006 18:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y2m-0007Fs-DE for dix@megatron.ietf.org; Tue, 24 Jan 2006 18:57:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18461 for ; Tue, 24 Jan 2006 18:56:18 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1YCQ-0007MN-Ei for dix@ietf.org; Tue, 24 Jan 2006 19:07:46 -0500 Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id k0ONvYHr004767 for ; Tue, 24 Jan 2006 23:57:38 GMT Message-ID: <43D6BEE6.7000803@neustar.biz> Date: Tue, 24 Jan 2006 15:57:26 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] To add to the charter References: <97BEFC4D-8771-4DA6-8BD3-D1D9FB6EBA83@netmesh.us> <460C8C0D-2DA0-4D60-93C6-B3E2B03858B5@netmesh.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org John Merrells wrote: > > On 20-Jan-06, at 10:08 PM, Johannes Ernst wrote: > >> - but you also say that we should just be codifying existing practice >> ... which existing practice are you referring to? > > As I wrote in draft #0: 'For example: SXIP, LID, OpenID, and Passel.' and you left out SAML, Liberty, and WS-Federation, at least. >> As far as I know, the only technology that makes some of the >> technologies you listed interoperate so far (and only partially, >> because SXIP is not involved) is YADIS... I have the proof right here >> on my machine that it works beautifully between LID and OpenID >> implementations of at least four different vendors already ... so I'm >> a little unclear what exactly are you proposing? > > I don't think that we need a protocol to interoperate with other protocols. > > I think we need one protocol. You're dreaming. Those horses are out of the barn and off in the next state. Thus, seems to me that the YADIS work (http://yadis.org/) is more relevant and interesting than this here attempt to get an IETF rubber-stamp for sxip. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 19:44:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YlU-0005Xu-Oj; Tue, 24 Jan 2006 19:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YlT-0005Xh-An for dix@megatron.ietf.org; Tue, 24 Jan 2006 19:43:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21543 for ; Tue, 24 Jan 2006 19:42:28 -0500 (EST) Message-Id: <200601250042.TAA21543@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Yv6-0000U4-Jq for dix@ietf.org; Tue, 24 Jan 2006 19:53:57 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc14) with SMTP id <20060125004347m1400nd97me>; Wed, 25 Jan 2006 00:43:47 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] To add to the charter Date: Tue, 24 Jan 2006 16:43:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <43D6BEE6.7000803@neustar.biz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYhQgFMjodKDyxCRkugaOpmorgeSgAA0+oQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > Thus, seems to me that the YADIS work (http://yadis.org/) is more relevant > and interesting than this here attempt to get an IETF rubber-stamp for > sxip. Although John has put out a SXIP-like DIX draft, there is no reason for anyone to accept it at face-value. At this point the only thing of value is the purpose and reasoning set forward in the charter document. >> I don't think that we need a protocol to interoperate with other >> protocols. I think we need one protocol. > > You're dreaming. Those horses are out of the barn and off in the next > state. IMO, the horses are a bunch of disconnected islands spread across the internet. It sure would be nice to have a single system that wasn't controlled by one company to connect the islands. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Jeff Hodges Sent: Tuesday, January 24, 2006 3:57 PM To: Digital Identity Exchange Subject: Re: [dix] To add to the charter John Merrells wrote: > > On 20-Jan-06, at 10:08 PM, Johannes Ernst wrote: > >> - but you also say that we should just be codifying existing practice >> ... which existing practice are you referring to? > > As I wrote in draft #0: 'For example: SXIP, LID, OpenID, and Passel.' and you left out SAML, Liberty, and WS-Federation, at least. >> As far as I know, the only technology that makes some of the >> technologies you listed interoperate so far (and only partially, >> because SXIP is not involved) is YADIS... I have the proof right here >> on my machine that it works beautifully between LID and OpenID >> implementations of at least four different vendors already ... so I'm >> a little unclear what exactly are you proposing? > > I don't think that we need a protocol to interoperate with other protocols. > > I think we need one protocol. You're dreaming. Those horses are out of the barn and off in the next state. Thus, seems to me that the YADIS work (http://yadis.org/) is more relevant and interesting than this here attempt to get an IETF rubber-stamp for sxip. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 20:00:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Z15-0005tq-Go; Tue, 24 Jan 2006 20:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Z13-0005tD-5c for dix@megatron.ietf.org; Tue, 24 Jan 2006 20:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23086 for ; Tue, 24 Jan 2006 19:58:34 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ZAd-0001CO-Hu for dix@ietf.org; Tue, 24 Jan 2006 20:10:04 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k0P0xorK071534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2006 00:59:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.0.16.0.20060124164934.037bf0f0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 24 Jan 2006 16:59:27 -0800 To: Digital Identity Exchange From: "Kurt D. Zeilenga" Subject: RE: [dix] To add to the charter Cc: "'Digital Identity Exchange'" In-Reply-To: <200601250042.TAA21543@ietf.org> References: <43D6BEE6.7000803@neustar.biz> <200601250042.TAA21543@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org At 04:43 PM 1/24/2006, Suresh Venkatraman wrote: >At this point the only thing of value is >the purpose and reasoning set forward in the charter document. I would like to see the charter specifically refer to a set of individual submissions as serving as the "basis" for the working group's deliverables (one existing I-D per deliverable document). This not only shows we have enough folks to produce our deliverables, but (at least rough) consensus going in. Without a consensus-supported basis, the WG will wander endlessly in the the fields of requirement documents. Kurt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 20:18:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ZD0-0008NT-6K; Tue, 24 Jan 2006 20:12:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ZCx-0008Lv-R9 for dix@megatron.ietf.org; Tue, 24 Jan 2006 20:12:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23752 for ; Tue, 24 Jan 2006 20:10:52 -0500 (EST) Message-Id: <200601250110.UAA23752@ietf.org> Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ZMb-0001YO-Gw for dix@ietf.org; Tue, 24 Jan 2006 20:22:22 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (rwcrmhc14) with SMTP id <20060125011211m1400nd2h4e>; Wed, 25 Jan 2006 01:12:12 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: [dix] To add to the charter Date: Tue, 24 Jan 2006 17:11:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7.0.0.16.0.20060124164934.037bf0f0@OpenLDAP.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYhSzo918TLCvVJTKSnMN4VLkTTfgAAI1NA X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > Without a consensus-supported basis, the WG will wander endlessly in the > fields of requirement documents. I agree and I should have said "proposed" charter document; as that is what needs to be scrutinized and refined before tackling other issues. -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Kurt D. Zeilenga Sent: Tuesday, January 24, 2006 4:59 PM To: Digital Identity Exchange Cc: 'Digital Identity Exchange' Subject: RE: [dix] To add to the charter At 04:43 PM 1/24/2006, Suresh Venkatraman wrote: >At this point the only thing of value is >the purpose and reasoning set forward in the charter document. I would like to see the charter specifically refer to a set of individual submissions as serving as the "basis" for the working group's deliverables (one existing I-D per deliverable document). This not only shows we have enough folks to produce our deliverables, but (at least rough) consensus going in. Without a consensus-supported basis, the WG will wander endlessly in the the fields of requirement documents. Kurt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 21:53:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1an1-0000Bx-HD; Tue, 24 Jan 2006 21:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1an0-0000Bs-5R for dix@megatron.ietf.org; Tue, 24 Jan 2006 21:53:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00092 for ; Tue, 24 Jan 2006 21:52:10 -0500 (EST) Received: from exprod6og1.obsmtp.com ([64.18.1.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1awe-0004o7-Er for dix@ietf.org; Tue, 24 Jan 2006 22:03:42 -0500 Received: from source ([192.150.20.142]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 24 Jan 2006 18:53:26 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0P2rOFX022915 for ; Tue, 24 Jan 2006 18:53:25 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k0P2rOrs004747 for ; Tue, 24 Jan 2006 18:53:24 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 18:53:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] To add to the charter Date: Tue, 24 Jan 2006 18:53:23 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E452808F@namail3.corp.adobe.com> In-Reply-To: <200601250042.TAA21543@ietf.org> Thread-Topic: [dix] To add to the charter Thread-Index: AcYhQgFMjodKDyxCRkugaOpmorgeSgAA0+oQAATPZ1A= From: "Duane Nickull" To: "Digital Identity Exchange" X-OriginalArrivalTime: 25 Jan 2006 02:53:23.0555 (UTC) FILETIME=[81D3C330:01C6215A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org "IMO, the horses are a bunch of disconnected islands spread across the internet. It sure would be nice to have a single system that wasn't controlled by one company to connect the islands." Hmm - if I am not mistaken (or drunk) what you allude to is called a "standard", presumably the raison d'etre. Nevertheless, standards, whether ipso facto, de facto or du jure are all standards. A single company who writes a standard has no more freedom to manipulate that standard that the du jure standards from ISO, IEEE et al, given they have to always act in the best interests of the users of the standard.=20 Summary: let's accept submissions for their value, regardless of where they arise from. =20 Pragmatically yours.... Duane Nickull Senior Technical Evangelist, Adobe Systems, Inc. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jan 24 22:06:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1azC-0006JS-RT; Tue, 24 Jan 2006 22:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1az9-0006JF-I8 for dix@megatron.ietf.org; Tue, 24 Jan 2006 22:06:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01123 for ; Tue, 24 Jan 2006 22:04:44 -0500 (EST) Received: from exprod6og12.obsmtp.com ([64.18.1.24]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1b8n-0005GD-Vs for dix@ietf.org; Tue, 24 Jan 2006 22:16:15 -0500 Received: from source ([192.150.11.134]) by exprod6ob12.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 24 Jan 2006 19:06:12 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k0P35kYc001354 for ; Tue, 24 Jan 2006 19:05:46 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k0P368ru005443 for ; Tue, 24 Jan 2006 19:06:10 -0800 (PST) Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 19:06:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] To add to the charter Date: Tue, 24 Jan 2006 19:06:05 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E4528091@namail3.corp.adobe.com> In-Reply-To: <7.0.0.16.0.20060124164934.037bf0f0@OpenLDAP.org> Thread-Topic: [dix] To add to the charter Thread-Index: AcYhSuhPT8nY4VKBSnSDkyU5qaA3ugAEPL/w From: "Duane Nickull" To: "Digital Identity Exchange" X-OriginalArrivalTime: 25 Jan 2006 03:06:08.0889 (UTC) FILETIME=[4A007690:01C6215C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org If I may be as bold as to make a suggestion. This (demand for) process exists within standards bodies. OASIS and UN/CEFACT both have strict processes; I am not familiar with IETF stnandards development processes however. Are such things existent?=20 If not, perhaps we should make an open call for submissions for a predetermined temporal segment, then distill the points of common interest into a formal charter. I am a big fan of consensus rather than majority will, given it tends to build more well though out standards. Duane ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ *******************************=20 -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Kurt D. Zeilenga Sent: Tuesday, January 24, 2006 4:59 PM To: Digital Identity Exchange Cc: 'Digital Identity Exchange' Subject: RE: [dix] To add to the charter At 04:43 PM 1/24/2006, Suresh Venkatraman wrote: >At this point the only thing of value is >the purpose and reasoning set forward in the charter document. I would like to see the charter specifically refer to a set of individual submissions as serving as the "basis" for the working group's deliverables (one existing I-D per deliverable document). This not only shows we have enough folks to produce our deliverables, but (at least rough) consensus going in. Without a consensus-supported basis, the WG will wander endlessly in the the fields of requirement documents. Kurt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 25 02:59:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fZ8-0003pi-5W; Wed, 25 Jan 2006 02:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fZ6-0003pd-NM for dix@megatron.ietf.org; Wed, 25 Jan 2006 02:59:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18667 for ; Wed, 25 Jan 2006 02:58:09 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1fim-00060H-Kh for dix@ietf.org; Wed, 25 Jan 2006 03:09:43 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Wed, 25 Jan 2006 00:59:27 -0700 Message-Id: <43D6CD5C.D091.001C.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Wed, 25 Jan 2006 00:59:08 -0700 From: "Jim Sermersheim" To: "Digital Identity Exchange" Subject: Re: [dix] draft of proposed charter (#3) References: <2F5B1B00-8163-4D3F-83C7-800F6213689A@sxip.com> In-Reply-To: <2F5B1B00-8163-4D3F-83C7-800F6213689A@sxip.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org John, =20 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 statements, but didn't want to step on your toes too much ;). =20 Take or leave all or parts at will. =20 Jim =20 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 authenticatio= n 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.=20 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. 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 authoritat= ive 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. While any solution should allow DIX messages to be carried over multiple = alternative transports, including, but not limited to: HTTP, XMPP,=20 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.=20 Support for both compartmentalized and anonymous identities. 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. = - The schema and type system for identity information. Internet Drafts The Working Group anticipates the authoring of at least three Internet-Draf= ts. Two of these are expected to become Standards Track documents. 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 dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 25 03:13:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fmj-0000x3-Jy; Wed, 25 Jan 2006 03:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fmi-0000wy-KP for dix@megatron.ietf.org; Wed, 25 Jan 2006 03:13:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19532 for ; Wed, 25 Jan 2006 03:12:13 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1fwP-0006SO-NV for dix@ietf.org; Wed, 25 Jan 2006 03:23:47 -0500 Received: from [192.168.1.105] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0P8DWCu070743 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 25 Jan 2006 00:13:32 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43D60007.0A7A.00E4.0@novell.com> References: <43D13790.9050001@thinkingcat.com> <43D60007.0A7A.00E4.0@novell.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] draft proposed charter - consensus? Date: Wed, 25 Jan 2006 00:13:31 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 24-Jan-06, at 9:23 AM, Tom Doman wrote: > Yes, Leslie, taking your thought further, it makes me wonder, how > does the DIX protocol end up being much different from SAML? Dick, > I know you like to discount SAML due to RSA licensing issues (which > is a very relevant point), but I'd like to have you weigh in on the > other material differences you might anticipate in the DIX protocol > itself. In other words, where else do you think SAML is lacking or > perhaps inappropriate for digital identity information exchange? > Hey Tom I think the SAML authors did a great job of standardizing a language to represent assertions to be moved between systems, and was driven by vendors wanting to enable interop with between their enterprise solutions. I think it is/was difficult from that point of reference to think of how to move digital identity around at Internet scale, or to scale down the required technological footprint for low risk, low value identity transactions. Processing digitally signed XML is much harder then fetching an HTML page and working with name/pairs. SAML is pretty heavy to move my name, email address and blog URL. It also does not integrate well into existing applications. The ID submitted allows an existing form to use DIX with the addition of HTML, and no change to the existing form processing code (assuming the required fields are available) Given the growing number of solutions that produce and consume SAML , it would be *good* for DIX to be able to move around SAML tokens, just as Microsoft states they will do with their meta-system / Infocard. Summary: The token part of the SAML specs map to a type of thing that can be moved around DIX, the protocol part is missing chunks and is not light enough. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 25 13:45:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1peM-0005Xi-Ub; Wed, 25 Jan 2006 13:45:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1peL-0005XM-MN for dix@megatron.ietf.org; Wed, 25 Jan 2006 13:45:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12096 for ; Wed, 25 Jan 2006 13:44:14 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1po8-00050R-Bm for dix@ietf.org; Wed, 25 Jan 2006 13:55:53 -0500 Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k0PIjPr7030519 for ; Wed, 25 Jan 2006 18:45:29 GMT Message-ID: <43D7C73A.4000604@neustar.biz> Date: Wed, 25 Jan 2006 10:45:14 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: of identifiers and identity service discovery (was: Re: [dix] To add to the charter) References: <200601250042.TAA21543@ietf.org> In-Reply-To: <200601250042.TAA21543@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org >> John Merrells had mused: >>> I don't think that we need a protocol to interoperate with other >>> protocols. I think we need one protocol. > Jeff Hodges replied: >> You're dreaming. Those horses are out of the barn and off in the next >> state. Suresh Venkatraman opined: > IMO, the horses are a bunch of disconnected islands spread across the > internet. It sure would be nice to have a single system that wasn't > controlled by one company to connect the islands. So, yes, my point is that for whatever reason there is an extant plethora of identity-asserting protocols, and they aren't simply going to dry up and blow away because this working group is formed, and perhaps re-invents another wheel. I think where some value could be added is pretty much what you're alluding to above which is specifying a standard means by which one can determine which flavor of identity-asserting system a given identifier is recognized by. yadis.org is one such effort, fwiw. And as PHB noted earlier on this list, another high-level aspect of this overall identity puzzle is one of identifiers themselves. And even with identifiers themselves, there is a fair bit of extant non-trivial emerging deployed work, which isn't necessarily going to disappear right away. Eg XRIs [1][2]. So I tend to think that up-leveling the discussion to be one focusing on a meta-layer framework for identifier resolution and identity service discovery (aka identity provider discovery) is where the value for an IETF-based effort lies. JeffH [1] OASIS Extensible Resource Identifier (XRI) TC http://www.oasis-open.org/committees/xri/ [2] OpenXRI http://www.openxri.org/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 25 14:03:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1pvc-0004Sf-Dv; Wed, 25 Jan 2006 14:03:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1pvb-0004SX-KO for dix@megatron.ietf.org; Wed, 25 Jan 2006 14:03:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13816 for ; Wed, 25 Jan 2006 14:02:04 -0500 (EST) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1q5P-0005lO-LM for dix@ietf.org; Wed, 25 Jan 2006 14:13:44 -0500 Received: from user-10ib3g5.biz.mindspring.com ([65.37.142.5] helo=belka.radicalmode.com) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F1pva-00054q-00 for dix@ietf.org; Wed, 25 Jan 2006 14:03:34 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1F1pvZ-0006Qq-5t for dix@ietf.org; Wed, 25 Jan 2006 11:03:33 -0800 From: Nick Ragouzis Sent: Wednesday, January 25, 2006 11:02 AM To: dix@ietf.org Subject: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter - consensus?) Message-Id: Date: Wed, 25 Jan 2006 11:03:33 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Dick Hardt @ Wed, 25 Jan 2006 00:13:31 -0800 wrote: > On 24-Jan-06, at 9:23 AM, Tom Doman wrote: > > > Yes, Leslie, taking your thought further, it makes me wonder, how > > does the DIX protocol end up being much different from SAML? Dick, ... > > but I'd like to have you weigh in ... > > where ... > > SAML is lacking or perhaps inappropriate for digital identity > > information exchange? > > NR: I think this is an important question to answer with specifics, as best as one can in the moment, before we dedicate a lot of energy and resources -- if we're going for an improvement in some dimension(s), then it serves us to be clear about it. > > Hey Tom > > I think the SAML authors did a great job of standardizing a language > to represent assertions to be moved between systems, and was driven > by vendors wanting to enable interop with between their enterprise > solutions. NR: Um, was driven ^in part^ by such vendors. In this forum, in the inclusive fashion marking this and other SDO, let's be straight about this, or be silent. Self-interest has many guises. [ > I think it is/was difficult from that point of reference > to think of how to move digital identity around at Internet > scale, or to scale down the required technological footprint for ] ... > low risk, low value identity transactions. NR: Seems a reasonable use case. But not one exclusive of SAML, right? Possibly also the case, in the least, that relying parties might be served by being able to easily distinguish among, and even have granular mechanisms for selecting the 'level' of, the footprint (and security). Which suggests certain mechanisms as valued in each of the protocols -- but which might not be strictly necessary in any of them alone. > Processing digitally signed XML is much harder then fetching > an HTML page and working with name/pairs. NR: This is a non-sequitor to your claim, below. If it's possible in some future for DIX to handle the 'SAML token', well then you're suggesting inclusion of precisely this sort of thing within DIX (the processing digital sigs). And, OTOH, within the SAML (i.e., v2.0) WebSSO, the "fetching" (assuming from this para and by the below you mean the transport part) can be precisely just dealing in straightforward REST. [ > SAML is pretty heavy to move my name, email address and blog URL. > It also does not integrate well into existing applications. The ID > submitted allows an existing form to use DIX with the addition of HTML, ] ... > and no change to the existing form processing code (assuming the > required fields are available) NR: Well, not quite. The minimal change is the required change: to make the application aware of identity attestations of a trusted third party. So far I'm not convinced by your characterization, Dick. Let's take a "what if". Let's create a SAMLv2.0 "SAML-LowLow" profile, a sort of reduction to SAMLv2.0 WebSSO HTTPPost, that removes any signature requirement (even tho that's token, not necssrly transport), and assumes some of the party/counterparty status that's assumed in the ID (leaving any transport-related digest or dsig to the same discussion needed in dix). Here's a rough of the "heaviness" of such a speculative profile (of which obvious parts can appear in htmlforms, and for which I've ignored the trivial serialization into url form): Request (by relying party): @ID of the request @Version of the protocol @IssueInstant of the request Issuer UID Subject identifier related to the request Response (by authority): @ID of the resp @Version of the protocol @IssueInstant @InResponseTo the RequestID Status for request Assertion (unsigned in this SAML-LowLow profile): @ID of the assertion @Version of the protocol @IssueInstant Issuer UID Subject's ID Authentication Statement @AuthnInstant AuthnContext NR: Right off this is indeed heavier. But what's the *objective* bar? Some of the extras are probably unnecessary for the "low risk, low value" use case, sure. Unfortunately, or not, using SAMLv2 you can't really shed yourself of those attributes on the base request and response elements. But these particular 'extras' are trivial capabilities inherent in any forms generation and processing engine, right? Beyond that this "SAML-LowLow" profile could even be lighter, if that’s what's required. Such as removing the Authentication statement ... although I'm at a loss for why that would save significant resources when doing so would remove some valuable *optional* capabilities for the requester. Of course a further simplified version of this could be had by profiling the Liberty ID-FF1.2 standard. And, more, this doesn't handle capability discovery. But that's not DIX's raison d'etre as of yet, right? ... > > Summary: The token part of the SAML specs map to a type of > thing that can be moved around DIX, the protocol part is missing > chunks NR: I didn't deal with this, but it would be good to be more specific here. > and is not light enough. > > -- Dick > --Nick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 25 14:42:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qXD-0004dx-Uz; Wed, 25 Jan 2006 14:42:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qXD-0004dQ-D8 for dix@megatron.ietf.org; Wed, 25 Jan 2006 14:42:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17653 for ; Wed, 25 Jan 2006 14:40:56 -0500 (EST) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1qh1-0007OT-0K for dix@ietf.org; Wed, 25 Jan 2006 14:52:36 -0500 Received: from user-10ib3g5.biz.mindspring.com ([65.37.142.5] helo=belka.radicalmode.com) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F1qXA-0005VF-00 for dix@ietf.org; Wed, 25 Jan 2006 14:42:25 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1F1qX9-0006TJ-Ua for dix@ietf.org; Wed, 25 Jan 2006 11:42:23 -0800 From: Nick Ragouzis Sent: Wednesday, January 25, 2006 11:42 AM To: dix@ietf.org Subject: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter - consensus?) Message-Id: Date: Wed, 25 Jan 2006 11:42:23 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org A quick note on that SAML-LowLow profile. Of course it is for purposes of example only, tho' I've tried to make it as true to something that could (maybe during an epidemic of bird flu on the SSTC) be realized. It's really an exercise using assumptions parallel to the ID ... which may turn out to be insufficient in-and-of themselves. The simplifications of the WebSSO HTTPPost are: * The types of nameids (in all cases) is assumed to be fixed * SubjectConfirmation is omitted (so sender-vouches as far as SAML, but for the ID's cases the effect is more bearer, plus no timelimits, etc) * Conditions is omitted (so audience assumed) * Other services and features are ignored: Endpoints and checking of counter- party by authority and relying party are assumed at, essentially, none. Assumes no SLO support for session, no Metadata support, etc. I think that's it. --Nick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jan 25 19:00:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1uYe-000562-Sf; Wed, 25 Jan 2006 19:00:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1uYc-000556-Uy for dix@megatron.ietf.org; Wed, 25 Jan 2006 19:00:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07175 for ; Wed, 25 Jan 2006 18:58:39 -0500 (EST) Message-Id: <200601252358.SAA07175@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1uiO-0007iV-Tu for dix@ietf.org; Wed, 25 Jan 2006 19:10:19 -0500 Received: from sureshmobile (unknown[70.58.75.233]) by comcast.net (sccrmhc14) with SMTP id <2006012523595301400dq2dhe>; Wed, 25 Jan 2006 23:59:53 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: of identifiers and identity service discovery (was: Re: [dix] Toadd to the charter) Date: Wed, 25 Jan 2006 15:59:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYh3/1v/us5mG8oSnu7HdRJooK8kgAJ/nVQ In-Reply-To: <43D7C73A.4000604@neustar.biz> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > So, yes, my point is that for whatever reason there is an extant plethora > of identity-asserting protocols, and they aren't simply going to dry up > and blow away because this working group is formed, and perhaps re-invents > another wheel. In order for DIX to be approved by the IESG we need to choose one of the identity-asserting protocols. That could mean a subset of an existing standard (SAMLv2) or creating one that can provide an "interoperable implementation". Emerging or alternative protocols could be added in later. > And as PHB noted earlier on this list, another high-level aspect of this > overall identity puzzle is one of identifiers themselves. > > And even with identifiers themselves, there is a fair bit of extant non > trivial emerging deployed work, which isn't necessarily going to disappear > right away. Eg XRIs [1][2]. IMO, leveraging existing identifiers (URI's, URL's, Mail Addresses) and discovery mechanisms (DNS) are more interesting than trying to reinvent the wheel. It's much easier to codify DIX with well known and widely-used identifiers. OTOH I would want DIX to keep the core spec open for emerging or alternative identifiers (e.g. XRI's). > So I tend to think that up-leveling the discussion to be one focusing on a > meta-layer framework for identifier resolution and identity service > discovery (aka identity provider discovery) is where the value for an > IETF-based effort lies. To quote Scott Hollenbeck: "A charter that does not describe at least one method to produce interoperable implementations will not be approved by the IESG." -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Jeff Hodges Sent: Wednesday, January 25, 2006 10:45 AM To: Digital Identity Exchange Subject: of identifiers and identity service discovery (was: Re: [dix] Toadd to the charter) >> John Merrells had mused: >>> I don't think that we need a protocol to interoperate with other >>> protocols. I think we need one protocol. > Jeff Hodges replied: >> You're dreaming. Those horses are out of the barn and off in the next >> state. Suresh Venkatraman opined: > IMO, the horses are a bunch of disconnected islands spread across the > internet. It sure would be nice to have a single system that wasn't > controlled by one company to connect the islands. So, yes, my point is that for whatever reason there is an extant plethora of identity-asserting protocols, and they aren't simply going to dry up and blow away because this working group is formed, and perhaps re-invents another wheel. I think where some value could be added is pretty much what you're alluding to above which is specifying a standard means by which one can determine which flavor of identity-asserting system a given identifier is recognized by. yadis.org is one such effort, fwiw. And as PHB noted earlier on this list, another high-level aspect of this overall identity puzzle is one of identifiers themselves. And even with identifiers themselves, there is a fair bit of extant non-trivial emerging deployed work, which isn't necessarily going to disappear right away. Eg XRIs [1][2]. So I tend to think that up-leveling the discussion to be one focusing on a meta-layer framework for identifier resolution and identity service discovery (aka identity provider discovery) is where the value for an IETF-based effort lies. JeffH [1] OASIS Extensible Resource Identifier (XRI) TC http://www.oasis-open.org/committees/xri/ [2] OpenXRI http://www.openxri.org/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 00:26:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zdx-0004IV-Qs; Thu, 26 Jan 2006 00:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zdw-0004Hp-Am for dix@megatron.ietf.org; Thu, 26 Jan 2006 00:26:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11470 for ; Thu, 26 Jan 2006 00:24:27 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1znp-0005cT-6S for dix@ietf.org; Thu, 26 Jan 2006 00:36:13 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0Q5PvZt026440 for ; Wed, 25 Jan 2006 21:25:58 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 21:25:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) Date: Wed, 25 Jan 2006 21:25:57 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD378CE022@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) Thread-Index: AcYh3/1v/us5mG8oSnu7HdRJooK8kgAJ/nVQAAvfrjA= From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 26 Jan 2006 05:25:57.0616 (UTC) FILETIME=[FC7C5F00:01C62238] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org I think that there are two separate types of identity information that need to be considered here: 1) Self asserted information (nickname, photo, email etc.) 2) Third party assertions (reputation, spamminess, star alliance gold etc.) The first type of information is not difficult to manage, the relying party understands that the data is self asserted. Attribute value pairs in any standard format work as well as anything. The second type of information requires the reputation of the information provider to be considered by the relying party.=20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Suresh Venkatraman > Sent: Wednesday, January 25, 2006 3:59 PM > To: 'Digital Identity Exchange' > Subject: RE: of identifiers and identity service discovery=20 > (was: Re: [dix]Toadd to the charter) >=20 > > So, yes, my point is that for whatever reason there is an extant=20 > > plethora of identity-asserting protocols, and they aren't=20 > simply going=20 > > to dry up and blow away because this working group is formed, and=20 > > perhaps re-invents another wheel. >=20 > In order for DIX to be approved by the IESG we need to choose=20 > one of the identity-asserting protocols. That could mean a=20 > subset of an existing standard (SAMLv2) or creating one that=20 > can provide an "interoperable implementation". Emerging or=20 > alternative protocols could be added in later. >=20 > > And as PHB noted earlier on this list, another high-level aspect of=20 > > this overall identity puzzle is one of identifiers themselves. > > > > And even with identifiers themselves, there is a fair bit of extant=20 > > non trivial emerging deployed work, which isn't necessarily=20 > going to=20 > > disappear right away. Eg XRIs [1][2]. >=20 > IMO, leveraging existing identifiers (URI's, URL's, Mail=20 > Addresses) and discovery mechanisms (DNS) are more=20 > interesting than trying to reinvent the wheel. It's much=20 > easier to codify DIX with well known and widely-used=20 > identifiers. OTOH I would want DIX to keep the core spec open=20 > for emerging or alternative identifiers (e.g. XRI's). >=20 > > So I tend to think that up-leveling the discussion to be=20 > one focusing=20 > > on a >=20 > > meta-layer framework for identifier resolution and identity service=20 > > discovery (aka identity provider discovery) is where the=20 > value for an=20 > > IETF-based effort lies. >=20 > To quote Scott Hollenbeck: "A charter that does not describe=20 > at least one method to produce interoperable implementations=20 > will not be approved by the IESG." >=20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Jeff Hodges > Sent: Wednesday, January 25, 2006 10:45 AM > To: Digital Identity Exchange > Subject: of identifiers and identity service discovery (was:=20 > Re: [dix] Toadd to the charter) >=20 >=20 > >> John Merrells had mused: > >>> I don't think that we need a protocol to interoperate=20 > with other >>> protocols. I think we need one protocol. >=20 > > Jeff Hodges replied: > >> You're dreaming. Those horses are out of the barn and off=20 > in the next >> state. >=20 > Suresh Venkatraman opined: > > IMO, the horses are a bunch of disconnected islands spread=20 > across the > internet. It sure would be nice to have a=20 > single system that wasn't > controlled by one company to=20 > connect the islands. >=20 > So, yes, my point is that for whatever reason there is an=20 > extant plethora of >=20 > identity-asserting protocols, and they aren't simply going to=20 > dry up and blow away because this working group is formed,=20 > and perhaps re-invents another wheel. >=20 > I think where some value could be added is pretty much what=20 > you're alluding to above which is specifying a standard means=20 > by which one can determine which flavor of identity-asserting=20 > system a given identifier is recognized by. >=20 > yadis.org is one such effort, fwiw. >=20 > And as PHB noted earlier on this list, another high-level=20 > aspect of this overall identity puzzle is one of identifiers=20 > themselves. >=20 > And even with identifiers themselves, there is a fair bit of=20 > extant non-trivial emerging deployed work, which isn't=20 > necessarily going to disappear right away.=20 > Eg XRIs [1][2]. >=20 > So I tend to think that up-leveling the discussion to be one=20 > focusing on a meta-layer framework for identifier resolution=20 > and identity service discovery (aka identity provider=20 > discovery) is where the value for an IETF-based effort lies. >=20 > JeffH >=20 > [1] OASIS Extensible Resource Identifier (XRI) TC=20 > http://www.oasis-open.org/committees/xri/ >=20 > [2] OpenXRI > http://www.openxri.org/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 00:30:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zhu-00064e-3o; Thu, 26 Jan 2006 00:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zhs-00064Y-Qo for dix@megatron.ietf.org; Thu, 26 Jan 2006 00:30:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11771 for ; Thu, 26 Jan 2006 00:28:31 -0500 (EST) Received: from whois.csas.com ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1zrl-0005ki-EV for dix@ietf.org; Thu, 26 Jan 2006 00:40:18 -0500 Received: from mail.reptiles.org([198.96.119.1] port=3415) (2313 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Thu, 26 Jan 2006 00:29:54 -0500 (EST) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Thu, 26 Jan 2006 00:29:53 -0500 (EST) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: Digital Identity Exchange Subject: RE: of identifiers and identity service discovery (was: Re: [dix] Toadd to the charter) In-Reply-To: <200601252358.SAA07175@ietf.org> Message-ID: <20060126002647.U5950@skink.reptiles.org> References: <200601252358.SAA07175@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On Wed, 25 Jan 2006, Suresh Venkatraman wrote: >> So, yes, my point is that for whatever reason there is an extant plethora >> of identity-asserting protocols, and they aren't simply going to dry up >> and blow away because this working group is formed, and perhaps re-invents >> another wheel. > > In order for DIX to be approved by the IESG we need to choose one of the > identity-asserting protocols. That could mean a subset of an existing > standard (SAMLv2) or creating one that can provide an "interoperable > implementation". Emerging or alternative protocols could be added in later. Given the number of existing and lively identity-asserting protocols it seems more valuable to create a standard that provides for an interoperable implementation - it also seems the most likely way to avoid the endless internecine debate of which existing identity-asserting protocol should be considered 'best', and allow this group to move forward. > IMO, leveraging existing identifiers (URI's, URL's, Mail Addresses) and > discovery mechanisms (DNS) are more interesting than trying to reinvent the > wheel. It's much easier to codify DIX with well known and widely-used > identifiers. OTOH I would want DIX to keep the core spec open for emerging > or alternative identifiers (e.g. XRI's). agreed. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 01:53:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F210v-0005Ef-PS; Thu, 26 Jan 2006 01:53:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F210u-0005Ea-4e for dix@megatron.ietf.org; Thu, 26 Jan 2006 01:53:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16706 for ; Thu, 26 Jan 2006 01:52:16 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F21Ag-00080D-OM for dix@ietf.org; Thu, 26 Jan 2006 02:03:56 -0500 Received: from [192.168.1.105] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0Q6rV8M012260 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 25 Jan 2006 22:53:32 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD378CE022@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD378CE022@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) Date: Wed, 25 Jan 2006 22:53:30 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip wrote: > I think that there are two separate types of identity information that > need to be considered here: > > 1) Self asserted information (nickname, photo, email etc.) > 2) Third party assertions (reputation, spamminess, star alliance gold > etc.) > > The first type of information is not difficult to manage, the relying > party understands that the data is self asserted. Attribute value > pairs > in any standard format work as well as anything. > > The second type of information requires the reputation of the > information provider to be considered by the relying party. I generally agree Phillip. In the identity gang discussions we have called these claims instead of identity information. Identity having a vague meaning. I see (2) requiring not only a trust relationship with the asserting party by the relying party (something that is social, not technical), but also a mechanism for the relying party to know it is a valid assertion, which requires some verification mechanism such as PKI. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 07:35:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26M0-0006zM-8z; Thu, 26 Jan 2006 07:35:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F26Ly-0006yG-Kp for dix@megatron.ietf.org; Thu, 26 Jan 2006 07:35:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09660 for ; Thu, 26 Jan 2006 07:34:22 -0500 (EST) Received: from web88110.mail.re2.yahoo.com ([206.190.37.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F26Vs-0001lQ-Ir for dix@ietf.org; Thu, 26 Jan 2006 07:46:11 -0500 Received: (qmail 52498 invoked by uid 60001); 26 Jan 2006 12:35:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W79zSLDoTLpxhjiFoGwch6nClyq0gOlpDoIPBLErinV33MsXZqEHHBoGa/BdbRIzeSAS1HrnqwtuNrpbJBdga9Kvuc8Swwc+TeKj6TCsZRqScQfsFaW4URndLP8as6r1+c7SNcK03kgin7jVXmYtIZttUmABmtpTXSk/RDM01k0= ; Message-ID: <20060126123540.52496.qmail@web88110.mail.re2.yahoo.com> Received: from [72.1.215.180] by web88110.mail.re2.yahoo.com via HTTP; Thu, 26 Jan 2006 07:35:40 EST Date: Thu, 26 Jan 2006 07:35:40 -0500 (EST) From: James Benedict Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) To: Digital Identity Exchange In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 8bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --- Dick Hardt wrote: > > On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip > wrote: > > > I think that there are two separate types of > identity information that > > need to be considered here: > > > > 1) Self asserted information (nickname, photo, > email etc.) > > 2) Third party assertions (reputation, spamminess, > star alliance gold > > etc.) > > > > The first type of information is not difficult to > manage, the relying > > party understands that the data is self asserted. > Attribute value > > pairs > > in any standard format work as well as anything. > > > > The second type of information requires the > reputation of the > > information provider to be considered by the > relying party. > > I generally agree Phillip. > I gotta disagree to a certain extent with this one. I don't consider these two separate types of Identity Information, I consider it an arbitrary decision about the "required" reliability of certain attributes. For example: A photo, for the purposes of a web-forum avatar doesn't have to be very reliable ... in most cases, it isn't even expected to be really representative. On the other hand: a passport photo, drivers license or even a company access id photo needs to be verified by a trusted 3rd party. > In the identity gang discussions we have called > these claims instead > of identity information. Identity having a vague > meaning. > All the more reason to agree to common terminology, so we all know what the heck each other are talking about :) > I see (2) requiring not only a trust relationship > with the asserting > party by the relying party (something that is > social, not technical), > but also a mechanism for the relying party to know > it is a valid > assertion, which requires some verification > mechanism such as PKI. > Agreed. I just don't believe that we should treat the (1) and (2) as separate types of attributes. Maybe the should be represented as a triple {attribute,value(s),verification(s)} where "verifications" (or whatever, someone give it a name) is a codification of the mechanism Dick was alluding to above. > -- Dick > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 08:49:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Uv-0008Vm-Ah; Thu, 26 Jan 2006 08:49:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27Ut-0008Um-3U for dix@megatron.ietf.org; Thu, 26 Jan 2006 08:49:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15850 for ; Thu, 26 Jan 2006 08:47:39 -0500 (EST) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F27ep-0004ao-Sj for dix@ietf.org; Thu, 26 Jan 2006 08:59:29 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 48A1E33D81 for ; Thu, 26 Jan 2006 13:48:58 +0000 (GMT) Message-ID: <43D8D351.9060004@algroup.co.uk> Date: Thu, 26 Jan 2006 13:49:05 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft of proposed charter (#2) References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org Lisa Dusseault wrote: >> We could state: >> >> "To ensure interoperability between implementations we mandate >> that the user's client and their agent must support at least DIX >> over HTTP." > > Yes, but even more important for the identity server to have > required-to-implement transports. Errr. The identity server in your diagram is the agent in the proposed charter, surely? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 11:20:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F29rL-0007w3-1Z; Thu, 26 Jan 2006 11:20:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F29rJ-0007vq-66 for dix@megatron.ietf.org; Thu, 26 Jan 2006 11:20:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01280 for ; Thu, 26 Jan 2006 11:18:55 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2A1G-0002ka-KT for dix@ietf.org; Thu, 26 Jan 2006 11:30:48 -0500 Received: from [192.168.1.105] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0QGKHNN027204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 26 Jan 2006 08:20:19 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060126123540.52496.qmail@web88110.mail.re2.yahoo.com> References: <20060126123540.52496.qmail@web88110.mail.re2.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) Date: Thu, 26 Jan 2006 08:20:18 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 26-Jan-06, at 4:35 AM, James Benedict wrote: > --- Dick Hardt wrote: > >> >> On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip >> wrote: >> >>> I think that there are two separate types of >> identity information that >>> need to be considered here: >>> >>> 1) Self asserted information (nickname, photo, >> email etc.) >>> 2) Third party assertions (reputation, spamminess, >> star alliance gold >>> etc.) >>> >>> The first type of information is not difficult to >> manage, the relying >>> party understands that the data is self asserted. >> Attribute value >>> pairs >>> in any standard format work as well as anything. >>> >>> The second type of information requires the >> reputation of the >>> information provider to be considered by the >> relying party. >> >> I generally agree Phillip. >> > > I gotta disagree to a certain extent with this one. I > don't consider these two separate types of Identity > Information, I consider it an arbitrary decision about > the "required" reliability of certain attributes. > > For example: A photo, for the purposes of a web-forum > avatar doesn't have to be very reliable ... in most > cases, it isn't even expected to be really > representative. On the other hand: a passport photo, > drivers license or even a company access id photo > needs to be verified by a trusted 3rd party. Hmmm. Not sure what you are disagreeing with. Yes, they are both photos. One is just the data, the other has been asserted to be associated with the user by a *trusted* third party. The assertion is what makes them different. > >> In the identity gang discussions we have called >> these claims instead >> of identity information. Identity having a vague >> meaning. >> > > All the more reason to agree to common terminology, so > we all know what the heck each other are talking about > :) Totally agree! > >> I see (2) requiring not only a trust relationship >> with the asserting >> party by the relying party (something that is >> social, not technical), >> but also a mechanism for the relying party to know >> it is a valid >> assertion, which requires some verification >> mechanism such as PKI. >> > > Agreed. I just don't believe that we should treat the > (1) and (2) as separate types of attributes. Maybe > the should be represented as a triple > {attribute,value(s),verification(s)} where > "verifications" (or whatever, someone give it a name) > is a codification of the mechanism Dick was alluding > to above. They are both attributes or properties or claims. (2) has a modifier that means it has been asserted. btw: I prefer not to use the term "attributes" since it has a specific meaning in XML, "the attribute attribute ..." gets confusing ... -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 11:35:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A5e-0007ij-RT; Thu, 26 Jan 2006 11:35:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A5d-0007hk-0i for dix@megatron.ietf.org; Thu, 26 Jan 2006 11:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02322 for ; Thu, 26 Jan 2006 11:33:43 -0500 (EST) Received: from web88101.mail.re2.yahoo.com ([206.190.37.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2AFb-0003G5-0O for dix@ietf.org; Thu, 26 Jan 2006 11:45:36 -0500 Received: (qmail 97561 invoked by uid 60001); 26 Jan 2006 16:35:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZKmJydvl7YOjl99exmtnBtG2K0ysMzYCHfSJrN0G3ZJj7Z1rnohZ/MEykyjdXs42Rw9spHXf+ns2N0wiwjJx5eIZvpoj1zmEdXWXUHt+qxJRkBebLnBoyd4DsGdFrgOJ8JM9zWib75xLjPKSCOWWp5eV3/ekGPYa72uVJvNnzc8= ; Message-ID: <20060126163505.97559.qmail@web88101.mail.re2.yahoo.com> Received: from [72.1.215.180] by web88101.mail.re2.yahoo.com via HTTP; Thu, 26 Jan 2006 11:35:05 EST Date: Thu, 26 Jan 2006 11:35:05 -0500 (EST) From: James Benedict Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) To: Digital Identity Exchange In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 8bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --- Dick Hardt wrote: > > On 26-Jan-06, at 4:35 AM, James Benedict wrote: > > > --- Dick Hardt wrote: > > > >> > >> On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip > >> wrote: > >> > >>> I think that there are two separate types of > >> identity information that > >>> need to be considered here: > >>> > >>> 1) Self asserted information (nickname, photo, > >> email etc.) > >>> 2) Third party assertions (reputation, > spamminess, > >> star alliance gold > >>> etc.) > >>> > >>> The first type of information is not difficult > to > >> manage, the relying > >>> party understands that the data is self > asserted. > >> Attribute value > >>> pairs > >>> in any standard format work as well as anything. > >>> > >>> The second type of information requires the > >> reputation of the > >>> information provider to be considered by the > >> relying party. > >> > >> I generally agree Phillip. > >> > > > > I gotta disagree to a certain extent with this > one. I > > don't consider these two separate types of > Identity > > Information, I consider it an arbitrary decision > about > > the "required" reliability of certain attributes. > > > > For example: A photo, for the purposes of a > web-forum > > avatar doesn't have to be very reliable ... in > most > > cases, it isn't even expected to be really > > representative. On the other hand: a passport > photo, > > drivers license or even a company access id photo > > needs to be verified by a trusted 3rd party. > > Hmmm. Not sure what you are disagreeing with. > > Yes, they are both photos. One is just the data, the > other has been > asserted to be associated with the user by a > *trusted* third party. > The assertion is what makes them different. > I agree with your explanation. That just isn't what I read in the first post. In your explanation I see two types of "information" 1) the data (photo, reputation, email, nickname, etc.) 2) the assertions on the data ("DMV-validated photo", "unvalidated nickname") The way I read the original post, it sounds like Phillip is describing two types of "data": 1) self-asserted 2) third-party asserted I'm all for saying that data can be self-asserted or third-party asserted... but I don't want to start categorizing the information based on what "can" be self-asserted vs. third-party. > > ... snip'd recursive aggreements ... > -- James _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 11:44:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AE4-0001Lf-3i; Thu, 26 Jan 2006 11:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2AE2-0001La-O2 for dix@megatron.ietf.org; Thu, 26 Jan 2006 11:43:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03110 for ; Thu, 26 Jan 2006 11:42:25 -0500 (EST) Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2AO0-0003YA-HO for dix@ietf.org; Thu, 26 Jan 2006 11:54:17 -0500 Received: from [192.168.1.105] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k0QGhkgZ027978 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 26 Jan 2006 08:43:46 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060126163505.97559.qmail@web88101.mail.re2.yahoo.com> References: <20060126163505.97559.qmail@web88101.mail.re2.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19959180-B2ED-44EE-9DF4-9AE52D53724D@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) Date: Thu, 26 Jan 2006 08:43:46 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 26-Jan-06, at 8:35 AM, James Benedict wrote: > The way I read the original post, it sounds like > Phillip is describing two types of "data": > > 1) self-asserted > 2) third-party asserted > > I'm all for saying that data can be self-asserted or > third-party asserted... but I don't want to start > categorizing the information based on what "can" be > self-asserted vs. third-party. Glad we agree and that we have "clarified" Phillip's post! Phillip, are you in agreement? (don't want to speak for you) -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 12:51:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BH6-0005KJ-86; Thu, 26 Jan 2006 12:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BH0-0005Jz-Ty for dix@megatron.ietf.org; Thu, 26 Jan 2006 12:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09231 for ; Thu, 26 Jan 2006 12:49:33 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BR0-0007UQ-1z for dix@ietf.org; Thu, 26 Jan 2006 13:01:27 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k0QHou6n006048; Thu, 26 Jan 2006 17:50:56 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 12:48:58 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Jan 2006 17:48:58 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 26 Jan 2006 12:50:58 -0500 Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) From: Peter Davis To: "Digital Identity Exchange " , "Hallam-Baker, Phillip" Message-ID: Thread-Topic: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) Thread-Index: AcYh3/1v/us5mG8oSnu7HdRJooK8kgAJ/nVQAAvfrjAAGmaASA== In-Reply-To: <198A730C2044DE4A96749D13E167AD378CE022@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jan 2006 17:48:58.0732 (UTC) FILETIME=[C8E6D2C0:01C622A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org On 1/26/2006 12:25 AM, "Hallam-Baker, Phillip" wrote: > I think that there are two separate types of identity information that > need to be considered here: > > 1) Self asserted information (nickname, photo, email etc.) > 2) Third party assertions (reputation, spamminess, star alliance gold > etc.) > > The first type of information is not difficult to manage, the relying > party understands that the data is self asserted. Attribute value pairs > in any standard format work as well as anything. > > The second type of information requires the reputation of the > information provider to be considered by the relying party. > The is a sub-type of type 1 above, IMHO: 1a) Self-Asserted, but verifiable by a third party. Today's Credit Card transactions (esp those conducted via web sites) fall into this type. Tho I wonder, having written this, if it is some hybrid of 1 and 2? =peterd (http://public.xdi.org/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 13:06:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BVU-000598-Hu; Thu, 26 Jan 2006 13:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2BVS-00057q-4k for dix@megatron.ietf.org; Thu, 26 Jan 2006 13:06:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10903 for ; Thu, 26 Jan 2006 13:04:30 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BfQ-0008Cb-8U for dix@ietf.org; Thu, 26 Jan 2006 13:16:22 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0QI5fXI024041 for ; Thu, 26 Jan 2006 10:05:41 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 10:05:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: of identifiers and identity service discovery (was: Re:[dix]Toadd to the charter) Date: Thu, 26 Jan 2006 10:05:39 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD378CE071@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: of identifiers and identity service discovery (was: Re:[dix]Toadd to the charter) Thread-Index: AcYimEfBFc3MnMJrQpGO7/sQDHzmbgACeNzA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 26 Jan 2006 18:05:40.0461 (UTC) FILETIME=[1DFA89D0:01C622A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > Behalf Of Dick Hardt > > The way I read the original post, it sounds like Phillip is=20 > describing=20 > > two types of "data": > > > > 1) self-asserted > > 2) third-party asserted > > > > I'm all for saying that data can be self-asserted or third-party=20 > > asserted... but I don't want to start categorizing the information=20 > > based on what "can" be self-asserted vs. third-party. >=20 > Glad we agree and that we have "clarified" Phillip's post! >=20 > Phillip, are you in agreement? (don't want to speak for you) There are certainly some types of data that makes it very unlikely that anyone would want to trust a self-asserted claim on, e.g. "I am not a spammer". But in general most of the data being traded today can be self asserted. For example nobody seems to have much of a problem with self asserted zip codes, even though many people automatically enter a bogus one. One caution I would suggest is to not use credit card information as an example of the type of profile information that might be stored. While it is certainly possible to store such data in principle there are major security and liability considerations that are attached. Unless the proposal is being made by someone with a deep understanding of the payments business it is likely to get picked appart pretty quickly by the security vultures. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 14:00:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CMC-0001h2-Du; Thu, 26 Jan 2006 14:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2CM9-0001gM-1X for dix@megatron.ietf.org; Thu, 26 Jan 2006 14:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15914 for ; Thu, 26 Jan 2006 13:58:57 -0500 (EST) Received: from imo-m21.mx.aol.com ([64.12.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2CW9-0001rv-6y for dix@ietf.org; Thu, 26 Jan 2006 14:10:49 -0500 Received: from THayes0993@aol.com by imo-m21.mx.aol.com (mail_out_v38_r6.3.) id l.6b.5443ceaa (15874) for ; Thu, 26 Jan 2006 14:00:09 -0500 (EST) Received: from FWM-M29 (fwm-m29.webmail.aol.com [64.12.193.231]) by air-id07.mx.aol.com (v108_r1_b1.2) with ESMTP id MAILINID71-3e0243d91c37188; Thu, 26 Jan 2006 14:00:07 -0500 Date: Thu, 26 Jan 2006 14:00:06 -0500 Message-Id: <8C7F0C1DB6C62F5-E28-59DC@FWM-M29.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD378CE022@MOU1WNEXMB04.vcorp.ad.vrsn.com> Received: from 10.169.155.114 by FWM-M29.sysops.aol.com (64.12.193.231) with HTTP (WebMailUI); Thu, 26 Jan 2006 14:00:06 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: X-Mailer: AOL WebMail 15106 Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 64.12.193.231 X-Spam-Flag: NO X-Spam-Score: 2.4 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0559159552==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --===============0559159552== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C7F0C1DB6C62F5_E28_5A7C_FWM-M29.sysops.aol.com" ----------MailBlocks_8C7F0C1DB6C62F5_E28_5A7C_FWM-M29.sysops.aol.com Content-Type: text/plain; charset="us-ascii" I also agree with Phillip that there are two types of claims. (I like that word better.) I would point out that in the proposed protocol, the "agent" is actually making the claims on behalf of the user. The whole point of a "Homesite Inspection" step performed by the relying party ("Membersite") in the draft is to establish the reputation of an endpoint for speaking on behalf of the user. However the agent and the user are so closely aligned that making this distinction is probably overkill. A more important difference is that case (2) requires some sort of name that can be used by the third-party to refer to the subject of the claims. Case (1) doesn't have this need, since the subject is always the "current user". Naming always seems to be the most difficult thing to agree on. The name can be: 1) a key value (public key) or the hash of a key value 2) a unique value generated by the relying party to represent the user for this session 3) a globally unique name (good luck with this one!) 4) a name given by some naming authority (which must also have a name) A DIX protocol that only supported case (1) claims would avoid the whole naming issue. This might be a good thing to focus on, so that something is accomplished in a shorter period of time. Terry Hayes -----Original Message----- From: Dick Hardt To: Digital Identity Exchange Sent: Wed, 25 Jan 2006 22:53:30 -0800 Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter) On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip wrote: > I think that there are two separate types of identity information that > need to be considered here: > > 1) Self asserted information (nickname, photo, email etc.) > 2) Third party assertions (reputation, spamminess, star alliance gold > etc.) > > The first type of information is not difficult to manage, the relying > party understands that the data is self asserted. Attribute value > pairs > in any standard format work as well as anything. > > The second type of information requires the reputation of the > information provider to be considered by the relying party. I generally agree Phillip. In the identity gang discussions we have called these claims instead of identity information. Identity having a vague meaning. I see (2) requiring not only a trust relationship with the asserting party by the relying party (something that is social, not technical), but also a mechanism for the relying party to know it is a valid assertion, which requires some verification mechanism such as PKI. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ----------MailBlocks_8C7F0C1DB6C62F5_E28_5A7C_FWM-M29.sysops.aol.com Content-Type: text/html; charset="us-ascii"
I also agree with Phillip that there are two types of claims. (I like that word better.)
 
I would point out that in the proposed protocol, the "agent" is actually making the claims on behalf of the user.  The whole point of a "Homesite Inspection" step performed by the relying party ("Membersite") in the draft is to establish the reputation of an endpoint for speaking on behalf of the user. However the agent and the user are so closely aligned that making this distinction is probably overkill.
 
A more important difference is that case (2) requires some sort of name that can be used by the third-party to refer to the subject of the claims.  Case (1) doesn't have this need, since the subject is always the "current user". Naming always seems to be the most difficult thing to agree on.  The name can be:
   1) a key value (public key) or the hash of a key value
   2) a unique value generated by the relying party to represent the user for this session
   3) a globally unique name (good luck with this one!)
   4) a name given by some naming authority (which must also have a name)
 
A DIX protocol that only supported case (1) claims would avoid the whole naming issue.  This might be a good thing to focus on, so that something is accomplished in a shorter period of time.
 
Terry Hayes
 
-----Original Message-----
From: Dick Hardt <dick@sxip.com>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Wed, 25 Jan 2006 22:53:30 -0800
Subject: Re: of identifiers and identity service discovery (was: Re: [dix]Toadd to the charter)

On 25-Jan-06, at 9:25 PM, Hallam-Baker, Phillip wrote: 
 
> I think that there are two separate types of identity information that 
> need to be considered here: 
> 
> 1) Self asserted information (nickname, photo, email etc.) 
> 2) Third party assertions (reputation, spamminess, star alliance gold 
> etc.) 
> 
> The first type of information is not difficult to manage, the relying 
> party understands that the data is self asserted. Attribute value > pairs 
> in any standard format work as well as anything. 
> 
> The second type of information requires the reputation of the 
> information provider to be considered by the relying party. 
 
I generally agree Phillip. 
 
In the identity gang discussions we have cal! led these claims instead of identity information. Identity having a vague meaning. 
 
I see (2) requiring not only a trust relationship with the asserting party by the relying party (something that is social, not technical), but also a mechanism for the relying party to know it is a valid assertion, which requires some verification mechanism such as PKI. 
 
-- Dick 
 
_______________________________________________ 
dix mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 
----------MailBlocks_8C7F0C1DB6C62F5_E28_5A7C_FWM-M29.sysops.aol.com-- --===============0559159552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0559159552==-- From dix-bounces@ietf.org Thu Jan 26 14:02:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2COH-0002NE-4Y; Thu, 26 Jan 2006 14:02:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2COF-0002Mv-OO for dix@megatron.ietf.org; Thu, 26 Jan 2006 14:02:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16046 for ; Thu, 26 Jan 2006 14:01:07 -0500 (EST) Received: from web88103.mail.re2.yahoo.com ([206.190.37.204]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2CYD-0001vv-4R for dix@ietf.org; Thu, 26 Jan 2006 14:13:00 -0500 Received: (qmail 36481 invoked by uid 60001); 26 Jan 2006 19:02:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KffQVa9u2fYgbdAMwAxIDh7gi3p83Q46qYTYas8z21xlOOAzkQuG89ryAHB3f66iLFROSmLdQ8SJMAKaNlZH/dX6RmYQQCYQrnMRIglOYwy/4nkQ4c638/BNReuyXVlX35XoVLAjQ2Ao8HRO5wW1YMzfK6X7YCQGWUgE/VQkp/Q= ; Message-ID: <20060126190224.36479.qmail@web88103.mail.re2.yahoo.com> Received: from [72.1.215.180] by web88103.mail.re2.yahoo.com via HTTP; Thu, 26 Jan 2006 14:02:24 EST Date: Thu, 26 Jan 2006 14:02:24 -0500 (EST) From: James Benedict Subject: RE: of identifiers and identity service discovery (was: Re:[dix]Toadd to the charter) To: Digital Identity Exchange In-Reply-To: <198A730C2044DE4A96749D13E167AD378CE071@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 8bit X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --- "Hallam-Baker, Phillip" wrote: > > Behalf Of Dick Hardt > > > > The way I read the original post, it sounds like > Phillip is > > describing > > > two types of "data": > > > > > > 1) self-asserted > > > 2) third-party asserted > > > > > > I'm all for saying that data can be > self-asserted or third-party > > > asserted... but I don't want to start > categorizing the information > > > based on what "can" be self-asserted vs. > third-party. > > > > Glad we agree and that we have "clarified" > Phillip's post! > > > > Phillip, are you in agreement? (don't want to > speak for you) > > There are certainly some types of data that makes it > very unlikely that > anyone would want to trust a self-asserted claim on, > e.g. "I am not a > spammer". > > But in general most of the data being traded today > can be self asserted. > For example nobody seems to have much of a problem > with self asserted > zip codes, even though many people automatically > enter a bogus one. > > > One caution I would suggest is to not use credit > card information as an > example of the type of profile information that > might be stored. While > it is certainly possible to store such data in > principle there are major > security and liability considerations that are > attached. Unless the > proposal is being made by someone with a deep > understanding of the > payments business it is likely to get picked appart > pretty quickly by > the security vultures. > Busted :) While I wouldn't say that I have a "deep" understanding of the payments business ... I've built a few tools in that area. I know John and co. have already set a few security disclaimers into their draft ... but, I'de rather see the security guys picking at it sooner than later. -- James > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jan 26 18:41:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Gk2-0003HI-U9; Thu, 26 Jan 2006 18:41:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Gk1-0003HC-F5 for dix@megatron.ietf.org; Thu, 26 Jan 2006 18:41:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17391 for ; Thu, 26 Jan 2006 18:39:52 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Gu3-0006q6-Ad for dix@ietf.org; Thu, 26 Jan 2006 18:51:48 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0QNfIx0004216 for ; Thu, 26 Jan 2006 15:41:18 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 15:41:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: of identifiers and identity service discovery (was: Re:[dix]Toadd to the charter) Date: Thu, 26 Jan 2006 15:41:17 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD378CE10B@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: of identifiers and identity service discovery (was: Re:[dix]Toadd to the charter) Thread-Index: AcYiRWrVmSqeWXukRYm5D0O7w6IcVQAiyWPQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 26 Jan 2006 23:41:18.0146 (UTC) FILETIME=[00F96A20:01C622D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > I see (2) requiring not only a trust relationship with the=20 > asserting party by the relying party (something that is=20 > social, not technical), but also a mechanism for the relying=20 > party to know it is a valid assertion, which requires some=20 > verification mechanism such as PKI. Third party assertions require an accountability mechanism. The point of the Karma scoring scheme on slashdot is to hold posters accountable for their posts, post crud onto slashdot and your karma quickly falls. The tricky part in the system is how to hold the moderators accountable, slashdot tries with meta-moderation. Now imagine that we attempt to do apply the karma concept across sites. It is very hard to do so and maintain accountability. If we simply say 'Fred has excellent slashdot karma he can post' we have a problem because Fred is only accountable for his slashdot posts.=20 Extending the system so that Fred is accountable for off site posts so that they then feed back to his now global karma score means that we are vulnerable to a new form of attack where Fred sets up a bogus site for the sole purpose of reporting positive karma, or perhaps there is a red/blue issue. Lefty poster posts on righty blog, gets lots of negative moderation, should it affect his karma score on lefty blogs as well as righty? It's a complex problem and there is a lot of information to manage. SAML syntax is the last of anyone's worries in that case. Much easier to start with 'this is a picture of my pet dog Eric'. There is a lot of value that can be provided there at little cost. A second form of information that is interesting is quasi-confidential information. I don't know what vulnerability is involved if I disclose my star alliance frequent flyer number but I prefer to avoid it unless necessary. Why does any party other than United or a star alliance member ever need to see it? We could just use the uniform identifier. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jan 27 16:40:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bKO-00084I-Pa; Fri, 27 Jan 2006 16:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bKN-000831-8e for dix@megatron.ietf.org; Fri, 27 Jan 2006 16:40:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18412 for ; Fri, 27 Jan 2006 16:38:44 -0500 (EST) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2bMw-0007kh-Kk for dix@ietf.org; Fri, 27 Jan 2006 16:42:59 -0500 Received: from user-10ib3g5.biz.mindspring.com ([65.37.142.5] helo=belka.radicalmode.com) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F2bCX-00053S-00 for dix@ietf.org; Fri, 27 Jan 2006 16:32:13 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1F2bCW-0002Ud-IR for dix@ietf.org; Fri, 27 Jan 2006 13:32:12 -0800 From: Nick Ragouzis Sent: Friday, January 27, 2006 13:15 AM To: dix@ietf.org Message-Id: Date: Fri, 27 Jan 2006 13:32:12 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [dix] Five paths for the six propositions of the "DIX Service"? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org (Note that in the following I am only assuming the submitted I-D is intended only as an exemplar and descriptive of the use cases (i.e., the productions of such cases); not more than that. It is at the charter this note is directed.) Comments I've received on the discussion of lightness (or not) of just one pre-existing identity-domain protocol really just point me to an underlying problem in the proposed charter and the I-D: when defense about the fitness of a protocol on one dimension (identity token) is carried forward principally by advancing the *other* merits of that protocol (web page editing), then that protocol has likely wound together too many goals. A similar dynamic has played out on the list. That's prompted me to take another look at the discussion abt the charter, and the I-D. I find the "DIX protocol" of the I-D to be a combination of protocols (in a most general meaning) at various levels and to various ends. As such it is more the "DIX Service", a vertically- integrated system (here using DIX less as a meaningful acronym but more, merely, as a label). Maybe that's just me, just waking up (or being excused from jury duty). I think that design and adoption of such vertically-integrated systems have some well known characteristics, but ease of specification for wide interoperability and future proofing (and actual implementation of such interoperability) isn't one of them. This just reinforces that the proposed work would unfold in the context of several component protocols already designed for composing, extensibility, and profiling. Or at least we've not found the specific gap where such composing, extension, and profiling couldn't be brought to bear. The overall context is for some version/profile of operations of this service to be possible to realize with as little as possible effort over that required for slightly-enlightened web site operators and web site authors, for working with clued-in web site users. The presumption is that HTTP protocols handled by common HTTP servers working with ordinary HTML presentations of data. This presumption extends to nothing more than, say, such users following simple-if-a-bit-mysterious ordinary copy-paste of "magic potions" with some substitutions in templates. The expectation is, however, that even with this simplified service, most of the services (the protections, the additional capabilities) would be automated through, say, scripting facilities of the related service providers and installed web products and environments. Although that's the baseline, it's not necessarily the full extent. These are only presumptions, not prescriptive or limiting, at this point. We'd want many other services to be able to adopt parts, right? The next thing to notice is something a bit extraordinary: the user interface, and the expression in a user agent presentation language, is integral to the proposition. To me it seems by comparison enlarged to the level of a separate component of the service. >From there I suggest we are considering several propositions: 1. There is a "digital identity user form factor expression markup language", which describes how components of digital identities may be marked and handled in html page forms intended for human consumption (but not excluding automation). 2. There is a "digital identity authority cookie protocol", which can hold user preferences regarding authorities. This could not be called a discovery service as it would describe nothing more than description and publication (or redirection of same) of said preferences using the simple known-location registration (UA) and simple table lookup of cookie handling. 3. There is a "digital identity authority services description and discovery protocol" authorities to use to describe their supported identity operations with respect to the particular identity, including one (presumably more) ways to publish this, and to re-vector requests it receives to other authorities of similar information according to user and service desires. 4. There is a protocol for relying parties to describe requirements for, and to request statements about, claims. 5. There are the related security protocols. 6. And some seem to be entertaining the need to propose a restriction or characterization of some type on the structure, syntax and meaning of identifiers and digital identifier. Notwithstanding the above, at the outset of our work there is no presumption of one identifier format, or one token format, or one request/response language, MEP, or transport. As dialog has proceeded on the charter, however, we see how the range and intermixing of the above propositions make very difficult the questions of required implementations and selections of use cases. My suggestion is that we work towards agreement on (or discard) a few items: First: Proposition #1 is a useful piece of work, and could happen with the intention of being compatible across a selection of other lower/parallel protocols (of which we could pick the initial set). It could be implemented and such implementations deployed separate and apart, or exclusive, of the realizations of the other propositions. Second: Proposition #2 is also a useful piece of work, with broad applicability, but defined separate from proposition #1 (and the others). It too could be implemented and deployed separate and apart from the other propositions. Third: Proposition #3 is certainly useful, and likely a significant separate piece of work. For one it would benefit from making a creditable effort at characterization and gap analysis of other pre-existing protocols and work in progress. The ultimate outcome would, then, be a generalized method for serialization and transformation, with the probably addition of metadata. Fourth: Proposition #4 and #5 are areas where significant pre- existing work exists, and that work is highly susceptible to composition, extension, and profiling. Further work is necessary by this/some community, and then a community (perhaps in those bodies, perhaps here) can describe the related compositions/extensions/profiles. A possible outcome is a new capability, but one that also (simultaneously) demonstrates its potential for interoperation with the other work. BTW: A finding of a gap in _clarity_ of these pre-existing component protocols isn't an argument for building another protocol. It, OTOH, argues for work on clarity on those protocols ... from which all would benefit. Realistically, a large number of the same people (and especially a large number of the key architects) who've worked on those protocols will work (and vote) here, and those new to those protocols can, here, bring valued perspectives for their improvement, in clarity and in extensions and profiles. Fifth: Proposition #6 should be out of scope for this work, avoiding attempts at a narrowed or limited definition. More specifically, the test should be that every proposal for work (e.g., on Propositions 1-5) should support at least the known identifiers, more ideally the expected identifiers. An approach would be: presumption of support; or a specific description for why support is omitted in the face of overwhelming difficulties. Restriction or removal of particular identifiers or a particular concept of digital identity should require more than some undifferentiated ideal of simplicity or lightness, otherwise we do not advance interoperability nor do we prepare for the future ... neither of which makes user's lives easier. I'd just like to mention that I propose this intending that if it has any merit it would be modified until we can see that all the goals, including the search for simplicity, are still achievable. Thanks, --Nick BTW, on that theme of existing work, I think we should endeavor to use existing glossaries, or to create new definitions as derived through extension and modification of the several pre- existing glossaries on the matter (not the least the IETF contributions). Unfortunately this weight falls to the writers and editors, as few readers of the list will actually bother to write at length about every stray term (with the usual Pareto effect of a few generating a LOT of noise). Perhaps its a work item to designate authoritative glossaries, and a procedure for extending them with local additions or variants. In the least, then, folks would know which glossaries to read. :-) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix