From dix-bounces@ietf.org Thu Feb 02 20:53: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 1F4q99-00088u-FT; Thu, 02 Feb 2006 20:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4q98-00084a-Dj for dix@megatron.ietf.org; Thu, 02 Feb 2006 20:53: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 UAA09962 for ; Thu, 2 Feb 2006 20:52: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 1F4qKL-0008QV-K8 for dix@ietf.org; Thu, 02 Feb 2006 21:05:34 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k131rWSO041419 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Feb 2006 17:53:33 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Thu, 2 Feb 2006 17:53:31 -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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [dix] wiki for dix 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 Some of the feedback I received from the mailing list subscribers included requests for a wiki. This was to better capture the results of the interesting discussions we've been having. We (Sxip Identity) have registered a domain name (dixs.org) and are hosting a wiki there. We regard this as a community space and nothing to do with the corporation. http://dixs.org/ The only content there right now is the DIX protocol ID that I wrote and published to illustrate the protocol work we've been doing. Next I'll put the charter draft up there (#3 + Jim's reworking). You're most welcome to add your own content/comments/edits/whatever to the site. I'd very much welcome use case contributions.... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Feb 03 13:37: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 1F55nu-0001UC-H3; Fri, 03 Feb 2006 13:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F55ns-0001TI-T0 for dix@megatron.ietf.org; Fri, 03 Feb 2006 13:37: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 NAA27489 for ; Fri, 3 Feb 2006 13:35:25 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F55zU-0006dA-Jx for dix@ietf.org; Fri, 03 Feb 2006 13:49:06 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Fri, 03 Feb 2006 11:36:46 -0700 Message-Id: <43E3403D.D091.001C.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Fri, 03 Feb 2006 11:36:29 -0700 From: "Jim Sermersheim" To: "Digital Identity Exchange" Subject: Re: [dix] wiki for dix References: In-Reply-To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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="===============0711923137==" 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. --===============0711923137== Content-Type: multipart/alternative; boundary="=__PartD7F57ABD.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. --=__PartD7F57ABD.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit When I shrunk the proposed charter, I either glossed over or removed some of the requirements. In order to track them, I added a requirements page (http://dixs.org/index.php/Requirements). It may be useful to add another column for something like importance or priority. My reasoning behind the table is to have a central place where use cases and requirements can be described. This way people new to the discussion don't have to grope through the archives. I've only seeded it with a couple items from the proposed charter, just to see if it look ok. Someone could start by capturing all the requirements from John's #3 charter. Jim >>> merrells@sxip.com 2/2/06 6:53:31 pm >>> Some of the feedback I received from the mailing list subscribers included requests for a wiki. This was to better capture the results of the interesting discussions we've been having. We (Sxip Identity) have registered a domain name (dixs.org) and are hosting a wiki there. We regard this as a community space and nothing to do with the corporation. http://dixs.org/ The only content there right now is the DIX protocol ID that I wrote and published to illustrate the protocol work we've been doing. Next I'll put the charter draft up there (#3 + Jim's reworking). You're most welcome to add your own content/comments/edits/whatever to the site. I'd very much welcome use case contributions.... John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=__PartD7F57ABD.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
When I shrunk the proposed charter, I either glossed over or removed some of the requirements. In order to track them, I added a requirements page (http://dixs.org/index.php/Requirements).
 
It may be useful to add another column for something like importance or priority. My reasoning behind the table is to have a central place where use cases and requirements can be described. This way people new to the discussion don't have to grope through the archives.
 
I've only seeded it with a couple items from the proposed charter, just to see if it look ok. Someone could start by capturing all the requirements from John's #3 charter.
 
Jim

>>> merrells@sxip.com 2/2/06 6:53:31 pm >>>

Some of the feedback I received from the mailing list subscribers 
included
requests for a wiki. This was to better capture the results of the 
interesting
discussions we've been having.

We (Sxip Identity) have registered a domain name (dixs.org) and are
hosting a wiki there. We regard this as a community space and nothing
to do with the corporation.

http://dixs.org/

The only content there right now is the DIX protocol ID that I wrote and
published to illustrate the protocol work we've been doing. Next I'll 
put
the charter draft up there (#3 + Jim's reworking).

You're most welcome to add your own content/comments/edits/whatever
to the site. I'd very much welcome use case contributions....

John





_______________________________________________
dix mailing list
dix@ietf.org
https:/! /www1.ietf.org/mailman/listinfo/dix
--=__PartD7F57ABD.0__=-- --===============0711923137== 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 --===============0711923137==-- From dix-bounces@ietf.org Sat Feb 04 21: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 1F5Zso-00042x-0F; Sat, 04 Feb 2006 21: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 1F5Zsk-00040v-Pb for dix@megatron.ietf.org; Sat, 04 Feb 2006 21:44:08 -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 VAA28217 for ; Sat, 4 Feb 2006 21:42:15 -0500 (EST) Received: from smtp104.sbc.mail.mud.yahoo.com ([68.142.198.203]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5a4R-0005Mp-Gq for dix@ietf.org; Sat, 04 Feb 2006 21:56:12 -0500 Received: (qmail 52443 invoked from network); 5 Feb 2006 02:43:38 -0000 Received: from unknown (HELO elijah.joaquin.net) (jm-acm.no@sbcglobal.net@70.137.176.53 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 5 Feb 2006 02:43:38 -0000 Message-Id: <6.2.3.4.0.20060128102954.04010d00@pop.netmesh.us> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 04 Feb 2006 18:43:00 -0800 To: Digital Identity Exchange From: Joaquin Miller In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [dix] Charter and example Internet Draft 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 Folks: Nick, with his usual insight, has put his finger on what has been troubling me. We seem to be trying to bite off way more than a mouthful. There are several good reasons to separate the parts and tackle them one at a time: easier to get this established at IETF; greatly simplify the work on each part; a cleaner work product; several distinct and useful protocols, which can each be combined in various ways with other established protocols. There is a lot of work to do. It may be best to: bite off what can be fairly quickly chewed, deliver something solid and ready to use, see it used while we get on with the next bite. Cordially, Joaquin On 27 January, Nick Ragouzis wrote: >(Note that in the following I am only assuming the submitted >Internet Draft is intended only as an exemplar and descriptive of >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. > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Feb 09 21:58: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 1F7OUb-0000sP-O9; Thu, 09 Feb 2006 21:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7OUW-0000pD-7J for dix@megatron.ietf.org; Thu, 09 Feb 2006 21:58: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 VAA05119 for ; Thu, 9 Feb 2006 21:56: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 1F7Oh9-0005sF-Sq for dix@ietf.org; Thu, 09 Feb 2006 22:11:41 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1A2w9QP026489 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Feb 2006 18:58:10 -0800 (PST) (envelope-from merrells@sxip.com) To: ietf@ietf.org Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Resent-Date: Thu, 9 Feb 2006 18:58:09 -0800 Message-Id: <17857469-4F78-4EC3-AFA0-4D12E0365D3D@sxip.com> Content-Transfer-Encoding: quoted-printable Resent-To: Digital Identity Exchange From: John Merrells Resent-From: John Merrells Resent-Message-Id: <0B122D04-4593-407D-AF00-C936F593947B@sxip.com> Date: Thu, 9 Feb 2006 18:28: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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , shollenbeck@verisign.com Subject: [dix] IETF 65 BOF Announcement: Digital Identity Exchange (DIX) 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 An announcement of a DIX BOF at IETF 65 just went out on the=20=20 ietf@ietf.org mailing list. The announcement message is below. It includes a draft agenda. Of=20=20 course the draft of the proposed charter and the agenda are both up=20=20 for bashing before we meet in Dallas. If we can make some progress on=20=20 use cases I'd love to see that added. I hope to meet many of you in person in Dallas, March 19-24. I=20=20 foolishly offered up some beer tokens a while back and I suspect=20=20 there will be people trying to cash them in. So, let me know if=20=20 you're attending! John ----- Name of the BOF Digital Identity Exchange (DIX) Area: Applications Chairs: Lisa Dusseault John Merrells Sponsoring Area Directors: Scott Hollenbeck Ted Hardie BOF Description Objectives 1. To consider the creation of a new IETF working group within the=20=20 Applications Area titled "Digital Identity Exchange". The proposed=20=20 charter for such a working group is referenced below. 2. To discuss and hone the scope of a DIX working group. 3. To discuss the architectural requirements that derive from the=20=20 laws of identity identified by =91The Identity Gang=92 at =91The Berkman=20= =20 Center for Internet & Society, Harvard Law School=92. Referenced below. 4. To discuss existing architectural implementations within the=20=20 context of these requirements. An individual submission Internet=20=20 Draft that describes one such implementation is referenced below,=20=20 named =91draft-merrells-dix-00.txt=92 5. To determine if there is enough interest and commitment to form a=20=20 Working Group and if so to then discuss what the specific goals and=20=20 milestones of that working group would be. BOF Agenda Introduction and Agenda Discussion (5 min) Scope Discussion (10 min) Identity Laws and Architectural Requirements (10 min) Existing Architecture Presentations (30 min) Call for Participation (5 min) Deliverables Discussion (15 min ) Open Discussion (any remaining time) Documents Charter Draft: http://dixs.org/index.php/DIX_Charter DIX Protocol ID: http://www.ietf.org/internet-drafts/draft-merrells-=20 dix-00.txt DIX Protocol ID: http://dixs.org/index.php/DIX_Protocol_ID Identity Laws: http://www.identityblog.com/stories/2004/12/09/=20 thelaws.html _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Feb 11 18:17: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 1F83zl-0000jj-48; Sat, 11 Feb 2006 18:17:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F83zk-0000ja-8L for dix@megatron.ietf.org; Sat, 11 Feb 2006 18:17: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 SAA05700 for ; Sat, 11 Feb 2006 18:15:51 -0500 (EST) Received: from [198.144.201.116] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F84Cn-0003UQ-Ax for dix@ietf.org; Sat, 11 Feb 2006 18:31:21 -0500 Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1B227B811 for ; Sat, 11 Feb 2006 15:17:09 -0800 (PST) To: dix@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 11 Feb 2006 15:17:08 -0800 From: Eric Rescorla Message-Id: <20060211231709.1B227B811@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [dix] Review of draft-merrells-dix-00.txt 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 BACKGROUND The idea behind DIX is to have a third-party authentication system where a user can have a preexisting relationship with a third party that then vouches for its identity to the system site/server that it actually wants to communicate with. This is, of course, a pretty common desire and there are already a lot of systems that do it (Kerberos, PKI, etc.). The particular scheme described in this draft is based on Web forms, Javascript, and redirection. SUMMARY OF THE DIX SCHEME Here's my reconstruction of how the DIX scheme works from the document (which, unfortunately, does not contain a helpful summary or diagram) The DIX scheme involves at minimum three agents: - The user's client (browser) - The site that the user is trying to access (called the Membersite) - The site that authenticates the user (called the Homesite) When the user contacts the Membersite (1), it responds with a web page prompting the user to enter the URL of its Homesite (2). The user then enters the Homesite URL (3). The Membersite contacts the Homesite (4,5) to determine whether the Homesite can provide the appropriate kind of authentication. If it can, the Membersite sends the client a redirect (6) (using Javascript) to the Homesite. In some way that's not entirely clear the Homesite validates the request and returns a ticket to the Client (8) The Client then (via Javascript?) sends the ticket to the the Membersite (9). The Membersite contacts the Homesite with a digest of the ticket in order to confirm its validity (10) If the Homesite says its OK (11), the Membersite returns OK to the Client (12) Client Membersite Homesite 1 Hello --------------------------> 2 <------- Enter homesite URL 3 Homesite URL -------------------> 4 Get capabilities ----------> 5 <------------- Capabilities 6 <------ Redirect to Homesite 7 Get Ticket--------------------------------------------------> 8 <----------------------------------------------------- Ticket 9 Ticket -------------------------> 10 Verify ticket --------------> 11 <----------------------- Ticket OK 12 <------------------------ OK There's one more detail that I haven't mentioned: in order to enable automatic submission of the abovementioned form (2,3), this document specifies a particular form for the page (i.e., particular names for form input fields) so that clients can detect it and auto-fill-in. COMMENTS I have four major concerns about this system as described: - Relationship to existing work - Use of Javascript - Method of ticket validation The remainder of this review details these issues. Relationship To Existing Work There has been a very large amount of work in delegated/federated authentication systems, ranging from RADIUS/DIAMETER to Shibboleth, Liberty, and SAML. It's not clear from this document or from the charter why something new is needed here. So, I think the first order of business to establish what properties are required here that present systems don't provide. Use of Javascript Section 5.10.2.1 reads: The Membersite sends a fetch-request message to the Homesite through the User's client via a redirected HTTP POST to their Homesite Endpoint URL using JavaScript to autosubmit the form. I appreciate the rationale for this: you want things to work with dumb clients but given that Javascript isn't any kind of IETF standard--it's hard to see how we could require it in an IETF standard. ECMASCript, perhaps. Even then, specifying this kind of implementation detail is the kind of thing that IETF typically stays out of. I appreciate that this is also a wire protocol issue, but given that there's no specification of the exact JavaScript incantation, it's not clear it makes sense to specify only the language. Method of ticket validation This draft validates the ticket by having the Membersite send a digest to the Homesite and get an ACK. It's not clear why this is desirable. Wouldn't it be simpler to have the Homesite digitally sign the ticket (the key could be delivered in the initial capabilities discovery phase) and then let the Membersite do the verification directly? I appreciate that there's a freshness concern, but this can be alleviated using the usual nonce-based anti-replay techniques. A suggested implementation of a signature function would be to use the SHA1 algorithm, which takes as input a digest of the message and a secret known only to the Homesite. Signature = T ( S + Digest ) Where, Digest is message digest (defined above), S is the Homesite Secret, T is the signature generation function, and '+' means string concatentation. The technical term for a "signature" which can only be verified by the holder of a symmetric secret is Message Authentication Code (MAC) and there's a standard technique for performing MACs: HMAC (RFC 2104). _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Feb 11 19:29: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 1F857Q-0003el-R9; Sat, 11 Feb 2006 19:29:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F857P-0003eC-PL for dix@megatron.ietf.org; Sat, 11 Feb 2006 19:29: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 TAA08794 for ; Sat, 11 Feb 2006 19:27:50 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F85Ke-00055L-MK for dix@ietf.org; Sat, 11 Feb 2006 19:43:21 -0500 Received: from [192.168.0.2] (adsl-71-131-42-237.dsl.sntc01.pacbell.net [71.131.42.237]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1C0TwWC020562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Feb 2006 16:29:58 -0800 Message-ID: <43EE815E.6090600@dcrocker.net> Date: Sat, 11 Feb 2006 16:29:18 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange References: <20060211231709.1B227B811@delta.rtfm.com> In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [dix] use of non-ietf work in ietf standards X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, 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 > dumb clients but given that Javascript isn't any kind of IETF > standard--it's hard to see how we could require it in an IETF > standard. small procedural point: the ietf does it all the time. x.400 interoperability specs. IP-over-* specs. Anything using Unicode. And so on. (The subject line of this message is changed so that no one confuses this note with a comment on dix or your substantive review of it.) d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Feb 11 22:34: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 1F880d-0007Hg-0o; Sat, 11 Feb 2006 22:34:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F880b-0007HY-KW for dix@megatron.ietf.org; Sat, 11 Feb 2006 22:34: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 WAA18579 for ; Sat, 11 Feb 2006 22:33:01 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F88Dv-0001An-8n for dix@ietf.org; Sat, 11 Feb 2006 22:48:32 -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 <20060212033434m1100o6q8ne>; Sun, 12 Feb 2006 03:34:34 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: multipart/mixed; boundary=Apple-Mail-24-346803549 Message-Id: From: Johannes Ernst Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Sat, 11 Feb 2006 19:34:37 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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-24-346803549 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Feb 11, 2006, at 15:17, Eric Rescorla wrote: > Relationship To Existing Work > There has been a very large amount of work in delegated/federated > authentication systems, ranging from RADIUS/DIAMETER to > Shibboleth, Liberty, and SAML. It's not clear from this document or > from > the charter why something new is needed here... Just having returned from a workshop at Harvard with many of the important players in the extended identity universe, in which we touched on most of the major existing standards and proposals (e.g. Microsoft's) in one way or another, I can relay that I have heard that concern repeatedly. Everybody pretty much now agrees that we need more interoperability, not more stovepipes. Personally, as I have indicated previously on this list, I think there are a number of things that the IETF could usefully do complementing rather than replicating other people's work, but I concur that this has not be articulated so far. > Method of ticket validation ... Are you basically proposing a variation of OpenID authentication, or do I misunderstand you? Johannes Ernst NetMesh Inc. --Apple-Mail-24-346803549 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-24-346803549 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit http://netmesh.info/jernst --Apple-Mail-24-346803549 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-24-346803549-- From dix-bounces@ietf.org Sun Feb 12 00:32: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 1F89qL-0007gD-Mz; Sun, 12 Feb 2006 00:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F89qJ-0007fS-Mn for dix@megatron.ietf.org; Sun, 12 Feb 2006 00:32: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 AAA23814 for ; Sun, 12 Feb 2006 00:30:30 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8A3e-0003rB-BB for dix@ietf.org; Sun, 12 Feb 2006 00:46:03 -0500 Received: from [192.168.0.2] (adsl-71-131-42-237.dsl.sntc01.pacbell.net [71.131.42.237]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1C5WUJg014073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Feb 2006 21:32:31 -0800 Message-ID: <43EEC847.3030003@dcrocker.net> Date: Sat, 11 Feb 2006 21:31:51 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net 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: dcrocker@bbiw.net, 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 J> Just having returned from a workshop at Harvard with many of the > important players in the extended identity universe, in which we touched > on most of the major existing standards and proposals (e.g. Microsoft's) > in one way or another, I can relay that I have heard that concern > repeatedly. Everybody pretty much now agrees that we need more > interoperability, not more stovepipes. Yup. It would help to separate identity from policy/credentials, just as it helps to separate identity from address. One of the more curious things to observe is that the world of tcp/ip lower layers has been learning about the need to *separate* the semantic construct of identity from that of location, just as the upper-layered applications world seems to be deciding -- in my opinion, quite erroneously -- to *merge* semantic constructs. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Feb 12 12:16: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 1F8KqH-0008J4-B0; Sun, 12 Feb 2006 12:16:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8KqF-0008Iz-Sp for dix@megatron.ietf.org; Sun, 12 Feb 2006 12: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 MAA01170 for ; Sun, 12 Feb 2006 12:15:10 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8L3g-0008Uh-Pd for dix@ietf.org; Sun, 12 Feb 2006 12:30:50 -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 k1CHGo7W010760; Sun, 12 Feb 2006 09:16:50 -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); Sun, 12 Feb 2006 09:16:49 -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] use of non-ietf work in ietf standards Date: Sun, 12 Feb 2006 09:16:48 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792A396@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] use of non-ietf work in ietf standards Thread-Index: AcYva4/Tc/9cOAMfT8GdogRjSxKVdgAjFBLg From: "Hallam-Baker, Phillip" To: , "Digital Identity Exchange" X-OriginalArrivalTime: 12 Feb 2006 17:16:49.0669 (UTC) FILETIME=[1C1CEB50:01C62FF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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 Eric was making was the pedantic point that the Javascript 'standard' is called ECMAScript and that is what the spec should reference. > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Dave Crocker > Sent: Saturday, February 11, 2006 7:29 PM > To: Digital Identity Exchange > Subject: [dix] use of non-ietf work in ietf standards >=20 >=20 >=20 > > dumb clients but given that Javascript isn't any kind of IETF=20 > > standard--it's hard to see how we could require it in an IETF=20 > > standard. >=20 >=20 > small procedural point: the ietf does it all the time. >=20 > x.400 interoperability specs. IP-over-* specs. Anything using Unicode. >=20 > And so on. >=20 > (The subject line of this message is changed so that no one=20 > confuses this note with a comment on dix or your substantive=20 > review of it.) >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > >=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 Sun Feb 12 20:08: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 1F8SD5-0001SW-GO; Sun, 12 Feb 2006 20:08:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8SD4-0001SR-Am for dix@megatron.ietf.org; Sun, 12 Feb 2006 20:08: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 UAA28951 for ; Sun, 12 Feb 2006 20:07:12 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8SQY-0004Bi-EB for dix@ietf.org; Sun, 12 Feb 2006 20:22:56 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id CE2381E8C1B; Sun, 12 Feb 2006 17:08:46 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> From: Eric Rescorla Date: Sun, 12 Feb 2006 17:08:46 -0800 In-Reply-To: (Johannes Ernst's message of "Sat, 11 Feb 2006 19:34:37 -0800") Message-ID: <86wtg0qd41.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 Johannes Ernst writes: >> Method of ticket validation ... > > Are you basically proposing a variation of OpenID authentication, or > do I misunderstand you? I'm not proposing anything. There are a number of ways to do the kind of ticket verification that a DIX-type system would need. The digest exchange that DIX uses strikes me as one of the least convenient. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Feb 12 20:09: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 1F8SDs-0001Ub-P5; Sun, 12 Feb 2006 20:09:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8SDr-0001UW-KG for dix@megatron.ietf.org; Sun, 12 Feb 2006 20:09: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 UAA28964 for ; Sun, 12 Feb 2006 20:08:01 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8SRN-0004Cb-OS for dix@ietf.org; Sun, 12 Feb 2006 20:23:46 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 722D41E8C1C; Sun, 12 Feb 2006 17:09:38 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] use of non-ietf work in ietf standards References: <198A730C2044DE4A96749D13E167AD3792A396@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: Eric Rescorla Date: Sun, 12 Feb 2006 17:09:38 -0800 In-Reply-To: <198A730C2044DE4A96749D13E167AD3792A396@MOU1WNEXMB04.vcorp.ad.vrsn.com> (Phillip Hallam-Baker's message of "Sun, 12 Feb 2006 09:16:48 -0800") Message-ID: <86pslsqd2l.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dcrocker@bbiw.net X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 Quite so. And Dave is of course right about being able to reference non-IETF standards. A spurious "IETF" snuck into what should be a one IETF sentence there... -Ekr "Hallam-Baker, Phillip" writes: > Eric was making was the pedantic point that the Javascript 'standard' is > called ECMAScript and that is what the spec should reference. > > >> -----Original Message----- >> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On >> Behalf Of Dave Crocker >> Sent: Saturday, February 11, 2006 7:29 PM >> To: Digital Identity Exchange >> Subject: [dix] use of non-ietf work in ietf standards >> >> >> >> > dumb clients but given that Javascript isn't any kind of IETF >> > standard--it's hard to see how we could require it in an IETF >> > standard. >> >> >> small procedural point: the ietf does it all the time. >> >> x.400 interoperability specs. IP-over-* specs. Anything using Unicode. >> >> And so on. >> >> (The subject line of this message is changed so that no one >> confuses this note with a comment on dix or your substantive >> review of it.) >> >> d/ >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> >> >> _______________________________________________ >> 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 Feb 12 20:28: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 1F8SVd-0006CZ-7g; Sun, 12 Feb 2006 20:28:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8SVa-0006CO-SD for dix@megatron.ietf.org; Sun, 12 Feb 2006 20:28: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 UAA29953 for ; Sun, 12 Feb 2006 20:26:21 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Sj3-0004dq-0D for dix@ietf.org; Sun, 12 Feb 2006 20:42: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 k1D1S0M2015908; Sun, 12 Feb 2006 17:28:00 -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); Sun, 12 Feb 2006 17:28:00 -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] Review of draft-merrells-dix-00.txt Date: Sun, 12 Feb 2006 17:27:59 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792A3B0@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Review of draft-merrells-dix-00.txt Thread-Index: AcYwOmviMv2S3qBuSR2n/vBJdP1+fQAAhJAA From: "Hallam-Baker, Phillip" To: "EKR" , "Digital Identity Exchange" X-OriginalArrivalTime: 13 Feb 2006 01:28:00.0344 (UTC) FILETIME=[BA010D80:01C6303C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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 SAML has a ticket format defined (the artifact). I did not take part in that part of the design but it should probably be looked at as it may solve the problems already. =20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of Eric Rescorla > Sent: Sunday, February 12, 2006 8:09 PM > To: Digital Identity Exchange > Subject: Re: [dix] Review of draft-merrells-dix-00.txt >=20 > Johannes Ernst writes: >=20 > >> Method of ticket validation ... > > > > Are you basically proposing a variation of OpenID=20 > authentication, or=20 > > do I misunderstand you? >=20 > I'm not proposing anything. There are a number of ways to do=20 > the kind of ticket verification that a DIX-type system would need.=20 > The digest exchange that DIX uses strikes me as one of the=20 > least convenient. >=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 Mon Feb 13 03: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 1F8ZOi-0007tG-1Z; Mon, 13 Feb 2006 03: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 1F8ZOh-0007t6-1E for dix@megatron.ietf.org; Mon, 13 Feb 2006 03: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 DAA26270 for ; Mon, 13 Feb 2006 03:47:42 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8ZcF-0007ru-41 for dix@ietf.org; Mon, 13 Feb 2006 04:03:29 -0500 Received: from [192.168.0.2] (adsl-71-131-42-237.dsl.sntc01.pacbell.net [71.131.42.237]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1D8nlsr031094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2006 00:49:48 -0800 Message-ID: <43F04804.9020407@dcrocker.net> Date: Mon, 13 Feb 2006 00:49:08 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: EKR Subject: Re: [dix] use of non-ietf work in ietf standards References: <198A730C2044DE4A96749D13E167AD3792A396@MOU1WNEXMB04.vcorp.ad.vrsn.com> <86pslsqd2l.fsf@raman.networkresonance.com> In-Reply-To: <86pslsqd2l.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, 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 Eric Rescorla wrote: > Quite so. And Dave is of course right about being able to reference > non-IETF standards. A spurious "IETF" snuck into what should be > a one IETF sentence there... ahh. i see your point. it can, indeed, be a bit challenging to create a stable standards specification, when it includes an unstable -- or nonexistent -- component specification. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:00: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 1F8i01-0001ES-ER; Mon, 13 Feb 2006 13:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8i00-0001EN-01 for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:00: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 MAA11494 for ; Mon, 13 Feb 2006 12:58: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 1F8iDa-0000XY-OP for dix@ietf.org; Mon, 13 Feb 2006 13:14:39 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DI0M9U056344 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:00:25 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792A396@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792A396@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C12659C-0565-4747-8B37-4BE90CBE2446@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] use of non-ietf work in ietf standards Date: Mon, 13 Feb 2006 10:00: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.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 12-Feb-06, at 9:16 AM, Hallam-Baker, Phillip wrote: > Eric was making was the pedantic point that the Javascript > 'standard' is > called ECMAScript and that is what the spec should reference. Thanks. I've reflected this into the draft... which I'll republish just before the BOF. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:05: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 1F8i4i-0002b9-ST; Mon, 13 Feb 2006 13:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8i4g-0002Vs-JX for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:05: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 NAA11763 for ; Mon, 13 Feb 2006 13:03: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 1F8iIL-0000gB-HK for dix@ietf.org; Mon, 13 Feb 2006 13:19:29 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DI5KMu056532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:05:20 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:05: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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > Use of Javascript > Section 5.10.2.1 reads: > > The Membersite sends a fetch-request message to the Homesite > through > the User's client via a redirected HTTP POST to their Homesite > Endpoint URL using JavaScript to autosubmit the form. > > I appreciate the rationale for this: you want things to work with > dumb clients but given that Javascript isn't any kind of IETF > standard--it's hard to see how we could require it in an IETF > standard. ECMASCript, perhaps. Even then, specifying this kind > of implementation detail is the kind of thing that IETF typically > stays out of. I appreciate that this is also a wire protocol issue, > but given that there's no specification of the exact JavaScript > incantation, it's not clear it makes sense to specify only > the language. I've changed the wording so that auto submission is a 'should', and that using ECMAScript is a 'could'. Thanks John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:08: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 1F8i7J-0003Yj-4d; Mon, 13 Feb 2006 13:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8i7H-0003Yb-Rp for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:08: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 NAA11885 for ; Mon, 13 Feb 2006 13:06:18 -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 1F8iKr-0000kK-I5 for dix@ietf.org; Mon, 13 Feb 2006 13:22:11 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DI7r95056656 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:07:55 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9014BBBB-8019-4C0C-A34F-30ABD8784C8F@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:07: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: 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 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > The idea behind DIX is to have a third-party authentication system > where a user can have a preexisting relationship with a third party > that then vouches for its identity to the system site/server that it > actually wants to communicate with. Yes, but there's more. We're also moving properties from one party to the other, where the property could be self or third party asserted. John > This is, of course, a pretty > common desire and there are already a lot of systems that do > it (Kerberos, PKI, etc.). The particular scheme described in > this draft is based on Web forms, Javascript, and redirection. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13: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 1F8i9Q-00041t-AY; Mon, 13 Feb 2006 13:10:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8i8n-0003wo-Mc for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:09: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 NAA11981 for ; Mon, 13 Feb 2006 13:07: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 1F8iMR-0000nQ-LK for dix@ietf.org; Mon, 13 Feb 2006 13:23:45 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DI9XFb056722 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:09:35 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B4CB733-268B-420F-888C-DC5C4C9282F2@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:09:36 -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 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > SUMMARY OF THE DIX SCHEME > Here's my reconstruction of how the DIX scheme works from the > document (which, unfortunately, does not contain a helpful > summary or diagram) Agreed. I'll reflect your sequence diagram into the draft, and will provide informational references to our engineering documents, which include pretty pictures. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:17: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 1F8iGW-0007E9-8S; Mon, 13 Feb 2006 13:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iGU-0007Cc-7b for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:17: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 NAA12451 for ; Mon, 13 Feb 2006 13:15: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 1F8iU4-00011z-UT for dix@ietf.org; Mon, 13 Feb 2006 13:31:41 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DIHRpB056967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:17:27 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:17:29 -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: 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 On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > When the user contacts the Membersite (1), it responds with a web > page prompting the user to enter the URL of its Homesite (2). The > user then enters the Homesite URL (3). Actually, we call it the Homesite Path. The user provides it, so it may not be a well-formed URL, so we say Path and encourage the Membersite to turn it into a URL. eg. yahoo.com -> http://yahoo.com/ > The Membersite contacts the > Homesite (4,5) to determine whether the Homesite can provide the > appropriate kind of authentication. Capability, rather than authentication. Yes, a capability could be a means of authentication. ie. MS wants a HS that can perform authentication with a Foo-Bar-Baz 2-factor device. > If it can, the Membersite > sends the client a redirect (6) (using Javascript) to the > Homesite. In some way that's not entirely clear True. > the Homesite > validates the request and returns a ticket to the Client (8) > The Client then (via Javascript?) sends the ticket to the > the Membersite (9). The Membersite contacts the Homesite with > a digest of the ticket in order to confirm its validity (10) > If the Homesite says its OK (11), the Membersite returns OK > to the Client (12) Not sure it's a Ticket, but... the HS sends a message digest and a signature that is a digest of the message digest and a HS secret... if that's a ticket then yes. The MS sends both the digest and the signature to the HS for verification . John > > > Client Membersite Homesite > > 1 Hello --------------------------> > 2 <------- Enter homesite URL > 3 Homesite URL -------------------> > 4 Get capabilities ----------> > 5 <------------- Capabilities > 6 <------ Redirect to Homesite > 7 Get Ticket--------------------------------------------------> > 8 <----------------------------------------------------- Ticket > 9 Ticket -------------------------> > 10 Verify ticket --------------> > 11 <----------------------- Ticket OK > 12 <------------------------ OK _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:24: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 1F8iNI-0000pH-Fn; Mon, 13 Feb 2006 13:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iNG-0000nm-Rz for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:24: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 NAA12916 for ; Mon, 13 Feb 2006 13:22:49 -0500 (EST) Received: from smtp108.sbc.mail.mud.yahoo.com ([68.142.198.207]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8iaq-0001GA-Nm for dix@ietf.org; Mon, 13 Feb 2006 13:38:42 -0500 Received: (qmail 13596 invoked from network); 13 Feb 2006 18:24:20 -0000 Received: from unknown (HELO elijah.joaquin.net) (jm-acm.no@sbcglobal.net@63.200.55.210 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 13 Feb 2006 18:24:19 -0000 Message-Id: <6.2.3.4.0.20060213094958.036f81d0@pop.netmesh.us> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 13 Feb 2006 10:05:01 -0800 To: Digital Identity Exchange From: Joaquin Miller In-Reply-To: <86wtg0qd41.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <86wtg0qd41.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [dix] protocols and names 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 >The digest exchange that DIX uses strikes me as one of the least convenient. Since it is ok for a contribution to this list to be open to the accusation of being pedantic: Is there a digest exchange that DIX uses? Or is it only that there is a digest exchange that an individual submission Internet Draft that describes one such implementation uses? If the latter, is there a convenient name for the protocol(s) described in that individual submission draft? Cordially, Joaquin _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:31: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 1F8iTo-0001fL-KX; Mon, 13 Feb 2006 13:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iTm-0001eY-JY for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:31: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 NAA13208 for ; Mon, 13 Feb 2006 13:29:32 -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 1F8ihN-0001QB-3R for dix@ietf.org; Mon, 13 Feb 2006 13:45:25 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DIVAgP057713 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:31:11 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:31: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: 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 On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > Method of ticket validation > This draft validates the ticket by having the Membersite send a digest > to the Homesite and get an ACK. It's not clear why this is desirable. > Wouldn't it be simpler to have the Homesite digitally sign the ticket > (the key could be delivered in the initial capabilities discovery > phase) and then let the Membersite do the verification directly? > I appreciate that there's a freshness concern, but this can > be alleviated using the usual nonce-based anti-replay techniques. The motivation wasn't freshness. The dix:/message-id parameter is a nonce that takes care of this. The motivation was to get all the binary crypto code out of the MS to ease adoption. We learnt from our prior experience with the SXIP protocol that this was a barrier to adoption. Writing good DSIG code for all platforms/stacks/languages is tedious and expensive and worse increases the number of lines of code that a MS developer has to write to enable a site. [SXIP 1.0 worked this way.] Note that using dmd0 (*) as a layer a capability could be defined that provided this improved signature handling alternative. John dmd0= draft-merrells-dix-00.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:34: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 1F8iWR-0003DX-8y; Mon, 13 Feb 2006 13:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iWQ-0003CX-9C for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:34: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 NAA13504 for ; Mon, 13 Feb 2006 13:32: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 1F8ik4-0001YA-Bq for dix@ietf.org; Mon, 13 Feb 2006 13:48:09 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DIX2xr057810 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:33:59 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0DC4DA78-9F20-4761-9700-2226A52C65F1@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:34:01 -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 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > A suggested implementation of a signature function would be to use > the SHA1 algorithm, which takes as input a digest of the message and > a secret known only to the Homesite. > > Signature = T ( S + Digest ) > > Where, Digest is message digest (defined above), S is the Homesite > Secret, T is the signature generation function, and '+' means string > concatentation. > > The technical term for a "signature" which can only be verified by > the holder of a symmetric secret is Message Authentication Code (MAC) > and there's a standard technique for performing MACs: HMAC (RFC 2104). We looked at that... but decided what we were doing was different in some way. I'll dig out my notes. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:35: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 1F8iXT-0003dq-KR; Mon, 13 Feb 2006 13:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iXR-0003d3-PE for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:35: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 NAA13562 for ; Mon, 13 Feb 2006 13:33: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 1F8il5-0001Zj-Ua for dix@ietf.org; Mon, 13 Feb 2006 13:49:13 -0500 Received: from [192.168.1.101] (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 k1DIZ2gb057945 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:35:03 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@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] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:35: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.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 13-Feb-06, at 10:31 AM, John Merrells wrote: > > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > >> Method of ticket validation >> This draft validates the ticket by having the Membersite send a >> digest >> to the Homesite and get an ACK. It's not clear why this is desirable. >> Wouldn't it be simpler to have the Homesite digitally sign the ticket >> (the key could be delivered in the initial capabilities discovery >> phase) and then let the Membersite do the verification directly? >> I appreciate that there's a freshness concern, but this can >> be alleviated using the usual nonce-based anti-replay techniques. > > The motivation wasn't freshness. The dix:/message-id parameter > is a nonce that takes care of this. > > The motivation was to get all the binary crypto code out of the MS to > ease adoption. We learnt from our prior experience with the SXIP > protocol that this was a barrier to adoption. Writing good DSIG code > for all platforms/stacks/languages is tedious and expensive and worse > increases the number of lines of code that a MS developer has to > write to enable a site. [SXIP 1.0 worked this way.] Just to clarify, getting someone to install or dynamic language script or module is *way* easier then installing a binary. XML DSIG libraries are not widely available at this time for the scripting platforms. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:36: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 1F8iZ2-0004By-J4; Mon, 13 Feb 2006 13:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iZ0-0004Bd-K4 for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:36: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 NAA13714 for ; Mon, 13 Feb 2006 13:34:56 -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 1F8imb-0001dY-EP for dix@ietf.org; Mon, 13 Feb 2006 13:50:50 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DIaZmM058023 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:36:36 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <6.2.3.4.0.20060213094958.036f81d0@pop.netmesh.us> References: <20060211231709.1B227B811@delta.rtfm.com> <86wtg0qd41.fsf@raman.networkresonance.com> <6.2.3.4.0.20060213094958.036f81d0@pop.netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13577999-0E63-4F7F-B708-051813533F19@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] protocols and names Date: Mon, 13 Feb 2006 10:36:38 -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 13-Feb-06, at 10:05 AM, Joaquin Miller wrote: > >> The digest exchange that DIX uses strikes me as one of the least >> convenient. > > Since it is ok for a contribution to this list to be open to the > accusation of being pedantic: > > > Is there a digest exchange that DIX uses? > > Or is it only that there is a digest exchange that an individual > submission Internet Draft that describes one such implementation uses? Yes. > If the latter, is there a convenient name for the protocol(s) > described in that individual submission draft? It's called draft-merrells-dix-00.txt, or for shorthand I call it dmd0. (Note that pre publication I called it dmd1, because I'd forgotten they are numbered from zero... silly me.) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:42: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 1F8ieY-0006CY-1g; Mon, 13 Feb 2006 13:42:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ieX-0006CP-6O for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:42: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 NAA14124 for ; Mon, 13 Feb 2006 13:40:39 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8isB-0001p7-GJ for dix@ietf.org; Mon, 13 Feb 2006 13:56:32 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 871FB1E8C1C; Mon, 13 Feb 2006 10:42:14 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 10:42:14 -0800 In-Reply-To: (John Merrells's message of "Mon, 13 Feb 2006 10:17:29 -0800") Message-ID: <86k6bzqewp.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > >> When the user contacts the Membersite (1), it responds with a web >> page prompting the user to enter the URL of its Homesite (2). The >> user then enters the Homesite URL (3). > > Actually, we call it the Homesite Path. The user provides it, so it may > not be a well-formed URL, so we say Path and encourage the > Membersite to turn it into a URL. eg. yahoo.com -> http://yahoo.com/ > >> The Membersite contacts the >> Homesite (4,5) to determine whether the Homesite can provide the >> appropriate kind of authentication. > > Capability, rather than authentication. Yes, a capability could be > a means of authentication. ie. MS wants a HS that can perform > authentication with a Foo-Bar-Baz 2-factor device. Uh, Capability has a pretty well understood meaning in information security, and it doesn't seem to me that that matches what you're doing here. I would advise finding a new name. >> If it can, the Membersite >> sends the client a redirect (6) (using Javascript) to the >> Homesite. In some way that's not entirely clear > > True. > >> the Homesite >> validates the request and returns a ticket to the Client (8) >> The Client then (via Javascript?) sends the ticket to the >> the Membersite (9). The Membersite contacts the Homesite with >> a digest of the ticket in order to confirm its validity (10) >> If the Homesite says its OK (11), the Membersite returns OK >> to the Client (12) > > Not sure it's a Ticket, but... the HS sends a message digest > and a signature that is a digest of the message digest and > a HS secret... if that's a ticket then yes. > > The MS sends both the digest and the signature to the HS > for verification . Well, we're running a bit short on names (credential, ticket, token, certificate, cookie, etc. being all taken) so I just picked the one I thought was closest on the theory that the term you were using "message" wasn't that evocative. The bottom line here is that the Homesite sends the Membersite a message through the client that vouches for the authentication/ properties/whatever of the client/user. Ticket seems like as good a name as anything for that. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:46: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 1F8iiM-0007EK-4c; Mon, 13 Feb 2006 13:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iiK-0007Cc-P1 for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:46: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 NAA14411 for ; Mon, 13 Feb 2006 13:44:34 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8ivw-0001wK-2u for dix@ietf.org; Mon, 13 Feb 2006 14:00:28 -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 k1DIkF0D018236 for ; Mon, 13 Feb 2006 10:46:15 -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); Mon, 13 Feb 2006 10:46:15 -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] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:46:14 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792A425@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dix] Review of draft-merrells-dix-00.txt Thread-Index: AcYwzBJOilRuQThBRVWHzCMjIsh3rgAAWaWw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 13 Feb 2006 18:46:15.0074 (UTC) FILETIME=[C48E8020:01C630CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 We should look at HTTP Digest as well. HTTP Digest is an existing standard used for password authentication. It was designed before the current level of understanding of MAC function construction from a Digest. That said though the amount of data involved means that the difference between the Digest scheme and HMAC is not significant. =20 > -----Original Message----- > From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On=20 > Behalf Of John Merrells > Sent: Monday, February 13, 2006 1:34 PM > To: Digital Identity Exchange > Subject: Re: [dix] Review of draft-merrells-dix-00.txt >=20 >=20 > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: >=20 > > A suggested implementation of a signature function=20 > would be to use > > the SHA1 algorithm, which takes as input a digest of=20 > the message and > > a secret known only to the Homesite. > > > > Signature =3D T ( S + Digest ) > > > > Where, Digest is message digest (defined above), S is=20 > the Homesite > > Secret, T is the signature generation function, and '+'=20 > means string > > concatentation. > > > > The technical term for a "signature" which can only be=20 > verified by the=20 > > holder of a symmetric secret is Message Authentication Code=20 > (MAC) and=20 > > there's a standard technique for performing MACs: HMAC (RFC 2104). >=20 > We looked at that... but decided what we were doing was=20 > different in some way. I'll dig out my notes. >=20 > John >=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 Mon Feb 13 13:51:52 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 1F8ing-0000yr-6J; Mon, 13 Feb 2006 13:51:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8inf-0000ye-62 for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:51: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 NAA14754 for ; Mon, 13 Feb 2006 13:50:05 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8j1K-00025z-HR for dix@ietf.org; Mon, 13 Feb 2006 14:05:58 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id E8F431E8C1B; Mon, 13 Feb 2006 10:51:41 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 10:51:41 -0800 In-Reply-To: <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> (John Merrells's message of "Mon, 13 Feb 2006 10:31:12 -0800") Message-ID: <86ek27qegy.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > >> Method of ticket validation >> This draft validates the ticket by having the Membersite send a digest >> to the Homesite and get an ACK. It's not clear why this is desirable. >> Wouldn't it be simpler to have the Homesite digitally sign the ticket >> (the key could be delivered in the initial capabilities discovery >> phase) and then let the Membersite do the verification directly? >> I appreciate that there's a freshness concern, but this can >> be alleviated using the usual nonce-based anti-replay techniques. > > The motivation wasn't freshness. The dix:/message-id parameter > is a nonce that takes care of this. > > The motivation was to get all the binary crypto code out of the MS to > ease adoption. We learnt from our prior experience with the SXIP > protocol that this was a barrier to adoption. Writing good DSIG code > for all platforms/stacks/languages is tedious and expensive and worse > increases the number of lines of code that a MS developer has to > write to enable a site. [SXIP 1.0 worked this way.] What do you mean "binary crypto code"? You've got a hash algorithm, no? At worst, you could share a pairwise secret between the MS and the HS during the initial discovery phase and use that to key a MAC. (This is of course only safe if you're doing that exchange over SSL/TLS, but that's true of your scheme too...) Anyway, I don't really find this that convincing. Java certainly comes with built-in public key functionality and there are modules for Python, Perl and PHP (it's actually a compilation flag for PHP). Yes, it's not zero effort, but it's not exactly prohibitive either. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:52: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 1F8ioC-0001Hn-8j; Mon, 13 Feb 2006 13:52:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ioB-0001H5-AZ for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:52: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 NAA14802 for ; Mon, 13 Feb 2006 13:50:37 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8j1p-000276-Ox for dix@ietf.org; Mon, 13 Feb 2006 14:06:31 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 3A8231E8C1E; Mon, 13 Feb 2006 10:52:13 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 10:52:12 -0800 In-Reply-To: (Dick Hardt's message of "Mon, 13 Feb 2006 10:35:03 -0800") Message-ID: <86accvqeg3.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 13-Feb-06, at 10:31 AM, John Merrells wrote: > >> >> On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: >> >>> Method of ticket validation >>> This draft validates the ticket by having the Membersite send a >>> digest >>> to the Homesite and get an ACK. It's not clear why this is desirable. >>> Wouldn't it be simpler to have the Homesite digitally sign the ticket >>> (the key could be delivered in the initial capabilities discovery >>> phase) and then let the Membersite do the verification directly? >>> I appreciate that there's a freshness concern, but this can >>> be alleviated using the usual nonce-based anti-replay techniques. >> >> The motivation wasn't freshness. The dix:/message-id parameter >> is a nonce that takes care of this. >> >> The motivation was to get all the binary crypto code out of the MS to >> ease adoption. We learnt from our prior experience with the SXIP >> protocol that this was a barrier to adoption. Writing good DSIG code >> for all platforms/stacks/languages is tedious and expensive and worse >> increases the number of lines of code that a MS developer has to >> write to enable a site. [SXIP 1.0 worked this way.] > > Just to clarify, getting someone to install or dynamic language > script or module is *way* easier then installing a binary. > > XML DSIG libraries are not widely available at this time for the > scripting platforms. Who said anything about XML DSIG? I just said you could use a digital signature, which doesn't require XML at all. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:56: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 1F8irs-0002eI-OS; Mon, 13 Feb 2006 13:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8irr-0002cY-VX for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:56: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 NAA15053 for ; Mon, 13 Feb 2006 13:54: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 1F8j5T-0002EW-2B for dix@ietf.org; Mon, 13 Feb 2006 14:10:19 -0500 Received: from [192.168.1.101] (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 k1DIu4nd058906 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:56:05 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <245BCC54-0096-4455-AA9B-C1188837C2E8@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:56: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.0 (/) 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 On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > Client Membersite Homesite > > 1 Hello --------------------------> > 2 <------- Enter homesite URL > 3 Homesite URL -------------------> > 4 Get capabilities ----------> > 5 <------------- Capabilities > 6 <------ Redirect to Homesite > 7 Get Ticket--------------------------------------------------> > 8 <----------------------------------------------------- Ticket > 9 Ticket -------------------------> > 10 Verify ticket --------------> > 11 <----------------------- Ticket OK > 12 <------------------------ OK > > > There's one more detail that I haven't mentioned: in order to > enable automatic submission of the abovementioned form (2,3), > this document specifies a particular form for the page > (i.e., particular names for form input fields) so that > clients can detect it and auto-fill-in. This also allows an enhanced browser to detect the request and rewrite the action for the page and process the request directly. This could include the enhanced browser acting as the Homesite. We have a prototype of this running now. It is pretty easy to do the protocol stuff. The data management is a little more work. :) -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 13:58: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 1F8iuK-0003iO-HM; Mon, 13 Feb 2006 13:58:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iuI-0003iE-Uo for dix@megatron.ietf.org; Mon, 13 Feb 2006 13:58: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 NAA15219 for ; Mon, 13 Feb 2006 13:56:56 -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 1F8j7w-0002JI-Qx for dix@ietf.org; Mon, 13 Feb 2006 14:12:50 -0500 Received: from [192.168.1.101] (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 k1DIwdvm059039 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 10:58:39 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06D2D47F-7F9B-4709-B329-992879C241AD@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 10:58: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.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 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > Relationship To Existing Work > There has been a very large amount of work in delegated/federated > authentication systems, ranging from RADIUS/DIAMETER to > Shibboleth, Liberty, and SAML. It's not clear from this document or > from > the charter why something new is needed here. So, I think the > first order of business to establish what properties are required > here that present systems don't provide. We define identity very broadly. There is much more to a person then being able to authenticate. In discussions with many web sites, it is much more interesting to get properties about the user then to enable SSO. Agree that the charter does not answer this question well. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:02:46 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 1F8iyE-000550-Eg; Mon, 13 Feb 2006 14:02:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iyD-00054v-GK for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:02: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 OAA15441 for ; Mon, 13 Feb 2006 14:00:59 -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 1F8jBo-0002Pz-LQ for dix@ietf.org; Mon, 13 Feb 2006 14:16:53 -0500 Received: from [192.168.1.101] (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 k1DJ2cxD059330 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 11:02:39 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <495782F7-19CB-4BF7-B2B1-A2DBD580A695@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:02:38 -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 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > Use of Javascript > Section 5.10.2.1 reads: > > The Membersite sends a fetch-request message to the Homesite > through > the User's client via a redirected HTTP POST to their Homesite > Endpoint URL using JavaScript to autosubmit the form. > > I appreciate the rationale for this: you want things to work with > dumb clients but given that Javascript isn't any kind of IETF > standard--it's hard to see how we could require it in an IETF > standard. ECMASCript, perhaps. Even then, specifying this kind > of implementation detail is the kind of thing that IETF typically > stays out of. I appreciate that this is also a wire protocol issue, > but given that there's no specification of the exact JavaScript > incantation, it's not clear it makes sense to specify only > the language. The protocol works without the ECMAScript, the user would need to click another button to continue on with the exchange. The ECMAScript provides a more seamless use experience since a POST cannot be redirected, and we did not want to limit the data to what could sit on a URL, as well, did not want the data to have to be exposed by being on a URL. As noted in another email, an enhanced browser does not need to the ECMAScript. We see this as a boot strap method. wrt. how it is positioned in the ID, I agree it is an implementation detail. How would you suggest that implementation hints like this are communicated? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:04: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 1F8izc-0005K1-II; Mon, 13 Feb 2006 14:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8izb-0005Jw-BV for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:04: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 OAA15499 for ; Mon, 13 Feb 2006 14:02: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 1F8jDG-0002Rn-QP for dix@ietf.org; Mon, 13 Feb 2006 14:18:19 -0500 Received: from [192.168.1.101] (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 k1DJ49Rk059354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2006 11:04:09 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060211231709.1B227B811@delta.rtfm.com> References: <20060211231709.1B227B811@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:04: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.0 (/) 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 On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > > Method of ticket validation > This draft validates the ticket by having the Membersite send a digest > to the Homesite and get an ACK. It's not clear why this is desirable. > Wouldn't it be simpler to have the Homesite digitally sign the ticket > (the key could be delivered in the initial capabilities discovery > phase) and then let the Membersite do the verification directly? > I appreciate that there's a freshness concern, but this can > be alleviated using the usual nonce-based anti-replay techniques. > > A suggested implementation of a signature function would be to use > the SHA1 algorithm, which takes as input a digest of the message and > a secret known only to the Homesite. > > Signature = T ( S + Digest ) > > Where, Digest is message digest (defined above), S is the Homesite > Secret, T is the signature generation function, and '+' means string > concatentation. > > The technical term for a "signature" which can only be verified by > the holder of a symmetric secret is Message Authentication Code (MAC) > and there's a standard technique for performing MACs: HMAC (RFC 2104). Our current implementation uses HMAC. Since the Homesite can use whatever it wants, we left it out of the spec. You call the message a "ticket" -- perhaps you can elaborate on that? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:06: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 1F8j1g-0005gW-Ng; Mon, 13 Feb 2006 14:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8j1g-0005fu-3l for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:06: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 OAA15642 for ; Mon, 13 Feb 2006 14:04: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 1F8jFK-0002VF-IV for dix@ietf.org; Mon, 13 Feb 2006 14:20:28 -0500 Received: from [192.168.1.101] (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 k1DJ6FvP059583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:06:16 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <86accvqeg3.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86accvqeg3.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4DD25199-48D0-4187-B426-5F436871A3B5@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:06:15 -0800 To: EKR , 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: 93238566e09e6e262849b4f805833007 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 13-Feb-06, at 10:52 AM, Eric Rescorla wrote: >>> The motivation was to get all the binary crypto code out of the >>> MS to >>> ease adoption. We learnt from our prior experience with the SXIP >>> protocol that this was a barrier to adoption. Writing good DSIG code >>> for all platforms/stacks/languages is tedious and expensive and >>> worse >>> increases the number of lines of code that a MS developer has to >>> write to enable a site. [SXIP 1.0 worked this way.] >> >> Just to clarify, getting someone to install or dynamic language >> script or module is *way* easier then installing a binary. >> >> XML DSIG libraries are not widely available at this time for the >> scripting platforms. > > Who said anything about XML DSIG? I just said you could use a digital > signature, which doesn't require XML at all. A digital signature of what though? And there is key management etc. Would seem challenging to convince anyone to NOT be using XML DSIG for signing an XML message these days. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:08: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 1F8j3K-000600-Os; Mon, 13 Feb 2006 14:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8j3K-0005zv-3n for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:08: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 OAA15791 for ; Mon, 13 Feb 2006 14:06:15 -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 1F8jGv-0002YB-Cv for dix@ietf.org; Mon, 13 Feb 2006 14:22:09 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DJ7t9I059829 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:07:55 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <86accvqeg3.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86accvqeg3.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03B24E83-2409-4662-9298-2F4B8E6AB33D@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:07:53 -0800 To: EKR , 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: 08170828343bcf1325e4a0fb4584481c 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 13-Feb-06, at 10:52 AM, Eric Rescorla wrote: >> XML DSIG libraries are not widely available at this time for the >> scripting platforms. > > Who said anything about XML DSIG? I just said you could use a digital > signature, which doesn't require XML at all. Sorry, yes, was thinking of our SXIP 1.0 architecture, and signing of property values, rather than generic digital signatures for message verification. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:08: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 1F8j41-0006GT-O8; Mon, 13 Feb 2006 14:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8j3z-0006GG-VE for dix@megatron.ietf.org; Mon, 13 Feb 2006 14: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 OAA15877 for ; Mon, 13 Feb 2006 14:06:57 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8jHe-0002Z6-Hb for dix@ietf.org; Mon, 13 Feb 2006 14:22:51 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BEF0A1E8C1B; Mon, 13 Feb 2006 11:08:33 -0800 (PST) To: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86accvqeg3.fsf@raman.networkresonance.com> <4DD25199-48D0-4187-B426-5F436871A3B5@sxip.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 11:08:33 -0800 In-Reply-To: <4DD25199-48D0-4187-B426-5F436871A3B5@sxip.com> (Dick Hardt's message of "Mon, 13 Feb 2006 11:06:15 -0800") Message-ID: <8664njqdou.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 13-Feb-06, at 10:52 AM, Eric Rescorla wrote: > >>>> The motivation was to get all the binary crypto code out of the >>>> MS to >>>> ease adoption. We learnt from our prior experience with the SXIP >>>> protocol that this was a barrier to adoption. Writing good DSIG code >>>> for all platforms/stacks/languages is tedious and expensive and >>>> worse >>>> increases the number of lines of code that a MS developer has to >>>> write to enable a site. [SXIP 1.0 worked this way.] >>> >>> Just to clarify, getting someone to install or dynamic language >>> script or module is *way* easier then installing a binary. >>> >>> XML DSIG libraries are not widely available at this time for the >>> scripting platforms. >> >> Who said anything about XML DSIG? I just said you could use a digital >> signature, which doesn't require XML at all. > > A digital signature of what though? Whatever information you're digesting now. > And there is key management etc. What key management? Just hand over the key during the capabilities exchange. > Would seem challenging to convince anyone to NOT be using XML DSIG > for signing an XML message these days. If you say so. You seem perfectly happy to digest a bunch of data without using any special XML pixie dust. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:09: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 1F8j4l-0006Ru-2d; Mon, 13 Feb 2006 14:09:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8j4j-0006Rp-Mk for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:09: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 OAA15969 for ; Mon, 13 Feb 2006 14:07:43 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8jIP-0002aZ-9x for dix@ietf.org; Mon, 13 Feb 2006 14:23:37 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 9DDC61E8C1C; Mon, 13 Feb 2006 11:09:20 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 11:09:20 -0800 In-Reply-To: (Dick Hardt's message of "Mon, 13 Feb 2006 11:04:09 -0800") Message-ID: <861wy7qdnj.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > >> >> Method of ticket validation >> This draft validates the ticket by having the Membersite send a digest >> to the Homesite and get an ACK. It's not clear why this is desirable. >> Wouldn't it be simpler to have the Homesite digitally sign the ticket >> (the key could be delivered in the initial capabilities discovery >> phase) and then let the Membersite do the verification directly? >> I appreciate that there's a freshness concern, but this can >> be alleviated using the usual nonce-based anti-replay techniques. >> >> A suggested implementation of a signature function would be to use >> the SHA1 algorithm, which takes as input a digest of the message and >> a secret known only to the Homesite. >> >> Signature = T ( S + Digest ) >> >> Where, Digest is message digest (defined above), S is the Homesite >> Secret, T is the signature generation function, and '+' means string >> concatentation. >> >> The technical term for a "signature" which can only be verified by >> the holder of a symmetric secret is Message Authentication Code (MAC) >> and there's a standard technique for performing MACs: HMAC (RFC 2104). > > Our current implementation uses HMAC. Since the Homesite can use > whatever it wants, we left it out of the spec. Well, that's fine, but you shouldn't be recommending a technique which is known to be inferior to HMAC. > You call the message a "ticket" -- perhaps you can elaborate on that? See my response to John. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:10: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 1F8j5u-0006a8-JN; Mon, 13 Feb 2006 14:10:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8j5t-0006a3-IM for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:10: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 OAA16036 for ; Mon, 13 Feb 2006 14:08: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 1F8jJW-0002c1-3O for dix@ietf.org; Mon, 13 Feb 2006 14:24:49 -0500 Received: from [192.168.1.101] (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 k1DJAa2i060028 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:10:36 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <86ek27qegy.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86ek27qegy.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0964F809-2B40-4988-9CF1-A0DBE457D982@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:10:36 -0800 To: EKR , 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 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 13-Feb-06, at 10:51 AM, Eric Rescorla wrote: > > What do you mean "binary crypto code"? You've got a hash algorithm, > no? At worst, you could share a pairwise secret between the MS and > the HS during the initial discovery phase and use that to key > a MAC. (This is of course only safe if you're doing that exchange > over SSL/TLS, but that's true of your scheme too...) > > Anyway, I don't really find this that convincing. Java certainly > comes with built-in public key functionality and there are modules > for Python, Perl and PHP (it's actually a compilation flag for PHP). > Yes, it's not zero effort, but it's not exactly prohibitive either. Yes, hash algorithms are widely available on the platforms. (but even SHA-1 is not everywhere) Public Key algorithms are not widely available on the dynamic language platforms. Easy for Perl, Python, PHP and Ruby developers in addition to Java and .Net developers was a core goal of DIX. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14: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 1F8j7w-00076k-9X; Mon, 13 Feb 2006 14: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 1F8j7u-00073i-8y for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:12: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 OAA16159 for ; Mon, 13 Feb 2006 14:11:00 -0500 (EST) Received: from imo-m23.mx.aol.com ([64.12.137.4] helo=imo-m23.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8jLY-0002fD-Sw for dix@ietf.org; Mon, 13 Feb 2006 14:26:54 -0500 Received: from THayes0993@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.3.) id l.292.5992bb0 (15886) for ; Mon, 13 Feb 2006 14:12:33 -0500 (EST) Received: from MBLK-M29 (mblk-m29.mblk.aol.com [64.12.136.73]) by air-id08.mx.aol.com (vx) with ESMTP id MAILINID81-3e0e43f0da2135f; Mon, 13 Feb 2006 14:12:33 -0500 Date: Mon, 13 Feb 2006 14:12:33 -0500 Message-Id: <8C7FEE89399BB73-D78-435@MBLK-M29.sysops.aol.com> From: thayes0993@aol.com References: <20060211231709.1B227B811@delta.rtfm.com> <495782F7-19CB-4BF7-B2B1-A2DBD580A695@sxip.com> Received: from 10.169.155.114 by MBLK-M29.sysops.aol.com (64.12.136.73) with HTTP (WebMailUI); Mon, 13 Feb 2006 14:12:33 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <495782F7-19CB-4BF7-B2B1-A2DBD580A695@sxip.com> X-Mailer: AOL WebMail 15106 Subject: Re: [dix] Review of draft-merrells-dix-00.txt MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 64.12.136.73 X-Spam-Flag: NO X-Spam-Score: 2.1 (++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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="===============1657074597==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --===============1657074597== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C7FEE8939031E7_D78_3F9_MBLK-M29.sysops.aol.com" ----------MailBlocks_8C7FEE8939031E7_D78_3F9_MBLK-M29.sysops.aol.com Content-Type: text/plain; charset="us-ascii" I would suggest a clearly labeled non-normative section, probably toward the end of the document. Terry -----Original Message----- From: Dick Hardt To: Digital Identity Exchange Sent: Mon, 13 Feb 2006 11:02:38 -0800 Subject: Re: [dix] Review of draft-merrells-dix-00.txt wrt. how it is positioned in the ID, I agree it is an implementation detail. How would you suggest that implementation hints like this are communicated? ----------MailBlocks_8C7FEE8939031E7_D78_3F9_MBLK-M29.sysops.aol.com Content-Type: text/html; charset="us-ascii"
I would suggest a clearly labeled non-normative section, probably toward the end of the document.
 
Terry 
 
-----Original Message-----
From: Dick Hardt <dick@sxip.com>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Mon, 13 Feb 2006 11:02:38 -0800
Subject: Re: [dix] Review of draft-merrells-dix-00.txt
wrt. how it is positioned in the ID, I agree it is an implementation detail. How would you suggest that implementation hints like this are communicated? 
 
----------MailBlocks_8C7FEE8939031E7_D78_3F9_MBLK-M29.sysops.aol.com-- --===============1657074597== 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 --===============1657074597==-- From dix-bounces@ietf.org Mon Feb 13 14:15: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 1F8jAY-0007g5-V2; Mon, 13 Feb 2006 14:15:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jAX-0007fs-8J for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:15: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 OAA16421 for ; Mon, 13 Feb 2006 14:13:42 -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 1F8jO8-0002k0-Ct for dix@ietf.org; Mon, 13 Feb 2006 14:29:36 -0500 Received: from [192.168.1.101] (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 k1DJFMMO060678 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:15:22 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <8664njqdou.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86accvqeg3.fsf@raman.networkresonance.com> <4DD25199-48D0-4187-B426-5F436871A3B5@sxip.com> <8664njqdou.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A0E6873-0873-4C1B-9E99-7C63E5D97011@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:15:19 -0800 To: EKR 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: Digital Identity Exchange 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 13-Feb-06, at 11:08 AM, Eric Rescorla wrote: > Dick Hardt writes: > >> On 13-Feb-06, at 10:52 AM, Eric Rescorla wrote: >> >>>>> The motivation was to get all the binary crypto code out of the >>>>> MS to >>>>> ease adoption. We learnt from our prior experience with the SXIP >>>>> protocol that this was a barrier to adoption. Writing good DSIG >>>>> code >>>>> for all platforms/stacks/languages is tedious and expensive and >>>>> worse >>>>> increases the number of lines of code that a MS developer has to >>>>> write to enable a site. [SXIP 1.0 worked this way.] >>>> >>>> Just to clarify, getting someone to install or dynamic language >>>> script or module is *way* easier then installing a binary. >>>> >>>> XML DSIG libraries are not widely available at this time for the >>>> scripting platforms. >>> >>> Who said anything about XML DSIG? I just said you could use a >>> digital >>> signature, which doesn't require XML at all. >> >> A digital signature of what though? > > Whatever information you're digesting now. > >> And there is key management etc. > > What key management? Just hand over the key during the capabilities > exchange. Requires state management. Current method does not require state. One of the goals of the capabilities would be able to extend DIX so that if a Membersite was able to maintain state, key exchange could happen and the Membersite could verify the message itself. > >> Would seem challenging to convince anyone to NOT be using XML DSIG >> for signing an XML message these days. > > If you say so. You seem perfectly happy to digest a bunch of data > without using any special XML pixie dust. Digest of name / value pairs now. Easier to sidestep the XML standards police. :) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:15: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 1F8jAZ-0007go-D2; Mon, 13 Feb 2006 14:15:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jAX-0007ft-8U for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:15: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 OAA16419 for ; Mon, 13 Feb 2006 14:13:42 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8jOA-0002jq-H9 for dix@ietf.org; Mon, 13 Feb 2006 14:29:36 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id CA4CD1E8C1B; Mon, 13 Feb 2006 11:15:17 -0800 (PST) To: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86ek27qegy.fsf@raman.networkresonance.com> <0964F809-2B40-4988-9CF1-A0DBE457D982@sxip.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 11:15:17 -0800 In-Reply-To: <0964F809-2B40-4988-9CF1-A0DBE457D982@sxip.com> (Dick Hardt's message of "Mon, 13 Feb 2006 11:10:36 -0800") Message-ID: <86wtfzoyt6.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 13-Feb-06, at 10:51 AM, Eric Rescorla wrote: > >> >> What do you mean "binary crypto code"? You've got a hash algorithm, >> no? At worst, you could share a pairwise secret between the MS and >> the HS during the initial discovery phase and use that to key >> a MAC. (This is of course only safe if you're doing that exchange >> over SSL/TLS, but that's true of your scheme too...) >> >> Anyway, I don't really find this that convincing. Java certainly >> comes with built-in public key functionality and there are modules >> for Python, Perl and PHP (it's actually a compilation flag for PHP). >> Yes, it's not zero effort, but it's not exactly prohibitive either. > > Yes, hash algorithms are widely available on the platforms. (but even > SHA-1 is not everywhere) Well, since your scheme requires SHA-1 implementations (see S 5.10.2.2), I don't see how non-universality of SHA-1 can be an objection. And as I indicated, it's possible to attack this problem using only SHA-1 (though the solution is inferior to when PK is used). > Public Key algorithms are not widely available on the dynamic > language platforms. > > Easy for Perl, Python, PHP and Ruby developers in addition to Java > and .Net developers was a core goal of DIX. I don't think you've addressed my point here. There are PK modules for all the major dynamic platforms for the price of a recompile. I don't see how this is prohibitive. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14: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 1F8jBZ-0007xg-RA; Mon, 13 Feb 2006 14: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 1F8jBY-0007xb-Sy for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:16: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 OAA16524 for ; Mon, 13 Feb 2006 14:14: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 1F8jPE-0002ma-3j for dix@ietf.org; Mon, 13 Feb 2006 14:30:40 -0500 Received: from [192.168.1.101] (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 k1DJGUpC060726 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:16:30 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <861wy7qdnj.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <861wy7qdnj.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:16:30 -0800 To: EKR , 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 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 13-Feb-06, at 11:09 AM, Eric Rescorla wrote: >>> The technical term for a "signature" which can only be verified by >>> the holder of a symmetric secret is Message Authentication Code >>> (MAC) >>> and there's a standard technique for performing MACs: HMAC (RFC >>> 2104). >> >> Our current implementation uses HMAC. Since the Homesite can use >> whatever it wants, we left it out of the spec. > > Well, that's fine, but you shouldn't be recommending a technique > which is known to be inferior to HMAC. I agree. Did not know we were recommending a different technique. Where is that mentioned? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:20: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 1F8jEv-0008TQ-Jp; Mon, 13 Feb 2006 14:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jEt-0008RQ-DU for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:19: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 OAA16720 for ; Mon, 13 Feb 2006 14:18:13 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8jSY-0002rh-02 for dix@ietf.org; Mon, 13 Feb 2006 14:34:07 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2B1D61E8C1C; Mon, 13 Feb 2006 11:19:49 -0800 (PST) To: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt References: <20060211231709.1B227B811@delta.rtfm.com> <861wy7qdnj.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 13 Feb 2006 11:19:49 -0800 In-Reply-To: (Dick Hardt's message of "Mon, 13 Feb 2006 11:16:30 -0800") Message-ID: <86slqnoylm.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , 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 writes: > On 13-Feb-06, at 11:09 AM, Eric Rescorla wrote: > >>>> The technical term for a "signature" which can only be verified by >>>> the holder of a symmetric secret is Message Authentication Code >>>> (MAC) >>>> and there's a standard technique for performing MACs: HMAC (RFC >>>> 2104). >>> >>> Our current implementation uses HMAC. Since the Homesite can use >>> whatever it wants, we left it out of the spec. >> >> Well, that's fine, but you shouldn't be recommending a technique >> which is known to be inferior to HMAC. > > I agree. Did not know we were recommending a different technique. > Where is that mentioned? Section 5.10.2.3. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:20: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 1F8jF1-0008W2-WC; Mon, 13 Feb 2006 14:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jF0-0008Vu-Vh for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:20: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 OAA16735 for ; Mon, 13 Feb 2006 14:18:20 -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 1F8jSg-0002sS-IE for dix@ietf.org; Mon, 13 Feb 2006 14:34:14 -0500 Received: from [192.168.1.101] (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 k1DJK3L6061257 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:20:05 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <86wtfzoyt6.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <197002AB-AEDE-4763-A2AC-3687B3E9C678@sxip.com> <86ek27qegy.fsf@raman.networkresonance.com> <0964F809-2B40-4988-9CF1-A0DBE457D982@sxip.com> <86wtfzoyt6.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A173E31-D8BF-4CBC-978B-7F566CE0ECA4@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:20:03 -0800 To: EKR 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Digital Identity Exchange 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 13-Feb-06, at 11:15 AM, Eric Rescorla wrote: > Dick Hardt writes: > >> On 13-Feb-06, at 10:51 AM, Eric Rescorla wrote: >> >>> >>> What do you mean "binary crypto code"? You've got a hash algorithm, >>> no? At worst, you could share a pairwise secret between the MS and >>> the HS during the initial discovery phase and use that to key >>> a MAC. (This is of course only safe if you're doing that exchange >>> over SSL/TLS, but that's true of your scheme too...) >>> >>> Anyway, I don't really find this that convincing. Java certainly >>> comes with built-in public key functionality and there are modules >>> for Python, Perl and PHP (it's actually a compilation flag for PHP). >>> Yes, it's not zero effort, but it's not exactly prohibitive either. >> >> Yes, hash algorithms are widely available on the platforms. (but even >> SHA-1 is not everywhere) > > Well, since your scheme requires SHA-1 implementations > (see S 5.10.2.2), I don't see how non-universality of > SHA-1 can be an objection. And as I indicated, it's > possible to attack this problem using only SHA-1 (though > the solution is inferior to when PK is used). Sorry I was not clear, my point was that even SHA-1, which we require, is not universally available. > > >> Public Key algorithms are not widely available on the dynamic >> language platforms. >> >> Easy for Perl, Python, PHP and Ruby developers in addition to Java >> and .Net developers was a core goal of DIX. > > I don't think you've addressed my point here. There are PK > modules for all the major dynamic platforms for the price of > a recompile. I don't see how this is prohibitive. Having been a tool vendor for those languages, it is not as simple as that. Our experience with SXIP 1.0 was that it was prohibitive for many, even when we supplied the binary. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 14:24: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 1F8jJV-0003yf-IL; Mon, 13 Feb 2006 14:24:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jJT-0003yX-Sa for dix@megatron.ietf.org; Mon, 13 Feb 2006 14:24: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 OAA17026 for ; Mon, 13 Feb 2006 14:22:57 -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 1F8jX5-00030I-BB for dix@ietf.org; Mon, 13 Feb 2006 14:38:51 -0500 Received: from [192.168.1.101] (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 k1DJObtj061775 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 11:24:37 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <86slqnoylm.fsf@raman.networkresonance.com> References: <20060211231709.1B227B811@delta.rtfm.com> <861wy7qdnj.fsf@raman.networkresonance.com> <86slqnoylm.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46FE1A05-3D94-4062-8C18-1E28BCE1C9A0@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 11:24:37 -0800 To: EKR 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 Cc: Digital Identity Exchange 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 13-Feb-06, at 11:19 AM, Eric Rescorla wrote: > Dick Hardt writes: > >> On 13-Feb-06, at 11:09 AM, Eric Rescorla wrote: >> >>>>> The technical term for a "signature" which can only be verified by >>>>> the holder of a symmetric secret is Message Authentication Code >>>>> (MAC) >>>>> and there's a standard technique for performing MACs: HMAC (RFC >>>>> 2104). >>>> >>>> Our current implementation uses HMAC. Since the Homesite can use >>>> whatever it wants, we left it out of the spec. >>> >>> Well, that's fine, but you shouldn't be recommending a technique >>> which is known to be inferior to HMAC. >> >> I agree. Did not know we were recommending a different technique. >> Where is that mentioned? > > Section 5.10.2.3. Ok. I agree. We should recommend HMAC directly. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 13 16:27: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 1F8lEl-0004yE-Bp; Mon, 13 Feb 2006 16:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8lEk-0004xE-66 for dix@megatron.ietf.org; Mon, 13 Feb 2006 16:27: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 QAA24859 for ; Mon, 13 Feb 2006 16:26: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 1F8lSM-0006bK-Ha for dix@ietf.org; Mon, 13 Feb 2006 16:42:07 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1DLRoPr066583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 13 Feb 2006 13:27:51 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: <46FE1A05-3D94-4062-8C18-1E28BCE1C9A0@sxip.com> References: <20060211231709.1B227B811@delta.rtfm.com> <861wy7qdnj.fsf@raman.networkresonance.com> <86slqnoylm.fsf@raman.networkresonance.com> <46FE1A05-3D94-4062-8C18-1E28BCE1C9A0@sxip.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <937F2951-74B6-4A2E-8598-50EDBFE24A94@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Review of draft-merrells-dix-00.txt Date: Mon, 13 Feb 2006 13:27: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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 13-Feb-06, at 11:24 AM, Dick Hardt wrote: > On 13-Feb-06, at 11:19 AM, Eric Rescorla wrote: > >> Dick Hardt writes: >> >>> On 13-Feb-06, at 11:09 AM, Eric Rescorla wrote: >>> >>>>>> The technical term for a "signature" which can only be >>>>>> verified by >>>>>> the holder of a symmetric secret is Message Authentication Code >>>>>> (MAC) >>>>>> and there's a standard technique for performing MACs: HMAC (RFC >>>>>> 2104). >>>>> >>>>> Our current implementation uses HMAC. Since the Homesite can use >>>>> whatever it wants, we left it out of the spec. >>>> >>>> Well, that's fine, but you shouldn't be recommending a technique >>>> which is known to be inferior to HMAC. >>> >>> I agree. Did not know we were recommending a different technique. >>> Where is that mentioned? >> >> Section 5.10.2.3. > > Ok. I agree. We should recommend HMAC directly. I've changed that paragraph in dmd1 to state HMAC and reference the RFC. "A suggested implementation of a signature function would be to use the HMAC mechanism with the SHA1 cryptographic hash function, which takes as input a digest of the message and a secret known only to the Homesite. [RFC2104]" John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 14 05:17: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 1F8xFV-0008Uz-CQ; Tue, 14 Feb 2006 05:17:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8xFT-0008Uu-Qg for dix@megatron.ietf.org; Tue, 14 Feb 2006 05:17: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 FAA13979 for ; Tue, 14 Feb 2006 05:15: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 1F8xTC-0004JG-Lz for dix@ietf.org; Tue, 14 Feb 2006 05:31:47 -0500 Received: from [192.168.1.101] (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 k1EAHNuc087589 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 14 Feb 2006 02:17:24 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter - consensus?) Date: Tue, 14 Feb 2006 02:17: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.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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 Sorry for the late response Nick, I had a flood of email a while ago=20=20 and am now just catching up ... On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote: > 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. Agreed. > >> >> 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. Not sure what your point is here, sorry. > > [ >> 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. SAML immediately implies an XML document. That is heavier then name/=20 value pairs. > >> 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). SAML tokens could be moved around by DIX. That does not mean all data=20=20 has to be in SAML tokens. Lots of low value transactions can be done=20=20 with name/value pairs, and no need for XML or XML-DSIG. > > 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=20=20 >> 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. only if you need that in your application. Lots of existing=20=20 applications just need name/value pairs. DIX could be added to such a=20=20 site without any code change, just additional HTML > > 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=20=20 > 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=20=20 > (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? Really simple to implement. :) > > 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? Are they though? Why don't form generators have them then? > > Beyond that this "SAML-LowLow" profile could even be lighter, > if that=92s 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? Well, that is part of the problem with SAML. It is not clear to an=20=20 average web developer how to get it all up and running. Perhaps another way of looking at this is to ask the following=20=20 questions: Why is SAML not widely adopted? Why is it not being used at Amazon,=20=20 Yahoo!, Google or MSN? It has been around long enough. Why was SMTP standardized when X.400 was being worked on? Why was LDAP created when X.500 was looming? My opinion is because X.400 and X.500 were too heavy and did not=20=20 easily solve the problems people wanted to solve. SAML solves some people's problems, but clearly is not solving a=20=20 bunch of other people's problems, or it would have been adopted by now. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 14 14:52: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 1F96DU-0006t3-Mz; Tue, 14 Feb 2006 14:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F96DU-0006sy-3N for dix@megatron.ietf.org; Tue, 14 Feb 2006 14:52: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 OAA22547 for ; Tue, 14 Feb 2006 14:50:17 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F96RI-0005vz-Hn for dix@ietf.org; Tue, 14 Feb 2006 15:06:25 -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 k1EJpw08002183 for ; Tue, 14 Feb 2006 14:51: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 k1EJpv129276 for ; Tue, 14 Feb 2006 14:51:57 -0500 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k1EJpu27014798 for ; Tue, 14 Feb 2006 14:51:56 -0500 Message-ID: <43F234DC.6050806@redhat.com> Date: Tue, 14 Feb 2006 11:51:56 -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: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter - consensus?) References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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="===============0981533767==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0981533767== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090909020407030309020604" This is a cryptographically signed message in MIME format. --------------ms090909020407030309020604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dick Hardt wrote: > Why is SAML not widely adopted? Why is it not being used at Amazon, > Yahoo!, Google or MSN? It has been around long enough. > Why was SMTP standardized when X.400 was being worked on? > Why was LDAP created when X.500 was looming? > > My opinion is because X.400 and X.500 were too heavy and did not > easily solve the problems people wanted to solve. > > SAML solves some people's problems, but clearly is not solving a > bunch of other people's problems, or it would have been adopted by now. This, for me, sums up what DIX should be about. There has been a suggestion that DIX is biting off more than it can chew - but it seems to me it is rather avoiding a whole host of complexity in order to solve a simple problem simply. It is trivially easy implement the DMD0 protocol for example, and that is usually a good indicator of likely adoption (assuming the problem is actually solved in a reasonable manner). One key thing is that DMD0 is really just grease to make existing wheels go round, it does not force adoption of major infrastructure, deployment of new servers, or that users or sites change the way they do things. Real world people just want their real world problems solved, and I would like the focus of DIX to remain on that, rather than attempting to be yet another total identity solution. -- Pete --------------ms090909020407030309020604 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 CSqGSIb3DQEJBTEPFw0wNjAyMTQxOTUxNTZaMCMGCSqGSIb3DQEJBDEWBBT+C0aqnxwsgqh4 eFMgSVpx1zy/5jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAD+gZwPYhDfEFDwa/lZZiql4nzOwQ81ouyit8sMNzE/tkcGZhWE+KIvsglISZ f88NwIPbbDWdLYM3JEK5FqT7kmVOjFdNNUiF8suPwd8rooUvn93kbLg6+qMI8A5C23lvBtcx /614mmtr/ysmxX+HJo1a+xNF8EVhrsF/vJKW0bm7EFfz/d5d2/BgCe3S0cta2RT+y04DaRx9 h3WSpVQNZCrHGB58HmHyfFUHYHroJBm6ZlOtQ9Cd5DZnRdRTyfyJkkIZh5CjjUW+iw4SnxKZ f9t9sLYpDG0FovwU5JM+H3OwxJZ8GJ7YRSrNYBdmiXwUXCkvPdYektb7bldN/HoswQAAAAAA AA== --------------ms090909020407030309020604-- --===============0981533767== 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 --===============0981533767==-- From dix-bounces@ietf.org Tue Feb 14 17:47: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 1F98xg-00086t-5L; Tue, 14 Feb 2006 17:47:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F98xd-00085x-4O for dix@megatron.ietf.org; Tue, 14 Feb 2006 17:47: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 RAA09368 for ; Tue, 14 Feb 2006 17:46:07 -0500 (EST) Received: from exprod6og3.obsmtp.com ([64.18.1.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F99BS-0005G1-Vz for dix@ietf.org; Tue, 14 Feb 2006 18:02:15 -0500 Received: from source ([192.150.11.134]) by exprod6ob3.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 14 Feb 2006 14:47:41 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 k1EMl6Bl008503 for ; Tue, 14 Feb 2006 14:47:07 -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 k1EMl2sM000538 for ; Tue, 14 Feb 2006 14:47:39 -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, 14 Feb 2006 14:47:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) Date: Tue, 14 Feb 2006 14:44:20 -0800 Message-ID: <63C6921B571CC740BF472C356B1291E452830F@namail3.corp.adobe.com> In-Reply-To: <43F234DC.6050806@redhat.com> X-MS-Has-Attach: yes Thread-Topic: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) Thread-Index: AcYxoClrtzocn+6GSyG5L0RQxwyGHAAF/K7w From: "Duane Nickull" To: X-OriginalArrivalTime: 14 Feb 2006 22:47:36.0018 (UTC) FILETIME=[A648F320:01C631B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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="===============1529971138==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1529971138== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0073_01C63175.235B04A0" This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C63175.235B04A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Adobe is using SAML. Anyone at RSA can drop by our booth to see. 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/ ******************************* -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of Pete Rowley Sent: Tuesday, February 14, 2006 11:52 AM To: Digital Identity Exchange Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) Dick Hardt wrote: > Why is SAML not widely adopted? Why is it not being used at Amazon, > Yahoo!, Google or MSN? It has been around long enough. > Why was SMTP standardized when X.400 was being worked on? > Why was LDAP created when X.500 was looming? > > My opinion is because X.400 and X.500 were too heavy and did not > easily solve the problems people wanted to solve. > > SAML solves some people's problems, but clearly is not solving a > bunch of other people's problems, or it would have been adopted by now. This, for me, sums up what DIX should be about. There has been a suggestion that DIX is biting off more than it can chew - but it seems to me it is rather avoiding a whole host of complexity in order to solve a simple problem simply. It is trivially easy implement the DMD0 protocol for example, and that is usually a good indicator of likely adoption (assuming the problem is actually solved in a reasonable manner). One key thing is that DMD0 is really just grease to make existing wheels go round, it does not force adoption of major infrastructure, deployment of new servers, or that users or sites change the way they do things. Real world people just want their real world problems solved, and I would like the focus of DIX to remain on that, rather than attempting to be yet another total identity solution. -- Pete ------=_NextPart_000_0073_01C63175.235B04A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKxjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggPEMIIDLaADAgECAhAMDbcEPQQnvrFa7KAt yVkDMA0GCSqGSIb3DQEBBAUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTAzMjcwMDAw MDBaFw0wOTAzMjYyMzU5NTlaMIHWMSMwIQYDVQQKExpBZG9iZSBTeXN0ZW1zIEluY29ycG9yYXRl ZDEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIg T25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEfMB0GA1UEAxMWRW50ZXJwcmlzZSBTZXJ2 aWNlcyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyZNC085RTOgjsgRegul2Pjpc57Y4 tl77A0Y8n3xY6dNVSLamAeiSlgSeMbQzoqr+PFfSYpT0emPRRejDn6t+mKDQohZXjX1D2OLL/V1n NfKId4hQie7t/mYQenRfwUBBFgqpuQ3g3CAq+Md1wMRwXiKteqaFb6lhJ2+dcj0UZSUCAwEAAaOB pTCBojAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHAQEwKjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTM3MzANBgkq hkiG9w0BAQQFAAOBgQBcpMrE+2guXkJ68hMpEAjiRskIFYVpKthadcWCQgfay08fH2+6m8bFIFJh 6wohGlSqYXbO7Wbe5SVUG6CRKwkHITv5b1WA7BMmJUzj/LeVpBcQYXMjLVgi+KF5bFy8ceI47UXk 4cOQ6OxFT49u/e6orEH/yptSQZoBPthdnFQWqzCCA/MwggNcoAMCAQICEAfzGPIJmNQ4hEnwgTlR qqMwDQYJKoZIhvcNAQEEBQAwgdYxIzAhBgNVBAoTGkFkb2JlIFN5c3RlbXMgSW5jb3Jwb3JhdGVk MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMR8wHQYDVQQDExZFbnRlcnByaXNlIFNlcnZp Y2VzIENBMB4XDTA2MDIwMjAwMDAwMFoXDTA3MDIwMjIzNTk1OVowgbwxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkx NzA1BgNVBAsULkFkb2JlIENQUyAtIGh0dHA6Ly93d3cuYWRvYmUuY29tL21pc2MvQ1BTLmh0bWwx FjAUBgNVBAMTDUR1YW5lIE5pY2t1bGwxITAfBgkqhkiG9w0BCQEWEmRuaWNrdWxsQGFkb2JlLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsh4x68m47MSj4QYAnbT34gbgRY4BghOVU69T Sfw5wWGOaY2VQcGGDLzA8LWtBk5Q24aVPYbYIygYYrjeK7ZCrutpCf7c6qmNF9ZzLdcUOjV+52Ee ZraQMXTCH9YiLq0v0jvCAI2tHb3yyLI1XtN0FzoKrDRzsmQ/bzIo696hXrECAwEAAaOB2TCB1jAJ BgNVHRMEAjAAMGMGA1UdHwRcMFowWKBWoFSGUmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L0Fkb2JlU3lzdGVtc0luY29ycG9yYXRlZEVudGVycHJpc2VTZXJ2aWNlcy9MYXRlc3RDUkwwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQEEBQAD gYEAt1n86wPrxzBJf/Qp/zKLsHKYrWCfATekyB+DW1ZqAx2CNY1u0I7XnqVLyS0d9nwpHP6pLHP4 LN7lQsXfQHu1bjUpp9bpqOWp8iDrrPg34/um7dPAVKZaaiu+tQNoIiWZh43RGQA36uVtk4IJKfjN r7mIjyN6UyPnxUucq0RO3E4xggRcMIIEWAIBATCB6zCB1jEjMCEGA1UEChMaQWRvYmUgU3lzdGVt cyBJbmNvcnBvcmF0ZWQxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAxMTAwLgYD VQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExHzAdBgNVBAMTFkVu dGVycHJpc2UgU2VydmljZXMgQ0ECEAfzGPIJmNQ4hEnwgTlRqqMwCQYFKw4DAhoFAKCCAsYwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMjE0MjI0NDIwWjAjBgkq hkiG9w0BCQQxFgQU4wog57+mGUDv0ndvB02NRoocWUMwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgfwGCSsGAQQBgjcQBDGB7jCB6zCB1jEjMCEGA1UEChMa QWRvYmUgU3lzdGVtcyBJbmNvcnBvcmF0ZWQxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex HzAdBgNVBAMTFkVudGVycHJpc2UgU2VydmljZXMgQ0ECEAfzGPIJmNQ4hEnwgTlRqqMwgf4GCyqG SIb3DQEJEAILMYHuoIHrMIHWMSMwIQYDVQQKExpBZG9iZSBTeXN0ZW1zIEluY29ycG9yYXRlZDEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEfMB0GA1UEAxMWRW50ZXJwcmlzZSBTZXJ2aWNl cyBDQQIQB/MY8gmY1DiESfCBOVGqozANBgkqhkiG9w0BAQEFAASBgHaGOc0W3TXH30A+sk/YHrKU 3UqqvVV+gDN4yHsEurAiOkm10pBT6y4mVQIQpvRI4saZ4cRch0r84rh5v5BfpVNwnMfbGzl3coaj i9eCyNPYU2olaCXOWW8FkYo/iMUTGbHo4iFHeykiN//Po90zWIQYbOOCFWBwNnR85PCDSr3cAAAA AAAA ------=_NextPart_000_0073_01C63175.235B04A0-- --===============1529971138== 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 --===============1529971138==-- From dix-bounces@ietf.org Tue Feb 14 18:14: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 1F99Nc-00017T-5X; Tue, 14 Feb 2006 18:14:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99Na-00015S-QX; Tue, 14 Feb 2006 18:14: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 SAA10872; Tue, 14 Feb 2006 18:12:54 -0500 (EST) Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F99bO-000606-Em; Tue, 14 Feb 2006 18:29:03 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1ENEQMu021911; Tue, 14 Feb 2006 18:14:26 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1ENGw0e180960; Tue, 14 Feb 2006 16:16:58 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k1ENEP19018230; Tue, 14 Feb 2006 16:14:25 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1ENEP6F018225; Tue, 14 Feb 2006 16:14:25 -0700 In-Reply-To: <63C6921B571CC740BF472C356B1291E452830F@namail3.corp.adobe.com> Subject: RE: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) To: Digital Identity Exchange Cc: dix@ietf.org, dix-bounces@ietf.org X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Anthony Nadalin Date: Tue, 14 Feb 2006 17:11:37 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 02/14/2006 16:16:36 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80" X-Spam-Score: 2.9 (++) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df 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 --0__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: multipart/related; Boundary="1__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80" --1__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: multipart/alternative; Boundary="2__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80" --2__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Why does one care about the "lightness", seems that the consumability i= s the factor, as every device we use gets heavier and heavier, we learned= this with the 4MB OS battle we had, things grow. Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 = "Duane Nickull" = = To Sent by: = dix-bounces@ietf. = cc org = Subj= ect RE: The Lightness of SAMLv2, or= 02/14/2006 04:44 not (Re: [dix] draft proposed = PM charter- consensus?) = = = Please respond to = Digital Identity = Exchange = = = = Adobe is using SAML. Anyone at RSA can drop by our booth to see. 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/ ******************************* -----Original Message----- From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On Behalf Of P= ete Rowley Sent: Tuesday, February 14, 2006 11:52 AM To: Digital Identity Exchange Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) Dick Hardt wrote: > Why is SAML not widely adopted? Why is it not being used at Amazon, > Yahoo!, Google or MSN? It has been around long enough. > Why was SMTP standardized when X.400 was being worked on? > Why was LDAP created when X.500 was looming? > > My opinion is because X.400 and X.500 were too heavy and did not > easily solve the problems people wanted to solve. > > SAML solves some people's problems, but clearly is not solving a > bunch of other people's problems, or it would have been adopted by no= w. This, for me, sums up what DIX should be about. There has been a suggestion that DIX is biting off more than it can chew - but it seems to me it is rather avoiding a whole host of complexity in order to solv= e a simple problem simply. It is trivially easy implement the DMD0 protocol for example, and that is usually a good indicator of likely adoption (assuming the problem is actually solved in a reasonable manne= r). One key thing is that DMD0 is really just grease to make existing wheel= s go round, it does not force adoption of major infrastructure, deploymen= t of new servers, or that users or sites change the way they do things. Real world people just want their real world problems solved, and I would like the focus of DIX to remain on that, rather than attempting t= o be yet another total identity solution. -- Pete (See attached file: smime.p7s) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix = --2__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Why does one care about the "lightness", seems that the co= nsumability is the factor, as every device we use gets heavier and heav= ier, we learned
this with the 4MB OS battle we had, things grow.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
3D"Inactive"Duane Nickull" <dnicku= ll@adobe.com>


=
          "Duane Nickull" <dnickull@adobe.co= m>
          Sent by: dix-bounces@ietf.org

          02/14/2006 04:44 PM
          Please respond to
          Digital Identity Exchange <dix@ietf.org>

 =

To
3D""
<dix@ietf.org>

cc
3D""

Subject
3D""
RE: The Lightness of SAMLv2, or not (Re: [dix] draft p= roposed charter- consensus?)
=3D""3D""<= /td>

Adobe is using SAML.  Anyone at RSA can drop by our booth to s= ee.

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 - h= ttp://technoracle.blogspot.com/
*******************************


-----Original Message-----
From: dix-bounces@ietf.org [mai= lto:dix-bounces@ietf.org] On Behalf Of Pete
Rowley
Sent: Tuesday, February 14, 2006 11:52 AM
To: Digital Identity Exchange
Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed<= br> charter- consensus?)

Dick Hardt wrote:

> Why is SAML not widely adopted? Why is it not being used at Amazon= ,  
> Yahoo!, Google or MSN?  It has been around long enough.
> Why was SMTP standardized when X.400 was being worked on?
> Why was LDAP created when X.500 was looming?
>
> My opinion is because X.400 and X.500 were too heavy and did not &= nbsp;
> easily solve the problems people wanted to solve.
>
> SAML solves some people's problems, but clearly is not solving a &= nbsp;
> bunch of other people's problems, or it would have been adopted by= now.

This, for me, sums up what DIX should be about.  There has been a =
suggestion that DIX is biting off more than it can chew - but it seems =
to me it is rather avoiding a whole host of complexity in order to solv= e
a simple problem simply.  It is trivially easy implement the DMD0 =
protocol for example, and that is usually a good indicator of likely adoption (assuming the problem is actually solved in a reasonable manne= r).

One key thing is that DMD0 is really just grease to make existing wheel= s
go round, it does not force adoption of major infrastructure, deploymen= t
of new servers, or that users or sites change the way they do things. &= nbsp;
Real world people just want their real world problems solved, and I would like the focus of DIX to remain on that, rather than attempting t= o
be yet another total identity solution.

--
Pete

(See attached file: smime.p7s)_________________________= ______________________
dix mailing list
dix@ietf.org
https:/= /www1.ietf.org/mailman/listinfo/dix

= --2__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80-- --1__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <20__=09BBFB86DFECBA808f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --1__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: image/gif; name="pic01207.gif" Content-Disposition: inline; filename="pic01207.gif" Content-ID: <30__=09BBFB86DFECBA808f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --1__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <40__=09BBFB86DFECBA808f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --1__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80-- --0__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 Content-type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-ID: <10__=09BBFB86DFECBA808f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKxjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggPEMIIDLaADAgECAhAMDbcEPQQnvrFa7KAt yVkDMA0GCSqGSIb3DQEBBAUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTAzMjcwMDAw MDBaFw0wOTAzMjYyMzU5NTlaMIHWMSMwIQYDVQQKExpBZG9iZSBTeXN0ZW1zIEluY29ycG9yYXRl ZDEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIg T25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEfMB0GA1UEAxMWRW50ZXJwcmlzZSBTZXJ2 aWNlcyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyZNC085RTOgjsgRegul2Pjpc57Y4 tl77A0Y8n3xY6dNVSLamAeiSlgSeMbQzoqr+PFfSYpT0emPRRejDn6t+mKDQohZXjX1D2OLL/V1n NfKId4hQie7t/mYQenRfwUBBFgqpuQ3g3CAq+Md1wMRwXiKteqaFb6lhJ2+dcj0UZSUCAwEAAaOB pTCBojAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHAQEwKjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTM3MzANBgkq hkiG9w0BAQQFAAOBgQBcpMrE+2guXkJ68hMpEAjiRskIFYVpKthadcWCQgfay08fH2+6m8bFIFJh 6wohGlSqYXbO7Wbe5SVUG6CRKwkHITv5b1WA7BMmJUzj/LeVpBcQYXMjLVgi+KF5bFy8ceI47UXk 4cOQ6OxFT49u/e6orEH/yptSQZoBPthdnFQWqzCCA/MwggNcoAMCAQICEAfzGPIJmNQ4hEnwgTlR qqMwDQYJKoZIhvcNAQEEBQAwgdYxIzAhBgNVBAoTGkFkb2JlIFN5c3RlbXMgSW5jb3Jwb3JhdGVk MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMR8wHQYDVQQDExZFbnRlcnByaXNlIFNlcnZp Y2VzIENBMB4XDTA2MDIwMjAwMDAwMFoXDTA3MDIwMjIzNTk1OVowgbwxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkx NzA1BgNVBAsULkFkb2JlIENQUyAtIGh0dHA6Ly93d3cuYWRvYmUuY29tL21pc2MvQ1BTLmh0bWwx FjAUBgNVBAMTDUR1YW5lIE5pY2t1bGwxITAfBgkqhkiG9w0BCQEWEmRuaWNrdWxsQGFkb2JlLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsh4x68m47MSj4QYAnbT34gbgRY4BghOVU69T Sfw5wWGOaY2VQcGGDLzA8LWtBk5Q24aVPYbYIygYYrjeK7ZCrutpCf7c6qmNF9ZzLdcUOjV+52Ee ZraQMXTCH9YiLq0v0jvCAI2tHb3yyLI1XtN0FzoKrDRzsmQ/bzIo696hXrECAwEAAaOB2TCB1jAJ BgNVHRMEAjAAMGMGA1UdHwRcMFowWKBWoFSGUmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L0Fkb2JlU3lzdGVtc0luY29ycG9yYXRlZEVudGVycHJpc2VTZXJ2aWNlcy9MYXRlc3RDUkwwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQEEBQAD gYEAt1n86wPrxzBJf/Qp/zKLsHKYrWCfATekyB+DW1ZqAx2CNY1u0I7XnqVLyS0d9nwpHP6pLHP4 LN7lQsXfQHu1bjUpp9bpqOWp8iDrrPg34/um7dPAVKZaaiu+tQNoIiWZh43RGQA36uVtk4IJKfjN r7mIjyN6UyPnxUucq0RO3E4xggRcMIIEWAIBATCB6zCB1jEjMCEGA1UEChMaQWRvYmUgU3lzdGVt cyBJbmNvcnBvcmF0ZWQxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAxMTAwLgYD VQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExHzAdBgNVBAMTFkVu dGVycHJpc2UgU2VydmljZXMgQ0ECEAfzGPIJmNQ4hEnwgTlRqqMwCQYFKw4DAhoFAKCCAsYwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMjE0MjI0NDIwWjAjBgkq hkiG9w0BCQQxFgQU4wog57+mGUDv0ndvB02NRoocWUMwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgfwGCSsGAQQBgjcQBDGB7jCB6zCB1jEjMCEGA1UEChMa QWRvYmUgU3lzdGVtcyBJbmNvcnBvcmF0ZWQxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex HzAdBgNVBAMTFkVudGVycHJpc2UgU2VydmljZXMgQ0ECEAfzGPIJmNQ4hEnwgTlRqqMwgf4GCyqG SIb3DQEJEAILMYHuoIHrMIHWMSMwIQYDVQQKExpBZG9iZSBTeXN0ZW1zIEluY29ycG9yYXRlZDEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEfMB0GA1UEAxMWRW50ZXJwcmlzZSBTZXJ2aWNl cyBDQQIQB/MY8gmY1DiESfCBOVGqozANBgkqhkiG9w0BAQEFAASBgHaGOc0W3TXH30A+sk/YHrKU 3UqqvVV+gDN4yHsEurAiOkm10pBT6y4mVQIQpvRI4saZ4cRch0r84rh5v5BfpVNwnMfbGzl3coaj i9eCyNPYU2olaCXOWW8FkYo/iMUTGbHo4iFHeykiN//Po90zWIQYbOOCFWBwNnR85PCDSr3cAAAA AAAA --0__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80 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 --0__=09BBFB86DFECBA808f9e8a93df938690918c09BBFB86DFECBA80-- From dix-bounces@ietf.org Tue Feb 14 18:18:58 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 1F99Ri-0002uy-K0; Tue, 14 Feb 2006 18:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99Rh-0002rz-EK for dix@megatron.ietf.org; Tue, 14 Feb 2006 18:18: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 SAA11105 for ; Tue, 14 Feb 2006 18:17:11 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F99fX-00067Y-LP for dix@ietf.org; Tue, 14 Feb 2006 18:33:20 -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 k1ENIqfi006056 for ; Tue, 14 Feb 2006 18:18:52 -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 k1ENIp107779 for ; Tue, 14 Feb 2006 18:18:51 -0500 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k1ENIo27026880 for ; Tue, 14 Feb 2006 18:18:50 -0500 Message-ID: <43F26559.1030707@redhat.com> Date: Tue, 14 Feb 2006 15:18:49 -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: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) References: <63C6921B571CC740BF472C356B1291E452830F@namail3.corp.adobe.com> In-Reply-To: <63C6921B571CC740BF472C356B1291E452830F@namail3.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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="===============0186498300==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0186498300== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030708090605070805060305" This is a cryptographically signed message in MIME format. --------------ms030708090605070805060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Duane Nickull wrote: >Adobe is using SAML. Anyone at RSA can drop by our booth to see. > > > How many external sites are you able to interoperate with? -- Pete --------------ms030708090605070805060305 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 CSqGSIb3DQEJBTEPFw0wNjAyMTQyMzE4NDlaMCMGCSqGSIb3DQEJBDEWBBTNY12RMIkKRDNC 5+2xl/kJxDhpWjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAywjuJzFfsePEi5mQPlpRdhAntODpVLFEMruSHI1xvja0R3J9uBsddtYebg3K YiJX5m8LF89AYy/mI7DjURgzu4tJFQJBAbSYOYcfdHN0OCbqiuws/1G9eaK3ChM7SWcygKy2 0nlw7syBqDeDD+yKQZNskF6MZHz2vCvMusaxvMLkvkUiv6y8Ekit4Vg8p3bZpzKbwnY7/5J1 H9SLjnZo8wdy5IPaUgvU4Vcdi1oOsHXaqXz3LegfXR+p4yfN91KvWGXa5xFbMArRpLbtN6OC kTcAh6Irab0YUzS1sikOE3hy+q5A1OexkOaYlSKNkQeUrqpsM4oovfFOiij/EUjHMgAAAAAA AA== --------------ms030708090605070805060305-- --===============0186498300== 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 --===============0186498300==-- From dix-bounces@ietf.org Tue Feb 14 20:48: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 1F9Blw-0000Vo-Qk; Tue, 14 Feb 2006 20:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Blv-0000VR-GE for dix@megatron.ietf.org; Tue, 14 Feb 2006 20:47: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 UAA25158 for ; Tue, 14 Feb 2006 20:46:12 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Bzn-000487-16 for dix@ietf.org; Tue, 14 Feb 2006 21:02:23 -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 k1F1lrJM020134 for ; Tue, 14 Feb 2006 17:47:53 -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); Tue, 14 Feb 2006 17:47:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter-consensus?) Date: Tue, 14 Feb 2006 17:47:53 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD375A2C0A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter-consensus?) Thread-Index: AcYxvR3R9nLCMcqLRIG4jhDdyFL/2gAFLgrH From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" , "Digital Identity Exchange" X-OriginalArrivalTime: 15 Feb 2006 01:47:53.0455 (UTC) FILETIME=[D5FAD7F0:01C631D1] 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="===============1938465995==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1938465995== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C631D1.D5F1500A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C631D1.D5F1500A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One oint to bear in mind here. If the outcome of this exercise is we discover that saml does the job in = a way that is acceptable to the identified user community we have done a = good job. If we discover that there is some delta that needs to be addressed = likewise. If we discover that we can reuse the language of the saml spec then that = is useful. The traditional model that groups follow in this environment is seek and = destroy. The incumbents try to block emergence of rivals. I do not see that as a usefull approach. We tried that with ssh and = pkix. Let's see where we can get with embrace and extend. -----Original Message----- From: Pete Rowley [mailto:prowley@redhat.com] Sent: Tue Feb 14 15:19:34 2006 To: Digital Identity Exchange Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed = charter-consensus?) Duane Nickull wrote: >Adobe is using SAML. Anyone at RSA can drop by our booth to see. > > =20 > How many external sites are you able to interoperate with? --=20 Pete ------_=_NextPart_001_01C631D1.D5F1500A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed = charter-consensus?)

One oint to bear in mind here.

If the outcome of this exercise is we discover that saml does the job in = a way that is acceptable to the identified user community we have done a = good job.

If we discover that there is some delta that needs to be addressed = likewise.

If we discover that we can reuse the language of the saml spec then that = is useful.

The traditional model that groups follow in this environment is seek and = destroy. The incumbents try to block emergence of rivals.

I do not see that as a usefull approach. We tried that with ssh and = pkix.

Let's see where we can get with embrace and extend.


 -----Original Message-----
From:   Pete Rowley [mailto:prowley@redhat.com]
Sent:   Tue Feb 14 15:19:34 2006
To:     Digital Identity Exchange
Subject:        Re: The Lightness of = SAMLv2, or not (Re: [dix] draft proposed charter-consensus?)

Duane Nickull wrote:

>Adobe is using SAML.  Anyone at RSA can drop by our booth to = see.
>
> 
>
How many external sites are you able to interoperate with?


--
Pete

------_=_NextPart_001_01C631D1.D5F1500A-- --===============1938465995== 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 --===============1938465995==-- From dix-bounces@ietf.org Wed Feb 15 06:06: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 1F9KUp-00079Y-2p; Wed, 15 Feb 2006 06:06:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9KUn-00079T-4m for dix@megatron.ietf.org; Wed, 15 Feb 2006 06:06: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 GAA29088 for ; Wed, 15 Feb 2006 06:05:06 -0500 (EST) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Kii-000527-6c for dix@ietf.org; Wed, 15 Feb 2006 06:21:21 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7034933C1C for ; Wed, 15 Feb 2006 11:06:44 +0000 (GMT) Message-ID: <43F30BC3.3040906@algroup.co.uk> Date: Wed, 15 Feb 2006 11:08:51 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Anthony Nadalin wrote: > Why does one care about the "lightness", seems that the consumability is > the factor, as every device we use gets heavier and heavier, we learned > this with the 4MB OS battle we had, things grow. Because the heavier a system is the more code has to be written. Code costs money, even free code. -- 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 Wed Feb 15 12:20: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 1F9QFp-0008SP-B7; Wed, 15 Feb 2006 12:15:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9QFl-0008QQ-53 for dix@megatron.ietf.org; Wed, 15 Feb 2006 12:15: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 MAA13402 for ; Wed, 15 Feb 2006 12:13:58 -0500 (EST) Received: from skink.reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9QTi-0008H6-10 for dix@ietf.org; Wed, 15 Feb 2006 12:30:17 -0500 Received: from mail.reptiles.org([198.96.119.1] port=3333) (1540 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) Wed, 15 Feb 2006 12:15:36 -0500 (EST) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Wed, 15 Feb 2006 12:15:36 -0500 (EST) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: Digital Identity Exchange Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) In-Reply-To: <43F30BC3.3040906@algroup.co.uk> Message-ID: <20060215121457.D2884@skink.reptiles.org> References: <43F30BC3.3040906@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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, 15 Feb 2006, Ben Laurie wrote: > Anthony Nadalin wrote: >> Why does one care about the "lightness", seems that the consumability is >> the factor, as every device we use gets heavier and heavier, we learned >> this with the 4MB OS battle we had, things grow. > > Because the heavier a system is the more code has to be written. Code > costs money, even free code. ... and oddly enough, the more code that's written, the more scope there is for errors. 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 Wed Feb 15 13:02: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 1F9Qz7-0002jV-9l; Wed, 15 Feb 2006 13:02:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Qz5-0002e8-PE for dix@megatron.ietf.org; Wed, 15 Feb 2006 13:02: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 NAA18601 for ; Wed, 15 Feb 2006 13:00:48 -0500 (EST) Received: from toad.mtbrook.bozemanpass.com ([69.145.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9RD0-00024t-Sj for dix@ietf.org; Wed, 15 Feb 2006 13:17:08 -0500 Received: from [69.145.82.218] (unknown [69.145.82.218]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id B9F931102E6 for ; Wed, 15 Feb 2006 10:02:15 -0800 (PST) Message-ID: <43F36C2D.6010107@boreham.org> Date: Wed, 15 Feb 2006 11:00:13 -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: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) References: <43F30BC3.3040906@algroup.co.uk> <20060215121457.D2884@skink.reptiles.org> In-Reply-To: <20060215121457.D2884@skink.reptiles.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 I'm not sure that we need to speculate on the reasons why 'heavy' standards are not widely used. It's an observed fact. The only reason I'd want to think about why this is would be if I were planning to make a heavy standard that did not have whatever the badness is that cases lack of adoption. Personally I would not bother with that line of thinking: instead I'd go make a 'light' standard... And that I believe is roughly the goal of this present effort. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Feb 15 14:51: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 1F9SgA-0005Mi-4W; Wed, 15 Feb 2006 14:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Sg9-0005M2-6V; Wed, 15 Feb 2006 14:51: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 OAA26424; Wed, 15 Feb 2006 14:49:19 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9SuA-00061C-MD; Wed, 15 Feb 2006 15:05:40 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1FJopJt005242; Wed, 15 Feb 2006 14:50:51 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1FJmaim242554; Wed, 15 Feb 2006 12:48:36 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k1FJooBr017103; Wed, 15 Feb 2006 12:50:50 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1FJoosI017091; Wed, 15 Feb 2006 12:50:50 -0700 In-Reply-To: <43F36C2D.6010107@boreham.org> Subject: Re: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) To: david_list@boreham.org, Digital Identity Exchange X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Anthony Nadalin Date: Wed, 15 Feb 2006 13:32:45 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 02/15/2006 12:53:02 MIME-Version: 1.0 X-Spam-Score: 2.7 (++) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: Digital Identity Exchange , dix-bounces@ietf.org 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="===============0247090823==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org --===============0247090823== Content-type: multipart/related; Boundary="0__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC" --0__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC Content-type: multipart/alternative; Boundary="1__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC" --1__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >speculate on the reasons why 'heavy' standards are not widely used. It= 's an observed fact. First I don't believe that as we have successfully deployed many "heavy= " standards along with other companies. Also there are many factors that can play in "heavy" standards, the amo= unt of code is one of them but not the most important factor. We see "heavy" as being very complex= , and not consumable, and these 2 characteristic could fall into other's "Lightness".u Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 = David Boreham = = To Sent by: Digital Identity Exchange = dix-bounces@ietf. = org = cc = Subj= ect 02/15/2006 12:00 Re: The Lightness of SAMLv2, or = not PM (Re: [dix] draft proposed charte= r- consensus?) = = Please respond to = david_list@boreha = m.org; Please = respond to = Digital Identity = Exchange = = = = I'm not sure that we need to speculate on the reasons why 'heavy' standards are not widely used. It's an observed fact. The only reason I'd want to think about why this is would be if I were planning to make a heavy standard that did not have whatever the badness is that cases lack of adoption. Personally I would not bother with that line of thinking: instead I'd go make a 'light' standard... And that I believe is roughly the goal of this present effort. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix = --1__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

>speculate on the reasons why 'heavy' standards are not widel= y used. It's an observed fact.
First I don't believe that as we have successfully deployed many &q= uot;heavy" standards along with other companies.

Also there are many factors that can play in "heavy" stan= dards, the amount of code is one of them
but not the most important factor. We see "heavy" as bein= g very complex, and not consumable, and these 2 characteristic could fa= ll into other's "Lightness".u

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
3D"InactiveDavid Boreham <david_list@boreham.org>=


=
          David Boreham <david_list@boreham.org>
          Sent by: dix-bounces@ietf.org

          02/15/2006 12:00 PM
          Please respond to
          david_list@boreham.org; Please respond to
          Digital Identity Exchange <dix@ietf.org>

 =

To
3D""
Digital Identity Exchange <dix@ietf.org><= /td>

cc
3D""

Subject
3D""
Re: The Lightness of SAMLv2, or not (Re: [dix] draft p= roposed charter- consensus?)
=3D""3D""<= /td>

I'm not sure that we need to speculate on the reasons why
'heavy' standards are not widely used. It's an observed fact.
The only reason I'd want to think about why this is would be
if I were planning to make a heavy standard that did not have
whatever the badness is that cases lack of adoption. Personally
I would not bother with that line of thinking: instead I'd go make
a 'light' standard...

And that I believe is roughly the goal of this present effort.



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

= --1__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC-- --0__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBFB85DFF953EC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC Content-type: image/gif; name="pic03207.gif" Content-Disposition: inline; filename="pic03207.gif" Content-ID: <20__=09BBFB85DFF953EC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <30__=09BBFB85DFF953EC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBFB85DFF953EC8f9e8a93df938690918c09BBFB85DFF953EC-- --===============0247090823== 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 --===============0247090823==-- From dix-bounces@ietf.org Wed Feb 15 16:41: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 1F9UP6-0004EQ-Ba; Wed, 15 Feb 2006 16:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9UP4-00049p-5Y for dix@megatron.ietf.org; Wed, 15 Feb 2006 16:41: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 QAA09886 for ; Wed, 15 Feb 2006 16:39:50 -0500 (EST) Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Ud6-0003Zo-8L for dix@ietf.org; Wed, 15 Feb 2006 16:56:12 -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 k1FLfWjs003741 for ; Wed, 15 Feb 2006 16:41:32 -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 k1FLfW120734 for ; Wed, 15 Feb 2006 16:41:32 -0500 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k1FLfU27030849 for ; Wed, 15 Feb 2006 16:41:31 -0500 Message-ID: <43F3A00A.9070806@redhat.com> Date: Wed, 15 Feb 2006 13:41:30 -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: The Lightness of SAMLv2, or not (Re: [dix] draft proposed charter- consensus?) References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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="===============1276915685==" Sender: dix-bounces@ietf.org Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1276915685== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090000060909030304010707" This is a cryptographically signed message in MIME format. --------------ms090000060909030304010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anthony Nadalin wrote: > >speculate on the reasons why 'heavy' standards are not widely used. > It's an observed fact. > First I don't believe that as we have successfully deployed many > "heavy" standards along with other companies. > Success of one or more companies deploying anything is not an indicator of wide adoption. This is particularly true for larger companies, which tend to deploy pretty much everything somewhere, though not necessarily widely even within that company. By any measure, the current crop of extranet "identity" protocols cannot be said to be deployed widely. My gut tells me that even those that are deployed at all don't see much in the way of extranet action. Which, after all, was the only "problem" that didn't already have abundant and adequate solutions, nobody needed those protocols for logging into the intranet portal. I think the underlying issue here is who doesn't have what they need, why is it they don't have it, and do we care to solve that problem? The contention is that individual web users and web sites do not have what they need because what is available standards-wise is too complex to be developed widely or to deploy widely, particularly in the smaller scale operation. Clearly some want to solve that problem. > Also there are many factors that can play in "heavy" standards, the > amount of code is one of them > but not the most important factor. We see "heavy" as being very > complex, and not consumable, and these 2 characteristic could fall > into other's "Lightness".u > I prefer the term "simple", then everyone can agree what it means. -- Pete --------------ms090000060909030304010707 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 CSqGSIb3DQEJBTEPFw0wNjAyMTUyMTQxMzBaMCMGCSqGSIb3DQEJBDEWBBSEvnUN5bj0Y+fs RiszMBq1+b7RkzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEApMa61dZyWYQ0ZPJvqyDThN42+hrkN4HlyS6xuUlgsTKSlmpPKvPDhTk8axJf g43QyDzDrvtxDxv4hXWpdM/bLVncQX97qdWQhx8V6bCLb43Iw/9gZmqTTumlqNSxQDThqPlP njRPvN2aTpC0cDP5LGKKE2ZE0IP6PVg7s5REAYgMcD094cwnR1T6mlVztj5srVKQqLpSDskf O8zszzOHxdEBtxffWu6zY6ygUN9iyi4HvHI9DNoEiHVaxKvmjbJq9uVwTby1aGWHcQI6E686 nvikySxVngRNN9ur21WtD35HT5lRvSn7Rk7NN7U9IFxY9A/qZC8tYlW/9iKLnVbO+gAAAAAA AA== --------------ms090000060909030304010707-- --===============1276915685== 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 --===============1276915685==-- From dix-bounces@ietf.org Mon Feb 20 20:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMYC-0002o2-22; Mon, 20 Feb 2006 20:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMYA-0002nx-CK for dix@ietf.org; Mon, 20 Feb 2006 20:42:46 -0500 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBMY7-0005BI-Oe for dix@ietf.org; Mon, 20 Feb 2006 20:42:46 -0500 Received: from user-10ib3g5.biz.mindspring.com ([65.37.142.5] helo=belka.radicalmode.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FBMY6-00052B-00 for dix@ietf.org; Mon, 20 Feb 2006 20:42:42 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1FBMY5-0001uJ-98; Mon, 20 Feb 2006 17:42:41 -0800 From: Nick Ragouzis Send: Monday, February 20, 2006 5:40 PM To: dix@ietf.org, dix@enosis.com Message-Id: Date: Mon, 20 Feb 2006 17:42:41 -0800 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: Subject: [dix] Meaning of Simple? Basis for concrete and specific requirements 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: , Errors-To: dix-bounces@ietf.org [Thread note: To avoid expanding this email, and follow on digests, I've broken the prior email up into several different threads. As we don't have real distinguishing topical thread names, yet ... so I didn't see that as a problem. Apologies in advance if it's bothersome. The original thread continues on: 1. Setting aside irrelevant or incomplete histories 2. Meaning of Simple? Basis for concrete and specific requirements. 3. SAMLv2-LowLow: Bindings and Profiles?. ] Dick, Dick Hardt @ Tue, 14 Feb 2006 02:17:22 -0800 wrote: > Sorry for the late response Nick, I had a flood of > email a while ago and am now just catching up ... NP. It does serve to remind just how busy folks are in this community ... and why we'd want, as a community, to focus just on innovations of significant need and clear merit, and to build on what the community has achieved. Dick continued: > On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote: > > 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. > > Agreed. Great. In this dialog since Tom Doman's question (responding to Leslie's more general point about interoperability, etc; and to which Boris asked/suggested the same thing; to mention just a few) I don't think we've seen much that's specific or detailed on this. That is, about specific differences that could be either robustly described or objectively tested, as inappropriate or lacking (I don't think it has to be both.). We have these gaps proposed [PG], as far as I've noticed: PG1. Existing protocol SAMLv2 uses XML; we want non-XML; handling HTML and working with name-value pairs is about right PG2. Existing protocol SAMLv2 is heavy; we want light. PG3. We don't want to use XML-DSIG. Also, I think we've seen a few specifics floated about the surrounding environment that are also relevant to this question (proposed requirements, or proposed design criteria PDC?): PDC1. Easy for Perl, Python, PHP and Ruby developers in addition to Java and .Net developers [was a core goal of DIX, per D. Hardt 13Feb06]. (Tentative and partial) PDC2. Do not require state management in the Membersite. But we might want extensibility to allow benefits for Membersites that can/do maintain state. [characterization of current method in SXIP, per D. Hardt 13Feb06] (Tentative and partial) These are weakly related to the "Simple Deployment" requirement proposed on the wiki. Dick continued: > > Dick Hardt continues: > >> 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. > > SAML immediately implies an XML document. That is heavier then > name/value pairs. Okay, so let's work from there. I've captured the XML bit in PG1, above. (And discussed a name/value serialization and encoding for SAMLv2 in another email.) I don't see an objection here to the other design criteria I floated (and which others have mentioned in various forms), so: PDC3. That Membersite would have ability to learn and/or require a level of service from Homesite, regarding (e.g.,): state-based services, Homesite security measures wrt and form of: authentication of principal, timeliness of said authentication, assuring proper consent to data release, etc., according to the value attached to the transaction by the Membersite. (Tentative and partial, although dmd00 implies and otherwise specifies that it is a PG/G to deliver parts of this. Questions are: which parts are separable? are these parts mutually complete? what mechanism is provided for specifying additional needs, e.g., through the fetch request msg parms?) PDC4. Be open to additional requirements that enhance interoperability (the presumption here is these would otherwise not be 'naturally' a part of the base conceptions and requirements). (Tentative and partial) PDC5. In pursuit of PDC4, be prepared to describe and communicate to SDO of other relevant standards changes which would improve interoperability with this protocol. For example, a profile of such a protocol. (Tentative and partial) Before moving further let's roll-up the next item. Dick continued: > > Dick Hardt continues: > >> 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). > > SAML tokens could be moved around by DIX. That does not mean > all data has to be in SAML tokens. Lots of low value transactions > can be done with name/value pairs, and no need for XML or XML-DSIG. Here's what I see there, but I could have it wrong: 1. Low value differs from "no value" (otherwise we, and Membersites, would not be concerned at all) 2. Processing digitally-signed XML is too hard. But there's a difference, right, between the burdens a Homesite vs. a Membersite are expected to shoulder? 3. Creating HTML pages, and handling HTTP POST with name-value pairs is about right 4. DIX might "move around SAML tokens" ... but it would not be desirable for all data to have to be in "SAML tokens." So, I have: PDC6. Membersites would be correct to expect Homesites to maintain an higher-than ordinary standard of normal, security, and cryptographic operations with the care appropriate to the value the Membersite assigns to the business it conducts (or wishes to conduct) with the Homesite. As such, certain requirements might be [globally] prerequisite for operating a Homesite, or the protocol might provide a way to specify or discover such. There might be a need for a standard way for principals to describe what they intend, wrt the Membersite, or the Homesite, regarding "responsibilities for authentication and identifying the user, maintaining a repository of identity data, releasing that data, obtaining (certain) user consent" [abstract from dmd00]. Any assumed, or unstated, requirements in this respect might limit the scope of operation even if technical interoperability were possible. (Tentative and partial, although the requirement in dmd00 implies capabilities as PG/Gs which would be dependent on or assume this.) By comparison, whereas (in general) PDC3 pertains to the security concerns relative to the Membersite user of the current transaction, PDC6 pertains to the security concerns of the Membersite as a whole as a relying party to that particular Homesite. Of course these are related, but PDC3 relates to protocol exchange; PDC6 relates to criteria about and surrounding the protocol itself and the entities that would offer the services. PDC7. The protocol should be built to accommodate (natively or through use of native extension points) SAML tokens. (Tentative and partial) A bit of definition is required here. Dick, what do you mean by "SAML token": SAMLRequest and SAMLReply objects? SAMLAuthnRequest, SAMLAssertion? There are further implications associated with any complete definition of the ability you mention when you say "SAML tokens could be moved around by DIX." I haven't tried to straighten that out here. Perhaps you could elaborate (in a separate thread:-)? Dick contined: > > > > 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. > > > > Dick Hardt wrote: > >> 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. > > only if you need that in your application. Lots of existing > applications just need name/value pairs. DIX could be added > to such a site without any code change, just additional HTML Hum ... well there are two parts to that. The first just doesn't rise to the level of the proposed effort: if your web app doesn't need more than to just get some name-value pair injected into your login form, then you don't need dix or anything like it. That's a definition of "simple" I can design to. But (part two) if as a relying party/Membersite you need more than that, then there's a requirement or two ... scaled to your needs (some specified above). dmd00 in the least imposes these requirements on the 'application' it calls the Membersite: * Membersite must be aware of the existence of a Homesite, in the least to address the request there, yes? * To request that a user identify their Homesite, using an appropriate HTML form control * To make that into a cookie using the appropriate name=value pair * To later retrieve that cookie and use the appropriate name=value pair. * To direct a request to a Homesite, if necessary retrying at least once and dealing with redirects. * To retrieve endpoint and capabilities information proceed to endpoint, possibly also requiring discovery of that endpoint and capabilities of the Homesite * To form the HTTP POST for redirect with appropriate verification and cryptographic features * To maintain in pendency the user's requested session at the Membersite * To verify the response message from the Homesite and more. That looks to me like a bit more than: > "added ... without any code change, just additional HTML" So, how am I not correct, then, in concluding that for any effort that would rise to a community effort, this protocol must be designed to account for "making the application aware of identity attestations of a trusted third party"? Dick continued: > > > > NR: Right off this is indeed heavier. But what's the > > *objective* bar? > > Really simple to implement. :) I'll take that grin as a nod that we might want to get a bit more specific about that "objective test." I note that the list has had a bit more chatter about this. I encourage us to think a bit more specifically and fully about the question. "Simple," "easy-to-implement," "light," "consumable," "not complex," even what 'code' would be considered "in" vs "out" of the entire solution (therefore part of the 'bug pool') ... all or any of these still require agreement before they mean anything useful. Especially if we are to design for the possibility of supporting in the proposed protocol the 'any ole name=value pair' type relying party, as well as one that might be as serious to ask about two-factor authn (as in the example in dmd00). Consider, perhaps, that having presented the above PG and PDC, we now recognize that there are quite a few requirements on the Homesite to be prepared for pertaining a request from the Membersite (who is, ultimately, in control of the question). We hear the protocol is supposed to rise to the level of responding to a Membersite that expects true assurances that the Homesite really does carry out operations that assure 'true' member's consent, or even more, desires two-factor authentication. Then the burden is certainly higher than just any ordinary host: keep up to date on security updates (including any new tool chain recompiles), maintain firewalls, control data repositories, etc. These aren't minor or out-of-scope to the use of the protocol; they are intrinsic with standing up, e.g., dmd00, AFAICT. In that context, then, what is the objective test that separates these issues? An unelaborated "Simple" isn't good enough for this domain, particularly for a community-developed standard. The question is even one of "where?" Over the wire? Or within the Homesite, or Membersite for the developer? And for whom? On this latter question, it appears it can only be wrt the developer at a Homesite or Membersite who develops the code incantation that 'users' put in their cgi. Even the PG1 seems a bit disconnected to the intrinsic requirements: If you are a Perl developer (who must also meet all the operations requirements, above), what's the objective difference *for the developer in a system otherwise meeting the environmental requirements* between (installing and maintaining and) 'use'ing CGI :form or :html and 'use'ing XML::Simple (both mostly just assigning suitably-named hashes and attributes) for the type of processing we're discussing? Even at that, if we're just talking about over-the-wire, well, fine. Perhaps at some level an existing protocol can address that. Then we might get closer to understanding the innovations and value of a new effort. See: "SAMLv2-LowLow, bindings and profiles?" thread. Dick continued: > > 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? > > Are they though? Why don't form generators have them then? Now I don't understand. What candidate form generators *don't* allow developers to add this data to a form? What candidate form generators *don't* operate in a domain where timestamps and request-response identifiers can't be sustained? These are the two principal 'additions' that comprise that "extra." Dick continued: > > > Beyond that this "SAML-LowLow" profile could even be lighter, > > if that’s what's required. Such as removing the Authentication > > ...snipped > > Well, that is part of the problem with SAML. It is not clear to > an average web developer how to get it all up and running. Getting clarity seems like a reasonable community effort. Getting toolkits does as well. If we can identify distinct and clear gaps that can't be corrected from the pool of existing community work, then innovations in those areas seems like a really good idea too. (I think that DIXUFFEML (digital identity user form factor expression markup language) bit would be really useful, and sufficiently challenging, and distinct, work.) Recapitulation and creating another isolated security exchange doesn't seem like such a good thing. Best, --Nick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 20 20:45:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMbE-0002vC-Fu; Mon, 20 Feb 2006 20:45:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMbC-0002v3-PS for dix@ietf.org; Mon, 20 Feb 2006 20:45:54 -0500 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBMbC-0005D6-Cr for dix@ietf.org; Mon, 20 Feb 2006 20:45:54 -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 1FBMbB-00022Q-00 for dix@ietf.org; Mon, 20 Feb 2006 20:45:53 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1FBMbA-0001vS-OW; Mon, 20 Feb 2006 17:45:52 -0800 From: Nick Ragouzis Send: Monday, February 20, 2006 5:45 PM To: dix@ietf.org, dix@enosis.com Message-Id: Date: Mon, 20 Feb 2006 17:45:52 -0800 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Subject: [dix] SAMLv2-LowLow: Bindings and Profiles? 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: , Errors-To: dix-bounces@ietf.org [Thread note: To avoid expanding this email, and follow on digests, I've broken the prior email up into several different threads. As we don't have real distinguishing topical thread names, yet ... so I didn't see that as a problem. Apologies in advance if it's bothersome. The original thread continues on: 1. Setting aside irrelevant or incomplete histories 2. Meaning of Simple? Basis for concrete and specific requirements. 3. SAMLv2-LowLow: Bindings and Profiles?. ] Dick, Dick Hardt @ Tue, 14 Feb 2006 02:17:22 -0800 wrote: > SAML immediately implies an XML document. That is heavier then > name/value pairs. >On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote: > > > > 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 Yep, it's true that SAML is defined wrt an XML encoding for security assertions. So, yes, that's what SAMLv2 uses today, in its initial form. But, I'm not so sure that "SAML immediately implies an XML document," since, e.g., SAML includes aspects regarding HTTP cookies, and HTML form-encoded content. Beyond that, and more importantly, there are other crucial facets to SAMLv2: 1. SAML's built in extensibility and composability, so arguably it could be carried in any format; and, 2. SAML is more than the wire exchanges. I think that one could say that SAML is actually more about: a. The responsibilities of the entities who participate as SAML Requesters and Responders; and, b. The ability to bridge several regimes and domains, including: classes of authentication and the tokens and devices inherent therein; communication among and between attribute domains and authorities, even those using different mappings; the proxying and linking of different domains of authority; bridging between different domains, including X.509v3, LDAP, and Windows All of which makes it certainly more than about using XML to exchange assertions. But it's pretty good at that, so far. Let's continue the thinking with that SAMLv2-LowLow, assuming we've decided to create a minimized profile of SAMLv2, using its extensibility and composability features. We know the SSO HTTPPOST profile is entirely REST, so we can build from there. What we're thinking next is: what we'd like is a binding that is just name=value pairs, instead of those nasty scary pointy brackets. So let's do just that, say: SAML:2.0:bindings:HTTP-CGI Using this binding, any requester or responder could (create and canonicalize and) send those SAML-LowLow elements and attributes according to our defined serialization and encoding schemes. To complement this we'd like a profile where this binding would be used. Just quickly I'd guess we couldn't just add binding- specific processing rules to SAML's WebSSO HTTP POST profile, but we'd instead define a new profile: SAML:2.0:profiles:SSO:dix. Using this profile (which requires the HTTP-CGI binding) a SAMLv2 relying party (including Membersite) could use name-value pairs to talk to a SAML-LowLow supporting SAML IDP for authentication, and so on. - - - - Now, why do any of this? Especially when we could just plunk some hidden elements on a form? Well, first off, although we might be able to bend SAML to our purposes -- it's still a question whether we'd want to do that. The exercise is meant, more, to encourage us to not hold loosely- defined ideas as design criteria for a security protocol. I for one am looking for a specific statement of gaps, and a succinct statement of objectively-testable concrete goals. I think the threshold is higher than for something new in a new field. Second, as I discussed in another email, the Homesite isn't just some site that can process requests. The processing of even dmd00 holds intrinsic responsibilities and burdens on operations and security and privacy, among others. This is an important factor to any significant deployment of something like dmd00. The immediate implication is that processing from a SSO:dix Membersite to a SAMLv2 LowLow-IDP would offer that Membersite a significant trust authority. Third, this promises users and their Membersite-like relying parties a user-controlled gateway to a broad range of attributes and capabilities -- just the kind of things that we might want to pop up on our blogs, etc (geolocation, direct publication and community updating of media preferences, cross-family activities, etc.) Fourth, beyond simple attributes, this would provide the kind of interoperability that real end users and service providers, together, might appreciate. Use cases would include all the typical cross-overs, from corporate/school/medical/banking/media/ national/state to personal/entertainment/recreation/hobbies/writing and do that while assuring privacy, security, and independence across providers of all levels. Fifth, perhaps also because some of us would prefer to not be paying yet more license fees and device leases on more protocol gateways and bridges, with even more maintenance sync points, and points of failure. :-) Best, --Nick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 20 20:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMcd-0002yo-Rg; Mon, 20 Feb 2006 20:47:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMcd-0002yj-8N for dix@ietf.org; Mon, 20 Feb 2006 20:47:23 -0500 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBMcc-0005Ds-P1 for dix@ietf.org; Mon, 20 Feb 2006 20:47:23 -0500 Received: from user-10ib3g5.biz.mindspring.com ([65.37.142.5] helo=belka.radicalmode.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FBMcb-0005y4-00 for dix@ietf.org; Mon, 20 Feb 2006 20:47:22 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1FBMcb-0001vX-4o; Mon, 20 Feb 2006 17:47:21 -0800 From: Nick Ragouzis Send: Monday, February 20, 2006 5:47 PM To: dix@ietf.org, dix@enosis.com Message-Id: Date: Mon, 20 Feb 2006 17:47:21 -0800 X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: Subject: [dix] Setting aside irrelevant or incomplete histories 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: , Errors-To: dix-bounces@ietf.org [Thread note: To avoid expanding this email, and follow on digests, I've broken the prior email up into several different threads. As we don't have real distinguishing topical thread names, yet ... so I didn't see that as a problem. Apologies in advance if it's bothersome. The original thread continues on: 1. Setting aside irrelevant or incomplete histories 2. Meaning of Simple? Basis for concrete and specific requirements. 3. SAMLv2-LowLow: Bindings and Profiles?. ] Dick, Dick Hardt @ Tue, 14 Feb 2006 02:17:22 -0800 wrote: > On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote: Dick continued: > > Dick Hardt wrote: > >> 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. > > Not sure what your point is here, sorry. Great, then we're in agreement: lineage, even if appropriately described, is irrelevant to our challenges here. Dick continued: > Perhaps another way of looking at this is to ask the following > questions: > > Why is SAML not widely adopted? Why is it not being used at Amazon, > Yahoo!, Google or MSN? It has been around long enough. > Why was SMTP standardized when X.400 was being worked on? > Why was LDAP created when X.500 was looming? > > My opinion is because X.400 and X.500 were too heavy and did not > easily solve the problems people wanted to solve. > > SAML solves some people's problems, but clearly is not solving a > bunch of other people's problems, or it would have been > adopted by now. > > -- Dick Well, now we're back with that same sort of argument as with protocol lineage. I hope we will soon drop this sort of argument altogether. The DIX proposal should, on its own, have definite and specific descriptions of the gaps and directed fixes, along with the additions that pull it together. X.400 and X.500 might have been, be, too heavy, whatever that means. But if we are going to design for success on that basis, we'd also have to include other histories: A. All the 'light' protocols and extensions that also failed for one reason of another (lack of robustness, absence of integration and interoperability, poor extensibility ...); and, B. All the effort that's been required to unify these protocols with their forks. E.g., to fatten up LDAP. IOW, if we were going to use these sorts of generalizations, we'd have to be more accurate and relevant in any characterization that was intended to drive our decision making. And we'd have to consider a few other factors too: C. The fact that the community has learned a thing or two about how to build an extensible, composable protocol, so we're not working with the likes of X.400 here; and, D. The value of community resources, and the importance of not running off without thinking through the longer-term and combined effects. . . . . For those who are not easily convinced that these aren't useful arguments, I include the following, below: A summary profile of the extent of adoption for the SAML-LAP family of standards (and others that are included). For any of these entries you'd have to apply a multiplier. I don't know what those multipliers are, but they are very large, whether for multi-country deployments or single-use environments. On this basis you can hardly argue that SAML is "not widely adopted". Other mysteries remain, however. If we take that more seriously, for a minute, we, the community, could make some progress by setting straight any of the silly parochial notions that certain service providers have about what's strategically sound or not. Division and one-upsmanship on identity exchange is just silly nonsense. If we are appropriately determined, we will make sure in this effort that AS MUCH AS POSSIBLE (even if in some perspective a bit sub-optimally) we build our innovations on, and bridge across, existing systems as much as possible. --Nick Adoptions in SAML-LAP family standards. These are compiled from, mostly, secondary sources and publicly available information. Likely to be out-of-date, or in error. I haven't updated it in months with information I've received. (But please send info, I'm getting to an update.) Certainly incomplete: e.g., it doesn't account for the main body of the $1.2billion 2005worldwide estimate of Radicati Group; or for the millions of consumer identities coming online in several deployments; or for the count of actual students, researchers, and other users behind, e.g., the Shib deployments.) 1. Implementations Certified for SAMLv1.0 Artifact Profile in U.S. eGov E-Authentication Program: Entegrity, Entrust, Hewlett-Packard, IBM, CA/Netegrity, Novell, Oblix (Oracle), RSA Security, Sun Microsystems, Trustgenix (HP), DataPower (IBM); 2. Conformance-Tested Implementations of SAMLv2 (for various web single sign-on and SOAP profiles): Electronics and Telecommunications Research Institute (ETRI), Ericsson, Hewlett-Packard, IBM, NEC, NTT, Novell, Oracle, Reactivity, RSA Security, Sun Microsystems, Symlabs, Trustgenix (HP); 3. Demonstrated Mutual SAMLv2 Interoperability: ECA/Netegrity, DataPower (IBM), Entrust, NTT, OpenNetwork, Oracle, RSA Security, Sun Microsystems, Symlabs, Trustgenix (HP); 4. Conformance-Tested Implementations of ID-WSF1.0 and ID-WSF1.1: Hewlett-Packard, Nokia, Novell, NTT, Sun Microsystems, Symlabs, Trustgenix (HP);1 5. Adoption in other standards and recommendations:   -- ID-WSF1.1 in OMA (Open Mobile Alliance) in Web Services Enabler Releases, TV-Anytime Forum for AdvEPG (and therefore by the DVB Project) in Europe, Asia and Americas (possibly U.S.);   -- Liberty ID-FF1.2 in SAMLv2.0;   -- SAMLv2.0 in ebXML Registry v3.0, in WS-Security SAML Token Profile 1.1 (to be proposed), HIMSS IHE XUA for XDS (Global healthcare interoperability specification, cross-domain authentication including extended profiles), and in Liberty ID-WSF2.0;   -- SAMLv1.1 in Trusted Mobile Platform;   -- Microsoft and Sun Microsystem’s convergence profile of ID-FF1.2 (therefore SAMLv1.1) and WS-Federation in Web SSO Interop Profile and WS-MetadataExchange in Web SSO MEX;   -- Microsoft InfoCard (use of SAMLv2.0, now in demonstration, forthcoming in Vista, 4Q06);   -- Globus Tookit for Grid Security Infrastructure (use of SAMLv1.1 in OGSA; and GridShib Shib-to-glob attribute gateway); 6. Open Source or Developer Tools:   -- Entr’Overt Lasso (ID-FF1.2) for eGovernment; OpenSAML (SAMLv1.1, soon SAMLv2.0);   -- PingIdentity (SAML and ID-FF, and toolkit);   -- Sun Microsystems (ID-FF, and toolkit);   -- Shibboleth (SAMLv1.1, SAMLv2.0 imminent);   -- Oracle (toolkit);   -- NTT for vendor integration; Guanxi and Samuel (SAML1.1 and Shibboleth); 7. ID-WSF Deployments, including discovery and interaction services: AOL Radio@AOL, Axalto, Hewlett-Packard, Nokia (including in retail handsets), Novell, NTT, Sun Microsystems, Juniper Networks (embedded in VPN appliances), Symlabs, Trustgenix (HP); 8. Infrastructure and Embedded Implementations: Ericsson, Alcatel, Elios, Nokia, Trustgenix (HP), France Telecom/Orange, IBM, Sun Microsystems, NEC, NTT, NTT DoCoMo, Vodafone, Turkcell; 9. Education, Government, eHealth and Regulatory:   -- U.S. Government eGov E-Authentication (SAMLv1.0) for 14 major government agencies (The Danish Government have adopted this program, in SAMLv2.0);   -- BIPAC (ID-FF1.2) for regulatory-compliant employee participation in government independent of employer;   -- EduMart (ID-WSF1.1) in Japan for 98 public schools and 24 content providers;   -- HAKA Federation (Shibboleth) of Finnish universities, polytechnics, and research institutions;  -- Juniper Networks application at Catholic Health Systems in New York, NY;   -- InCommon (Shibboleth) 18 higher institutions of higher-education throughout the US, including the University of California, Cornell, Ohio State, University of Chicago, and several content providers, such as Elsevier ScienceDirect, as well as products such as Blackboard, WebCT, WebAssign, EBSCO, JSTOR, and SFX;   -- InQueue (Shibboleth) over 100 institutions across the Americas, Europe, and Asia in trial; -- Joint Warrior Interoperability Demonstration (JWID) 2003 with Canada, Australia, New Zealand, United States, United Kingdom, and Norway using ID-FF1.1 (larger group in CWID 2006);   -- SDSS (Shibboleth Development and Support Services) for Edima at Edinburgh University Data Liberty for a large collection of UK academic online resources (Shibboleth);   -- SWITCH Swiss education and Research Network (Shibboleth);  -- U.S. Department of Labor Mine Safety and Health Administration (likely SAMLv1.0); 10. Financial Services and related:   -- Fidelity Investments, in a corporate setting 401(k) management application, uses Liberty ID-FF, with identity services discovery techniques, and Liberty Identity Services Personal Profiles, to isolate corporate from personal persona;   -- Communicator’s SecuritiesHub (Citigroup, Credit Suisse First Boston, Goldman Sachs, JPMorgan Case & Co, Lehman Brothers, Merrill Lynch, Morgan Stanley, UBS Warburg) for over 24,000 institutional investors in 60 countries co-mingling 800 analysts results;   -- ACS Electronic Land Records Exchange (eRX) electronic recordation;   -- Nationwide Insurance throughout the producer channel;   -- Niteo, for the Financial Services Technology Consortium (FSTC), JPMorgan Chase, Wachovia, and Bank of America;   -- Workscape Inc. and Sun Microsystems providing General Motors’ 401(k) services portal;   -- XConnect’s partnership with eBIZ.mobility Federated Payment for fixed and mobile payments;   -- Other financial services companies thought to be active at some stage (Wells Fargo, AmericanExpress); 11. Airlines and related:   -- Star Alliance (Lufthansa, United Airlines, SAS Scandinavian Airlines, Thai Airways International, Air Canada and 10 more), for authentication and resources, with Novell;   -- JAL Online (travel planning, check-in, expenses and reimbursement to credit cards) with NTT Data;   -- Boeing in two applications, one for 500,000 former employees and beneficiaries, another for MyBoeingFleet for customer access to fleet operation and maintenance information; 12. Supply Chain Management:  -- Proctor & Gamble (also an employee gateway); Covisint (using RSA Security FIM, for Ford, DaimlerChrysler, Delphi, Visteon, Freightliner, Metaldyne, Mitsubishi); ??Oracle implies PeopleSoft and Siebel; ??SAP’s wide use of 13. Protocol gateways and bridging: Trustgenix (HP), PingIdentity, Sun Microsystem, BMC Software; 14. Other: Siemens HiPath DirX Access Federation (SAMLv1.0 and SAMLv1.1);  -- BEA, a SAMLv1.1 gateway on WebLogic Server;  -- Adobe in LiveCycle, SAMLv1.x, might be SAMLv2;  -- Evidian, with Deutsche Post on SAMLv1.1? (c. 2003) and Liberty id-ff1.2?. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 20 21:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBN5Y-0003cE-ST; Mon, 20 Feb 2006 21:17:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBN5X-0003c8-M1 for dix@ietf.org; Mon, 20 Feb 2006 21:17:15 -0500 Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBN5X-0005ad-Cp for dix@ietf.org; Mon, 20 Feb 2006 21:17:15 -0500 Received: from user-10ib3g5.biz.mindspring.com ([65.37.142.5] helo=belka.radicalmode.com) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FBN5W-0006qi-00 for dix@ietf.org; Mon, 20 Feb 2006 21:17:14 -0500 Received: from root by belka.radicalmode.com with local (Exim 4.22) id 1FBN5R-0001xt-EP; Mon, 20 Feb 2006 18:17:09 -0800 From: Nick Ragouzis Send: Monday, February 20, 2006 6:17 PM To: dix@ietf.org, dix@enosis.com Subject: Client Interaction and Automation (was Re: [dix] Review of draft-merrells-dix-00.txt) Message-Id: Date: Mon, 20 Feb 2006 18:17:09 -0800 X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: , Errors-To: dix-bounces@ietf.org > Dick Hardt wrote @ Mon, 13 Feb 2006 11:02:38 -0800 > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > > > Use of Javascript > > Section 5.10.2.1 reads: > > > > The Membersite sends a fetch-request message to the Homesite > > through > > the User's client via a redirected HTTP POST to their Homesite > > Endpoint URL using JavaScript to autosubmit the form. > > > > I appreciate the rationale for this: you want things to work with > > dumb clients but given that Javascript isn't any kind of IETF > > standard--it's hard to see how we could require it in an IETF > > standard. ECMASCript, perhaps. Even then, specifying this kind > > of implementation detail is the kind of thing that IETF typically > > stays out of. I appreciate that this is also a wire protocol issue, > > but given that there's no specification of the exact JavaScript > > incantation, it's not clear it makes sense to specify only > > the language. > > The protocol works without the ECMAScript, the user would need to > click another button to continue on with the exchange. The > ECMAScript > provides a more seamless use experience since a POST cannot be > redirected, and we did not want to limit the data to what could sit > on a URL, as well, did not want the data to have to be exposed by > being on a URL. As noted in another email, an enhanced browser does > not need to the ECMAScript. We see this as a boot strap method. > > wrt. how it is positioned in the ID, I agree it is an implementation > detail. How would you suggest that implementation hints like > this are > communicated? > > -- Dick Two things for me here. 1. This underscores that the FIRST consideration is the user interaction at this interface. That it *can* be automated doesn't relieve us of thinking fully about how it works when it isn't automated. This will unfold in an environment of wide diversity, to say the least. Who would be surprised if when plug in/extension makers, or browser designers, look at this they don't decide it is part of the same cloth in which users are asked to agree that a particular certificate should be Green in their address bar, or that a particular picture should be presented in association with a (selectable) range of sites? And so on. Even among the "dix-loyal," there will be a wide range of approaches to presentation, including unintended (or intended) confusion. If we elevate the true basis here, then surely we don't want yet another badly, partially, often-ineptly, followed way for users to see security prompts and dialogs. I suggest this is an effort worthy of specific attention. 2. The specification of ECMAScript does not belong in the normative part of this specification, IMO. In the first instance, it is a matter between the Home/Membersite and their common user. Each might do something different, according to the interaction they intend. In the second instance, what we need is the general requirement, without regard to implementation, buttressed by a method for judging compliance. The general requirement tends to things that any client service (presenting to the user at least a dumb HTTP client) must provide, including security and timing and presentation/affordances: whether on mobiles or on grid nodes. This, then, could even be implemented as an automated service of the browser, perhaps as a declared capability. The compliance method prescribes the appropriate tests. These are tests, I would think, that even a user could provoke, to be assured of the correct operation of this 'magic' with that all-so-valuable identity. The ECMAScript, or Java, or VBScript, or JScript, or Postscript, or whatever tools will realize this redirection when fully or partially automated (as we look to the future) ... well some implementation guidelines could be provided as examples. If ECMAScript (and JavaScript) happen to be the most broadly deployed, we're none-the-worse off. --Nick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 20 21:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBN6O-0003fX-43; Mon, 20 Feb 2006 21:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBN6N-0003fN-0W for dix@ietf.org; Mon, 20 Feb 2006 21:18:07 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBN6L-0005b6-CD for dix@ietf.org; Mon, 20 Feb 2006 21:18:06 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 83586142298; Mon, 20 Feb 2006 18:18:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15820-09; Mon, 20 Feb 2006 18:18:04 -0800 (PST) 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 2D6C1142293; Mon, 20 Feb 2006 18:18:02 -0800 (PST) In-Reply-To: References: 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: Lisa Dusseault Subject: Re: [dix] SAMLv2-LowLow: Bindings and Profiles? Date: Mon, 20 Feb 2006 18:17:48 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: dix@enosis.com 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: , Errors-To: dix-bounces@ietf.org On Feb 20, 2006, at 5:45 PM, Nick Ragouzis wrote: > > What we're thinking next is: what we'd like is a binding that is > just name=value pairs, instead of those nasty scary pointy > brackets. > I note that JSON has been submitted as an Internet-Draft: Lisa _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 00:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPeb-0007Xf-AH; Tue, 21 Feb 2006 00:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPeZ-0007Xa-Tn for dix@ietf.org; Tue, 21 Feb 2006 00:01:35 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBPeY-0001wt-Hs for dix@ietf.org; Tue, 21 Feb 2006 00:01:35 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1L51Vvx055079 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 20 Feb 2006 21:01:32 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Mon, 20 Feb 2006 21:01:25 -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: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [dix] requirements 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: , Errors-To: dix-bounces@ietf.org In preparation for a W3C workshop on authentication I submitted a paper on the requirements for a digital identity architecture. They're based on the Seven Laws of Identity, documented by Kim Cameron, and were used to drive our protocol design work at Sxip. I thought it might be useful input to the conversation here. John Blog Post: http://www.identity20.com/ Full Paper Here: http://identity20.com/media/images/W3CWebAuth_Sxip.pdf Kim's Work: http://www.identityblog.com/stories/2004/12/09/thelaws.html Summary of the requirements.... 1. Provide a mechanism for presenting users with the information that is being requested. 2. Provide a mechanism for users to identify the recipient of the identity information they release. 3. Provide a mechanism for relying parties to inform users of the reason for requesting the information and how the information will be used. 4. Provide a mechanism for users to compartmentalize their identity information according to the context of the interaction. 5. Provide a mechanism that ensures that user information is only released after the user consents to its release. 6. Provide a mechanism for the user to specify what the relying party can do with the information. 7. Provide users with a mechanism for granular control over the information that they are releasing. 8. Provide a mechanism for separating the transaction for acquiring a claim from the transaction for presenting a claim. 9. Provide users with the ability to choose their identity storage agent. 10. Provide pairwise identifiers for anonymous identity transactions. 11. Provide identifiers for public identity transactions. 12. Provide interoperability with existing platforms and standards. 13. Provide a low barrier to entry. 14. Provide a consistent user experience by ensuring that the user always sees the same agent, regardless of the context. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 00:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPpl-0007pJ-8f; Tue, 21 Feb 2006 00:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPpk-0007pE-AI for dix@ietf.org; Tue, 21 Feb 2006 00:13:08 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBPpk-0002ff-04 for dix@ietf.org; Tue, 21 Feb 2006 00:13:08 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1L5Cwqg055622 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 20 Feb 2006 21:12:59 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Meaning of Simple? Basis for concrete and specific requirements Date: Mon, 20 Feb 2006 21:13:01 -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 Cc: dix@enosis.com 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: , Errors-To: dix-bounces@ietf.org Taking me a while to digest all that Nick. But, to pick off one small bit to chew on a bit... On 20-Feb-06, at 5:42 PM, Nick Ragouzis wrote: > In that context, then, what is the objective test that separates > these issues? An unelaborated "Simple" isn't good enough for this > domain, particularly for a community-developed standard. > > The question is even one of "where?" Over the wire? Or within > the Homesite, or Membersite for the developer? And for whom? > On this latter question, it appears it can only be wrt the > developer at a Homesite or Membersite who develops the code > incantation that 'users' put in their cgi. The way I think about it is this... The goal is adoption... How do we get all parties to buy into talking this protocol, for the good of all. So, the parties are (using the dmd0 terms that I'm most familiar with: The User, The Homesite Developer, and The Membersite Developer. In my opinion the simplicity priorities are: 1) The User 2) The Membersite 3) The Homesite All complexity moves from the User to the MS to the HS... to the point of there being nothing to install on the user's machine, and for a Membersite being enabled with just some HTML editing. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 00:28:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQ4h-0008Ak-TX; Tue, 21 Feb 2006 00:28:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQ4g-0008Af-DY for dix@ietf.org; Tue, 21 Feb 2006 00:28:34 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBQ4g-0003K1-3I for dix@ietf.org; Tue, 21 Feb 2006 00:28:34 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1L5SPNq056078 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 20 Feb 2006 21:28:25 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3D4A053F-34B8-43CB-8F13-D9ADE222228D@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Bfcsr - PG1 Date: Mon, 20 Feb 2006 21:28: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: 9466e0365fc95844abaf7c3f15a05c7d Cc: dix@enosis.com 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: , Errors-To: dix-bounces@ietf.org Had to truncate that subject. On 20-Feb-06, at 5:42 PM, Nick Ragouzis wrote: > PG1. Existing protocol SAMLv2 uses XML; we want non-XML; > handling HTML and working with name-value pairs is > about right The driver here is simplicity for the Membersite. XML's just lovely, and as simple as it started out it now has its own complexities. For representation of attribute value assertions with values of simple types it's more than is required. A name-value pair is enough. The result is no requirement for XML handling at the Membersite. If a MS and HS wanted to exchange complex types, then yes there needs to be some way of structuring that data, and XML is one the obvious way to do that. There could be others. This could easily be layered on top of the basic protocol. Perhaps by extending an extensible property name and type mechanism. (This is intended in dmd0 via the Property Capability mechanism, although how property types are defined is left as an exercise for the reader ;-) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 00:53:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQSe-0000Oy-5V; Tue, 21 Feb 2006 00:53:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQSc-0000Ot-Lh for dix@ietf.org; Tue, 21 Feb 2006 00:53:18 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBQSc-0003fW-Bb for dix@ietf.org; Tue, 21 Feb 2006 00:53:18 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1L5r9f4056801 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 20 Feb 2006 21:53:10 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Bfcasr - PG2 Date: Mon, 20 Feb 2006 21:53: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: 9466e0365fc95844abaf7c3f15a05c7d Cc: dix@enosis.com 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: , Errors-To: dix-bounces@ietf.org On 20-Feb-06, at 5:42 PM, Nick Ragouzis wrote: > PG2. Existing protocol SAMLv2 is heavy; we want light. Well 'heavy' and 'light' aren't very rigorous... but I'd say this goes back to the adoption goal: 'How do we get an internet wide identity protocol into everyone's hands as quickly as possible?' As a slight aside, in your 'Setting aside irrelevant or incomplete histories' post you had lots of nice data points about SAML deployments. Enlightened me actually. SAML's clearly offering people enough value that people are building businesses around it and it's being deployed by big corporations. But... in all my years of Internet surfing I've never come across a website that said 'Take me to your IdP...', or 'Can I be your Idp...' Never. Am I just cruising the web with my blinkers on? There's something about SAML that's meant that developers of the websites that I frequent haven't chosen to deploy it. Why is that? That's kinda rhetorical, but I don't want to rant about why SAML doesn't work for me as a User, Membersite or Homesite developer, I'd rather one of them stood up and said it. I think we need to drill into the reasons for PG2. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 01:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQZR-0000n8-PL; Tue, 21 Feb 2006 01:00:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQZR-0000n3-Aa for dix@ietf.org; Tue, 21 Feb 2006 01:00:21 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBQZR-0003lD-03 for dix@ietf.org; Tue, 21 Feb 2006 01:00:21 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1L60CBW057642 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 20 Feb 2006 22:00:13 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14FAECAE-B30A-43B9-9B0C-D83EC84367B0@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Bfcasr - PG3 Date: Mon, 20 Feb 2006 22:00: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: 79899194edc4f33a41f49410777972f8 Cc: dix@enosis.com 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: , Errors-To: dix-bounces@ietf.org On 20-Feb-06, at 5:42 PM, Nick Ragouzis wrote: > PG3. We don't want to use XML-DSIG. Not that we don't want to, just that it's more than is required. The minimum requirement is to be able to exchange an attribute value assertions between Homesites and Membersites. That's enough to exchnage self-asserted values, either simple types as literals or complex types as XML.... and also enough to exchange third-party asserted values as digitally signed values, which could be XML-DSIG. So, if required, could be layered on top, but don't need to be in the lowest layer of protocol, lest they hamper adoption, which we at Sxip found that they did. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 01:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBRBQ-0001rt-Jo; Tue, 21 Feb 2006 01:39:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBRBQ-0001rn-7M for dix@ietf.org; Tue, 21 Feb 2006 01:39:36 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBRBN-00059q-TB for dix@ietf.org; Tue, 21 Feb 2006 01:39:36 -0500 Received: from [10.0.1.21] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1L6dOI8059259 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 20 Feb 2006 22:39:25 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21A92256-F178-4D6F-B16E-042CB47AE93C@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Bfcasr - PPC1-7 Date: Mon, 20 Feb 2006 22:39: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.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: dix@enosis.com 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: , Errors-To: dix-bounces@ietf.org Will work though these myself asap, but am a bit tired and have to get up early tomorrow. Would love to hear what other's think of these points extracted by Nick. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 04:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTnn-0001rf-0D; Tue, 21 Feb 2006 04:27:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBTnm-0001rX-Hi for dix@ietf.org; Tue, 21 Feb 2006 04:27:22 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBTnk-000278-Ad for dix@ietf.org; Tue, 21 Feb 2006 04:27:22 -0500 Received: from lavazza.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 932B84F46E; Tue, 21 Feb 2006 04:27:19 -0500 (EST) Received: from roessler by lavazza.does-not-exist.org with local (Exim 4.54) id 1FBTni-0003m5-TK; Tue, 21 Feb 2006 10:27:18 +0100 Date: Tue, 21 Feb 2006 10:27:18 +0100 From: Thomas Roessler To: John Merrells Subject: Re: [dix] requirements Message-ID: <20060221092718.GB14180@lavazza.does-not-exist.org> Mail-Followup-To: John Merrells , Digital Identity Exchange References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Digital Identity Exchange 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: , Errors-To: dix-bounces@ietf.org On 2006-02-20 21:01:25 -0800, John Merrells wrote: > In preparation for a W3C workshop on authentication I > submitted a paper on the requirements for a digital identity > architecture. > Blog Post: http://www.identity20.com/ > Full Paper Here: http://identity20.com/media/images/W3CWebAuth_Sxip.pdf > Kim's Work: http://www.identityblog.com/stories/2004/12/09/thelaws.html Workshop web site, with links to all the position papers: http://www.w3.org/2005/Security/usability-ws/ Just FYI... Regards, -- Thomas Roessler, W3C _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 09:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYI7-0008K5-69; Tue, 21 Feb 2006 09:14:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBYI5-0008Js-5C for dix@ietf.org; Tue, 21 Feb 2006 09:14:57 -0500 Received: from uproxy.gmail.com ([66.249.92.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBYI2-0003z7-RN for dix@ietf.org; Tue, 21 Feb 2006 09:14:57 -0500 Received: by uproxy.gmail.com with SMTP id m3so663321ugc for ; Tue, 21 Feb 2006 06:14:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RCd5I5K5E8cPJobbzV0h6wrhM0OSYbFTi6yLvbBJ+RHDMvatGSQhz4dirskKGjEAJNMTYVvA5V+wOmsbTcIdG/enigECmTQU/QtthW7JSG61raf2hHAN3mtJT1J4amBWCRfCny7F6hNTuDCmNnhEN7kmxLOjMvu5txDBlUzGx8g= Received: by 10.66.250.9 with SMTP id x9mr2711522ugh; Tue, 21 Feb 2006 06:14:53 -0800 (PST) Received: by 10.67.21.20 with HTTP; Tue, 21 Feb 2006 06:14:53 -0800 (PST) Message-ID: <6f64bf7f0602210614t3324a0dat729833e4a2bf865b@mail.gmail.com> Date: Tue, 21 Feb 2006 09:14:53 -0500 From: "rob yates" To: dix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [dix] scope question - proxy authentication and then some thoughts about ticket based approaches 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: , Errors-To: dix-bounces@ietf.org I have a question on the scope of DIX. I have read the current draft and the use cases and it seems to be inline with openid / lid approaches. We have investigated the use of these protocols in some detail and one of the issues that seems to surface pretty quickly in real world scenarios is how one system can access another systems data acting as a proxy for a user. For example, I store my pictures on flickr and make some of these pictures "private" (only I can see them). I now want to use the printing services offered by http://www.qoop.com/ to access my flickr pictures. How does qoop authenticate with the flickr back end service to get to my private pictures and how does it state that it is acting on my behalf. I just wonder whether this is a use case you are considering for the core specification. Thanks, Rob p.s. in case I lost you in my scenario, see "proxy authentication" http://www.ja-sig.org/products/cas/overview/proxy_auth/index.html in JA-SIG's Central Authentication System (CAS) http://www.ja-sig.org/products/cas/index.html. p.p.s. Are any CAS developers participating in this working group? p.p.p.s. I notice that the current specification is relying on HMAC, has there been any consideration to a ticket based approach like the one outlined in CAS. Similar approaches seem to be pretty widespread http://dystopics.dump.be/2006/02/04/the-mysteries-of-x-google-token-and-why= -it-matters/ and it could be argued that CAS is more lightweight than openid / lid / dix, it doesn't get much simpler than this http://www.ja-sig.org/products/cas/overview/cas1_architecture/index.html. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 21 12:09:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBb0d-00042V-B7; Tue, 21 Feb 2006 12:09:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBb0b-00042K-RM for dix@ietf.org; Tue, 21 Feb 2006 12:09:05 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBb0a-0005h1-Le for dix@ietf.org; Tue, 21 Feb 2006 12:09:05 -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 k1LH94BW026502 for ; Tue, 21 Feb 2006 17:09:04 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 12:09: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 ; Tue, 21 Feb 2006 17:09:03 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 21 Feb 2006 12:09:02 -0500 Subject: Re: [dix] Bfcasr - PG2 From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: [dix] Bfcasr - PG2 Thread-Index: AcY3CYMUwaXcfKL8Edq9YAANk3jHKA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Feb 2006 17:09:04.0167 (UTC) FILETIME=[845EB370:01C63709] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: dix-bounces@ietf.org On 2/21/2006 12:53 AM, "John Merrells" wrote: > > On 20-Feb-06, at 5:42 PM, Nick Ragouzis wrote: > >> PG2. Existing protocol SAMLv2 is heavy; we want light. > > But... in all my years of Internet surfing > I've never come across a website that said 'Take me to your IdP...', or > 'Can I be your Idp...' Never. Am I just cruising the web with my > blinkers on? That's because good SAML deployments make this a seamless experience for the user ;-). The impediments for deploying federated architectures have little to do with technology. Federated identity management introduces new business and legal complexities which many are only now coming to terms with. The technology is there, in a number of forms (which is why I'm loath to add yet another form unless it's absolutely necessary). =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Feb 22 00:26:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmW4-0001l1-Ra; Wed, 22 Feb 2006 00:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmW3-0001kw-HO for dix@ietf.org; Wed, 22 Feb 2006 00:26:19 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBmW2-00080L-4f for dix@ietf.org; Wed, 22 Feb 2006 00:26:19 -0500 Received: from [192.168.0.3] (adsl-71-131-78-135.dsl.sntc01.pacbell.net [71.131.78.135]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1M5QrGY024272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Feb 2006 21:26:54 -0800 Message-ID: <43FBF5F5.5010909@dcrocker.net> Date: Tue, 21 Feb 2006 21:26:13 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > Summary of the requirements.... While I understand that reading the cited material will, no doubt, answer basic questions, I'll use the fact that you provided a summary to justify asking a few, basic questions. Your summary list does not seem to answer them, yet I believe the answers to these questions provide a basis for evaluating something like the summary list you provided. That is, I see your summary list is mostly about mechanism, whereas my own questions are about motivating factors: 1. What problem does DIX solve and for whom? How is the problem currently manifest? 2. What does a basic scenario for using DIX look like? That is, who are the typical actors and what are their typical interactions, for a single, "complete" use of DIX? 3. From the summary, I cannot tell what the actual "identity" is, where it comes from, and whether or how it is assured uniqueness. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Feb 22 09:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBv8e-0007XU-DU; Wed, 22 Feb 2006 09:38:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBv8e-0007XM-01 for dix@ietf.org; Wed, 22 Feb 2006 09:38:44 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBv8d-0006OD-QM for dix@ietf.org; Wed, 22 Feb 2006 09:38:43 -0500 Received: from [127.0.0.1] (stdhcp-229.va.neustar.com [10.31.13.229]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1MEcdBY029741; Wed, 22 Feb 2006 14:38:43 GMT Message-ID: <43FC7769.3050306@neustar.biz> Date: Wed, 22 Feb 2006 06:38:33 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: are you attending Dallas IETF? (was: Re: [dix] Meaning of Simple? Basis for concrete and specific requirements) 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: 6d62ab47271805379d7172ee693a45db 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: , Errors-To: dix-bounces@ietf.org are you attending Dallas IETF? just curious. I'll be there. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Feb 22 11:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxF1-00087w-9y; Wed, 22 Feb 2006 11:53:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxEz-00087h-Q8 for dix@ietf.org; Wed, 22 Feb 2006 11:53:25 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBxEy-0003mt-Gy for dix@ietf.org; Wed, 22 Feb 2006 11:53:25 -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 k1MGrN7L003458 for ; Wed, 22 Feb 2006 08:53:23 -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, 22 Feb 2006 08:53:23 -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: Wed, 22 Feb 2006 08:53:23 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792AC8B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dix BOF, Monday 1 thru 3pm Thread-Index: AcY2pAHVJlAw3gA+TOiDvTI9HZbJPQBLBkSA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 22 Feb 2006 16:53:23.0380 (UTC) FILETIME=[7E07BF40:01C637D0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [dix] Dix BOF, Monday 1 thru 3pm 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: , Errors-To: dix-bounces@ietf.org This is in conflict with DKIM.=20 I am not sure if I am the only person affected by the conflict but it is going to be a problem for me and probaly many of the security people. If we could get the BOF moved to Tuesday there are only five things going on.=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Feb 22 11:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxHU-0008W5-RC; Wed, 22 Feb 2006 11:56:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxHT-0008VZ-My for dix@ietf.org; Wed, 22 Feb 2006 11:55:59 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBxHS-0003qS-HP for dix@ietf.org; Wed, 22 Feb 2006 11:55:59 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Wed, 22 Feb 2006 11:55:14 -0500 id 01588148.43FC9772.0000252E From: "Scott Hollenbeck" To: "'Digital Identity Exchange'" Subject: RE: [dix] Dix BOF, Monday 1 thru 3pm Date: Wed, 22 Feb 2006 11:56:18 -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: <198A730C2044DE4A96749D13E167AD3792AC8B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcY2pAHVJlAw3gA+TOiDvTI9HZbJPQBLBkSAAAAnSlA= Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: dix-bounces@ietf.org > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Wednesday, February 22, 2006 11:53 AM > To: Digital Identity Exchange > Subject: [dix] Dix BOF, Monday 1 thru 3pm > > This is in conflict with DKIM. > > I am not sure if I am the only person affected by the > conflict but it is > going to be a problem for me and probaly many of the security people. > > If we could get the BOF moved to Tuesday there are only five things > going on. Others have noted this conflict as well. Your BOF chairs should work with the Secretariat to resolve the conflict. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Feb 22 12:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxXi-0002z1-Ls; Wed, 22 Feb 2006 12:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxXh-0002yr-Ux for dix@ietf.org; Wed, 22 Feb 2006 12:12:45 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBxXh-0004e4-Kf for dix@ietf.org; Wed, 22 Feb 2006 12:12:45 -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 k1MHCjar009598 for ; Wed, 22 Feb 2006 09:12:45 -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, 22 Feb 2006 09:12:44 -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] Dix BOF, Monday 1 thru 3pm Date: Wed, 22 Feb 2006 09:12:44 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792AC96@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Dix BOF, Monday 1 thru 3pm Thread-Index: AcY2pAHVJlAw3gA+TOiDvTI9HZbJPQBLBkSAAAAnSlAAAJVvgA== From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 22 Feb 2006 17:12:44.0444 (UTC) FILETIME=[32140DC0:01C637D3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: dix-bounces@ietf.org I wanted to see if the problem was more widespread first. It is a particular problem given that this is the first DIX BOF and the first DKIM meeting. =20 > -----Original Message----- > From: Scott Hollenbeck [mailto:sah@428cobrajet.net]=20 > Sent: Wednesday, February 22, 2006 11:56 AM > To: 'Digital Identity Exchange' > Subject: RE: [dix] Dix BOF, Monday 1 thru 3pm >=20 > > -----Original Message----- > > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > > Sent: Wednesday, February 22, 2006 11:53 AM > > To: Digital Identity Exchange > > Subject: [dix] Dix BOF, Monday 1 thru 3pm > >=20 > > This is in conflict with DKIM.=20 > >=20 > > I am not sure if I am the only person affected by the=20 > conflict but it=20 > > is going to be a problem for me and probaly many of the security=20 > > people. > >=20 > > If we could get the BOF moved to Tuesday there are only five things=20 > > going on. >=20 > Others have noted this conflict as well. Your BOF chairs=20 > should work with the Secretariat to resolve the conflict. >=20 > -Scott- >=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 Feb 22 12:32:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxqP-00042y-WB; Wed, 22 Feb 2006 12:32:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxqO-00042n-8a for dix@ietf.org; Wed, 22 Feb 2006 12:32:04 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBxqM-0005Vt-Hq for dix@ietf.org; Wed, 22 Feb 2006 12:32:04 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D842A1422A6 for ; Wed, 22 Feb 2006 09:32:01 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15659-04 for ; Wed, 22 Feb 2006 09:32:01 -0800 (PST) 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 316001422A3 for ; Wed, 22 Feb 2006 09:32:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792AC96@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792AC96@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B601302-2ECC-47FA-A9AD-6389F85BF35F@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Dix BOF, Monday 1 thru 3pm Date: Wed, 22 Feb 2006 09:31:47 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: dix-bounces@ietf.org I'm confident it's a problem :) I'll follow up, thanks for catching it. Lisa On Feb 22, 2006, at 9:12 AM, Hallam-Baker, Phillip wrote: > I wanted to see if the problem was more widespread first. > > It is a particular problem given that this is the first DIX BOF and > the > first DKIM meeting. > >> -----Original Message----- >> From: Scott Hollenbeck [mailto:sah@428cobrajet.net] >> Sent: Wednesday, February 22, 2006 11:56 AM >> To: 'Digital Identity Exchange' >> Subject: RE: [dix] Dix BOF, Monday 1 thru 3pm >> >>> -----Original Message----- >>> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] >>> Sent: Wednesday, February 22, 2006 11:53 AM >>> To: Digital Identity Exchange >>> Subject: [dix] Dix BOF, Monday 1 thru 3pm >>> >>> This is in conflict with DKIM. >>> >>> I am not sure if I am the only person affected by the >> conflict but it >>> is going to be a problem for me and probaly many of the security >>> people. >>> >>> If we could get the BOF moved to Tuesday there are only five things >>> going on. >> >> Others have noted this conflict as well. Your BOF chairs >> should work with the Secretariat to resolve the conflict. >> >> -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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Feb 24 12:10:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgS7-0006aG-0K; Fri, 24 Feb 2006 12:09:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgS4-0006a8-V0 for dix@ietf.org; Fri, 24 Feb 2006 12:09:57 -0500 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 1FCgS3-0001lH-Ce for dix@ietf.org; Fri, 24 Feb 2006 12:09:56 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id A01CC4BADE2; Fri, 24 Feb 2006 10:09:57 -0700 (MST) Message-ID: <43FF3DE5.7080709@jabber.org> Date: Fri, 24 Feb 2006 10:09:57 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: dcrocker@bbiw.net, Digital Identity Exchange Subject: Re: [dix] requirements References: <43FBF5F5.5010909@dcrocker.net> In-Reply-To: <43FBF5F5.5010909@dcrocker.net> X-Enigmail-Version: 0.94.0.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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: , Content-Type: multipart/mixed; boundary="===============1475003541==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1475003541== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080400090109020108080302" This is a cryptographically signed message in MIME format. --------------ms080400090109020108080302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Crocker wrote: >> Summary of the requirements.... > > While I understand that reading the cited material will, no doubt, > answer basic questions, I'll use the fact that you provided a summary to > justify asking a few, basic questions. Your summary list does not seem > to answer them, yet I believe the answers to these questions provide a > basis for evaluating something like the summary list you provided. > > That is, I see your summary list is mostly about mechanism, whereas my > own questions are about motivating factors: > > > 1. What problem does DIX solve and for whom? How is the problem > currently manifest? > > 2. What does a basic scenario for using DIX look like? That is, who are > the typical actors and what are their typical interactions, for a > single, "complete" use of DIX? > > 3. From the summary, I cannot tell what the actual "identity" is, where > it comes from, and whether or how it is assured uniqueness. Good questions. I helped write the spec for a technology called Passel that attempted to solve some problems in this space, and the whitepaper may be of interest to those on this list: http://passel.org/whitepaper.html Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD/z3lNF1RSzyt3NURAna3AJ4k0BRlXpfxfzMS6nfmm6b27//s7QCfQHUF b5y8JkgihdL75SL5patboYY= =GGpQ -----END PGP SIGNATURE----- --------------ms080400090109020108080302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 hkiG9w0BCQUxDxcNMDYwMjI0MTcwOTU3WjAjBgkqhkiG9w0BCQQxFgQUOWHPFVPFBpeXLxjo eE7zQN2UB1MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAL5a6dnXr1h01Jivf8+ArcYDnd7/z+v/ fDi2VUx7/ysS01QzZBoIO32o7EPT3ZonOxYvTiBcEB+tXpBLNMOqWwvUiO74tITK1EdBYu+Z wZP4JPhru9N0fBn7E6qEGMJU7UUJV8xJTOIFZ9FD01QmrpjoMSRDXkzHW7JiKYO8nPk69zF9 aHOvZkGOo9aCatSZCAJsWrlZf1dIp1GcOzqS4m0WfLzcGh7cJXpZ+hZ58lc7981fOE3TKYzB 8NmSKVeJL1g9o1izH5g1Fv7EUrZyLuwXxAx92SO88h0K0KIwNmo84c2l5/UTekmvIEvoko8+ vE7hL8CJtuaEEWe8N3j08AoAAAAAAAA= --------------ms080400090109020108080302-- --===============1475003541== 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 --===============1475003541==-- From dix-bounces@ietf.org Fri Feb 24 12:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgZr-00038B-C3; Fri, 24 Feb 2006 12:17:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgZp-000383-Vx for dix@ietf.org; Fri, 24 Feb 2006 12:17:57 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCgZn-000226-K9 for dix@ietf.org; Fri, 24 Feb 2006 12:17:57 -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 k1OHHqcD079442 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2006 09:17:54 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43FF3DE5.7080709@jabber.org> References: <43FBF5F5.5010909@dcrocker.net> <43FF3DE5.7080709@jabber.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88D59F1B-1010-4668-86C8-9BFC25725D50@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] requirements Date: Fri, 24 Feb 2006 09:17: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: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: dix-bounces@ietf.org On 24-Feb-06, at 9:09 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dave Crocker wrote: > >>> Summary of the requirements.... >> >> While I understand that reading the cited material will, no doubt, >> answer basic questions, I'll use the fact that you provided a >> summary to >> justify asking a few, basic questions. Your summary list does not >> seem >> to answer them, yet I believe the answers to these questions >> provide a >> basis for evaluating something like the summary list you provided. >> >> That is, I see your summary list is mostly about mechanism, >> whereas my >> own questions are about motivating factors: >> >> >> 1. What problem does DIX solve and for whom? How is the problem >> currently manifest? >> >> 2. What does a basic scenario for using DIX look like? That is, >> who are >> the typical actors and what are their typical interactions, for a >> single, "complete" use of DIX? >> >> 3. From the summary, I cannot tell what the actual "identity" is, >> where >> it comes from, and whether or how it is assured uniqueness. > > Good questions. > > I helped write the spec for a technology called Passel that > attempted to > solve some problems in this space, and the whitepaper may be of > interest > to those on this list: > > http://passel.org/whitepaper.html Peter, will you be at the BOF, and if so, would you present the Passel work? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Feb 24 12:39:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCguN-0000hk-KS; Fri, 24 Feb 2006 12:39:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCguM-0000hc-1R for dix@ietf.org; Fri, 24 Feb 2006 12:39:10 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCguK-000344-KU for dix@ietf.org; Fri, 24 Feb 2006 12:39:10 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1OHdh8q005769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 09:39:43 -0800 Message-ID: <43FF44B8.4030007@dcrocker.net> Date: Fri, 24 Feb 2006 09:39:04 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [dix] requirements References: <43FBF5F5.5010909@dcrocker.net> <43FF3DE5.7080709@jabber.org> In-Reply-To: <43FF3DE5.7080709@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > Good questions. > > I helped write the spec for a technology called Passel that attempted to > solve some problems in this space, and the whitepaper may be of interest > to those on this list: > > http://passel.org/whitepaper.html Something like that provides good input. However... I think the real issue is getting participants on the list to share a basic model. External papers won't do that. The summary list that prompted my own questions was specifically useful for making explicit, brief statements to the group, for the group to consider. My feeling is that we need to do same, simple, explicit thing for answering the questions I asked. Until we have that, and until we have converged on agreement about the answers, we are likely -- actually I consider it a certainty -- to have folks wandering about the mailing list with wildly different assumptions and expectations about the work and the desired output. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Feb 24 13:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChWb-0003qG-05; Fri, 24 Feb 2006 13:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChWZ-0003lr-1a for dix@ietf.org; Fri, 24 Feb 2006 13:18:39 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChWW-0004Y0-9f for dix@ietf.org; Fri, 24 Feb 2006 13:18:39 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A483B142283; Fri, 24 Feb 2006 10:18:35 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04722-05; Fri, 24 Feb 2006 10:18:35 -0800 (PST) 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 198C6142279; Fri, 24 Feb 2006 10:18:34 -0800 (PST) In-Reply-To: <43FF44B8.4030007@dcrocker.net> References: <43FBF5F5.5010909@dcrocker.net> <43FF3DE5.7080709@jabber.org> <43FF44B8.4030007@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9626CADD-695C-4576-AA0A-1770D7CE08B4@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] requirements Date: Fri, 24 Feb 2006 10:18:19 -0800 To: dcrocker@bbiw.net, Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: dix-bounces@ietf.org Dave, It's my hope that some illustrative examples, if presented briefly and succinctly more for their goals/differences than for their technical details, will be of great help. Examples can: - help people understand abstract goals, and as importantly, understand them in the same way (I've seen people interpret a requirement like "privacy" very differently and not even realize their different interpretations, until concrete cases came up) - convince BOF attendees who haven't worked on such a system personally that such systems exist, are deployed, are not theoretical or research I'll work with the BOF speakers to make sure that the presentations of existing solutions focus on high-level stuff: problem statement, goals and requirements, models and key differences. I do agree with your list of questions and that they need to be answered, let's work on that. I encourage the people involved in SXIP and Passel and anything else to post real use cases they feel are particularly illustrative. In the meantime, I expect people participating on this list in advance of the BOF to read the documentary input. Thanks, Lisa On Feb 24, 2006, at 9:39 AM, Dave Crocker wrote: > > >> Good questions. >> I helped write the spec for a technology called Passel that >> attempted to >> solve some problems in this space, and the whitepaper may be of >> interest >> to those on this list: >> http://passel.org/whitepaper.html > > > Something like that provides good input. > > However... > > I think the real issue is getting participants on the list to share > a basic > model. External papers won't do that. > > The summary list that prompted my own questions was specifically > useful for > making explicit, brief statements to the group, for the group to > consider. My > feeling is that we need to do same, simple, explicit thing for > answering the > questions I asked. > > Until we have that, and until we have converged on agreement about > the answers, > we are likely -- actually I consider it a certainty -- to have > folks wandering > about the mailing list with wildly different assumptions and > expectations about > the work and the desired output. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > > > _______________________________________________ > 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 Feb 24 14:13:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCiNS-0004fw-KN; Fri, 24 Feb 2006 14:13:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCiNR-0004fo-MS for dix@ietf.org; Fri, 24 Feb 2006 14:13:17 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCiNQ-0005wb-Av for dix@ietf.org; Fri, 24 Feb 2006 14:13:17 -0500 Received: from [192.168.6.201] (dhcp201.sxip.com [192.168.6.201]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1OJDF3i085535 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 24 Feb 2006 11:13:15 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <6f64bf7f0602210614t3324a0dat729833e4a2bf865b@mail.gmail.com> References: <6f64bf7f0602210614t3324a0dat729833e4a2bf865b@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1755E017-08F2-44C4-9FC5-9126398E780D@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] scope question - proxy authentication and then some thoughts about ticket based approaches Date: Fri, 24 Feb 2006 11:13: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: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: dix-bounces@ietf.org On 21-Feb-06, at 6:14 AM, rob yates wrote: > I have a question on the scope of DIX. I have read the current draft > and the use cases and it seems to be inline with openid / lid > approaches. > > We have investigated the use of these protocols in some detail and one > of the issues that seems to surface pretty quickly in real world > scenarios is how one system can access another systems data acting as > a proxy for a user. I like the term 'agency' for this scenario. > For example, I store my pictures on flickr and > make some of these pictures "private" (only I can see them). I now > want to use the printing services offered by http://www.qoop.com/ to > access my flickr pictures. How does qoop authenticate with the flickr > back end service to get to my private pictures and how does it state > that it is acting on my behalf. In your example 'qoop' is acting as an agent on your behalf. How does qoop get access to your data stored at flickr without being you? I do not believe this is in scope for DIX, but I think that DIX should enable this at a lower level. A solution to the problem is for the user to provide the agent with a token that allows them access to the data (the photo). Using dmd0: User instructs Agent (qoop) to perform action (print photo), Agent requests token (dmd0 fetch), Homesite doesn't have token so refers user to token generator (flickr), User authenticates and receives token, which they store at their Homesite (dmd0 store), User returns to Agent, Agent requests token (dmd0 fetch), Homesite provides Agent with token, Agent makes call on data source (flickr) with token as parameter. Out of Scope: Token definition. [There are many existing token definitions, e.g. SAML] Tokens in Web Services calls. (REST, SOAP, etc) [Could be WS-*, or at HTTP layer.] > I just wonder whether this is a use case you are considering for the > core specification. Not for the 'core', but certainly could be layered on top, or extended. This is something we've been thinking about at Sxip, and will present here, or in wherever forum seems most appropriate, if there's demand for it. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Feb 25 13:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD3my-00038b-Jp; Sat, 25 Feb 2006 13:05:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD3mx-00037Z-C5 for dix@ietf.org; Sat, 25 Feb 2006 13:05:03 -0500 Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD3mx-0007fX-3w for dix@ietf.org; Sat, 25 Feb 2006 13:05:03 -0500 Received: by wproxy.gmail.com with SMTP id 36so849775wra for ; Sat, 25 Feb 2006 10:05:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=oSSIEz7LP88639tDstqnQfhzfGWWK2wVJqtOlB06x8d1x7npAmFmF7o+RIQnMwCE+EuSRfJZWVZABLHMJD9oiIcjTcZw3d8CVz2K3dWgzY5FxvkNFbOmcrIoqqiYY5uVG8as3LJM4uQe57frdZB7QYtzFRWxhuTuT26MOIl17Iw= Received: by 10.54.148.11 with SMTP id v11mr2664251wrd; Sat, 25 Feb 2006 10:05:02 -0800 (PST) Received: from ?192.168.1.3? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 6sm1568460wrl.2006.02.25.10.05.01; Sat, 25 Feb 2006 10:05:02 -0800 (PST) Message-ID: <44009C4C.7040507@gmail.com> Date: Sat, 25 Feb 2006 13:05:00 -0500 From: robert yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [dix] character encoding in draft-merrells-dix-00.txt 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: , Errors-To: dix-bounces@ietf.org Am no expert on character encodings, but are there a few issues with the current draft and character encoding? Namely, 1) The fields dix:/message-type, dix:/membersite-url, dix:/signature and possibly others require Latin characters in their contents. However isn't a browser free to post the form with a character encoding that does not permit these characters? 2) The Canonicalization Algorithm relies on the browser posting the form in the same character encoding used by the server to generate it. With the current draft this can this be guaranteed? This article http://www-306.ibm.com/software/globalization/misc/code_considerations/index.jsp provides for a good overview of the problem, although may be a bit out of date. Having read this what do folks think of the following proposal to address the above issues. The dix spec ensures that information is always exchanged (via the browser) encoded as UTF8. It does this by stating that the character encoding of the forms pages must be UTF8 and also mandates the following rules for the html forms used for the data transportation. 1. The HTML head section of the form MUST contain . There needs to be a corresponding statement for XHTML. 2. The FORM element MUST contain the Accept-Charset attribute and it MUST be set to 'utf-8'i.e.

The Canonicalization Algorithm can also now probably be simplified a bit by stating that the sort is a byte sort of the utf8 representation. Also, does it not make sense to have the verify step be a REST style xml web service vs. this current form POST. XML seems much better suited to these character encoding issues than "application/x-www-form-urlencoded". Who knows whether the libraries for Ruby, Python, Java et al will be consistent with how they perform their character encoding. **Rob p.s. also in the spirit of internationalization I notice references to first and last name properties in the specification. Have you investigated the possibility of using vCards xml namespace " http://www.w3.org/2001/vcard-rdf/3.0#" for identifying user properties? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Feb 25 13:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD4MK-00033u-PW; Sat, 25 Feb 2006 13:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD4MK-00033p-B9 for dix@ietf.org; Sat, 25 Feb 2006 13:41:36 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD4MH-0000UZ-Vf for dix@ietf.org; Sat, 25 Feb 2006 13:41:36 -0500 Received: from [192.168.1.104] (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 k1PIfWo5022862 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 25 Feb 2006 10:41:32 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44009C4C.7040507@gmail.com> References: <44009C4C.7040507@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44F8D78E-B12D-4498-A556-9C0FA0831282@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] character encoding in draft-merrells-dix-00.txt Date: Sat, 25 Feb 2006 10:41: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: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: dix-bounces@ietf.org On 25-Feb-06, at 10:05 AM, robert yates wrote: > Am no expert on character encodings, but are there a few issues > with the current draft and character encoding? Namely, > > 1) The fields dix:/message-type, dix:/membersite-url, dix:/ > signature and possibly others require Latin characters in their > contents. However isn't a browser free to post the form with a > character encoding that does not permit these characters? > 2) The Canonicalization Algorithm relies on the browser posting the > form in the same character encoding used by the server to generate > it. With the current draft this can this be guaranteed? > > This article http://www-306.ibm.com/software/globalization/misc/ > code_considerations/index.jsp provides for a good overview of the > problem, although may be a bit out of date. Having read this what > do folks think of the following proposal to address the above issues. > > The dix spec ensures that information is always exchanged (via the > browser) encoded as UTF8. It does this by stating that the > character encoding of the forms pages must be UTF8 and also > mandates the following rules for the html forms used for the data > transportation. > 1. The HTML head section of the form MUST contain equiv="Content-Type" content="text/html; charset=utf-8">. There > needs to be a corresponding statement for XHTML. > 2. The FORM element MUST contain the Accept-Charset attribute and > it MUST be set to 'utf-8'i.e. Great suggestion! _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Feb 25 13:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD4a2-0003zw-G4; Sat, 25 Feb 2006 13:55:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD4a0-0003zr-Os for dix@ietf.org; Sat, 25 Feb 2006 13:55:44 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD4a0-0000pZ-En for dix@ietf.org; Sat, 25 Feb 2006 13:55:44 -0500 Received: from [192.168.1.104] (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 k1PItglu023163 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 25 Feb 2006 10:55:43 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44009C4C.7040507@gmail.com> References: <44009C4C.7040507@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] character encoding in draft-merrells-dix-00.txt Date: Sat, 25 Feb 2006 10:55: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: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: dix-bounces@ietf.org On 25-Feb-06, at 10:05 AM, robert yates wrote: > > Also, does it not make sense to have the verify step be a REST > style xml web service vs. this current form POST. XML seems much > better suited to these character encoding issues than "application/ > x-www-form-urlencoded". We had a fair amount of discussion on this. We chose POST although it is less elegant then a REST style call because we did not see any functional advantage, and for the following implementation advantages; 1) Currently, the HS is not having to parse any HTML or XML, and the MS is only generating pretty standard HTML. A little more complexity in adding XML to the base. 2) The HS is already getting POSTs on the Homesite-URL for the other messages. By having the verify message be another POST in the same format, it was thought it would be easier to implement a HS. The unique ID for the HS is the Homesite-URL, as it is in the Persona document and is where the MS sends all requests, either directly or indirectly. > Who knows whether the libraries for Ruby, Python, Java et al will > be consistent with how they perform their character encoding. I am pretty sure they are consistent. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Feb 26 23:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDa12-0003UW-DL; Sun, 26 Feb 2006 23:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDa11-0003UR-NP for dix@ietf.org; Sun, 26 Feb 2006 23:29:43 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDa10-0001r3-CC for dix@ietf.org; Sun, 26 Feb 2006 23:29:43 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1R4TcOA064878 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 26 Feb 2006 20:29:41 -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] Bfcasr - PG2 Date: Sun, 26 Feb 2006 20:29: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.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: dix-bounces@ietf.org On 21-Feb-06, at 9:09 AM, Peter Davis wrote: >> But... in all my years of Internet surfing >> I've never come across a website that said 'Take me to your >> IdP...', or >> 'Can I be your Idp...' Never. Am I just cruising the web with my >> blinkers on? > > That's because good SAML deployments make this a seamless > experience for the > user ;-). For sure, the tech should be under the covers, and the user's should just experience the benefits. But, I've never experienced the benefit of SAML on the web. Nick's big list of deployments suggests that I would have to be a Boeing employee who banks with Wells Fargo. (And I strongly suspect that even though both have deployed some form of SAML that there's no way for a user to actually move anything, between them... ) > The impediments for deploying federated architectures have little > to do with > technology. I think there clearly is a technology issue here. With the SAML protocol I don't see how you move a token between parties who don't already have a pre-existing relationship. > Federated identity management introduces new business and legal > complexities which many are only now coming to terms with. The > technology > is there, in a number of forms (which is why I'm loath to add yet > another > form unless it's absolutely necessary). Although the technology exists in the form of SAML/Liberty/Shibboleth and had been deployed by large enterprises/universities... I don't see any uptake in the internet space from the huge portals and commerce web sites down to the one person part-time websites. To me there's clearly an adoption issue. Scalability at one end and availability and usability at the other. If anyone has data points that suggest otherwise please share them. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 00:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDaW2-0001Xa-J1; Mon, 27 Feb 2006 00:01:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDaW1-0001XV-N7 for dix@ietf.org; Mon, 27 Feb 2006 00:01:45 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDaW1-0002ux-Cm for dix@ietf.org; Mon, 27 Feb 2006 00:01:45 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1R51g5c065713 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 26 Feb 2006 21:01:43 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43FBF5F5.5010909@dcrocker.net> References: <43FBF5F5.5010909@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] requirements Date: Sun, 26 Feb 2006 21:01:38 -0800 To: dcrocker@bbiw.net, 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 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: , Errors-To: dix-bounces@ietf.org On 21-Feb-06, at 9:26 PM, Dave Crocker wrote: > 1. What problem does DIX solve and for whom? How is the problem > currently manifest? > > 2. What does a basic scenario for using DIX look like? That is, > who are the typical actors and what are their typical interactions, > for a single, "complete" use of DIX? I'll write some scenarios that illustrate the problems being solved, which should answer both these questions. > 3. From the summary, I cannot tell what the actual "identity" is, > where it comes from, and whether or how it is assured uniqueness. Well, 'identity' is a bit of a philosophical term. Perhaps it is simpler to deal with an 'identifier'. But, your question relates to implementation issues, rather than design requirements. In the implementation detailed in dmd0 the identifier is a defined to be a URI, and a URL mechanism is detailed whereby a Delegation Tag is placed in the page at the end of the URL that delegates authentication to a list of Homesites. So, where it comes from is essentially a web server, and its uniqueness is based on its reuse of the domain namespace. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 00:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDawC-0005EU-Uy; Mon, 27 Feb 2006 00:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDawB-0005ED-UY for dix@ietf.org; Mon, 27 Feb 2006 00:28:47 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDawB-0003Zr-Hp for dix@ietf.org; Mon, 27 Feb 2006 00:28:47 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1R5Sjrf066132 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 26 Feb 2006 21:28:46 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <473B5EC4-FAF9-4CDA-99BC-A73128761692@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Sun, 26 Feb 2006 21:28:44 -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: 67c1ea29f88502ef6a32ccec927970f0 Subject: [dix] proposed charter (draft #4) 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: , Errors-To: dix-bounces@ietf.org This rewrite is based on Jim's editing down of draft #3 and the conversations on the list over the past couple of weeks. I'll work on some use cases / scenarios next. John ---- Description of Working Group: The Digital Identity Exchange (DIX) group will specify an Internet- scale identity information exchange protocol. A system architecture will be defined such that a separation of control may be maintained between all parties of the exchange. Problem Statement The Internet is host to many online information sources and services. There is a growing demand for users to identify, and provide information about themselves. Users bear the burden of managing their own authentication materials and repeatedly providing their identity information. Signing in to web pages and completing user registration forms is an example. Goals To specify a protocol for moving identity information between parties, and a system architecture that enables the development of software agents to manage this exchange. To specify a protocol with minimal adoption barriers, for which the following aspects of the protocol should be considered: Deployment of DIX-aware services and solutions should require minimal modifications to existing software to enable participation in an identity information exchange. The end-user should have control over their identity information and always be providing consent for the exchange of any of their information. Initiation of an exchange between two parties should be possible without any pre-established relationship. A naming scheme for user identifiers should be considered that allows the user to concurrently maintain multiple personas, to separate their digital identity from their identifier, and to separate the parties exchanging information from their identifier. Naming schemes for user attributes should be considered. The data that represents the identity information is expected to be opaque. It is expected that the messages of the protocol will include elements that associate property descriptors and their values to digital identities. Security should be considered (confidentiality and data integrity of any transferred information must be in place). Also, non-user parties should maintain the user's privacy. Existing techniques and technologies should be considered to ensure ease of adoption, implementation, and interoperability. Extensibility should be considered for each aspect of the protocol to ensure flexibility for future uses. The protocol should be scalable, requiring no centralized services beyond those that already exist (i.e. DNS). Out of Scope - How to federate identity namespaces. - How to use or issue digital certificates. - The schema and type system for identity information. - The mechanisms by which authentication is performed, (e.g. username/ password, one-time password devices). The scope is constrained to the movement of the authentication result between parties. Internet Drafts The Working Group anticipates the authoring of at least three Internet-Drafts. DIX Use Cases * A catalogue of DIX protocol use cases which illustrate the problems being solved, and to inform the decision making of the Working Group. For example, one use case could illustrate how DIX would be used by a website to check the reputation of potential posters to an online forum. Another use case could show how form fill-in could be automated. DIX Protocol * A description of the DIX protocol. It is expected that the protocol will be composed of discovery, exchange and verification; discovery of endpoints and negotiation of capabilities, exchange of identity information, and verification of the authenticity of identity information. This document should specify the protocol elements in a transport-independent manner. DIX HTTP Transport Binding * How the DIX protocol will be mapped onto HTTP as a transport layer. In this case the user's software is a HTTP client, to which no modifications should be required, and the third party would be a HTTP server. Continuing with the theme of simplicity a HTTP server should require minimal changes to support identity information exchange. For example, a HTML form could receive information the same way that a user would provide it, as if they typed it into the form themselves. It is anticipated that both the protocol and transport binding documents will be on the standards track. These documents provide a foundation layer for protocol extensions such as support for one party acting as an agent for another (e.g. Web Services), interoperation with existing protocols for movement of security information (e.g. WS-Trust, SAML), acquisition and presentation of third-party claims (e.g. XML-DSIG), alternative transport bindings (e.g. XMPP, SIP). _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 12:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlpL-0007uB-FA; Mon, 27 Feb 2006 12:06:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlnt-0007Jc-VN for dix@ietf.org; Mon, 27 Feb 2006 12:04:57 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDlgy-0001pR-Sz for dix@ietf.org; Mon, 27 Feb 2006 11:57:49 -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 k1RGvmho005202 for ; Mon, 27 Feb 2006 08:57:48 -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, 27 Feb 2006 08:57: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] Bfcasr - PG2 Date: Mon, 27 Feb 2006 08:57:47 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B06A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Bfcasr - PG2 Thread-Index: AcY7VnwzyC2b/QnLTd6XAHHgvwfICwAYrD0g From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 27 Feb 2006 16:57:48.0296 (UTC) FILETIME=[EFFF7880:01C63BBE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: dix-bounces@ietf.org > From: John Merrells [mailto:merrells@sxip.com]=20 > For sure, the tech should be under the covers, and the user's=20 > should just experience the benefits. But, I've never=20 > experienced the benefit of SAML on the web. Nick's big list=20 > of deployments suggests that I would have to be a Boeing=20 > employee who banks with Wells Fargo. Possibly, but this is simply a consequence of the way that network protocols are deployed. To get traction you have to aggressively court a tightly focused early adopter community. That does not mean that the protocol is only designed for that community, it does mean that you are most likely to find early adoption there. Obviously we were not designing a single sign on scheme for the blogosphere in 2002. Most of the companies who showed up for the SAML kickoff were vendors selling enterprise class products or services. That is where the market was in those days. From the very first meeting it was apparent that there was a huge number of people involved, 60 to 80 in the first WG meeting. There was thus a very understandable desire to try to keep the scope tightly focused.=20 I think that DIX is doing something different but it can certainly be something complimentary. I would like DIX to reuse components from SAML and WS-* wherever that makes sense.=20 If DIX is going to be used with attributes supplied by trusted third parties then DIX code is going to have to accept attributes in the form(s) supported by the commercial TTPs. At this point the only formats that I am aware that commercial TTPs support or are planning to support are X.509v3 certificates and SAML assertions.=20 > I think there clearly is a technology issue here. With the=20 > SAML protocol I don't see how you move a token between=20 > parties who don't already have a pre-existing relationship. That depends on how you configure the system. The SAML spec sets out a series of use cases that the spec is designed to support. That does not mean that they are the only use cases the spec supports as written. There was quite a bit of argument over which use cases should be included, more argument than we had over the protocol design which was taking place independently. SAML is designed to support a strong federation model where the user, the authentication service and the relying party can interact according to many different accreditation models. In DIX the problem of establishing trust between the authentication service and the relying party is essentially finessed by reducing the problem to a single communication pattern. Given where we are starting from I think that the most likely response from the IESG here is going to be 'go write a requirements document', it is certainly what I would request if I was making the decision and was not otherwise involved. I would then want to see a demonstration that each piece of new mechanism required in DIX is justified by a clear need. I think that there are clear justifications for certain DIX innovations: * The SAML assertion format is designed to support signed assertions using XML Signature. The overhead required is certainly justified when dealling with TTP assertions where the attributes are trusted and must be trustworthy. URI form encoding is much simpler and easier to manage and equally useful when the data is originally self asserted. * The use of a uniform identifier for identity is a key architectural innovation. SAML supports the use of a uniform identifier but there is a huge difference between support for a feature and designing a system around a feature.=20 When WS-* was first introduced people were determined to see a competition between the two. Today most people agree that there is a need for different approaches for different applications. WS-* is essentially a no-compromises system designed to provide the best possible security infrastructure for Web Services. It can also be used for other purposes and used standalone but the architecture does not make concessions that are designed to encourage early adoption for that application. The objective here is to establish an open identity system for the Internet. DIX, SAML, WS-* are merely means to that end. I am quite happy if it turns out that the output of DIX turns out to be a protocol that is mostly used as a transitional technology; a scafolding that allows the more ambitious schemes to be built more quickly. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 12:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlxt-0003YC-Op; Mon, 27 Feb 2006 12:15:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlxt-0003Y7-6a for dix@ietf.org; Mon, 27 Feb 2006 12:15:17 -0500 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDlxp-0002Ur-Ul for dix@ietf.org; Mon, 27 Feb 2006 12:15:17 -0500 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc14) with SMTP id <20060227171512m14003i5uge>; Mon, 27 Feb 2006 17:15:12 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: Johannes Ernst Date: Mon, 27 Feb 2006 09:15:11 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [dix] "Microsoft's InfoCard draws open-source response" 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: , Errors-To: dix-bounces@ietf.org http://news.com.com/Microsofts+InfoCard+draws+open-source+response/ 2100-7355_3-6043360.html?tag=nefd.top Lots of things are happening in identity land ... that either makes it a very good time to initiate a new standards effort or a bad time ... I suspect there would probably be advocates of either position ... _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 12:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDmWp-0005Az-MR; Mon, 27 Feb 2006 12:51:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDmWo-000584-Nz for dix@ietf.org; Mon, 27 Feb 2006 12:51:22 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDmWo-0003lc-Ca for dix@ietf.org; Mon, 27 Feb 2006 12:51:22 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RHpIvd086328 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Feb 2006 09:51:21 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B06A@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B06A@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Bfcasr - PG2 Date: Mon, 27 Feb 2006 09:51: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: bdc523f9a54890b8a30dd6fd53d5d024 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 8:57 AM, Hallam-Baker, Phillip wrote: > I think that DIX is doing something different but it can certainly be > something complimentary. I would like DIX to reuse components from > SAML > and WS-* wherever that makes sense. I agree. > If DIX is going to be used with attributes supplied by trusted third > parties then DIX code is going to have to accept attributes in the > form(s) supported by the commercial TTPs. At this point the only > formats > that I am aware that commercial TTPs support or are planning to > support > are X.509v3 certificates and SAML assertions. Also agree. > Given where we are starting from I think that the most likely response > from the IESG here is going to be 'go write a requirements > document', it > is certainly what I would request if I was making the decision and was > not otherwise involved. Sure, the draft charter includes a milestone for a use-case draft, which I think serves as requirements. > I think that there are clear justifications for certain DIX > innovations: > > * The SAML assertion format is designed to support signed assertions > using XML Signature. The overhead required is certainly justified when > dealling with TTP assertions where the attributes are trusted and must > be trustworthy. Yes. > URI form encoding is much simpler and easier to manage > and equally useful when the data is originally self asserted. Yes. > * The use of a uniform identifier for identity is a key architectural > innovation. SAML supports the use of a uniform identifier but there > is a > huge difference between support for a feature and designing a system > around a feature. Yes > When WS-* was first introduced people were determined to see a > competition between the two. Today most people agree that there is a > need for different approaches for different applications. WS-* is > essentially a no-compromises system designed to provide the best > possible security infrastructure for Web Services. It can also be used > for other purposes and used standalone but the architecture does not > make concessions that are designed to encourage early adoption for > that > application. The environment for WS-* seems different. Economically it's a two party platform... the desktop and the server... but Microsoft can leverage it's installed base and development tools to make sure it's at both ends everywhere. > The objective here is to establish an open identity system for the > Internet. DIX, SAML, WS-* are merely means to that end. I am quite > happy > if it turns out that the output of DIX turns out to be a protocol that > is mostly used as a transitional technology; a scafolding that allows > the more ambitious schemes to be built more quickly. Me too, and I think that dmd0 reflects that. All it really does is some discovery and then the movement of a blob between two parties. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 13:19:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDmxq-0005Dv-FD; Mon, 27 Feb 2006 13:19:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDmxp-0005DZ-Ro for dix@ietf.org; Mon, 27 Feb 2006 13:19:17 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDmxo-0004mF-G5 for dix@ietf.org; Mon, 27 Feb 2006 13:19:17 -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 k1RIJFk5012672 for ; Mon, 27 Feb 2006 10:19:15 -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); Mon, 27 Feb 2006 10:19:15 -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] Bfcasr - PG2 Date: Mon, 27 Feb 2006 10:19:14 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B092@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Bfcasr - PG2 Thread-Index: AcY7xnQQieCl4JUBR8aqFkFaku8avAAAjKMg From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 27 Feb 2006 18:19:15.0026 (UTC) FILETIME=[50B74B20:01C63BCA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: dix-bounces@ietf.org > From: John Merrells [mailto:merrells@sxip.com]=20 > The environment for WS-* seems different. Economically it's a=20 > two party platform... the desktop and the server... but=20 > Microsoft can leverage it's installed base and development=20 > tools to make sure it's at both ends everywhere. That depends on how you look at the problem... If you decide that you are going to use PKI as your authentication mechanism then you can make dramatic simplifications in your authentication protocol. Inband authentication can be effectively reduced to a two party protocol between the user and the relying party. There is still a third party involved but the involvement is now implicit. The credential issuer is an indirect party that in theory at least does not participate in the communication flow. In practice you are very likely to be using online revocation, which is even more vital for end user credentials than SSL certs.=20 Adding self signed credentials is useful but only to a point, I suspect that in practice relying parties will want to authenticate the email address at least. Both to reduce spam and to allow credentials to be replaced if necessary. Self signed certificates do have uses, but how do I recover from a stolen laptop if the only way a site recognizes me is through a self signed cert with no other attributes? How do I reclaim my identity? How do I stop another using it? Infocard is great but I still want a solution that works as a secure drop in replacement for username/password without being limited to that. I would rather the ten year out solution be that everyone implements WS-* plus legacy DIX than everyone implements WS_* but there is still a huge amount of ad-hoc password registration for traditional username/password _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 13:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDnSV-0002XO-FZ; Mon, 27 Feb 2006 13:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDnSU-0002Vr-AP for dix@ietf.org; Mon, 27 Feb 2006 13:50:58 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDnSS-0005t8-VP for dix@ietf.org; Mon, 27 Feb 2006 13:50:58 -0500 Received: from [142.131.33.143] ([142.131.33.143]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RIostX090217 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Feb 2006 10:50:56 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B092@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B092@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <156546E6-FCA5-4012-AFF6-BA5E3C33FA18@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Bfcasr - PG2 Date: Mon, 27 Feb 2006 10:50:50 -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: 79899194edc4f33a41f49410777972f8 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 10:19 AM, Hallam-Baker, Phillip wrote: > If you decide that you are going to use PKI as your authentication > mechanism then you can make dramatic simplifications in your > authentication protocol. Inband authentication can be effectively > reduced to a two party protocol between the user and the relying > party. I presume from your use of AuthN above that you are thinking of how hosts authenticate, since currently available users are still not capable of performing PK operations. I think it is important to be able to use other authentication methods besides PKI for hosts. eg. DNS mapping a hostname to an IP that data is retrieved from is a very light weight AuthN mechanism for a host, albeit primarily suited for low risk transactions. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 14:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDncC-0007Gm-3b; Mon, 27 Feb 2006 14:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDncB-0007Gh-IU for dix@ietf.org; Mon, 27 Feb 2006 14:00:59 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDncB-00067B-8k for dix@ietf.org; Mon, 27 Feb 2006 14:00:59 -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 k1RJ0sXA015032 for ; Mon, 27 Feb 2006 11: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.1830); Mon, 27 Feb 2006 11: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 Subject: RE: [dix] Bfcasr - PG2 Date: Mon, 27 Feb 2006 11:00:16 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B0A6@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Bfcasr - PG2 Thread-Index: AcY7zsXhGqK0Tf+2RuOY2ITF4uNG9wAAEykA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 27 Feb 2006 19:00:54.0628 (UTC) FILETIME=[22984A40:01C63BD0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: dix-bounces@ietf.org =20 > From: Dick Hardt [mailto:dick@sxip.com]=20 > On 27-Feb-06, at 10:19 AM, Hallam-Baker, Phillip wrote: > > If you decide that you are going to use PKI as your authentication=20 > > mechanism then you can make dramatic simplifications in your=20 > > authentication protocol. Inband authentication can be effectively=20 > > reduced to a two party protocol between the user and the relying=20 > > party. >=20 > I presume from your use of AuthN above that you are thinking=20 > of how hosts authenticate, since currently available users=20 > are still not capable of performing PK operations. True, but users are not capable of doing TCP/IP either. Perhaps after Kurzweil's singularity we will get the relevant implants. Most user's machines are quire capable of doing PKI today. SSL Client auth is practically universal. The user interface is shockingly bad but the code is certainly there. > I think it is important to be able to use other=20 > authentication methods besides PKI for hosts. >=20 > eg. DNS mapping a hostname to an IP that data is retrieved=20 > from is a very light weight AuthN mechanism for a host,=20 > albeit primarily suited for low risk transactions. I agree that we need other forms of AuthN of people to machines. But once we are passing along second degree assertions between machines every other form of authentication is second best. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 15:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDofj-0002qy-AY; Mon, 27 Feb 2006 15:08:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDofA-0002if-Jn for dix@ietf.org; Mon, 27 Feb 2006 15:08:08 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDoVk-0007zK-UD for dix@ietf.org; Mon, 27 Feb 2006 14:58:26 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1RJwxki029188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 11:58:59 -0800 Message-ID: <440359DB.8010309@dcrocker.net> Date: Mon, 27 Feb 2006 11:58:19 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] requirements References: <43FBF5F5.5010909@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org John, >> 3. From the summary, I cannot tell what the actual "identity" is, >> where it comes from, and whether or how it is assured uniqueness. > > Well, 'identity' is a bit of a philosophical term. Perhaps it is simpler > to deal > with an 'identifier'. But, your question relates to implementation issues, > rather than design requirements. My #3 question was really 3 questions, starting with concept and ending with a technical detail. Since the word identity is quite literally central to D*I*X, the meaning of identity needs to be more than philosophical. > In the implementation detailed in dmd0 the identifier is a defined to be > a URI, and a URL mechanism is detailed whereby a Delegation Tag is > placed in the page at the end of the URL that delegates authentication > to a list of Homesites. So, where it comes from is essentially a web All of this is fine-grained detail. That nature of the questions I am asking are intended to provide answers that non-technical people can understand. Non-technical people are going to be using it, so it would help if the nature of this stuff could be explained to them, without language like delegation tag, etc. > server, > and its uniqueness is based on its reuse of the domain namespace. ok. so, domain name, but something within the domain name (nonce, or whatever), to ensure uniqueness. Hence, each DNS administration is a sub-registry for DIX identities. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 15:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDp1A-0005CO-KS; Mon, 27 Feb 2006 15:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDp18-0005AF-Ng for dix@ietf.org; Mon, 27 Feb 2006 15:30:50 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDp17-0000dZ-Bd for dix@ietf.org; Mon, 27 Feb 2006 15:30:50 -0500 Received: from [10.0.1.15] (adsl-64-175-131-138.dsl.snfc21.pacbell.net [64.175.131.138]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RKUjeB095434 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 12:30:47 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440359DB.8010309@dcrocker.net> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 12:30:42 -0800 To: dcrocker@bbiw.net, 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: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 11:58 AM, Dave Crocker wrote: >> Well, 'identity' is a bit of a philosophical term. Perhaps it is >> simpler to deal >> with an 'identifier'. But, your question relates to implementation >> issues, >> rather than design requirements. > > My #3 question was really 3 questions, starting with concept and > ending with a technical detail. Since the word identity is quite > literally central to D*I*X, the meaning of identity needs to be > more than philosophical. I think of 'digital identity' as one word. I'm not hung up on defining 'identity'. The X.500/LDAP universe of discourse worked fine without drilling into it. Have a stab at it if you think it'll help. The Internet Identity Workshop has been kicking all this stuff about for a while. I'd rather this group focused on the technical realization of an architecture for user-centric digital identity. >> In the implementation detailed in dmd0 the identifier is a defined >> to be >> a URI, and a URL mechanism is detailed whereby a Delegation Tag is >> placed in the page at the end of the URL that delegates >> authentication >> to a list of Homesites. So, where it comes from is essentially a web > > All of this is fine-grained detail. That nature of the questions I > am asking are intended to provide answers that non-technical people > can understand. Non-technical people are going to be using it, so > it would help if the nature of this stuff could be explained to > them, without language like delegation tag, etc. Well, hopefully some use cases will cover that too. >> server, >> and its uniqueness is based on its reuse of the domain namespace. > > ok. so, domain name, but something within the domain name (nonce, > or whatever), to ensure uniqueness. Hence, each DNS administration > is a sub-registry for DIX identities. Based on dmd0, where the identifier is a URL - Yes. e.g. http://www.bbiw.net/dave http://www.bbiw.net/user1234 http://www.bbiw.net/ontimeuuid-1234-abcdef-4567-abcd But, DIX could use some other namespace that has the right properties. URIs, or as Phillip proposed email addresses. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 15:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpEW-0003Be-UC; Mon, 27 Feb 2006 15:44:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpEV-0003BN-DZ for dix@ietf.org; Mon, 27 Feb 2006 15:44:39 -0500 Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpEU-0001JU-2I for dix@ietf.org; Mon, 27 Feb 2006 15:44:39 -0500 Received: by wproxy.gmail.com with SMTP id 69so930026wra for ; Mon, 27 Feb 2006 12:44:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qPvXdHzDE5ZdEC2SfC36sSac96UC9Re6ntZpUfTfaMR6RN4bBvFrbgrWRzZnATJT0iNY4hPAlLIz/2NMOf6HXvTpKtxkt8r+IxjJrQL/y43ysO1JHorFGUB4G0B0hiORMCbwWRqP6JA2sS999rr3OkyuYKKvqMMX9saZrnpwZHY= Received: by 10.54.92.1 with SMTP id p1mr4559174wrb; Mon, 27 Feb 2006 12:44:37 -0800 (PST) Received: from ?9.33.25.195? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 39sm5134136wrl.2006.02.27.12.44.33; Mon, 27 Feb 2006 12:44:33 -0800 (PST) Message-ID: <440364B0.3010205@gmail.com> Date: Mon, 27 Feb 2006 15:44:32 -0500 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] scope question - proxy authentication References: <6f64bf7f0602210614t3324a0dat729833e4a2bf865b@mail.gmail.com> <1755E017-08F2-44C4-9FC5-9126398E780D@sxip.com> In-Reply-To: <1755E017-08F2-44C4-9FC5-9126398E780D@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Errors-To: dix-bounces@ietf.org John Merrells wrote: > I do not believe this is in scope for DIX, but I think that DIX should > enable this at a lower level. Good to hear > Using dmd0: User instructs Agent (qoop) to perform action (print > photo), Agent requests token (dmd0 fetch), Homesite doesn't > have token so refers user to token generator (flickr), User > authenticates and receives token, which they store at their > Homesite (dmd0 store), User returns to Agent, Agent requests > token (dmd0 fetch), Homesite provides Agent with token, Agent > makes call on data source (flickr) with token as parameter. Hmmm, this seems a little complicated to me at the moment.. I also wrote up the requirements for "proxy authentication" and called it "DIX Agency". Am interested if others are seeing this use case and whether they feel that a draft should be created that extends DIX Protocol to provide these capabilities, Rob 1. Introduction DIX Agency extends the DIX protocol [DIX]. It allows third party "agencies" to act on a user's behalf. A trivial example is allowing a photo printing service to access photographs stored by a separate service. 2. Definitions This document uses all the definitions outlined in [DIX] section 2 and additionally adds the following. 2.1. Servicesite A website or an application that provides services for end users. These services are available to other websites or applications via an API. 2.2. Agencysite A website or an application that acts on behalf of a user when accessing the servicesite. 3. Overview The core of DIX agency is a set of procedures for negotiating access to the servicesite by the agencysite. Without drilling into too many details, this is a general description of the DIX Agency protocol. The User browses to an Agencysite. The DIX Protocol is used to establish their "Persona URL" with the Agencysite. The user initiates an action that requires the Agencysite to access the Servicesite. The Agencysite determines that it is not authorized to access the Servicesite. The Agencysite then sends a request for access to the Servicesite through the User's client. The Servicesite processes the request (possibly also establishing the user's "Persona URL"), prompting the User for consent and returns a response, again through the User's client. The Agencysite utilizes this response to access the Servicesite. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 15:53:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpNM-0002Od-82; Mon, 27 Feb 2006 15:53:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpNL-0002OM-5D for dix@ietf.org; Mon, 27 Feb 2006 15:53:47 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpNJ-0001fZ-NE for dix@ietf.org; Mon, 27 Feb 2006 15:53:47 -0500 Received: from [142.131.33.200] ([142.131.33.200]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RKrhxU096751 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 12:53:44 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440359DB.8010309@dcrocker.net> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 12:53:39 -0800 To: dcrocker@bbiw.net, 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: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 11:58 AM, Dave Crocker wrote: > >>> 3. From the summary, I cannot tell what the actual "identity" is, >>> where it comes from, and whether or how it is assured uniqueness. >> Well, 'identity' is a bit of a philosophical term. Perhaps it is >> simpler to deal >> with an 'identifier'. But, your question relates to implementation >> issues, >> rather than design requirements. > > My #3 question was really 3 questions, starting with concept and > ending with a technical detail. Since the word identity is quite > literally central to D*I*X, the meaning of identity needs to be > more than philosophical. In my Identity 2.0 talk[1], I describe Identity as being who you are. This is a very broad statement, and is intended as such. What DIX is about is how can the user move any information concerning themselves around. Some of those properties are self asserted, and other properties tend to require assertion by trusted third parties. Your identity is the collection of all of these properties. This can be anything from my favorite movies and books so that I can rapidly educate an etailer what I like, to proof that I am canadian, over 21 and that I work at Sxip. I even include transactions that you have been a party to. When I return a purchase to store, the identity that I am using is the receipt to show that it was I (or someone I am acting on behalf of) that made the purchase. [1] http://www.identity20.com/media/OSCON2005/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 16:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqD2-0003B3-RV; Mon, 27 Feb 2006 16:47:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqD1-0003Au-Tz for dix@ietf.org; Mon, 27 Feb 2006 16:47:11 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDqD0-0007ZV-IV for dix@ietf.org; Mon, 27 Feb 2006 16:47:11 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1RLlZTL011227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 13:47:35 -0800 Message-ID: <44037350.4030106@dcrocker.net> Date: Mon, 27 Feb 2006 13:46:56 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> In-Reply-To: <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [dix] What is "identity"? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > I think of 'digital identity' as one word. I'm not hung up on defining > 'identity'. > The X.500/LDAP universe of discourse worked fine without drilling into it. By way of suggesting a line of discussion: I think that the X.500 world has not worked all that fine at all, except within very constrained environments. The scale and diversity of the open Internet has been a notable failure for the X.500 world, although that was its original ta > The Internet Identity Workshop has > been kicking all this stuff about for a while. I'd rather this group focused on > the technical realization of an architecture for user-centric digital identity. That presumes an Internet community consensus about both the meaning of the term identity, as it will be used here, and the architecture for it. I haven't noticed either present in the IETF arena, so I suspect you have some educating to do. > In my Identity 2.0 talk[1], I describe Identity as being who you are. This is a "who you are" is a reasonable place to begin, but does not have quite enough substance to direct technical work. For example, the difference between a person performing in one role, versus another, might or might not require different identities. It might even require some sort of identity "hierarchy". Yes, all of these issues have been discussed in specialized circles for some decades. The issue I am raising, here, is that the engineering work to be pursued here needs to list specific choices for these things and has to have community agreement on those choices. So, before there is any discussion of formats and protocol rules, there needs to be an understanding of the capabilities and constraints of the construct "identity" used for this work. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 16:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqNL-0002N2-T8; Mon, 27 Feb 2006 16:57:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqNK-0002Mu-Ce for dix@ietf.org; Mon, 27 Feb 2006 16:57:50 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDqNJ-0007mC-1X for dix@ietf.org; Mon, 27 Feb 2006 16:57:50 -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 k1RLNwdr019697; Mon, 27 Feb 2006 13:23:58 -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); Mon, 27 Feb 2006 13:23:58 -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] requirements Date: Mon, 27 Feb 2006 13:23:57 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] requirements Thread-Index: AcY72aCwfQ4Edy9EQHe8KhxMF87EpgABrtVA From: "Hallam-Baker, Phillip" To: , "Digital Identity Exchange" X-OriginalArrivalTime: 27 Feb 2006 21:23:58.0400 (UTC) FILETIME=[1EEBF400:01C63BE4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Errors-To: dix-bounces@ietf.org > From: Dave Crocker [mailto:dhc@dcrocker.net]=20 > My #3 question was really 3 questions, starting with concept=20 > and ending with a technical detail. Since the word identity=20 > is quite literally central to D*I*X, the meaning of identity=20 > needs to be more than philosophical. Is it possible for there to be a higher form of meaning than philosophical meaning? I think not because the only parties qualified to judge are philosophers. I think that what Dave is trying to say here in imprecise fashion is that we need to have a precise *definition* of what identity means in the context of DIX and that this must 1) not rely on the outcome of open philosophical questions and 2) be understood without direct recourse to modern continental philosophers. I believe that a useful working definition is something on the lines of: An identity is a set of assertions concerning a particular subject identifier. This is certainly consistent with Dick's Id2 talk.=20 As far as the computer is concerned, it first authenticates 'Dick Hardt of Sxip', as far as the computer is concerned any machine readable identifier that binds unambiguously to 'Dick Hardt of Sxip' is acceptable, for the sake of argument lets use 'dick@sxip.com'. Dick's identity is now the set of statements that are bound to identifiers for Dick: dick@sxip.com is Canadian dick@sxip.com lives in Vancouver dick@sxip.com is Star Alliance member 006342832 Star Alliance member 006342832 is Star Alliance Gold dick@sxip.com likes a bunch of (specified) sports teams dick@sxip.com likes a bunch of (specified) bands dick@sxip.com has blood group Z dick@sxip.com looks like this And so on. > > server, > > and its uniqueness is based on its reuse of the domain namespace. >=20 > ok. so, domain name, but something within the domain name=20 > (nonce, or whatever), to ensure uniqueness. Hence, each DNS=20 > administration is a sub-registry for DIX identities. It looks to me like there is a confusion here between the identifier and the identity. The identifier is not the identity, it is merely a reference point around which the identity is constructed. As the identifier is not what the relying party is actually interested in it can in most cases be factored out: That dude you just asked me about: is Canadian lives in Vancouver is Star Alliance member 006342832 Star Alliance member 006342832 is Star Alliance Gold likes a bunch of (specified) sports teams likes a bunch of (specified) bands has blood group Z looks like this _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 17:34:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqwV-0006G1-OK; Mon, 27 Feb 2006 17:34:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqwS-0006Ap-2G for dix@ietf.org; Mon, 27 Feb 2006 17:34:08 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDqwQ-0001po-M2 for dix@ietf.org; Mon, 27 Feb 2006 17:34:08 -0500 Received: from [192.168.2.140] (adsl-69-226-240-28.dsl.pltn13.pacbell.net [69.226.240.28]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RMY42S001521 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 14:34:05 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44037350.4030106@dcrocker.net> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B31E102-2F81-43B7-8D2D-5CD80E00F159@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] What is "identity"? Date: Mon, 27 Feb 2006 14:33:57 -0800 To: dcrocker@bbiw.net, 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 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 1:46 PM, Dave Crocker wrote: > >> I think of 'digital identity' as one word. I'm not hung up on >> defining 'identity'. >> The X.500/LDAP universe of discourse worked fine without drilling >> into it. > > By way of suggesting a line of discussion: > > I think that the X.500 world has not worked all that fine at all, You switched topics from 'X500/LDAP universe of discourse' to 'success of X500'... > except within very constrained environments. The scale and > diversity of the open Internet has been a notable failure for the X. > 500 world, although that was its original ta Hence LDAP. And, by analogy DIX. >> The Internet Identity Workshop has >> been kicking all this stuff about for a while. I'd rather this >> group focused on >> the technical realization of an architecture for user-centric >> digital identity. > > That presumes an Internet community consensus about both the > meaning of the term identity, as it will be used here, and the > architecture for it. > > I haven't noticed either present in the IETF arena, so I suspect > you have some educating to do. You could join the IIW group. >> In my Identity 2.0 talk[1], I describe Identity as being who you >> are. This is a > > "who you are" is a reasonable place to begin, but does not have > quite enough substance to direct technical work. For example, the > difference between a person performing in one role, versus another, > might or might not require different identities. It might even > require some sort of identity "hierarchy". Which motivates the desire for compartmentalization of identity. > Yes, all of these issues have been discussed in specialized circles > for some decades. > > The issue I am raising, here, is that the engineering work to be > pursued here needs to list specific choices for these things and > has to have community agreement on those choices. > > So, before there is any discussion of formats and protocol rules, > there needs to be an understanding of the capabilities and > constraints of the construct "identity" used for this work. Think we've come full circle Dave. John > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > > > _______________________________________________ > 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 Feb 27 17:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr1g-0001WN-Ms; Mon, 27 Feb 2006 17:39:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr1f-0001Vi-GD for dix@ietf.org; Mon, 27 Feb 2006 17:39:31 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDr1f-0002Vz-6K for dix@ietf.org; Mon, 27 Feb 2006 17:39:31 -0500 Received: from [192.168.2.140] (adsl-69-226-240-28.dsl.pltn13.pacbell.net [69.226.240.28]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RMdSJ0001773 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 14:39:29 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B0D6@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: <60981B18-8FB1-4CAA-8DB7-AC7FE8A999DE@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 14:39: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.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dcrocker@bbiw.net 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 1:23 PM, Hallam-Baker, Phillip wrote: > I believe that a useful working definition is something on the > lines of: > > An identity is a set of assertions concerning a particular subject > identifier. Well sure, that's pretty obvious though isn't it? dmd0 included a simple information model along those lines. Is Dave saying this should be pulled up to a higher level? I think that DIX could work within the context of many alternative information models... In dmd0 we move properties that have a name and a value. That's it. Simple to map onto the X500 or relational models or whatever. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 17:41:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr3C-0003Bl-B7; Mon, 27 Feb 2006 17:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr3B-0003Au-Mb for dix@ietf.org; Mon, 27 Feb 2006 17:41:05 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDr3A-0002qF-Vk for dix@ietf.org; Mon, 27 Feb 2006 17:41:05 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Feb 2006 17:41:05 -0500 X-IronPort-AV: i="4.02,150,1139202000"; d="scan'208"; a="83211015:sNHT35078176" Received: from [68.50.18.9] (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1RMf4jJ018167; Mon, 27 Feb 2006 17:41:04 -0500 (EST) In-Reply-To: <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0fa2470e80bcb6ce10d284be2f64d072@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 17:40:59 -0500 To: Digital Identity Exchange X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: dcrocker@bbiw.net 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: , Errors-To: dix-bounces@ietf.org What about using a Network Access Identifier (NAI) [RFC 4282]? John On Feb 27, 2006, at 3:30 PM, John Merrells wrote: > But, DIX could use some other namespace that has the right properties. > URIs, or as Phillip proposed email addresses. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 17:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr3F-0003G2-MR; Mon, 27 Feb 2006 17:41:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr3E-0003Ej-4q for dix@ietf.org; Mon, 27 Feb 2006 17:41:08 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDr3D-0002rE-Nf for dix@ietf.org; Mon, 27 Feb 2006 17:41:08 -0500 Received: from [142.131.33.200] ([142.131.33.200]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RMf6ot001896 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 14:41:06 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44037350.4030106@dcrocker.net> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Mon, 27 Feb 2006 14:41:02 -0800 To: dcrocker@bbiw.net, 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 1:46 PM, Dave Crocker wrote: > "who you are" is a reasonable place to begin, but does not have > quite enough substance to direct technical work. For example, the > difference between a person performing in one role, versus another, > might or might not require different identities. It might even > require some sort of identity "hierarchy". I see that people will have many personas, but only one identity. Each persona presents a different facet of themselves. > > Yes, all of these issues have been discussed in specialized circles > for some decades. > > The issue I am raising, here, is that the engineering work to be > pursued here needs to list specific choices for these things and > has to have community agreement on those choices. Do we need to preclude what is and is not identity? ... if we have an open mechanism for adding to the identity data that can be moved around, we will have a platform for moving around any identity data. In our ID, we intentionally left out describing the specifics of what could be moved around, our goal was to provide a mechanism for any organization to define properties that could be moved around and defining them as URIs. > > So, before there is any discussion of formats and protocol rules, > there needs to be an understanding of the capabilities and > constraints of the construct "identity" used for this work. Philips related post I think covers this a little, and his comments point out what I think is an important aspect of identity protocols. There is an implicit and often overlooked aspect of identity, which is the identity of session between machines. I use the term session here quite broadly, I mean for it to be a way for one machine to know that a message it receives is related to a previous message. When we talk about identity, there are two aspects, one is the property, and the other is who the property is about. Over 21 is rather useless. The entity at the other end of a session being over 21 is useful. Let's call tying a property to an identifier a claim. In this case, the identifier is the session. But the identifier could be something else that has more permanence. Philip used dick@sxip.com as an example. [dick@sxip.com is over 21] is a claim that will be true the rest of my life (as long as dick@sxip.com is associated with me :-) This leads to me controlling who can say they are dick@sxip.com. If only I can claim that the a session is associated with dick@sxip.com, then I will be the only where the claim [dick@sxip.com is over 21] is considered valid. Does this clarify your question Dave, or am I missing something? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrSq-000421-AN; Mon, 27 Feb 2006 18:07:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrSo-000416-Bl for dix@ietf.org; Mon, 27 Feb 2006 18:07:34 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrSo-0005ai-4A for dix@ietf.org; Mon, 27 Feb 2006 18:07:34 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2006 15:07:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,151,1139212800"; d="scan'208"; a="22692746:sNHT24576330" Received: from [68.50.18.9] (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1RN7XqM013958; Mon, 27 Feb 2006 18:07:33 -0500 (EST) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <26e5fc334b88e18c20c1168482c05744@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 18:07:30 -0500 To: Digital Identity Exchange X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dcrocker@bbiw.net 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: , Errors-To: dix-bounces@ietf.org On Feb 27, 2006, at 4:23 PM, Hallam-Baker, Phillip wrote: >> From: Dave Crocker [mailto:dhc@dcrocker.net] >> ... Since the word identity is quite literally central to D*I*X, >> the meaning of identity needs to be more than philosophical. > > ... > I think that what Dave is trying to say here in imprecise fashion is > that we need to have a precise *definition* of what identity means in > the context of DIX and that this must 1) not rely on the outcome of > open > philosophical questions and 2) be understood without direct recourse to > modern continental philosophers. Yes, precise but more abstract than the syntax of a message so we all understand the goals. The sort of problem we do not want to have to deal with is what "is" is. This is not as easy as it may appear when we attempt to design technical solutions for abstract things like identity that have such rich natural semantics. > I believe that a useful working definition is something on the lines > of: > > An identity is a set of assertions concerning a particular subject > identifier. This definition seems to apply to the concept in Dick's ID-2 talk, but we should be careful. Do we want to say that any set of assertions concerning an identifier is an identity. This looks like a semantic trap to me. I suggest that a definition more clearly associated with what the purpose or use of an identity is might avoid that trap. This is a trap-rich environment. > This is certainly consistent with Dick's Id2 talk. The presentation was entertaining. It contained at least one statement of equivalence that I find unpersuasive from just its assertion. The equivalence of identity = reputation is a strong and provocative claim. If the sort of definition of identity on which the WG's effort (implicitly) rests includes this equivalence, it deserves to be justified better. > As far as the computer is concerned, it first authenticates 'Dick Hardt > of Sxip', as far as the computer is concerned any machine readable > identifier that binds unambiguously to 'Dick Hardt of Sxip' is > acceptable, for the sake of argument lets use 'dick@sxip.com'. > > Dick's identity is now the set of statements that are bound to > identifiers for Dick: > > dick@sxip.com is Canadian > dick@sxip.com lives in Vancouver > dick@sxip.com is Star Alliance member 006342832 > Star Alliance member 006342832 is Star Alliance Gold > dick@sxip.com likes a bunch of (specified) sports teams > dick@sxip.com likes a bunch of (specified) bands > dick@sxip.com has blood group Z > dick@sxip.com looks like this > > And so on. One of the real-world details that is illustrated by this example is that assertions can be limited. For example, the Star Alliance Gold might be valid only until January of next year unless Dick flies enough this year (or has flown way too much already). Since XML is a proposed format for assertions, it is easy enough to add syntactic elements to reflect the limitations, but the careful designer will notice the slippery slope of embedding real-world semantics into the format of identity assertions. Careful bounds on the definitions of what we are dealing with are important here. Relying on the rich set of associations that people have with an abstract noun like identity will not do. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrWc-0007C3-GK; Mon, 27 Feb 2006 18:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrWa-0007Bm-W2 for dix@ietf.org; Mon, 27 Feb 2006 18:11:28 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrWY-0005pg-JL for dix@ietf.org; Mon, 27 Feb 2006 18:11:28 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1RNBvpt023028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2006 15:11:58 -0800 Message-ID: <44038717.6030305@dcrocker.net> Date: Mon, 27 Feb 2006 15:11:19 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] requirements References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <60981B18-8FB1-4CAA-8DB7-AC7FE8A999DE@sxip.com> In-Reply-To: <60981B18-8FB1-4CAA-8DB7-AC7FE8A999DE@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >> An identity is a set of assertions concerning a particular subject >> identifier. > > Well sure, that's pretty obvious though isn't it? dmd0 included a simple > information model along those lines. Is Dave saying this should be > pulled up to a higher level? I think that DIX could work within the > context of many alternative information models... In dmd0 we move > properties that have a name and a value. That's it. Simple to map > onto the X500 or relational models or whatever. The above sort of exchange is a good one, among specialists in the identity and x.500 kind of world. Unfortunately, it is not so useful for the larger community that is expected to implement or *use* these services. Yet those are the folk who will adopt or not adopt the output of the working group. If the working group's planned output cannot be described in a way that such folk will a) understand, and b) see immediate need for, then the dix working group will be another marginalized standards effort. >> That presumes an Internet community consensus about both the meaning >> of the term identity, as it will be used here, and the architecture >> for it. >> >> I haven't noticed either present in the IETF arena, so I suspect you >> have some educating to do. > > You could join the IIW group. I think this underscores the disconnect that concerns me. The task of bringing work into the IETF entails the obligation of recruiting the IETF community (and the rest of the Internet community) to understand and embrace the prior work. What it does NOT entail is telling the IETF (and larger) world that they should go and become familiar with the prior work, especially when the implication is that they are excluded from the dialogue until they do that outside (and unbounded) homework. (For reference, my own recent experiences with DKIM's efforts to come into the IETF have reminded me quite starkly of the difference between these perspectives.) d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrbd-0001Uc-8E; Mon, 27 Feb 2006 18:16:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrbb-0001UA-HN for dix@ietf.org; Mon, 27 Feb 2006 18:16:39 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrba-0006Fg-BG for dix@ietf.org; Mon, 27 Feb 2006 18:16:39 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2006 15:16:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,151,1139212800"; d="scan'208"; a="22693190:sNHT36073228" Received: from [68.50.18.9] (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1RNGbqM015268; Mon, 27 Feb 2006 18:16:37 -0500 (EST) In-Reply-To: References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5119e63cb20fae59275cbe3c13313bd9@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [dix] What is "identity"? Date: Mon, 27 Feb 2006 18:16:34 -0500 To: Digital Identity Exchange X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: dcrocker@bbiw.net 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: , Errors-To: dix-bounces@ietf.org On Feb 27, 2006, at 5:41 PM, Dick Hardt wrote: > On 27-Feb-06, at 1:46 PM, Dave Crocker wrote: > >> "who you are" is a reasonable place to begin, but does not have quite >> enough substance to direct technical work. For example, the >> difference between a person performing in one role, versus another, >> might or might not require different identities. It might even >> require some sort of identity "hierarchy". > > I see that people will have many personas, but only one identity. Each > persona presents a different facet of themselves. Slippery slope alert! This statement seems to mix the every-day meaning of identity with the formal definition that is necessary for technical progress. What is the precise relationship between a persona and an identity? Who gets to know that relationship? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrcO-0002CY-F6; Mon, 27 Feb 2006 18:17:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrcN-0002Bx-TB for dix@ietf.org; Mon, 27 Feb 2006 18:17:27 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrcM-0006JS-Iu for dix@ietf.org; Mon, 27 Feb 2006 18:17:27 -0500 Received: from [192.168.2.140] (adsl-69-226-240-28.dsl.pltn13.pacbell.net [69.226.240.28]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RNHODT004067 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 15:17:25 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44038717.6030305@dcrocker.net> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <60981B18-8FB1-4CAA-8DB7-AC7FE8A999DE@sxip.com> <44038717.6030305@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 15:17:17 -0800 To: dcrocker@bbiw.net, 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 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 3:11 PM, Dave Crocker wrote: > The above sort of exchange is a good one, among specialists in the > identity and x.500 kind of world. > > Unfortunately, it is not so useful for the larger community that is > expected to implement or *use* these services. > > Yet those are the folk who will adopt or not adopt the output of > the working group. > > If the working group's planned output cannot be described in a way > that such folk will a) understand, and b) see immediate need for, > then the dix working group will be another marginalized standards > effort. It seems to me that your comments are somewhat disassociated from the work we've done so far. How about you work through the draft charter #4 and annotate the bits that you have issue with? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrhl-000859-2u; Mon, 27 Feb 2006 18:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrhj-00082t-Mz for dix@ietf.org; Mon, 27 Feb 2006 18:22:59 -0500 Received: from toad.mtbrook.bozemanpass.com ([69.145.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrhg-0006fB-AJ for dix@ietf.org; Mon, 27 Feb 2006 18:22:59 -0500 Received: from [69.145.82.218] (unknown [69.145.82.218]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id 4B1D3110393 for ; Mon, 27 Feb 2006 15:22:53 -0800 (PST) Message-ID: <440389D2.9040803@boreham.org> Date: Mon, 27 Feb 2006 16:22:58 -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] What is "identity"? References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> In-Reply-To: <44037350.4030106@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: dix-bounces@ietf.org Dave Crocker wrote: > "who you are" is a reasonable place to begin, but does not have quite > enough substance to direct technical work. For example, the > difference between a person performing in one role, versus another, > might or might not require different identities. It might even > require some sort of identity "hierarchy". I think this is a rat hole that we don't need to go down. Users do just fine with multiple 'identities' given to them, or assumed, for whatever tasks they need to perform. We do not, for example, get worked up because my state drivers licence does not refer to my country passport number (and in my case the two are issued by different countries which I'm sure makes for an interesting hierarchy). > Yes, all of these issues have been discussed in specialized circles > for some decades. > > The issue I am raising, here, is that the engineering work to be > pursued here needs to list specific choices for these things and has > to have community agreement on those choices. > > So, before there is any discussion of formats and protocol rules, > there needs to be an understanding of the capabilities and constraints > of the construct "identity" used for this work. I think this is a red herring. It is not necessary to define what humans mean by 'identity' for this work. Instead all we need to do is define what the computers that implement the DIX protocol mean by 'identity' : a much easier task IMHO. I believe that all we need to know is that one identity needs to be differentiated from another one and that we have 'stuff' that belongs to each identity. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrwB-0003QN-Rk; Mon, 27 Feb 2006 18:37:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrwA-0003Q1-N9 for dix@ietf.org; Mon, 27 Feb 2006 18:37:54 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDrw9-00077N-Af for dix@ietf.org; Mon, 27 Feb 2006 18:37:54 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1RNcCOr025797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 15:38:12 -0800 Message-ID: <44038D3D.3000603@dcrocker.net> Date: Mon, 27 Feb 2006 15:37:33 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: david_list@boreham.org Subject: Re: [dix] What is "identity"? References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <440389D2.9040803@boreham.org> In-Reply-To: <440389D2.9040803@boreham.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >> So, before there is any discussion of formats and protocol rules, >> there needs to be an understanding of the capabilities and constraints >> of the construct "identity" used for this work. > > I think this is a red herring. It is not necessary to define what humans > mean by 'identity' for this work. > Instead all we need to do is define what the computers that implement > the DIX protocol mean by > 'identity' : a much easier task IMHO. > > I believe that all we need to know is that one identity needs to be > differentiated from another one > and that we have 'stuff' that belongs to each identity. The closer an IETF activity gets to humans and social activities, the less it seems to be possible to indulge in the view that the computer perspective is what counts. Comments, so far, have tended to stress both the generality and the computer-side orientation of the DIX work, with an apparent lack of focus on specific human uses. From my own experience, it is not possible to raise flags that are higher or more red. I wish this did not sound quite so reminiscent of the original X.500 work. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 18:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDs0C-0006Iw-2Q; Mon, 27 Feb 2006 18:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDs0A-0006IZ-UM for dix@ietf.org; Mon, 27 Feb 2006 18:42:02 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDs09-0007BQ-Jc for dix@ietf.org; Mon, 27 Feb 2006 18:42:02 -0500 Received: from [142.131.33.200] ([142.131.33.200]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RNfxHo006120 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 15:42:00 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <5119e63cb20fae59275cbe3c13313bd9@cisco.com> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <5119e63cb20fae59275cbe3c13313bd9@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EB73B54-0E9A-4880-9BCC-9CAC786A7A1D@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Mon, 27 Feb 2006 15:41: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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dcrocker@bbiw.net 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 3:16 PM, John Schnizlein wrote: > > On Feb 27, 2006, at 5:41 PM, Dick Hardt wrote: > >> On 27-Feb-06, at 1:46 PM, Dave Crocker wrote: >> >>> "who you are" is a reasonable place to begin, but does not have >>> quite enough substance to direct technical work. For example, >>> the difference between a person performing in one role, versus >>> another, might or might not require different identities. It >>> might even require some sort of identity "hierarchy". >> >> I see that people will have many personas, but only one identity. >> Each persona presents a different facet of themselves. > > Slippery slope alert! > > This statement seems to mix the every-day meaning of identity with > the formal definition that is necessary for technical progress. Perhaps the formal definition should be adjusted to the everyday meaning so that it is more useful? ... and we user other terms that are nice and specific for clarity. > What is the precise relationship between a persona and an identity? I have an identity. It is all the properties about me. I want a means of moving that identity data to a site. A persona is a set of properties aka. identity data. > Who gets to know that relationship? The user. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 19:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsU8-0006Gw-Pt; Mon, 27 Feb 2006 19:13:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsCD-0006h2-CC for dix@ietf.org; Mon, 27 Feb 2006 18:54:29 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsCC-0008Qu-DP for dix@ietf.org; Mon, 27 Feb 2006 18:54:28 -0500 Received: from [142.131.33.200] ([142.131.33.200]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1RNsQ7D006933 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 15:54:26 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <26e5fc334b88e18c20c1168482c05744@cisco.com> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 15:54: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.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dcrocker@bbiw.net 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 3:07 PM, John Schnizlein wrote: >> I believe that a useful working definition is something on the >> lines of: >> >> An identity is a set of assertions concerning a particular subject >> identifier. > > This definition seems to apply to the concept in Dick's ID-2 talk, > but we should be careful. Do we want to say that any set of > assertions concerning an identifier is an identity. This looks > like a semantic trap to me. I suggest that a definition more > clearly associated with what the purpose or use of an identity is > might avoid that trap. This is a trap-rich environment. Do you have a suggestion Dave? I hope you are not one of those people that just poo-poos what other people do! :-) >> This is certainly consistent with Dick's Id2 talk. > > The presentation was entertaining. It contained at least one > statement of equivalence that I find unpersuasive from just its > assertion. The equivalence of identity = reputation is a strong > and provocative claim. If the sort of definition of identity on > which the WG's effort (implicitly) rests includes this equivalence, > it deserves to be justified better. Glad you found it entertaining. The key point was that identity is much more then a username and password. The "reputation=identity" point is for people to get that there are things you say about yourself, and things others say about you, and that the latter is pretty valuable, and we have no way of communicating those in the digital world. The goal of the talk was to make digital identity issues accessible to a broad audience. >> >> And so on. > > One of the real-world details that is illustrated by this example > is that assertions can be limited. For example, the Star Alliance > Gold might be valid only until January of next year unless Dick > flies enough this year (or has flown way too much already). Since > XML is a proposed format for assertions, it is easy enough to add > syntactic elements to reflect the limitations, but the careful > designer will notice the slippery slope of embedding real-world > semantics into the format of identity assertions. No reason a digital claim cannot expire the same way that a physical one expires. > Careful bounds on the definitions of what we are dealing with are > important here. Relying on the rich set of associations that > people have with an abstract noun like identity will not do. Not sure what is wrong with the definition proposed. Per above, do you have a better suggestion so we can move forward? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 19:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsW3-00075J-IC; Mon, 27 Feb 2006 19:14:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsVB-0006R8-Qv for dix@ietf.org; Mon, 27 Feb 2006 19:14:05 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsIE-0000ho-NG for dix@ietf.org; Mon, 27 Feb 2006 19:00:43 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9B851422C6; Mon, 27 Feb 2006 16:00:41 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15351-07; Mon, 27 Feb 2006 16:00:41 -0800 (PST) Received: from [192.168.101.217] (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 8DFAF1422A5; Mon, 27 Feb 2006 16:00:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440389D2.9040803@boreham.org> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <440389D2.9040803@boreham.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] What is "identity"? Date: Mon, 27 Feb 2006 16:00:24 -0800 To: david_list@boreham.org, Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: dix-bounces@ietf.org On Feb 27, 2006, at 3:22 PM, David Boreham wrote: > > I think this is a red herring. It is not necessary to define what > humans mean by 'identity' for this work. > Instead all we need to do is define what the computers that > implement the DIX protocol mean by > 'identity' : a much easier task IMHO. > > I believe that all we need to know is that one identity needs to be > differentiated from another one > and that we have 'stuff' that belongs to each identity. > I agree with the first paragraph. The second not quite, I'm sure we'll need a little more. Using my own terminology, an identity is also something that a client can assert, where that assertion will be backed up by an identity server, and where the ability to assert said identity is a sufficiently limited ability for the assertion to be a useful piece of information. (For client, read agent if you prefer) Lisa _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 19:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsqW-0002OA-9q; Mon, 27 Feb 2006 19:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsqU-0002Nn-Mp for dix@ietf.org; Mon, 27 Feb 2006 19:36:06 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsqT-0004dX-Dl for dix@ietf.org; Mon, 27 Feb 2006 19:36:06 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7DF71422D2 for ; Mon, 27 Feb 2006 16:36:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13132-06 for ; Mon, 27 Feb 2006 16:36:04 -0800 (PST) Received: from [192.168.101.217] (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 DDA881422A2 for ; Mon, 27 Feb 2006 16:36:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <0fa2470e80bcb6ce10d284be2f64d072@cisco.com> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <0fa2470e80bcb6ce10d284be2f64d072@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E1A7481-0CF4-4908-9C5D-7957C1058538@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Using Network Access Identifiers (NAI) from RFC4282 (was Re: [dix] requirements) Date: Mon, 27 Feb 2006 16:35:45 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: dix-bounces@ietf.org Some thoughts on that suggestion. 1. The terminology of RFC4282 assumes a "Network Access Server" but there's no structural reason that can't be any identity server, not just the one that's providing the user with network access. 2. The identity "redirects" of RFC4282 -- the part that requires the "!" (exclamation mark) separator between realms -- is of unclear purpose to me. It might muddy the waters as I think assertable digital identity does not require redirects. I may be wrong. 3. Why aren't those identifiers in URI format? URI format is very useful for building on many Web technologies. If RF4282 were used, I would think it would have to be with a scheme added to be URI compliant. Lisa On Feb 27, 2006, at 2:40 PM, John Schnizlein wrote: > What about using a Network Access Identifier (NAI) [RFC 4282]? > > John > > On Feb 27, 2006, at 3:30 PM, John Merrells wrote: > >> But, DIX could use some other namespace that has the right >> properties. >> URIs, or as Phillip proposed email addresses. > > _______________________________________________ > 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 Feb 27 20:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtpV-0001hl-LC; Mon, 27 Feb 2006 20:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtpU-0001hb-BP for dix@ietf.org; Mon, 27 Feb 2006 20:39:08 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDtpT-0007KZ-1R for dix@ietf.org; Mon, 27 Feb 2006 20:39:08 -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 k1S1d67e004458 for ; Mon, 27 Feb 2006 17:39:06 -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); Mon, 27 Feb 2006 17:39:05 -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: Using Network Access Identifiers (NAI) from RFC4282 (was Re: [dix]requirements) Date: Mon, 27 Feb 2006 17:39:04 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B118@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using Network Access Identifiers (NAI) from RFC4282 (was Re: [dix]requirements) Thread-Index: AcY7/vp2Get+DthHRTKPGti3ZlbHuwACCWNQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 28 Feb 2006 01:39:05.0961 (UTC) FILETIME=[C2F06590:01C63C07] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: dix-bounces@ietf.org > From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 > Some thoughts on that suggestion. > 2. The identity "redirects" of RFC4282 -- the part that=20 > requires the "!" (exclamation mark) separator between realms=20 > -- is of unclear purpose to me. It might muddy the waters as=20 > I think assertable digital identity does not require=20 > redirects. I may be wrong. Me two. > 3. Why aren't those identifiers in URI format? URI format=20 > is very useful for building on many Web technologies. If=20 > RF4282 were used, I would think it would have to be with a=20 > scheme added to be URI compliant. I think that the definition of a URI form is useful, e.g. dix:alice@example.com PROVIDED that the spec makes it clear that this is a means of machine disambiguation and not something that MUST be exposed in the user interface. URIs were not intended as or designed to be a user interface. If someone is asked to provide their dix identifier they should not need to type dix: in front of it. If a dix identifier is entered in a context where the binding is ambiguous the scheme prefix may be a useful technique. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Feb 27 22:12:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDvHR-0005UP-4a; Mon, 27 Feb 2006 22:12:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDvHQ-0005UB-B9 for dix@ietf.org; Mon, 27 Feb 2006 22:12:04 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDvHP-0001fj-3D for dix@ietf.org; Mon, 27 Feb 2006 22:12:04 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FDvHO-0007yk-6N for dix@ietf.org; Mon, 27 Feb 2006 19:12:02 -0800 Message-Id: <6.2.3.4.2.20060228020850.057df810@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 28 Feb 2006 04:11:56 +0100 To: Digital Identity Exchange From: "JFC (Jefsey) Morfin" Subject: Re: [dix] What is "identity"? In-Reply-To: <440389D2.9040803@boreham.org> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <440389D2.9040803@boreham.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-226D7618 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: dix-bounces@ietf.org At 00:22 28/02/2006, David Boreham wrote: >I believe that all we need to know is that one identity needs to be >differentiated from another one and that we have 'stuff' that >belongs to each identity. I joined your debate only for a few days, so may be this is something you discussed and already killed? For me a network identity is an information that entity A can send to entity B so entity B can uniquely, surely, reliably, consistently and permanently identify and internally document entity A among all the Internet entities, and possibly to carry an authentication. If possible without leaking any information on entities A and B during the process. I think there also should be the requirement that entity B can pass that information onto entity C and that entity C is then able to uniquely, etc. identify entity A. I have no prerequisite about entities being a human, a machine, an application, a relation, an event, an information object, etc. or their avatars. However the entity carrying the identification must be able to process it (human or computer). Also, I tend to think that the best identity system is not protected, to reduce the risk of errors. Also, I think it should be as much as possible independent from any particular network technology. The avatar issue (an entity having several different identity roots) is, IMHO, addressed by the identity consistency and permanence. The difference between persona and avatars I make is that a persona is a variation of the same identity root. An avatar uses another non related indenty root. An avatar can have different personas. jfc _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 01:12:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDy66-0003cG-KN; Tue, 28 Feb 2006 01:12:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDy65-0003b9-Bk for dix@ietf.org; Tue, 28 Feb 2006 01:12:33 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDy64-0006sR-Nx for dix@ietf.org; Tue, 28 Feb 2006 01:12:33 -0500 Received: from [142.131.33.143] ([142.131.33.143]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1S6CVA2054084 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 22:12:31 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <4403D607.9020304@bbiw.net> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403D607.9020304@bbiw.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C0684E8-3D53-49AF-9A34-4EE706A36495@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 22:12:27 -0800 To: Dave Crocker 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: b1c41982e167b872076d0018e4e1dc3c Cc: Digital Identity Exchange 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 8:48 PM, Dave Crocker wrote: > > >>>> An identity is a set of assertions concerning a particular >>>> subject identifier. >>> >>> This definition seems to apply to the concept in Dick's ID-2 >>> talk, but we should be careful. Do we want to say that any set >>> of assertions > ... >> Do you have a suggestion Dave? I hope you are not one of those >> people that just poo-poos what other people do! :-) > > Thank heavens you included the dash between the poos. I might have > gotten > confused about what you were concerned about. Glad you are not confused > > I think i mentioned in any earlier post that I feel obligated to offer > alternative text, in these situations, when I think I understand > enough of the > goals of those seeking chartering. In this case, I don't even feel > close to > that understanding, although the single-signon example does help. > > Part of the problem I am seeing is that that example is nicely > concrete and very > much in the human realm, yet folks including Lisa seem fine with > definitions > that are entirely abstract. To me this seems entirely contradictory. > > So I'll attempt to lob an example of the sort I am suggesting is > needed, but > without any real faith that it will be in the same ballpark as the > bat you folks > are swinging. > > - - - - > > An identity is a globally unique reference to an online user or > agent. The form > of the reference is a URI. < statement that > general, but they will hold their breath, for now. /d>> Associated > with an > identity is a collection of information that describes > characteristics of the > identity and/or privileges imparted to the identity. The > information about an > identity can be divided into subsets, according to the different > functional > roles performed by the user or agent. This is where we differ. You are talking about "an identity" like it is an object. I see identity as being *all* the things about me. What you call identity above, I would call an identifier. > << Meta-suggestions: DIX should define an identity object first, > and make sure > it can be carried in multiple ways, unless there is something > special in the > semantics of the exchange mechanism. /d >> I was not involved, but HTTP did not need to define an object in order to be able to move things around. > > An initial application of DIX will be to permit users to have a > single step of > authenticating themselves to a DIX client and then having that > client be able to > perform other authentications, on behalf of the user, to servers > around the > Internet. If all we are doing is solving SSO with DIX, then we might as well stop now! Identity is *so* much more then username and password -- although not having to have a different username and password for each site is *nice*, it is not all that compelling for sites to adopt. That is a user issue. Making it easy for users to give sites data is compelling. The web took off because it was browsable. You did not need to type stuff in. Automating the movement of identity data is what DIX is about. SSO is a small subset of that. > > << By the way, one problem with this example is that it is not > obvious what it > is that requires an interoperable standard, as opposed to a common > database and > agent on a single machine, as folks already have. Where is the > requirement for > a distributed mechanism on the client side? /d >> that is because we are not just doing SSO -- need a common language for sites to make queries to get identity data > >>> The presentation was entertaining. It contained at least one >>> statement of equivalence that I find unpersuasive from just its >>> assertion. The equivalence of identity = reputation is a strong and > > Wearing my email anti-abuse hat, I will certainly claim that > anything called > "reputation" is grotesquely relative. It is not even close to "the > same as" the > identity of the thing having the reputation. your reputation is part of your identity ... >> Glad you found it entertaining. The key point was that identity is >> much more then a username and password. > > or less. > > if I change my password, I have not changed my identity. (Well, > not usually. I > did build an email service, once that used the password to ensure > uniqueness of > identity, but that was an anomoly is the design world, I think...) we need to be using the same definition of identity for this conversation to make sense :) -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 01:51:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDyiD-0004J3-H8; Tue, 28 Feb 2006 01:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDyiC-0004IE-AE for dix@ietf.org; Tue, 28 Feb 2006 01:51:56 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDyiA-00086C-SF for dix@ietf.org; Tue, 28 Feb 2006 01:51:56 -0500 Received: from [172.30.1.80] (207.47.33.7.rev.nextweb.net [207.47.33.7] (may be forged)) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1S6qS1J009162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 22:52:29 -0800 Message-ID: <4403F306.5000607@dcrocker.net> Date: Mon, 27 Feb 2006 22:51:50 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dick Hardt Subject: Re: [dix] requirements References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> In-Reply-To: <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>> An identity is a set of assertions concerning a particular subject >>> identifier. >> >> This definition seems to apply to the concept in Dick's ID-2 talk, but >> we should be careful. Do we want to say that any set of assertions ... > Do you have a suggestion Dave? I hope you are not one of those people > that just poo-poos what other people do! :-) Thank heavens you included the dash between the poos. I might have gotten confused about what you were concerned about. I think i mentioned in any earlier post that I feel obligated to offer alternative text, in these situations, when I think I understand enough of the goals of those seeking chartering. In this case, I don't even feel close to that understanding, although the single-signon example does help. Part of the problem I am seeing is that that example is nicely concrete and very much in the human realm, yet folks including Lisa seem fine with definitions that are entirely abstract. To me this seems entirely contradictory. So I'll attempt to lob an example of the sort I am suggesting is needed, but without any real faith that it will be in the same ballpark as the bat you folks are swinging. - - - - An identity is a globally unique reference to an online user or agent. The form of the reference is a URI. <> Associated with an identity is a collection of information that describes characteristics of the identity and/or privileges imparted to the identity. The information about an identity can be divided into subsets, according to the different functional roles performed by the user or agent. <> DIX is transaction mechanism for identity information. <> << Meta-suggestions: DIX should define an identity object first, and make sure it can be carried in multiple ways, unless there is something special in the semantics of the exchange mechanism. /d >> An initial application of DIX will be to permit users to have a single step of authenticating themselves to a DIX client and then having that client be able to perform other authentications, on behalf of the user, to servers around the Internet. << By the way, one problem with this example is that it is not obvious what it is that requires an interoperable standard, as opposed to a common database and agent on a single machine, as folks already have. Where is the requirement for a distributed mechanism on the client side? /d >> >> The presentation was entertaining. It contained at least one >> statement of equivalence that I find unpersuasive from just its >> assertion. The equivalence of identity = reputation is a strong and Wearing my email anti-abuse hat, I will certainly claim that anything called "reputation" is grotesquely relative. It is not even close to "the same as" the identity of the thing having the reputation. (By way of example, for a few folks on this list, there is a set of people among whom I have a reputation of being patient and kind. And, yes, they and the IETF community are perceiving the same identity... There is a reason I said "grotesque".) >> provocative claim. If the sort of definition of identity on which the >> WG's effort (implicitly) rests includes this equivalence, it deserves >> to be justified better. No, it deserves to be fixed. > Glad you found it entertaining. The key point was that identity is much > more then a username and password. or less. if I change my password, I have not changed my identity. (Well, not usually. I did build an email service, once that used the password to ensure uniqueness of identity, but that was an anomoly is the design world, I think...) d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 02:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDz5O-0003R7-1I; Tue, 28 Feb 2006 02:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDz5M-0003Qh-2p for dix@ietf.org; Tue, 28 Feb 2006 02:15:52 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDz5L-00004v-MW for dix@ietf.org; Tue, 28 Feb 2006 02:15:52 -0500 Received: from [172.30.1.80] (207.47.33.7.rev.nextweb.net [207.47.33.7] (may be forged)) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1S7GP9i011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 23:16:26 -0800 Message-ID: <4403F8A2.9090404@dcrocker.net> Date: Mon, 27 Feb 2006 23:15:46 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Dick Hardt Subject: Re: [dix] requirements References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403D607.9020304@bbiw.net> <6C0684E8-3D53-49AF-9A34-4EE706A36495@sxip.com> In-Reply-To: <6C0684E8-3D53-49AF-9A34-4EE706A36495@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > This is where we differ. You are talking about "an identity" like it is > an object. I see identity as being *all* the things about me. So when your password changes or your home phone number changes, it results in a different identity? I don't understand this paradigm. > What you call identity above, I would call an identifier. ok. >> << Meta-suggestions: DIX should define an identity object first, and >> make sure >> it can be carried in multiple ways, unless there is something special >> in the >> semantics of the exchange mechanism. /d >> > > I was not involved, but HTTP did not need to define an object in order > to be able to move things around. Protocols move data objects of some sort. No objects, no protocol. >> An initial application of DIX will be to permit users to have a single >> step of >> authenticating themselves to a DIX client and then having that client >> be able to >> perform other authentications, on behalf of the user, to servers >> around the >> Internet. > > If all we are doing is solving SSO with DIX, then we might as well stop > now! > > Identity is *so* much more then username and password -- although not > having to have a different username and password for each site is > *nice*, it is not all that compelling for sites to adopt. That is a user > issue. Making it easy for users to give sites data is compelling. > > The web took off because it was browsable. You did not need to type > stuff in. Automating the movement of identity data is what DIX is about. > SSO is a small subset of that. URLs can be typed in. Forms data can be typed in. A key click on a URL is a bit of input that is shipped to the server. The web was based on a particular usage goal. There was a very concrete problem to solve. That it was able to do more than that original task was not an accident, but it was not created as an exercise in abstract capabilities. >> << By the way, one problem with this example is that it is not obvious >> what it >> is that requires an interoperable standard, as opposed to a common >> database and >> agent on a single machine, as folks already have. Where is the >> requirement for >> a distributed mechanism on the client side? /d >> > > that is because we are not just doing SSO -- need a common language for > sites to make queries to get identity data As I said, I was trying to formulate a concrete task. SSO was mentioned by one of you folk so that's what I went with. If the entire goal of the exercise is to create a standard that is highly general but has no immediate customers trying to solve an immediate, concrete, specific problem, you will find adoption a tad slow. >>> Glad you found it entertaining. The key point was that identity is >>> much more then a username and password. >> >> or less. >> >> if I change my password, I have not changed my identity. (Well, not >> usually. I >> did build an email service, once that used the password to ensure >> uniqueness of >> identity, but that was an anomoly is the design world, I think...) > > we need to be using the same definition of identity for this > conversation to make sense :) yup. as I recall, that was a basic point to my early (and continuing) postings on this lists. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 02:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDzLk-0006hZ-6A; Tue, 28 Feb 2006 02:32:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDzLi-0006gu-Ue for dix@ietf.org; Tue, 28 Feb 2006 02:32:46 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDzLf-0000X7-JL for dix@ietf.org; Tue, 28 Feb 2006 02:32:46 -0500 Received: from [142.131.33.143] ([142.131.33.143]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1S7WfVV079384 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 27 Feb 2006 23:32:42 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <4403F8A2.9090404@dcrocker.net> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403D607.9020304@bbiw.net> <6C0684E8-3D53-49AF-9A34-4EE706A36495@sxip.com> <4403F8A2.9090404@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <490A8F43-009E-4A98-A8A7-9105DF121283@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] requirements Date: Mon, 27 Feb 2006 23:32:37 -0800 To: dcrocker@bbiw.net 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 Cc: Digital Identity Exchange 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: , Errors-To: dix-bounces@ietf.org On 27-Feb-06, at 11:15 PM, Dave Crocker wrote: > > >> This is where we differ. You are talking about "an identity" like >> it is an object. I see identity as being *all* the things about me. > > So when your password changes or your home phone number changes, it > results in a > different identity? I don't understand this paradigm. Good to point the temporal nature of identity. Since your identity is constantly changing, which makes it hard to be an object. My reputation one day is different then another day. Trusting me today does not mean you will trust me tomorrow. Not sure what is hard about this. It is how the world works. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 05:46:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2NE-0003xP-MA; Tue, 28 Feb 2006 05:46:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2ND-0003xC-34 for dix@ietf.org; Tue, 28 Feb 2006 05:46:31 -0500 Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE2N9-0006VG-M1 for dix@ietf.org; Tue, 28 Feb 2006 05:46:31 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B3D3933C44 for ; Tue, 28 Feb 2006 10:46:26 +0000 (GMT) Message-ID: <44042A05.30208@algroup.co.uk> Date: Tue, 28 Feb 2006 10:46:29 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] What is "identity"? References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <5119e63cb20fae59275cbe3c13313bd9@cisco.com> In-Reply-To: <5119e63cb20fae59275cbe3c13313bd9@cisco.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: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: dix-bounces@ietf.org John Schnizlein wrote: >=20 > On Feb 27, 2006, at 5:41 PM, Dick Hardt wrote: >=20 >> On 27-Feb-06, at 1:46 PM, Dave Crocker wrote: >> >>> "who you are" is a reasonable place to begin, but does not have quite >>> enough substance to direct technical work. For example, the >>> difference between a person performing in one role, versus another, >>> might or might not require different identities. It might even >>> require some sort of identity "hierarchy". >> >> I see that people will have many personas, but only one identity. Each >> persona presents a different facet of themselves. >=20 > Slippery slope alert! >=20 > This statement seems to mix the every-day meaning of identity with the > formal definition that is necessary for technical progress. What is th= e > precise relationship between a persona and an identity? Who gets to > know that relationship? There is a document that defines all the terms you could need for this discussion, and then some. I'd suggest we don't argue over terminology and just adopt it: "Anonymity, Unlinkability, Unobservability, Pseudonymity, and Identity Management - A Consolidated Proposal for Terminology" which can be found here: http://dud.inf.tu-dresden.de/Anon_Terminology.shtml Incidentally, it defines identity like this: "An identity is any subset of attributes of an individual which identifies this individual within any set of individuals. So usually there is no such thing as =93the identity=94, but several of them." The word "persona" does not come up at all. Which is probably a good thin= g. Cheers, Ben. --=20 http://www.apache-ssl.org/ben.html http://www.links.org/ "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 Tue Feb 28 10:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Pv-0001bD-CM; Tue, 28 Feb 2006 10:05:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Pt-0001b5-UY for dix@ietf.org; Tue, 28 Feb 2006 10:05:33 -0500 Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6Ps-0006VS-NJ for dix@ietf.org; Tue, 28 Feb 2006 10:05:33 -0500 Received: by wproxy.gmail.com with SMTP id 55so151687wri for ; Tue, 28 Feb 2006 07:05:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=RTizgf5HqfURh4j1Pu7XctjkWvMJMyQMv+0LmKuft+a3WhGUwVvLnLlZraObgGKH2MCZfKBkXzCaNxu7Ydjm9/gsmRHvDw7ATijzAjyLsItR+EychGlCbBZkRKcNjVlqXiK5ZC29aLB1njxsXSBS7+hrNWBlKU2KmhcD3MLLfZk= Received: by 10.54.109.15 with SMTP id h15mr695950wrc; Tue, 28 Feb 2006 07:05:31 -0800 (PST) Received: from ?9.33.25.195? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 15sm797055wrl.2006.02.28.07.05.31; Tue, 28 Feb 2006 07:05:31 -0800 (PST) Message-ID: <440466BA.7080803@gmail.com> Date: Tue, 28 Feb 2006 10:05:30 -0500 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [dix] authenticated feedreaders and current draft 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: , Errors-To: dix-bounces@ietf.org The current draft specifies that browsers are the only "Dumb Client". I'd argue that for widespread adoption the specification also needs to target feedreaders and potentially other dumb http clients. Feeds are becoming increasingly important and authenticated feeds are needed for subscribing to things like gmail or apple's photocasts. I think that feedreaders need to be able to utilize the SSO aspects of DIX. One means of achieving this is by allowing POSTS or GETS to move the messages. If a request to the homesite is received via a GET then its response should also be a GET and an HTTP redirect should be used to bounce the message via the users "dumb client". Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 12:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE96O-0004Bu-Gw; Tue, 28 Feb 2006 12:57:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE96O-0004Bp-33 for dix@ietf.org; Tue, 28 Feb 2006 12:57:36 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE96M-00045v-TX for dix@ietf.org; Tue, 28 Feb 2006 12:57:36 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FE96L-0001L8-Gn; Tue, 28 Feb 2006 09:57:34 -0800 Message-Id: <6.2.3.4.2.20060228154333.04c7c1c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 28 Feb 2006 15:45:09 +0100 To: Digital Identity Exchange , Digital Identity Exchange From: "JFC (Jefsey) Morfin" Subject: Re: [dix] What is "identity"? In-Reply-To: <44042A05.30208@algroup.co.uk> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <5119e63cb20fae59275cbe3c13313bd9@cisco.com> <44042A05.30208@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-33C3920 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: , Errors-To: dix-bounces@ietf.org At 11:46 28/02/2006, Ben Laurie wrote: >"An identity is any subset of attributes of an individual which >identifies this individual within any set of individuals. So usually >there is no such thing as "the identity", but several of them." I agree. My definition is more construed and can be used as part of an analysis. >The word "persona" does not come up at all. Which is probably a good thing. I understand persona as one of these subsets? jfc _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 14:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEAU5-0007Ie-QS; Tue, 28 Feb 2006 14:26:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEAU4-0007IK-Ly for dix@ietf.org; Tue, 28 Feb 2006 14:26:08 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEAU3-00074k-8t for dix@ietf.org; Tue, 28 Feb 2006 14:26:08 -0500 Received: from [142.131.33.143] ([142.131.33.143]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1SJQ5lm007449 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Feb 2006 11:26:06 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <6.2.3.4.2.20060228154333.04c7c1c0@mail.jefsey.com> References: <43FBF5F5.5010909@dcrocker.net> <440359DB.8010309@dcrocker.net> <94329A7F-680C-4CC0-9BC7-99E4729000E8@sxip.com> <44037350.4030106@dcrocker.net> <5119e63cb20fae59275cbe3c13313bd9@cisco.com> <44042A05.30208@algroup.co.uk> <6.2.3.4.2.20060228154333.04c7c1c0@mail.jefsey.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Tue, 28 Feb 2006 11:26:01 -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 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: , Errors-To: dix-bounces@ietf.org On 28-Feb-06, at 6:45 AM, JFC (Jefsey) Morfin wrote: > At 11:46 28/02/2006, Ben Laurie wrote: >> "An identity is any subset of attributes of an individual which >> identifies this individual within any set of individuals. So usually >> there is no such thing as "the identity", but several of them." > > I agree. My definition is more construed and can be used as part of > an analysis. I can go with that definition. Would all of the attributes be "your identity" Also, there would be an almost infinite number of combinations, so you have an unlimited number of identities. > >> The word "persona" does not come up at all. Which is probably a >> good thing. > > I understand persona as one of these subsets? I would suggest that persona is a *persistent* identity. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 15:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBq1-0000eL-SY; Tue, 28 Feb 2006 15:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBpq-0000Wo-5O for dix@ietf.org; Tue, 28 Feb 2006 15:52:42 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEBkB-0001WW-FV for dix@ietf.org; Tue, 28 Feb 2006 15:46:54 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A7B11422A8; Tue, 28 Feb 2006 12:46:50 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08342-08; Tue, 28 Feb 2006 12:46:49 -0800 (PST) Received: from [192.168.101.217] (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 C7CCE14228B; Tue, 28 Feb 2006 12:46:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4403F306.5000607@dcrocker.net> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403F306.5000607@dcrocker.net> Message-Id: <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> From: Lisa Dusseault Subject: Re: [dix] requirements Date: Tue, 28 Feb 2006 12:46:22 -0800 To: dcrocker@bbiw.net, Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 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: , Content-Type: multipart/mixed; boundary="===============1632228112==" Errors-To: dix-bounces@ietf.org --===============1632228112== Content-Type: multipart/alternative; boundary=Apple-Mail-10--356374465 --Apple-Mail-10--356374465 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote: > > An identity is a globally unique reference to an online user or > agent. The form > of the reference is a URI. < statement that > general, but they will hold their breath, for now. /d>> Associated > with an > identity is a collection of information that describes > characteristics of the > identity and/or privileges imparted to the identity. The > information about an > identity can be divided into subsets, according to the different > functional > roles performed by the user or agent. This is very useful text. I'd be happy to see such text in a draft introducing a particular identity system, but I think it's also appropriate for the charter provided it doesn't contradict too many models. It does pre-suppose some part of a solution but that may even be appropriate if we all agree on that part of a solution even before chartering. Is it helpful to also point out that it's expected that these identities will come from different authorities that aren't required to coordinate with one another in any way? > > DIX is transaction mechanism for identity information. < questions: > you mean dix semantics cannot transit via email? equally obvious > question: why > does this need a new transfer mechanism? >> Transport rather than transaction? Suggested further text perhaps: "Currently, there is no standard, interoperable way for a user to have some identity information transferred from an identity authority to a third-party consumer of such information." > > << Meta-suggestions: DIX should define an identity object first, > and make sure > it can be carried in multiple ways, unless there is something > special in the > semantics of the exchange mechanism. /d >> > > An initial application of DIX will be to permit users to have a > single step of > authenticating themselves to a DIX client and then having that > client be able to > perform other authentications, on behalf of the user, to servers > around the > Internet. I think most people are thinking in terms of "users having a way to authenticate themselves to a DIX identity authority (NOT a client) and having that authority be able to vouch for their identity, oh behalf of the user, to servers around the Internet." That is the most common model I've seen, although it *also* presupposes some aspects of a solution. For example, a solution where clients generated one or more self-signed certificates, in addition to a possible set of certs signed by other authorities, and selected from those to identify themselves to servers around the internet -- would not quite fit that description. > > << By the way, one problem with this example is that it is not > obvious what it > is that requires an interoperable standard, as opposed to a common > database and > agent on a single machine, as folks already have. Where is the > requirement for > a distributed mechanism on the client side? /d >> My last two paragraphs above may answer your question about what requires an interoperable standard. > > >>> The presentation was entertaining. It contained at least one >>> statement of equivalence that I find unpersuasive from just its >>> assertion. The equivalence of identity = reputation is a strong and > > Wearing my email anti-abuse hat, I will certainly claim that > anything called > "reputation" is grotesquely relative. It is not even close to "the > same as" the > identity of the thing having the reputation. > > (By way of example, for a few folks on this list, there is a set of > people among > whom I have a reputation of being patient and kind. And, yes, they > and the IETF > community are perceiving the same identity... There is a reason I > said > "grotesque".) Reputation may be out of scope for an initial charter for DIX. I would suggest that would be a wise choice for limiting the initial work as it would not limit later work. Lisa --Apple-Mail-10--356374465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 27, 2006, = at 10:51 PM, Dave Crocker wrote:


An = identity is a globally unique reference to an online user or agent.=A0 The form
of the reference is a URI.=A0 <<There are some = serious dragons in a statement that
general, but = they will hold their breath, for now. /d>> Associated with = an
identity is a collection of information that = describes characteristics of the
identity = and/or privileges imparted to the identity.=A0 The information about = an
identity can be divided into subsets, according = to the different functional
roles = performed by the user or agent.

This is very useful text.=A0 = I'd be happy to see such text in a draft introducing a particular = identity system, but I think it's also appropriate for the charter = provided it doesn't contradict too many models.=A0 It does pre-suppose = some part of a solution but that may even be appropriate if we all agree = on that part of a solution even before chartering.

Is it helpful to also point = out that it's expected that these identities will come from different = authorities that aren't required to coordinate with one another in any = way?


DIX is = transaction mechanism for identity information.=A0 <<obvious = questions:
you mean dix semantics cannot = transit via email?=A0 = equally obvious question: why
does this = need a new transfer mechanism? >>

Transport rather than = transaction?=A0=A0

Suggested further text = perhaps:=A0 "Currently, there is no standard, interoperable way for a = user to have some identity information transferred from an identity = authority to a third-party consumer of such = information."


<< = Meta-suggestions:=A0 DIX = should define an identity object first, and make sure
it can be carried in multiple ways, unless there is = something special in the
semantics of = the exchange mechanism. /d >>

An initial application of DIX = will be to permit users to have a single step of
authenticating themselves to a DIX client and then = having that client be able to
perform other = authentications, on behalf of the user, to servers around the
Internet.

I think most people are = thinking in terms of "users having a way to authenticate themselves to a = DIX identity authority (NOT a client) and having that authority be able = to vouch for their identity, oh behalf of the user, to servers around = the Internet."

That is the most common = model I've seen, although it *also* presupposes some aspects of a = solution.=A0 =A0For example, a solution where clients generated one or = more self-signed certificates, in addition to a possible set of certs = signed by other authorities, and selected from those to identify = themselves to servers around the internet --=A0 would not quite fit that = description.


<< By = the way, one problem with this example is that it is not obvious what = it
is that requires an interoperable standard, as = opposed to a common database and
agent on a = single machine, as folks already have.=A0 Where is the requirement = for
a distributed mechanism on the = client side?=A0 /d = >>

My last two paragraphs = above may answer your question about what requires an interoperable = standard.



The presentation was = entertaining.=A0 It = contained at least one statement of equivalence that I find unpersuasive = from just its assertion.=A0 = The equivalence of identity =3D reputation is a strong and=A0
=
Wearing my email anti-abuse hat, = I will certainly claim that anything called
=A0 It is not even close to "the = same as" the
identity of the thing having the = reputation.

(By way of example, for a few folks on this list, = there is a set of people among
whom I have a = reputation of being patient and kind.=A0 And, yes, they and the = IETF
community are perceiving the = same identity...=A0 There = is a reason I said

Reputation may be out of = scope for an initial charter for DIX.=A0 I would suggest that would be a = wise choice for limiting the initial work as it would not limit later = work.

Lisa

= --Apple-Mail-10--356374465-- --===============1632228112== 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 --===============1632228112==-- From dix-bounces@ietf.org Tue Feb 28 16:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FECig-0007p9-3O; Tue, 28 Feb 2006 16:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FECHn-0001vt-IC for dix@ietf.org; Tue, 28 Feb 2006 16:21:35 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FECHl-0006QQ-SS for dix@ietf.org; Tue, 28 Feb 2006 16:21:35 -0500 Received: from [172.16.1.126] (207.47.33.159.rev.nextweb.net [207.47.33.159] (may be forged)) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1SLM1Y1019740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Feb 2006 13:22:02 -0800 Message-ID: <4404BED4.80604@dcrocker.net> Date: Tue, 28 Feb 2006 13:21:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] requirements References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403F306.5000607@dcrocker.net> <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> In-Reply-To: <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >> DIX is transaction mechanism for identity information. <> questions: >> you mean dix semantics cannot transit via email? equally obvious >> question: why >> does this need a new transfer mechanism? >> > > Transport rather than transaction? Well, I meant transaction, but perhaps it is not correct. In any event, I suspect that a focus on the movement of the identity information is a distraction from the hard part, namely formulating a standard data structure, and basic contents, for the identity information object(s). d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 17:05:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FECy7-0007IG-4l; Tue, 28 Feb 2006 17:05:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FECy6-0007DX-08 for dix@ietf.org; Tue, 28 Feb 2006 17:05:18 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FECJv-0006g0-KD for dix@ietf.org; Tue, 28 Feb 2006 16:23:47 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEC8l-0004IJ-CO for dix@ietf.org; Tue, 28 Feb 2006 16:12:17 -0500 Received: from [142.131.33.143] ([142.131.33.143]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k1SLCDRP011109 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Feb 2006 13:12:13 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440466BA.7080803@gmail.com> References: <440466BA.7080803@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] authenticated feedreaders and current draft Date: Tue, 28 Feb 2006 13:12: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: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Errors-To: dix-bounces@ietf.org On 28-Feb-06, at 7:05 AM, Robert Yates wrote: > The current draft specifies that browsers are the only "Dumb > Client". I'd argue that for widespread adoption the specification > also needs to target feedreaders and potentially other dumb http > clients. Feeds are becoming increasingly important and > authenticated feeds are needed for subscribing to things like gmail > or apple's photocasts. I think that feedreaders need to be able to > utilize the SSO aspects of DIX. > > One means of achieving this is by allowing POSTS or GETS to move > the messages. If a request to the homesite is received via a GET > then its response should also be a GET and an HTTP redirect should > be used to bounce the message via the users "dumb client". Great suggestion Robert. For discussion sake, let's call things like feedreaders and other non- browser http clients "Rich Clients", since they are doing more then just getting a page and displaying it. This is a much deeper problem then fetching RSS feeds. There is much more complexity when you get into identity issues with full Web Services -- something that the WS- * efforts are working to solve. I would argue that a more RESTful identity exchange mechanism would be of great benefit to RESTful web services. A design constraint of DIX was being able to work with unmodified browsers (easier to get adoption), but I think Rich Clients can be modified to support a more seamless exchange of identity data. There was an IETF BOF on Beyond Basic Auth that I had hoped would develop some richer Auth mechanisms within HTTP that could work with DIX. Unfortunately, I think adding support for Rich Clients to the DIX charter would widen the scope too much. :( -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 17:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDam-0000za-K0; Tue, 28 Feb 2006 17:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDak-0000yM-55 for dix@ietf.org; Tue, 28 Feb 2006 17:45:14 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDai-0003cz-RU for dix@ietf.org; Tue, 28 Feb 2006 17:45:14 -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 k1SMjAMM024150 for ; Tue, 28 Feb 2006 14:45:10 -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); Tue, 28 Feb 2006 14:45: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 Date: Tue, 28 Feb 2006 14:45:09 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Federated Digest Auth Thread-Index: AcY8sxX1/Tf6NNI9ReW8N9zZoFvRAQABOwYQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 28 Feb 2006 22:45:09.0945 (UTC) FILETIME=[A1007A90:01C63CB8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [dix] Federated Digest Auth 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: , Errors-To: dix-bounces@ietf.org > From: Dick Hardt [mailto:dick@sxip.com]=20 > There was an IETF BOF on Beyond Basic Auth that I had hoped=20 > would develop some richer Auth mechanisms within HTTP that=20 > could work with DIX. How about Digest, it is supported inpractically every browser in use, it is secure against man in the middle attack, it is a standard and a MUST for HTTP/1.1 It takes practically no work to federate Digest and there is prior art on federation in the original proposal. If you use use the email address as the username, a common realm and SRV records as a discovery mechanism you can implement an interoperable federated auth scheme from existing code in a few hours. The scheme can be made even more compact and avoid leaking the URI being viewed by passing the HA2 value along with the federated auth request. Its simple, secure and built on existing standards. When I discussed this with Dan Connoly he had been thinking on very similar lines. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 18:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDti-0005eG-DA; Tue, 28 Feb 2006 18:04:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDte-0005Va-46 for dix@ietf.org; Tue, 28 Feb 2006 18:04:46 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDoI-0003o5-3u for dix@ietf.org; Tue, 28 Feb 2006 17:59:14 -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 k1SM1rJT021911; Tue, 28 Feb 2006 14:01: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); Tue, 28 Feb 2006 14:01:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] requirements Date: Tue, 28 Feb 2006 14:01:51 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B227@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] requirements Thread-Index: AcY8qP7dLs7XqDMVSU256/jHzYpjywABjQxQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" , X-OriginalArrivalTime: 28 Feb 2006 22:01:53.0083 (UTC) FILETIME=[9526C8B0:01C63CB2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 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: , Content-Type: multipart/mixed; boundary="===============0090148921==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0090148921== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63CB2.94CC324E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63CB2.94CC324E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would not like to see the text replicated in any document. It is fundamentally wrong. =20 I am not a number, I am a free man. =20 My Star Alliance account number is not my identity, it is one identifier that I use in one context. =20 =20 A DIX identifier is a globally unique reference to an online user or agent. The cannonical form of the reference is a URI. Associated with an identifier are collections of information that describes characteristics of and/or privileges imparted to the online user or agent. These collections of information are the identities of the online user or agent identified by the identifier. =20 =20 [The term persona should be avoided here. A persona or avatar is generally a disjoint identity that is not ordinarily linkable to other identies of the owner] =20 ________________________________ From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 Sent: Tuesday, February 28, 2006 3:46 PM To: dcrocker@bbiw.net; Digital Identity Exchange Subject: Re: [dix] requirements =09 =09 On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote: An identity is a globally unique reference to an online user or agent. The form of the reference is a URI. <> Associated with an identity is a collection of information that describes characteristics of the identity and/or privileges imparted to the identity. The information about an identity can be divided into subsets, according to the different functional roles performed by the user or agent. This is very useful text. I'd be happy to see such text in a draft introducing a particular identity system, but I think it's also appropriate for the charter provided it doesn't contradict too many models. It does pre-suppose some part of a solution but that may even be appropriate if we all agree on that part of a solution even before chartering. Is it helpful to also point out that it's expected that these identities will come from different authorities that aren't required to coordinate with one another in any way? =09 =09 DIX is transaction mechanism for identity information. <> Transport rather than transaction? =20 Suggested further text perhaps: "Currently, there is no standard, interoperable way for a user to have some identity information transferred from an identity authority to a third-party consumer of such information." << Meta-suggestions: DIX should define an identity object first, and make sure it can be carried in multiple ways, unless there is something special in the semantics of the exchange mechanism. /d >> An initial application of DIX will be to permit users to have a single step of authenticating themselves to a DIX client and then having that client be able to perform other authentications, on behalf of the user, to servers around the Internet. I think most people are thinking in terms of "users having a way to authenticate themselves to a DIX identity authority (NOT a client) and having that authority be able to vouch for their identity, oh behalf of the user, to servers around the Internet." That is the most common model I've seen, although it *also* presupposes some aspects of a solution. For example, a solution where clients generated one or more self-signed certificates, in addition to a possible set of certs signed by other authorities, and selected from those to identify themselves to servers around the internet -- would not quite fit that description. << By the way, one problem with this example is that it is not obvious what it is that requires an interoperable standard, as opposed to a common database and agent on a single machine, as folks already have. Where is the requirement for a distributed mechanism on the client side? /d >> My last two paragraphs above may answer your question about what requires an interoperable standard. The presentation was entertaining. It contained at least one statement of equivalence that I find unpersuasive from just its assertion. The equivalence of identity =3D reputation is = a strong and=20 Wearing my email anti-abuse hat, I will certainly claim that anything called "reputation" is grotesquely relative. It is not even close to "the same as" the identity of the thing having the reputation. (By way of example, for a few folks on this list, there is a set of people among whom I have a reputation of being patient and kind. And, yes, they and the IETF community are perceiving the same identity... There is a reason I said "grotesque".) Reputation may be out of scope for an initial charter for DIX. I would suggest that would be a wise choice for limiting the initial work as it would not limit later work. Lisa ------_=_NextPart_001_01C63CB2.94CC324E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would not like to see the text replicated in = any=20 document. It is fundamentally wrong.
 
I am not a number, I am a free = man.
 
My Star Alliance account number is not my = identity, it is=20 one identifier that I use in one context.
 
 
A DIX identifier is a globally unique reference to = an online=20 user or agent.  = The cannonical form=20 of the reference is a URI. Associated with an identifier are=20 collections of = information that=20 describes characteristics of  = and/or=20 privileges imparted to the = online user or=20 agent. These collections of = information are=20 the identities of the online user or agent identified by the=20 identifier.
 
 
[The term persona should be avoided here.=20 A persona or avatar is generally a disjoint = identity that=20 is not ordinarily linkable to other identies of the=20 owner]
 

From: Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Sent: Tuesday, February 28, = 2006=20 3:46 PM
To: dcrocker@bbiw.net; Digital Identity=20 Exchange
Subject: Re: [dix] = requirements


On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote:

An identity is a globally unique = reference to an=20 online user or agent.  = The=20 form
of the reference is a URI.  <<There are some = serious=20 dragons in a statement that
general, but they will hold their breath, = for now.=20 /d>> Associated with an
identity is a collection of information = that=20 describes characteristics of the
identity and/or privileges imparted to = the=20 identity.  The = information=20 about an
identity can be divided into subsets, = according to=20 the different functional
roles performed by the user or=20 agent.

This is very useful text.  I'd be happy to see such text in = a draft=20 introducing a particular identity system, but I think it's also = appropriate=20 for the charter provided it doesn't contradict too many models.  = It does=20 pre-suppose some part of a solution but that may even be appropriate = if we all=20 agree on that part of a solution even before chartering.

Is it helpful to also point out that it's expected that these = identities=20 will come from different authorities that aren't required to = coordinate with=20 one another in any way?


DIX is transaction mechanism for identity = information.  = <<obvious=20 questions:
you mean dix semantics cannot transit via = email?  equally = obvious=20 question: why
does this need a new transfer mechanism?=20 >>

Transport rather than transaction?  

Suggested further text perhaps:  "Currently, there is no = standard,=20 interoperable way for a user to have some identity information = transferred=20 from an identity authority to a third-party consumer of such=20 information."


<< Meta-suggestions:  DIX should define an = identity=20 object first, and make sure
it can be carried in multiple ways, = unless there is=20 something special in the
semantics of the exchange mechanism. /d=20 >>

An initial application of DIX will be to = permit=20 users to have a single step of
authenticating themselves to a DIX client = and then=20 having that client be able to
perform other authentications, on behalf = of the=20 user, to servers around the
Internet.

I think most people are thinking in terms of "users having a way = to=20 authenticate themselves to a DIX identity authority (NOT a client) and = having=20 that authority be able to vouch for their identity, oh behalf of the = user, to=20 servers around the Internet."

That is the most common model I've seen, although it *also* = presupposes=20 some aspects of a solution.   For example, a solution where = clients=20 generated one or more self-signed certificates, in addition to a = possible set=20 of certs signed by other authorities, and selected from those to = identify=20 themselves to servers around the internet --  would not quite fit = that=20 description.


<< By the way, one problem with = this example=20 is that it is not obvious what it
is that requires an interoperable = standard, as=20 opposed to a common database and
agent on a single machine, as folks = already=20 have.  Where is the=20 requirement for
a distributed mechanism on the client = side?  /d = >>

My last two paragraphs above may answer your question about what = requires=20 an interoperable standard.



The presentation was = entertaining.  It contained at = least one=20 statement of equivalence that I find unpersuasive from just its=20 assertion.  The=20 equivalence of identity =3D reputation is a strong and 

Wearing my email anti-abuse hat, I will = certainly=20 claim that anything called
"reputation" is grotesquely = relative.  It is not even close to = "the same=20 as" the
identity of the thing having the = reputation.

(By way of example, for a few folks on = this list,=20 there is a set of people among
whom I have a reputation of being patient = and=20 kind.  And, yes, = they and the=20 IETF
community are perceiving the same = identity...  There is a reason I = said
"grotesque".)

Reputation may be out of scope for an initial charter for = DIX.  I=20 would suggest that would be a wise choice for limiting the initial = work as it=20 would not limit later work.

Lisa

------_=_NextPart_001_01C63CB2.94CC324E-- --===============0090148921== 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 --===============0090148921==-- From dix-bounces@ietf.org Tue Feb 28 18:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEE3h-0003qM-VY; Tue, 28 Feb 2006 18:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEE3h-0003q6-1P for dix@ietf.org; Tue, 28 Feb 2006 18:15:09 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEE3g-0004HT-5o for dix@ietf.org; Tue, 28 Feb 2006 18:15:09 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 647631422A9; Tue, 28 Feb 2006 15:15:07 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05059-03; Tue, 28 Feb 2006 15:15:06 -0800 (PST) Received: from [192.168.101.217] (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 CAC951422BD; Tue, 28 Feb 2006 15:15:05 -0800 (PST) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B227@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B227@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Lisa Dusseault Subject: Re: [dix] requirements Date: Tue, 28 Feb 2006 15:14:47 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: dcrocker@bbiw.net 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="===============1927652220==" Errors-To: dix-bounces@ietf.org --===============1927652220== Content-Type: multipart/alternative; boundary=Apple-Mail-15--347469497 --Apple-Mail-15--347469497 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Well, that seems like an even better iteration of the text. We may also be able to avoid using "identity" by focusing only on "identifiers". Thanks Phillip. Lisa On Feb 28, 2006, at 2:01 PM, Hallam-Baker, Phillip wrote: > I would not like to see the text replicated in any document. It is > fundamentally wrong. > > I am not a number, I am a free man. > > My Star Alliance account number is not my identity, it is one > identifier that I use in one context. > > > A DIX identifier is a globally unique reference to an online user > or agent. The cannonical form of the reference is a URI. > Associated with an identifier are collections of information that > describes characteristics of and/or privileges imparted to the > online user or agent. These collections of information are the > identities of the online user or agent identified by the identifier. > > > [The term persona should be avoided here. A persona or avatar is > generally a disjoint identity that is not ordinarily linkable to > other identies of the owner] > > > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > Sent: Tuesday, February 28, 2006 3:46 PM > To: dcrocker@bbiw.net; Digital Identity Exchange > Subject: Re: [dix] requirements > > > On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote: > >> >> An identity is a globally unique reference to an online user or >> agent. The form >> of the reference is a URI. <> statement that >> general, but they will hold their breath, for now. /d>> Associated >> with an >> identity is a collection of information that describes >> characteristics of the >> identity and/or privileges imparted to the identity. The >> information about an >> identity can be divided into subsets, according to the different >> functional >> roles performed by the user or agent. > > This is very useful text. I'd be happy to see such text in a draft > introducing a particular identity system, but I think it's also > appropriate for the charter provided it doesn't contradict too many > models. It does pre-suppose some part of a solution but that may > even be appropriate if we all agree on that part of a solution even > before chartering. > > Is it helpful to also point out that it's expected that these > identities will come from different authorities that aren't > required to coordinate with one another in any way? > >> >> DIX is transaction mechanism for identity information. <> questions: >> you mean dix semantics cannot transit via email? equally obvious >> question: why >> does this need a new transfer mechanism? >> > > Transport rather than transaction? > > Suggested further text perhaps: "Currently, there is no standard, > interoperable way for a user to have some identity information > transferred from an identity authority to a third-party consumer of > such information." > >> >> << Meta-suggestions: DIX should define an identity object first, >> and make sure >> it can be carried in multiple ways, unless there is something >> special in the >> semantics of the exchange mechanism. /d >> >> >> An initial application of DIX will be to permit users to have a >> single step of >> authenticating themselves to a DIX client and then having that >> client be able to >> perform other authentications, on behalf of the user, to servers >> around the >> Internet. > > I think most people are thinking in terms of "users having a way to > authenticate themselves to a DIX identity authority (NOT a client) > and having that authority be able to vouch for their identity, oh > behalf of the user, to servers around the Internet." > > That is the most common model I've seen, although it *also* > presupposes some aspects of a solution. For example, a solution > where clients generated one or more self-signed certificates, in > addition to a possible set of certs signed by other authorities, > and selected from those to identify themselves to servers around > the internet -- would not quite fit that description. > >> >> << By the way, one problem with this example is that it is not >> obvious what it >> is that requires an interoperable standard, as opposed to a common >> database and >> agent on a single machine, as folks already have. Where is the >> requirement for >> a distributed mechanism on the client side? /d >> > > My last two paragraphs above may answer your question about what > requires an interoperable standard. > >> >> >>>> The presentation was entertaining. It contained at least one >>>> statement of equivalence that I find unpersuasive from just its >>>> assertion. The equivalence of identity = reputation is a strong >>>> and >> >> Wearing my email anti-abuse hat, I will certainly claim that >> anything called >> "reputation" is grotesquely relative. It is not even close to >> "the same as" the >> identity of the thing having the reputation. >> >> (By way of example, for a few folks on this list, there is a set >> of people among >> whom I have a reputation of being patient and kind. And, yes, >> they and the IETF >> community are perceiving the same identity... There is a reason I >> said >> "grotesque".) > > Reputation may be out of scope for an initial charter for DIX. I > would suggest that would be a wise choice for limiting the initial > work as it would not limit later work. > > Lisa > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-15--347469497 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Well, that seems like an even = better iteration of the text.=A0 We may also be able to avoid using = "identity" by focusing only on "identifiers". Thanks Phillip.

Lisa

= On Feb 28, 2006, at 2:01 PM, Hallam-Baker, Phillip wrote:

I would not like to see the = text replicated in any document. It is fundamentally = wrong.
=A0
I am not a number, I am a free man.
=A0
My Star Alliance account = number is not my identity, it is one identifier that I use in one = context.
=A0
=A0
A DIX=A0identifier is a globally unique reference = to an online user or agent.=A0 = The=A0cannonical = form of the reference = is a URI.=A0Associated with = an identifier=A0are collections of information that describes = characteristics of=A0 and/or = privileges imparted to the = online user or agent. These = collections of information=A0are the identities of the online user or = agent identified by the identifier.
=
=A0
=A0
[The term persona should be = avoided here. A persona or avatar is = generally a disjoint identity that is not ordinarily linkable to other = identies of the owner]
=A0

=
From: = Lisa Dusseault [mailto:lisa@osafoundation.org] =
Sent: Tuesday, February 28, 2006 3:46 PM
To: dcrocker@bbiw.net; Digital = Identity Exchange
Subject: Re: [dix] = requirements


On Feb = 27, 2006, at 10:51 PM, Dave Crocker wrote:


An identity is a globally unique reference to an = online user or agent.=A0 = The form
of the reference = is a URI.=A0 <<There = are some serious dragons in a statement that
general, but they will hold their breath, for now. = /d>> Associated with an
identity is a collection of information that describes = characteristics of the
identity = and/or privileges imparted to the identity.=A0 The information about = an
identity can be divided into = subsets, according to the different functional
roles performed by the user or = agent.

This is very useful = text.=A0 I'd be happy to see such text in a draft introducing a = particular identity system, but I think it's also appropriate for the = charter provided it doesn't contradict too many models.=A0 It does = pre-suppose some part of a solution but that may even be appropriate if = we all agree on that part of a solution even before chartering.
=

Is it helpful to = also point out that it's expected that these identities will come from = different authorities that aren't required to coordinate with one = another in any way?

=

DIX is transaction mechanism for identity information.=A0 <<obvious = questions:
you mean dix semantics = cannot transit via email?=A0 = equally obvious question: why
does this need a new transfer mechanism? = >>

Transport rather than = transaction?=A0=A0

Suggested further text = perhaps:=A0 "Currently, there is no standard, interoperable way for a = user to have some identity information transferred from an identity = authority to a third-party consumer of such information."

=

<< = Meta-suggestions:=A0 DIX = should define an identity object first, and make sure
it can be carried in multiple ways, unless there = is something special in the
semantics of the exchange mechanism. /d >>

An initial application of DIX will be to permit = users to have a single step of
authenticating themselves to a DIX client and then having that = client be able to
perform other = authentications, on behalf of the user, to servers around the
=
Internet.

I think most people are = thinking in terms of "users having a way to authenticate themselves to = a DIX identity authority (NOT a client) and having that authority be = able to vouch for their identity, oh behalf of the user, to servers = around the Internet."

That is the most common = model I've seen, although it *also* presupposes some aspects of a = solution.=A0 =A0For example, a solution where clients generated one or = more self-signed certificates, in addition to a possible set of certs = signed by other authorities, and selected from those to identify = themselves to servers around the internet --=A0 would not quite fit that = description.


<< By the way, one problem with this example = is that it is not obvious what it
is that requires an interoperable standard, as opposed to a = common database and
agent on a = single machine, as folks already have.=A0 Where is the requirement = for
a distributed mechanism on the = client side?=A0 /d = >>

My last two paragraphs = above may answer your question about what requires an interoperable = standard.



The presentation was entertaining.=A0 It contained at least one = statement of equivalence that I find unpersuasive from just its = assertion.=A0 The = equivalence of identity =3D reputation is a strong and=A0
=

Wearing my email anti-abuse hat, I will certainly = claim that anything called
"reputation" is grotesquely relative.=A0 It is not even close to "the = same as" the
identity of the = thing having the reputation.

(By way of = example, for a few folks on this list, there is a set of people = among
whom I have a reputation of = being patient and kind.=A0 = And, yes, they and the IETF
community are perceiving the same identity...=A0 There is a reason I = said
"grotesque".)

Reputation may be out of = scope for an initial charter for DIX.=A0 I would suggest that would be = a wise choice for limiting the initial work as it would not limit = later work.

=
Lisa

dix mailing list
=

= --Apple-Mail-15--347469497-- --===============1927652220== 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 --===============1927652220==-- From dix-bounces@ietf.org Tue Feb 28 18:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEQT-0006mf-8t; Tue, 28 Feb 2006 18:38:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEQS-0006mS-Gh for dix@ietf.org; Tue, 28 Feb 2006 18:38:40 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEEQR-0005Ix-6n for dix@ietf.org; Tue, 28 Feb 2006 18:38:40 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FEEQO-0006S0-Nl; Tue, 28 Feb 2006 15:38:37 -0800 Message-Id: <6.2.3.4.2.20060228232140.055f0400@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 28 Feb 2006 23:37:55 +0100 To: Digital Identity Exchange ,dcrocker@bbiw.net, Digital Identity Exchange From: "JFC (Jefsey) Morfin" Subject: Re: [dix] requirements In-Reply-To: <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403F306.5000607@dcrocker.net> <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-33C3920 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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: , Errors-To: dix-bounces@ietf.org At 21:46 28/02/2006, Lisa Dusseault wrote: >On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote: >>An identity is a globally unique reference to an online user or >>agent. The form >>of the reference is a URI. <>statement that >>general, but they will hold their breath, for now. /d>> This is a form of identifier. >>Associated with an >>identity is a collection of information that describes characteristics of the >>identity and/or privileges imparted to the identity. The >>information about an >>identity can be divided into subsets, according to the different functional >>roles performed by the user or agent. > >This is very useful text. I'd be happy to see such text in a draft >introducing a particular identity system, but I think it's also >appropriate for the charter provided it doesn't contradict too many >models. It does pre-suppose some part of a solution but that may >even be appropriate if we all agree on that part of a solution "\Àw >…»"\ÀwÐ]»àê even before chartering. Before proposing the IETF to enter the domain of identification, registration etc. I strongly suggest to consider the work of the JTC1/SC32/W2. >Is it helpful to also point out that it's expected that these >identities will come from different authorities that aren't required >to coordinate with one another in any way? May be a careful reading of ISO 11179 may help? >>DIX is transaction mechanism for identity information. <>you mean dix semantics cannot transit via email? equally obvious >>question: why >>does this need a new transfer mechanism? >> > >Transport rather than transaction? > >Suggested further text perhaps: "Currently, there is no standard, >interoperable way for a user to have some identity information >transferred from an identity authority to a third-party consumer of >such information." May be a reading of ISO 20944 oriented work could be considered? >><< Meta-suggestions: DIX should define an identity object first, >>and make sure >>it can be carried in multiple ways, unless there is something special in the >>semantics of the exchange mechanism. /d >> >> >>An initial application of DIX will be to permit users to have a >>single step of >>authenticating themselves to a DIX client and then having that >>client be able to >>perform other authentications, on behalf of the user, to servers around the >>Internet. > >I think most people are thinking in terms of "users having a way to >authenticate themselves to a DIX identity authority (NOT a client) >and having that authority be able to vouch for their identity, oh >behalf of the user, to servers around the Internet." > >That is the most common model I've seen, although it *also* >presupposes some aspects of a solution. For example, a solution >where clients generated one or more self-signed certificates, in >addition to a possible set of certs signed by other authorities, and >selected from those to identify themselves to servers around the >internet -- would not quite fit that description. Are we calling indentification and authentication the same? >><< By the way, one problem with this example is that it is not >>obvious what it >>is that requires an inter"\Àw …»"\ÀwÐ]»àê operable standard, as >>opposed to a common database and >>agent on a single machine, as folks already have. Where is the >>requirement for >>a distributed mechanism on the client side? /d >> > >My last two paragraphs above may answer your question about what >requires an interoperable standard. ISO 11179 has not worked much on networking. I think this is where IETF can contribute to a general concept? >>>>The presentation was entertaining. It contained at least one >>>>statement of equivalence that I find unpersuasive from just its >>>>assertion. The equivalence of identity = reputation is a strong and >> >>Wearing my email anti-abuse hat, I will certainly claim that anything called >>"reputation" is grotesquely relative. It is not even close to "the >>same as" the >>identity of the thing having the reputation. >> >>(By way of example, for a few folks on this list, there is a set of >>people among >>whom I have a reputation of being patient and kind. And, yes, they >>and the IETF >>community are perceiving the same identity... There is a reason I said >>"grotesque".) > >Reputation may be out of scope for an initial charter for DIX. I >would suggest that would be a wise choice for limiting the initial >work as it would not limit later work. I understood that DIX was to be an exchange system? In first analysis, I fail to see why reputation would be for it anything different from any other identity element and to be considered at all? jfc _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 19:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEFXb-0006BV-EV; Tue, 28 Feb 2006 19:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEFXZ-00069f-UN for dix@ietf.org; Tue, 28 Feb 2006 19:50:05 -0500 Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEFXY-00034b-M8 for dix@ietf.org; Tue, 28 Feb 2006 19:50:05 -0500 Received: by wproxy.gmail.com with SMTP id 50so10442wri for ; Tue, 28 Feb 2006 16:50:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sra8XlfyF1SBHIC/Ehj5uLZy/4QkAv1aN/ZKey+JMdsher+AFga/ea+swzCHO+c72koQYzgT/smYLAVL0XaQxjcOy+UqcuqdO6vLBZHUXgDvDSQjxa3Jzx7fS5irBbSthWeJj3tUPT7baKINiSgXreG8mjrO2ChfD++oXD6V9Fs= Received: by 10.54.66.13 with SMTP id o13mr1332167wra; Tue, 28 Feb 2006 16:50:04 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 26sm65871wrl.2006.02.28.16.50.03; Tue, 28 Feb 2006 16:50:03 -0800 (PST) Message-ID: <4404EFBA.8030501@gmail.com> Date: Tue, 28 Feb 2006 19:50:02 -0500 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Federated Digest Auth References: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: dix-bounces@ietf.org Hallam-Baker, Phillip wrote: >>From: Dick Hardt [mailto:dick@sxip.com] >> >>There was an IETF BOF on Beyond Basic Auth that I had hoped >>would develop some richer Auth mechanisms within HTTP that >>could work with DIX. >> >> > >How about Digest, it is supported inpractically every browser in use, it >is secure against man in the middle attack, it is a standard and a MUST >for HTTP/1.1 > +1 I would be a strong proponent of having an interop story for DIX and Digest. Most feedreaders support Digest and RESTful webservices can use it. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 20:02:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEFjA-00016h-4j; Tue, 28 Feb 2006 20:02:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEFj9-00016c-Gn for dix@ietf.org; Tue, 28 Feb 2006 20:02:03 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEFj8-0003Ew-7l for dix@ietf.org; Tue, 28 Feb 2006 20:02:03 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7BB271422A5 for ; Tue, 28 Feb 2006 17:02:01 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13035-06 for ; Tue, 28 Feb 2006 17:02:01 -0800 (PST) Received: from [192.168.101.217] (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 D7FED14229C for ; Tue, 28 Feb 2006 17:02:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4404EFBA.8030501@gmail.com> References: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> <4404EFBA.8030501@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Federated Digest Auth Date: Tue, 28 Feb 2006 17:01:44 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: dix-bounces@ietf.org Speaking as an implementor (CalDAV, WebDAV), so would I (+1). Lisa On Feb 28, 2006, at 4:50 PM, Robert Yates wrote: > Hallam-Baker, Phillip wrote: > >>> From: Dick Hardt [mailto:dick@sxip.com] >>> There was an IETF BOF on Beyond Basic Auth that I had hoped would >>> develop some richer Auth mechanisms within HTTP that could work >>> with DIX. >>> >> >> How about Digest, it is supported inpractically every browser in >> use, it >> is secure against man in the middle attack, it is a standard and a >> MUST >> for HTTP/1.1 >> > +1 I would be a strong proponent of having an interop story for DIX > and Digest. Most feedreaders support Digest and RESTful > webservices can use it. > > _______________________________________________ > 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 Feb 28 22:24:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEHwd-0000Jt-RZ; Tue, 28 Feb 2006 22:24:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEHwc-0000I8-5X for dix@ietf.org; Tue, 28 Feb 2006 22:24:06 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEHwa-00017S-Pn for dix@ietf.org; Tue, 28 Feb 2006 22:24:06 -0500 Received: from [142.131.33.143] ([142.131.33.143]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k213O3aT023512 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Feb 2006 19:24:04 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B227@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B227@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3582C839-F3CC-4C0B-B6FF-6FBD518A38E4@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] requirements Date: Tue, 28 Feb 2006 19:23: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 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: , Errors-To: dix-bounces@ietf.org On 28-Feb-06, at 2:01 PM, Hallam-Baker, Phillip wrote: > I would not like to see the text replicated in any document. It is > fundamentally wrong. > > I am not a number, I am a free man. > > My Star Alliance account number is not my identity, it is one > identifier that I use in one context. > > > A DIX identifier is a globally unique reference to an online user > or agent. The cannonical form of the reference is a URI. > Associated with an identifier are collections of information that > describes characteristics of and/or privileges imparted to the > online user or agent. These collections of information are the > identities of the online user or agent identified by the identifier. > > > [The term persona should be avoided here. A persona or avatar is > generally a disjoint identity that is not ordinarily linkable to > other identies of the owner] Phillip, I am confused by what you don't want replicated ... would you clarify? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 22:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEI2s-0000wX-Q5; Tue, 28 Feb 2006 22:30:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEI2r-0000qU-0S for dix@ietf.org; Tue, 28 Feb 2006 22:30:33 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEI2o-0001RY-NL for dix@ietf.org; Tue, 28 Feb 2006 22:30:32 -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 <20060301033030m11009sdbhe>; Wed, 1 Mar 2006 03:30:30 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> References: <198A730C2044DE4A96749D13E167AD3792B0D6@MOU1WNEXMB04.vcorp.ad.vrsn.com> <26e5fc334b88e18c20c1168482c05744@cisco.com> <4C079E51-FAB2-4F05-B1BE-EE213AE26423@sxip.com> <4403F306.5000607@dcrocker.net> <4BFF7A7B-453E-4E4B-A19D-56D655B5DC25@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30ABB96C-104D-4990-9CAC-80AA13C22642@netmesh.us> Content-Transfer-Encoding: 7bit From: Johannes Ernst Subject: Re: [dix] requirements Date: Tue, 28 Feb 2006 19:30:27 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: dix-bounces@ietf.org On Feb 28, 2006, at 12:46, Lisa Dusseault wrote: > On Feb 27, 2006, at 10:51 PM, Dave Crocker wrote: > >> An identity is a globally unique reference to an online user or >> agent. The form >> of the reference is a URI. <> statement that >> general, but they will hold their breath, for now. /d>> Associated >> with an >> identity is a collection of information that describes >> characteristics of the >> identity and/or privileges imparted to the identity. The >> information about an >> identity can be divided into subsets, according to the different >> functional >> roles performed by the user or agent. > > This is very useful text. I'd be happy to see such text in a draft > introducing a particular identity system, but I think it's also > appropriate for the charter provided it doesn't contradict too many > models. It does pre-suppose some part of a solution but that may > even be appropriate if we all agree on that part of a solution even > before chartering. Minus whether the term is "identity" or "identifier", the above paragraph sounds like a description of LID ... its the basic design principle is that URLs are used to identify people (or software agents), and that methods are associated by which information can be obtained that is held "behind" the URL, e.g. URL?xpath=/VCARD gets you the person's VCard info, URL?xpath=/VCARD/TEL[descendant::WORK][descendant::VOICE] gets you the person's work phone number (only) URL?xpath=/FOAF gets you the person's FOAF file, potentially filtered by who is doing the asking and how they prove it. Just thought I point that out ... more info at http://lid.netmesh.org/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Feb 28 22:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIBD-0000mJ-Px; Tue, 28 Feb 2006 22:39:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIBC-0000m6-Lx for dix@ietf.org; Tue, 28 Feb 2006 22:39:10 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEIBB-0001qv-AW for dix@ietf.org; Tue, 28 Feb 2006 22:39:10 -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 k213d8wQ015197 for ; Tue, 28 Feb 2006 19:39:08 -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); Tue, 28 Feb 2006 19:39:08 -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] requirements Date: Tue, 28 Feb 2006 19:39:07 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3792B280@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] requirements Thread-Index: AcY835zZRVCu8rFrR4KLVFx3PW6KyQAAcdAg From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 01 Mar 2006 03:39:08.0284 (UTC) FILETIME=[B2456BC0:01C63CE1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: dix-bounces@ietf.org > From: Dick Hardt [mailto:dick@sxip.com]=20 > On 28-Feb-06, at 2:01 PM, Hallam-Baker, Phillip wrote: >=20 > > I would not like to see the text replicated in any document. It is=20 > > fundamentally wrong. > > > > I am not a number, I am a free man. > > > > My Star Alliance account number is not my identity, it is one=20 > > identifier that I use in one context. > > > > > > A DIX identifier is a globally unique reference to an=20 > online user or=20 > > agent. The cannonical form of the reference is a URI. > > Associated with an identifier are collections of information that=20 > > describes characteristics of and/or privileges imparted to=20 > the online=20 > > user or agent. These collections of information are the=20 > identities of=20 > > the online user or agent identified by the identifier. > > > > > > [The term persona should be avoided here. A persona or avatar is=20 > > generally a disjoint identity that is not ordinarily=20 > linkable to other=20 > > identies of the owner] >=20 > Phillip, I am confused by what you don't want replicated ...=20 > would you clarify? I do not want to see the original text proposed by Dave that confuses Identifier and Identity. It is a fundamental mistake to conflate the signifier and the signified. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix