From dix-bounces@ietf.org Wed Mar 01 00:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEJxR-0004Lq-OA; Wed, 01 Mar 2006 00:33:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEJxQ-0004Lj-Tn for dix@ietf.org; Wed, 01 Mar 2006 00:33:04 -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 1FEJxP-0005kL-Iz for dix@ietf.org; Wed, 01 Mar 2006 00:33:04 -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 k215X1Kb027595 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Feb 2006 21:33:02 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <019857CE-E809-4A47-B7CE-B4DC48E21568@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Federated Digest Auth Date: Tue, 28 Feb 2006 20:21:54 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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:45 PM, 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 > > 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. How would this move around other identity data? My interest in DIX is to be able to move around all kinds of identity data. To me, that means that the site needs to be able to say "here is what I want", the user has an opportunity to select what to release, and then it is sent to the site. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 01 09:32:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESNS-0008UM-26; Wed, 01 Mar 2006 09:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESNR-0008S8-2C for dix@ietf.org; Wed, 01 Mar 2006 09:32:29 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESNQ-0008A1-SE for dix@ietf.org; Wed, 01 Mar 2006 09:32:29 -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 k21EWSBW012282 for ; Wed, 1 Mar 2006 14:32:28 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 09:32:28 -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 ; Wed, 1 Mar 2006 14:32:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 01 Mar 2006 09:32:28 -0500 Subject: Re: [dix] Federated Digest Auth From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY9PPcfNYfsSKkwEdqVbAANk3jHKA== In-Reply-To: <4404EFBA.8030501@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 14:32:28.0415 (UTC) FILETIME=[F75EB8F0:01C63D3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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/28/2006 7: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. > >From a protocol design standpoint, however, lets separate the 'act of authenticating' with the 'act of sharing a security token with a relying party' they are different. And in some cases, an RP to an assertion may require the homesite to use a certain authentication mechansim or else, don't bother. This is a design pattern in SAML, of course, but can be applied elsewhere. What's federated is not the digest auth, but (some form of) a token indicating that digest auth occurred. =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 01 11:27:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUAh-0004gw-Ak; Wed, 01 Mar 2006 11:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUAf-0004gr-Ka for dix@ietf.org; Wed, 01 Mar 2006 11:27:25 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUAc-000522-Rt for dix@ietf.org; Wed, 01 Mar 2006 11:27:25 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C49B1422B0 for ; Wed, 1 Mar 2006 08:27:22 -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 09647-07 for ; Wed, 1 Mar 2006 08:27:21 -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 371391422A6 for ; Wed, 1 Mar 2006 08:27:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <019857CE-E809-4A47-B7CE-B4DC48E21568@sxip.com> References: <198A730C2044DE4A96749D13E167AD3792B235@MOU1WNEXMB04.vcorp.ad.vrsn.com> <019857CE-E809-4A47-B7CE-B4DC48E21568@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37FB112E-3191-4CBD-80E9-3FB501D4870C@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Federated Digest Auth Date: Wed, 1 Mar 2006 08:27:02 -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 Digest might not be able to carry around the data -- Phillip can answer that better than I can -- but using Digest would be so much an improvement for non-browser HTTP client deployability, that it would be worth it. There could be a well-known way to decompose the identity to look up the identity information in a separate transaction between servers. Lisa On Feb 28, 2006, at 8:21 PM, Dick Hardt wrote: > > On 28-Feb-06, at 2:45 PM, 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 >> >> 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. > > How would this move around other identity data? My interest in DIX > is to be able to move around all kinds of identity data. To me, > that means that the site needs to be able to say "here is what I > want", the user has an opportunity to select what to release, and > then it is sent to the site. > > -- Dick > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 01 19:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEbNk-00054o-Sn; Wed, 01 Mar 2006 19:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEbNj-00054b-P7 for dix@ietf.org; Wed, 01 Mar 2006 19:09:23 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEbNi-0007DT-FU for dix@ietf.org; Wed, 01 Mar 2006 19:09:23 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2006 19:09:23 -0500 X-IronPort-AV: i="4.02,158,1139202000"; d="scan'208"; a="83348744:sNHT39285380" Received: from [68.50.18.9] (che-vpn-cluster-2-147.cisco.com [10.86.242.147]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2209LVU010937 for ; Wed, 1 Mar 2006 19:09:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v623) To: Digital Identity Exchange Message-Id: <9eff565afb3b174963bfc5c2ec3a4163@cisco.com> From: John Schnizlein Date: Wed, 1 Mar 2006 19:09:20 -0500 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [dix] background: system with similar goals: Higgins X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0574381361==" Errors-To: dix-bounces@ietf.org --===============0574381361== Content-Type: multipart/alternative; boundary=Apple-Mail-58--257796379 --Apple-Mail-58--257796379 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed It might be useful to look at another open source effort to empower users. One point where the description at the following URL seems to diverge from recent discussion here is its explicit support for multiple identities. One never knows what an announcement of support such as that from IBM and Novell might mean for the project. John http://spwiki.editme.com/HigginsIntroduction Begin forwarded message: > From: "Linux and Open Source Report" > > Date: March 1, 2006 10:46:17 AM EST > ... > IBM-LED GROUP BACKS NEW IDENTITY MANAGER TOOL > > IBM and Novell announced their support Monday for an open-source > project > aiming to give users more control over how information such as > passwords > and financial details are shared across multiple Web sites. > http://newsletter.infoworld.com/t?ctl=112BB5B:1F5DA10 > --Apple-Mail-58--257796379 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII It might be useful to look at another open source effort to empower users. One point where the description at the following URL seems to diverge from recent discussion here is its explicit support for multiple identities. One never knows what an announcement of support such as that from IBM and Novell might mean for the project. John http://spwiki.editme.com/HigginsIntroduction Begin forwarded message: 0000,0000,0000From: "Linux and Open Source Report" < 0000,0000,0000Date: March 1, 2006 10:46:17 AM EST 0000,0000,0000... IBM-LED GROUP BACKS NEW IDENTITY MANAGER TOOL IBM and Novell announced their support Monday for an open-source project aiming to give users more control over how information such as passwords and financial details are shared across multiple Web sites. http://newsletter.infoworld.com/t?ctl=112BB5B:1F5DA10 --Apple-Mail-58--257796379-- --===============0574381361== 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 --===============0574381361==-- From dix-bounces@ietf.org Wed Mar 01 22:30:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeW9-0000Li-Nn; Wed, 01 Mar 2006 22:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeW7-0000Kt-1d for dix@ietf.org; Wed, 01 Mar 2006 22:30:15 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEeW6-0007QO-Mn for dix@ietf.org; Wed, 01 Mar 2006 22:30:15 -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 k223U99j020038 for ; Wed, 1 Mar 2006 19:30:09 -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); Wed, 1 Mar 2006 19:30:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Federated Digest Auth Date: Wed, 1 Mar 2006 19:30:08 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C7D8@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY88aDBhZ5CQL5DSEaYkaYAr8ygUQAsom+A From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 02 Mar 2006 03:30:09.0776 (UTC) FILETIME=[9BB55F00:01C63DA9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 > How would this move around other identity data? My interest=20 > in DIX is to be able to move around all kinds of identity=20 > data. To me, that means that the site needs to be able to say=20 > "here is what I want", the user has an opportunity to select=20 > what to release, and then it is sent to the site. Here are some fake messages I created for the design. I can generate some genuine data tommorow (server is upstairs). OK three parties: Client (user), Relying party and Registry Following the Digest auth spec the protocol begins with a request from the client which results in a refused response containing a challenge: HTTP/1.0 401 Unauthorised Server: SokEvo/0.9 Date: Sun, 10 Apr 2005 20:26:47 GMT WWW-Authenticate: Digest realm=3D"low@portableidentifier" qop=3D"auth,auth-int", nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", Content-Type: text/html Content-Length: 311 The client responds using standard Digest Auth GET /dir/index.html HTTP/1.0 Host: localhost Authorization: Digest username=3D"dick@sxip.com", realm=3D"low@portableidentifier", nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", uri=3D"/dir/index.html", qop=3Dauth, nc=3D00000001, cnonce=3D"0a4f113b", response=3D"6629fae49393a05397450978507c4ef1" The relying party locates the registry server to authenticate users in sxip.com using the SRV mechanism. The response from the user is now relayed to the registry. The uri value, realm &ct are replaced by the ha2 hash value: GET / HTTP/1.0 Host: localhost Authorization: Digest username=3D"dick@sxip.com", realm=3D"low@portableidentifier", nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", ha2=3D"39aff3a2bab6126f332b942af96d3366", qop=3Dauth, nc=3D00000001, cnonce=3D"0a4f113b", response=3D"6629fae49393a05397450978507c4ef1" The registry replies either 200 OK or 401 unauthorized. HTTP/1.0 200 Accept Server: SokEvo/0.9 Date: Sun, 10 Apr 2005 20:27:42 GMT If you want attributes with that you simply add content to the request and response: GET /?ask=3Dname+ZIP+ShoeSize HTTP/1.0 Host: localhost Authorization: Digest username=3D"dick@sxip.com", realm=3D"low@portableidentifier", nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", ha2=3D"39aff3a2bab6126f332b942af96d3366", qop=3Dauth, nc=3D00000001, cnonce=3D"0a4f113b", response=3D"6629fae49393a05397450978507c4ef1" HTTP/1.0 200 OK Server: SokEvo/0.9 Date: Sun, 10 Apr 2005 20:27:42 GMT Name=3DDick+Hardt&zip=3D90210&ShoeSize=3D10 Or you can return a SAML token or use POST or whatever. You can use the rest of DIX at this point. Although this is limited to username/password type auth it is still possible to use a one time password token provided that the registry can access the list of expected password values.=20 If you are doing PKI based auth then you are going to need a new client anyway. The way I would handle this is using a prefixed TXT record: _authprot.sxip.com TXT "T=3DAUTHPROT P=3DDIGEST,SAML,DIX" _digest.tcp.sxip.com SRV 1,1,1,1, 80, digestreg.sxip.com It may be possible to use NAPTR. Although this is not supported in certain DNS servers it is already required by SIP. Given the critical nature of SIP it is arguable that NAPTR will deploy. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 10:10:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpRS-0004Ga-AZ; Thu, 02 Mar 2006 10:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpRR-0004GF-Gf for dix@ietf.org; Thu, 02 Mar 2006 10:10:09 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpRP-0001ma-1b for dix@ietf.org; Thu, 02 Mar 2006 10:10:09 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k22FA6NF020139 for ; Thu, 2 Mar 2006 07:10: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); Thu, 2 Mar 2006 07:10: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: [dix] Federated Digest Auth Date: Thu, 2 Mar 2006 07:10:05 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C7F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY88aDBhZ5CQL5DSEaYkaYAr8ygUQAsom+AABkvdTA= From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 02 Mar 2006 15:10:05.0901 (UTC) FILETIME=[63597FD0:01C63E0B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 forgot to mention, you can use the standard HTTP content negotiation mechanism to select form encoded or SAML assertions in the exchange between the relying party and the registry. A good way to think of it is that the exchange between the relying party and the registry is simply a standard HTTP request/response. The only difference is that the authentication data is provided by a different party, the user that initiated the original request rather than the relying party making the federated auth request. The key advantage here is that the protocol is safe against man-in-the-middle attacks, provided that is the user interface for the browser does not allow a downgrade attack to BASIC auth. This is of course a security failure that needs fixing regardless. What this scheme does not provide is a way for the end user to control the specific attributes that are released.=20 What it does very well is to provide transparent authentication, there is no need for the user to log in because the browser will do that automatically using the existing cache mechanism once it recognizes that the site has already been visited. The user only needs to provide credentials once per session, unlike cookies however the user is required to resupply the credentials at least once and the browser knows that the data is credential data. > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20 > Sent: Wednesday, March 01, 2006 10:30 PM > To: Digital Identity Exchange > Subject: RE: [dix] Federated Digest Auth >=20 > > From: Dick Hardt [mailto:dick@sxip.com] >=20 > > How would this move around other identity data? My interest=20 > in DIX is=20 > > to be able to move around all kinds of identity data. To me, that=20 > > means that the site needs to be able to say "here is what I=20 > want", the=20 > > user has an opportunity to select what to release, and then=20 > it is sent=20 > > to the site. >=20 > Here are some fake messages I created for the design. I can=20 > generate some genuine data tommorow (server is upstairs). >=20 > OK three parties: >=20 > Client (user), Relying party and Registry >=20 > Following the Digest auth spec the protocol begins with a=20 > request from the client which results in a refused response=20 > containing a challenge: >=20 > HTTP/1.0 401 Unauthorised > Server: SokEvo/0.9 > Date: Sun, 10 Apr 2005 20:26:47 GMT > WWW-Authenticate: Digest realm=3D"low@portableidentifier" > qop=3D"auth,auth-int", > nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", > Content-Type: text/html > Content-Length: 311 >=20 > The client responds using standard Digest Auth >=20 > GET /dir/index.html HTTP/1.0 > Host: localhost > Authorization: Digest username=3D"dick@sxip.com", > realm=3D"low@portableidentifier", > nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri=3D"/dir/index.html", > qop=3Dauth, > nc=3D00000001, > cnonce=3D"0a4f113b", > response=3D"6629fae49393a05397450978507c4ef1" >=20 > The relying party locates the registry server to authenticate=20 > users in sxip.com using the SRV mechanism. >=20 > The response from the user is now relayed to the registry.=20 > The uri value, realm &ct are replaced by the ha2 hash value: >=20 > GET / HTTP/1.0 > Host: localhost > Authorization: Digest username=3D"dick@sxip.com", > realm=3D"low@portableidentifier", > nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", > ha2=3D"39aff3a2bab6126f332b942af96d3366", > qop=3Dauth, > nc=3D00000001, > cnonce=3D"0a4f113b", > response=3D"6629fae49393a05397450978507c4ef1" >=20 > The registry replies either 200 OK or 401 unauthorized. >=20 > HTTP/1.0 200 Accept > Server: SokEvo/0.9 > Date: Sun, 10 Apr 2005 20:27:42 GMT >=20 > If you want attributes with that you simply add content to=20 > the request and response: >=20 >=20 > GET /?ask=3Dname+ZIP+ShoeSize HTTP/1.0 > Host: localhost > Authorization: Digest username=3D"dick@sxip.com", > realm=3D"low@portableidentifier", > nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", > ha2=3D"39aff3a2bab6126f332b942af96d3366", > qop=3Dauth, > nc=3D00000001, > cnonce=3D"0a4f113b", > response=3D"6629fae49393a05397450978507c4ef1" >=20 > HTTP/1.0 200 OK > Server: SokEvo/0.9 > Date: Sun, 10 Apr 2005 20:27:42 GMT >=20 > Name=3DDick+Hardt&zip=3D90210&ShoeSize=3D10 >=20 >=20 > Or you can return a SAML token or use POST or whatever. You=20 > can use the rest of DIX at this point. >=20 > Although this is limited to username/password type auth it is=20 > still possible to use a one time password token provided that=20 > the registry can access the list of expected password values.=20 >=20 > If you are doing PKI based auth then you are going to need a=20 > new client anyway. The way I would handle this is using a=20 > prefixed TXT record: >=20 > _authprot.sxip.com TXT "T=3DAUTHPROT P=3DDIGEST,SAML,DIX" > _digest.tcp.sxip.com SRV 1,1,1,1, 80, digestreg.sxip.com >=20 >=20 > It may be possible to use NAPTR. Although this is not=20 > supported in certain DNS servers it is already required by=20 > SIP. Given the critical nature of SIP it is arguable that=20 > NAPTR will deploy. >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 11:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqjH-0001z6-An; Thu, 02 Mar 2006 11:32:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqjF-0001xX-UU for dix@ietf.org; Thu, 02 Mar 2006 11:32:37 -0500 Received: from xproxy.gmail.com ([66.249.82.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqjE-0005b3-97 for dix@ietf.org; Thu, 02 Mar 2006 11:32:37 -0500 Received: by xproxy.gmail.com with SMTP id s9so293260wxc for ; Thu, 02 Mar 2006 08:32:36 -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=XXBGWiztF5HDO8wwFD5ZZIzPimQyQL3Wgw3+drAjyyc3cALqikPvE51KGmlv+gjbFpx6xNtvtyisAiviGsrei/4WZ9HE6xaVC0vlmy7Y8Unsi0Kq/tndrEGh0/dfWgTFZiSux0euwTnyXE+DwRu1d5mEe7mH5iD+y8ML7c+dfv0= Received: by 10.70.63.1 with SMTP id l1mr3517628wxa; Thu, 02 Mar 2006 08:32:35 -0800 (PST) Received: from ?9.33.157.42? ( [129.33.1.37]) by mx.gmail.com with ESMTP id i39sm1268050wxd.2006.03.02.08.32.34; Thu, 02 Mar 2006 08:32:34 -0800 (PST) Message-ID: <44071E20.8060503@gmail.com> Date: Thu, 02 Mar 2006 11:32: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] Federated Digest Auth References: <198A730C2044DE4A96749D13E167AD3797C7D8@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C7D8@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: 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 Or, with this approach modified, to be more along the lines of dmd0 Hallam-Baker, Phillip wrote: >OK three parties: > >Client (user), Relying party and Registry > >Following the Digest auth spec the protocol begins with a request from >the client which results in a refused response containing a challenge: > >HTTP/1.0 401 Unauthorised >Server: SokEvo/0.9 >Date: Sun, 10 Apr 2005 20:26:47 GMT >WWW-Authenticate: Digest realm="low@portableidentifier" > qop="auth,auth-int", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", >Content-Type: text/html >Content-Length: 311 > >The client responds using standard Digest Auth > >GET /dir/index.html HTTP/1.0 >Host: localhost > > The username passed is the persona-url Authorization: Digest username="dix:/sxip.com/employees/dick", > realm="low@portableidentifier", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri="/dir/index.html", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1" > The relying party locates a homesite-url for the persona-url using the persona document. (What if there is more than one homesite?) The relying party makes a call to the homesite-url with a "dix:/message-type" of "dix:/verify-digest-request". It also passes parameters for realm, nonce, ha2, qop, nc, cnonce and response. The homesite responds with a dix:/true or dix:/false as outlined in section 5.10.3.4. of dmd0 Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 11:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqmv-0004mm-VE; Thu, 02 Mar 2006 11:36:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqmu-0004me-5y for dix@ietf.org; Thu, 02 Mar 2006 11:36:24 -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 1FEqms-0005yD-Pi for dix@ietf.org; Thu, 02 Mar 2006 11:36:24 -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 k22GaLhm094243 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 08:36:21 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C7F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797C7F8@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Federated Digest Auth Date: Thu, 2 Mar 2006 08:36:18 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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-Mar-06, at 7:10 AM, Hallam-Baker, Phillip wrote: > I forgot to mention, you can use the standard HTTP content negotiation > mechanism to select form encoded or SAML assertions in the exchange > between the relying party and the registry. > > A good way to think of it is that the exchange between the relying > party > and the registry is simply a standard HTTP request/response. The only > difference is that the authentication data is provided by a different > party, the user that initiated the original request rather than the > relying party making the federated auth request. > > > The key advantage here is that the protocol is safe against > man-in-the-middle attacks, provided that is the user interface for the > browser does not allow a downgrade attack to BASIC auth. This is of > course a security failure that needs fixing regardless. > > > What this scheme does not provide is a way for the end user to control > the specific attributes that are released. IMHO it is critical for the user to control the release. LID et al have some mechanism for allowing site to query the registry and have the user control the release (which I don't fully understand) I think there is something from your previous post though in how a Rich Client can negotiate with the site leveraging existing standards. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 13:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsFM-0000Eh-Mc; Thu, 02 Mar 2006 13:09:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsFM-0000Ec-6a for dix@ietf.org; Thu, 02 Mar 2006 13:09:52 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEsFK-0000t5-RN for dix@ietf.org; Thu, 02 Mar 2006 13:09:52 -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 k22I9okX000443 for ; Thu, 2 Mar 2006 10:09: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); Thu, 2 Mar 2006 10:09:50 -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] Federated Digest Auth Date: Thu, 2 Mar 2006 10:09:48 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C828@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY+F3qJ0AqzYBokRKiYDAFj/dSmHAACat4Q From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 02 Mar 2006 18:09:50.0231 (UTC) FILETIME=[7F4FAA70:01C63E24] 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: , Errors-To: dix-bounces@ietf.org I think that there should be separate exchanges here for initiating a relationship and re-establishing one. I do not see a need for extensive attribute exchange every single time a person reads an article in the NYT or posts to a blog. This should be done once and the relying party should cache the details in a local store. We need two buttons, not just one. One button for create/update account, a second one for login to the account. Control can be a two edged sword, make it too easy for sites to ask for social security numbers and idiots will be asking for them on their blogs. We need to do some mock ups of the proposed user interfaces, and yes I do mean mock ups, not products. Mock ups are better, people are less likely to complain if they think the code is written, they try to be nice. You want grumpy curmudgeons. > -----Original Message----- > From: Dick Hardt [mailto:dick@sxip.com]=20 > Sent: Thursday, March 02, 2006 11:36 AM > To: Digital Identity Exchange > Subject: Re: [dix] Federated Digest Auth >=20 >=20 > On 2-Mar-06, at 7:10 AM, Hallam-Baker, Phillip wrote: >=20 > > I forgot to mention, you can use the standard HTTP content=20 > negotiation=20 > > mechanism to select form encoded or SAML assertions in the exchange=20 > > between the relying party and the registry. > > > > A good way to think of it is that the exchange between the relying=20 > > party and the registry is simply a standard HTTP=20 > request/response. The=20 > > only difference is that the authentication data is provided by a=20 > > different party, the user that initiated the original=20 > request rather=20 > > than the relying party making the federated auth request. > > > > > > The key advantage here is that the protocol is safe against=20 > > man-in-the-middle attacks, provided that is the user=20 > interface for the=20 > > browser does not allow a downgrade attack to BASIC auth. This is of=20 > > course a security failure that needs fixing regardless. > > > > > > What this scheme does not provide is a way for the end user=20 > to control=20 > > the specific attributes that are released. >=20 > IMHO it is critical for the user to control the release. >=20 > LID et al have some mechanism for allowing site to query the=20 > registry and have the user control the release (which I don't=20 > fully understand) >=20 > I think there is something from your previous post though in=20 > how a Rich Client can negotiate with the site leveraging=20 > existing standards. >=20 > -- Dick >=20 > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix >=20 >=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 13:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsU2-0006RE-JJ; Thu, 02 Mar 2006 13:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsU0-0006R7-OG for dix@ietf.org; Thu, 02 Mar 2006 13:25:00 -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 1FEsTz-0001On-DA for dix@ietf.org; Thu, 02 Mar 2006 13:25:00 -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 k22IOw8V099069 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 10:24:58 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C828@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797C828@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Federated Digest Auth Date: Thu, 2 Mar 2006 10:24: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.2 (/) 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 2-Mar-06, at 10:09 AM, Hallam-Baker, Phillip wrote: > I think that there should be separate exchanges here for initiating a > relationship and re-establishing one. 1) the site does not need to store the data if it only needs it in the transaction. The NYT is a perfect example. They receive profile data to increase demographic counters and potential serve targeted ads. No DB is required. No risk on losing the data. 2) the data is always fresh. I go to Amazon and give them my address. I change my address. I go back to Amazon and they have my latest address (with my permission) 3) the attributes may be TPC that have a short life. They have to be fresh 4) one button is easier then two > We need to do some mock ups of the proposed user interfaces, and yes I > do mean mock ups, not products. Mock ups are better, people are less > likely to complain if they think the code is written, they try to be > nice. You want grumpy curmudgeons. Write a comment on one of my blogs: http://identity20.com or http:// blame.ca and get an account and you can see the UX -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 13:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsbM-00057D-Fe; Thu, 02 Mar 2006 13:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsbL-00053S-KU for dix@ietf.org; Thu, 02 Mar 2006 13:32:35 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEsbK-0001V9-8n for dix@ietf.org; Thu, 02 Mar 2006 13:32:35 -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 k22IWXQV001821 for ; Thu, 2 Mar 2006 10:32:33 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 10:32:33 -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] Federated Digest Auth Date: Thu, 2 Mar 2006 10:32:31 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY+FvWf7QcrfzC3TgOMXljAfT62NQAD8blw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 02 Mar 2006 18:32:33.0119 (UTC) FILETIME=[ABA7DEF0:01C63E27] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 username passed is the persona-url > Authorization: Digest username=3D"dix:/sxip.com/employees/dick", Sure we could do that. But why are folk so intent on using a URL when it is guaranteed to result in a shitty user experience? What additional information is there in the URL you give that could not be returned as an attribute? I agree that the canonical form of the identifier should be dix:{something that includes dick, sxip.com} but why are you so intent on exposing that to the user? We didn't even use fully qualified URIs in the HTTP protocol until v1.1. We don't expose URIs to the user in SMTP, NNTP or FTP. URIs are a machine interface. They are NOT a USER interface. > > realm=3D"low@portableidentifier", > > nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", > > uri=3D"/dir/index.html", > > qop=3Dauth, > > nc=3D00000001, > > cnonce=3D"0a4f113b", > > response=3D"6629fae49393a05397450978507c4ef1" > > > The relying party locates a homesite-url for the persona-url=20 > using the persona document. (What if there is more than one=20 > homesite?) >=20 > The relying party makes a call to the homesite-url with a=20 > "dix:/message-type" of "dix:/verify-digest-request". It also=20 > passes parameters for realm, nonce, ha2, qop, nc, cnonce and response. >=20 > The homesite responds with a dix:/true or dix:/false as=20 > outlined in section 5.10.3.4. of dmd0 I agree that using a separate result code from the HTTP result code may well be a good thing. We have had some issues with registry services going offline and the host server reporting '200 success' for all queries as a result. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 14:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtBc-0004Fn-KH; Thu, 02 Mar 2006 14:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtBc-0004Cw-4n for dix@ietf.org; Thu, 02 Mar 2006 14:10:04 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEtBb-0003Hn-LA for dix@ietf.org; Thu, 02 Mar 2006 14:10:04 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F198C1422BD for ; Thu, 2 Mar 2006 11:10:02 -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 24979-05 for ; Thu, 2 Mar 2006 11:10:02 -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 DCAF3142293 for ; Thu, 2 Mar 2006 11:10:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C7B5547-2722-47E3-A535-1B4B9324EFAB@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Federated Digest Auth Date: Thu, 2 Mar 2006 11:09:42 -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: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 There are a number of protocols where there are placeholders or places for user identity to appear. I'm most familiar with how this works in WebDAV though it certainly crops up in other areas. WebDAV then, as an example, has tags for containing URLs that refer to principals. For example, the holder of a lock could advertise their identity with a URL in such an tag, but if it were not a URL, we'd have to invent something new. One of the exciting applications for something like DIX, in WebDAV, is the possibility to share with people across organizations properly. If I wanted to share my OSAF calendar with you, Phillip, but not share it publicly, how could I do that? Right now some WebDAV servers have a solution that would horrify security experts -- they have tickets such that I could ask the server for a ticket granting read access to the calendar, and the bearer of that ticket gets access. Then I send the ticket to you over email, attached to a URL to the calendar, and you use that to see my calendar. Obviously not very secure. Instead, imagine that I could enter your federated identity URL into my calendar permissions configuration page, and grant read access to that identity. Then when I send you the URL to my calendar, or you browse to it, my server asks "who are you" and you provide the same identity URL. My server checks that with your identity provider and allows read access to the calendar. Much better than a publicly readable calendar, much better than tickets. Reasonably usable. And it might even work without any protocol changes to WebDAV ACL. I am quite sure there are a lot of ways to simplify user interfaces while also supporting URL format. For example, a very simple Web signup form could look like this: "If you have an account elsewhere that you can log in here, please enter: Username: ___lisa______ Identity domain: ___osafoundation.org_____" This might be too simple because it doesn't allow any substructure inside one domain but it's certainly a possibility. The code handling this form would follow whatever rules DIX specifies to put this together into a URL: e.g. lookup osafoundation.org's identity server in DNS and discover that it's "users.osafoundation.org", concatenate the user name as "users.osafoundation.org/lisa", prefix with a scheme to have "dix://users.osafoundation.org/lisa", and now you're ready to go with a URL. lisa On Mar 2, 2006, at 10:32 AM, Hallam-Baker, Phillip wrote: > >> The username passed is the persona-url >> Authorization: Digest username="dix:/sxip.com/employees/dick", > > Sure we could do that. > > But why are folk so intent on using a URL when it is guaranteed to > result in a shitty user experience? > > What additional information is there in the URL you give that could > not > be returned as an attribute? > > > I agree that the canonical form of the identifier should be > dix:{something that includes dick, sxip.com} but why are you so intent > on exposing that to the user? > > We didn't even use fully qualified URIs in the HTTP protocol until > v1.1. > We don't expose URIs to the user in SMTP, NNTP or FTP. > > URIs are a machine interface. They are NOT a USER interface. > > >>> realm="low@portableidentifier", >>> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", >>> uri="/dir/index.html", >>> qop=auth, >>> nc=00000001, >>> cnonce="0a4f113b", >>> response="6629fae49393a05397450978507c4ef1" >>> >> The relying party locates a homesite-url for the persona-url >> using the persona document. (What if there is more than one >> homesite?) >> >> The relying party makes a call to the homesite-url with a >> "dix:/message-type" of "dix:/verify-digest-request". It also >> passes parameters for realm, nonce, ha2, qop, nc, cnonce and >> response. >> >> The homesite responds with a dix:/true or dix:/false as >> outlined in section 5.10.3.4. of dmd0 > > I agree that using a separate result code from the HTTP result code > may > well be a good thing. We have had some issues with registry services > going offline and the host server reporting '200 success' for all > queries as a result. > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 14:18:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtJf-00036g-M2; Thu, 02 Mar 2006 14:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtJe-00035x-6f for dix@ietf.org; Thu, 02 Mar 2006 14:18: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 1FEtJc-0003Tl-SN for dix@ietf.org; Thu, 02 Mar 2006 14:18:22 -0500 Received: from [192.168.1.110] (adsl-66-121-149-134.dsl.snfc21.pacbell.net [66.121.149.134]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k22JIJ7u001826 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 11:18:20 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <8BE6AE57-7C77-48EA-A074-6D7484CBEA76@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Thu, 2 Mar 2006 11:18:11 -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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [dix] DIX BOF, Tues 21st March, 9am, Dallas X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 final meeting schedule has been published. (No collision with DKIM, yay!) TUESDAY, March 21, 2006 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP dix Digial Identity Exchange Protocol BOF INT netlmm Network-based Localized Mobility Management WG INT trill Transparent Interconnection of Lots of Links WG OPS radext RADIUS Extensions WG RAI avt Audio/Video Transport WG RAI ecrit Emergency Context Resolution with Internet Technologies WG RTG forces Forwarding and Control Element Separation WG SEC pk14ipsec Profiling Use of PKI in IPSEC WG Current agenda is: 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) This isn't fixed, just a guideline... we can change it right up to the meeting itself. So, let's work on this agenda and work out what's going to be talked about, and by whom. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 14:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEthD-0006Gy-1y; Thu, 02 Mar 2006 14:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEthB-00067r-9K for dix@ietf.org; Thu, 02 Mar 2006 14:42:41 -0500 Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEth9-0004i7-U7 for dix@ietf.org; Thu, 02 Mar 2006 14:42:41 -0500 Received: by wproxy.gmail.com with SMTP id i28so492933wra for ; Thu, 02 Mar 2006 11:42:39 -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=jH5DZX4OvXhCvsmneINxV3wAN2K5WqvFWCZFk0r3mqIcOVSX/05+c1rycKjEN1fDKcEmqTr6ehhzNx/nroY8mqAnvwtTFh5G/OFbotod5ye6ZtlQ94sv/D/KRlV9yDxZ7hSVx1lPTNx6Rp/LgglPhIRN2NUpJYyqSV79oJbN25c= Received: by 10.54.107.1 with SMTP id f1mr1409991wrc; Thu, 02 Mar 2006 11:42:37 -0800 (PST) Received: from ?9.33.157.42? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 40sm2614754wrl.2006.03.02.11.42.36; Thu, 02 Mar 2006 11:42:37 -0800 (PST) Message-ID: <44074AAB.1040001@gmail.com> Date: Thu, 02 Mar 2006 14:42:35 -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: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C82E@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: 93238566e09e6e262849b4f805833007 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: >>The username passed is the persona-url >>Authorization: Digest username="dix:/sxip.com/employees/dick", >> >> > >Sure we could do that. > >But why are folk so intent on using a URL when it is guaranteed to >result in a shitty user experience? > > how is this "gmail.com/robyates" any different to this "robyates@gmail.com"? is the user experience that different? sure sites could give out hard to remember "shitty" persona-urls but will they catch on? There are many technical advantages to having URLs as identifiers and if the user experience doesn't suffer then why not? Rob p.s. As blogging and personal web sites become more the norm won't users actually find it a very natural experience to be entering "their" URL as "their" identifier. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 14:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtuQ-0000Ib-7G; Thu, 02 Mar 2006 14:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtuP-0000H0-3V for dix@ietf.org; Thu, 02 Mar 2006 14:56: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 1FEtuN-00058B-Kz for dix@ietf.org; Thu, 02 Mar 2006 14:56:21 -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 k22JuHgs003296 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 11:56:18 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04F23EDA-1071-4868-9077-E246871A3AD3@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Thu, 2 Mar 2006 11:56:15 -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: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [dix] User of identifiers X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Agree that URIs may not always be very user friendly. I have a couple public URIs. http://blame.ca and http:// Identity20.com ... but I there are many aspects of my online interactions where I would not want to expose those URIs, or it may be a unique URI for many sites so that I have a pair-wise or unidirectional relationship vis-a-vis the innovations from Liberty. These latter URIs are not user managable. I envisioned the UX would wrap the URI with a nice, user created labels for personas like "home", "work" or "nym" Lisa brings up an important point around admin that we have been pondering. How to you make it easy for users to restrict access to a set of people. A unique, public identifier is a good solution for that this. Email or easy URLs map well to this as it is easy for the resource owner to type in the identifier. Email has an advantage as it can be used to notify that permission has been granted. Assertions that the user is a certain identifier is then required to gain access. Taking this concept further, an assertion of a hash of the identifier allows the user to prove they are an identifier, without disclosing the identifier. IE, I can prove that I am dick@sxip.com, without giving a site my email address. On 2-Mar-06, at 10:32 AM, Hallam-Baker, Phillip wrote: > >> The username passed is the persona-url >> Authorization: Digest username="dix:/sxip.com/employees/dick", > > Sure we could do that. > > But why are folk so intent on using a URL when it is guaranteed to > result in a shitty user experience? > > What additional information is there in the URL you give that could > not > be returned as an attribute? > > > I agree that the canonical form of the identifier should be > dix:{something that includes dick, sxip.com} but why are you so intent > on exposing that to the user? > > We didn't even use fully qualified URIs in the HTTP protocol until > v1.1. > We don't expose URIs to the user in SMTP, NNTP or FTP. > > URIs are a machine interface. They are NOT a USER interface. > > >>> realm="low@portableidentifier", >>> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", >>> uri="/dir/index.html", >>> qop=auth, >>> nc=00000001, >>> cnonce="0a4f113b", >>> response="6629fae49393a05397450978507c4ef1" >>> >> The relying party locates a homesite-url for the persona-url >> using the persona document. (What if there is more than one >> homesite?) >> >> The relying party makes a call to the homesite-url with a >> "dix:/message-type" of "dix:/verify-digest-request". It also >> passes parameters for realm, nonce, ha2, qop, nc, cnonce and >> response. >> >> The homesite responds with a dix:/true or dix:/false as >> outlined in section 5.10.3.4. of dmd0 > > I agree that using a separate result code from the HTTP result code > may > well be a good thing. We have had some issues with registry services > going offline and the host server reporting '200 success' for all > queries as a result. > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 14:56:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtuT-0000YQ-Ca; Thu, 02 Mar 2006 14:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtuS-0000W3-QY for dix@ietf.org; Thu, 02 Mar 2006 14:56:24 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEtuR-00058O-Gw for dix@ietf.org; Thu, 02 Mar 2006 14:56:24 -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 k22JuMaU004042 for ; Thu, 2 Mar 2006 11:56:22 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 11:56:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Federated Digest Auth Date: Thu, 2 Mar 2006 11:56:22 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C84E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY+JqTiew9KPtaxT/ipED1VEDED7gAAWyAw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 02 Mar 2006 19:56:22.0839 (UTC) FILETIME=[619A3C70:01C63E33] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 =20 > 1) the site does not need to store the data if it only needs=20 > it in the transaction. The NYT is a perfect example. They=20 > receive profile data to increase demographic counters and=20 > potential serve targeted ads. No DB is required. No risk on=20 > losing the data. Lets think this use case through a bit further. Isn't the ultimate goal of the NYT to prove to advertisers that it is able to deliver a particular demographic profile? That said isn't the NYT going to end up having some sort of intermediary in the authentication chain in the same way they have third parties hosting their ads or doing other hacks for monitoring views? Having experienced P3P I am very wary of protocols that expec users to exercise choice in selecting privacy settings when they are given it. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 14:56:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtuW-0000ax-K5; Thu, 02 Mar 2006 14:56:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtuV-0000as-Ug for dix@ietf.org; Thu, 02 Mar 2006 14:56:27 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEtuU-00058X-KL for dix@ietf.org; Thu, 02 Mar 2006 14:56:27 -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 k22JuPhV007452 for ; Thu, 2 Mar 2006 11:56:26 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 11:56:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Mar 2006 11:56:25 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C850@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BOF date/time change Thread-Index: AcY+L1CP62jv0PchRx2kvG+FWhRvkQ== From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 02 Mar 2006 19:56:25.0865 (UTC) FILETIME=[6367F790:01C63E33] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [dix] BOF date/time change X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0140029793==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0140029793== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63E33.6324BB0C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63E33.6324BB0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just spotted this: =20 TUESDAY, March 21, 2006 0800-1800 IETF Registration -=20 0800-0900 Continental Breakfast -=20 0900-1130 Morning Session I APP dix Digial Identity Exchange Protocol BOF =20 So the DKIM clash has been avoided. The cryptocurmudgeons can come to grump at both. =20 Given the time I would expect people to be here on Monday evening. Anyone interested in a DIX dinner meetup? ------_=_NextPart_001_01C63E33.6324BB0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just = spotted=20 this:
 
TUESDAY, March = 21,=20 2006
0800-1800 IETF Registration -
0800-0900 Continental = Breakfast -=20
0900-1130 Morning Session I
APP =20 dix        Digial Identity Exchange = Protocol=20 BOF
 
So the DKIM=20 clash has been avoided. The cryptocurmudgeons can come to grump at=20 both.
 

Given the time I would expect people to be here on Monday evening. = Anyone=20 interested in a DIX dinner meetup?


 ------_=_NextPart_001_01C63E33.6324BB0C-- --===============0140029793== 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 --===============0140029793==-- From dix-bounces@ietf.org Thu Mar 02 14:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtxe-0006GI-9M; Thu, 02 Mar 2006 14:59:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtxc-0006GD-UM for dix@ietf.org; Thu, 02 Mar 2006 14:59:40 -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 1FEtxb-0005Aq-Jp for dix@ietf.org; Thu, 02 Mar 2006 14:59:40 -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 k22Jxcd3003476 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 11:59:39 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C84E@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797C84E@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C4921F4-81EE-44F7-855E-786482C4BA0C@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Federated Digest Auth Date: Thu, 2 Mar 2006 11:59: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.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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-Mar-06, at 11:56 AM, Hallam-Baker, Phillip wrote: > >> From: Dick Hardt [mailto:dick@sxip.com] > >> 1) the site does not need to store the data if it only needs >> it in the transaction. The NYT is a perfect example. They >> receive profile data to increase demographic counters and >> potential serve targeted ads. No DB is required. No risk on >> losing the data. > > Lets think this use case through a bit further. Isn't the ultimate > goal > of the NYT to prove to advertisers that it is able to deliver a > particular demographic profile? > > That said isn't the NYT going to end up having some sort of > intermediary > in the authentication chain in the same way they have third parties > hosting their ads or doing other hacks for monitoring views? Wether NYT gets the data and aggregates it or someone else, I don't see why that matters to the points I am making. > Having experienced P3P I am very wary of protocols that expec users to > exercise choice in selecting privacy settings when they are given it. Not sure what you are getting at wrt. P3P. The user is not necessarily selecting their privacy settings. They are choosing to either release their data or not. Binary decision. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 15:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtyj-0007C6-OK; Thu, 02 Mar 2006 15:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtyi-0007Bz-9o for dix@ietf.org; Thu, 02 Mar 2006 15:00:48 -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 1FEtyg-0005Bo-Uz for dix@ietf.org; Thu, 02 Mar 2006 15:00:48 -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 k22K0kog003795 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 12:00:46 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <198A730C2044DE4A96749D13E167AD3797C850@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797C850@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] BOF date/time change Date: Thu, 2 Mar 2006 12:00:43 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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-Mar-06, at 11:56 AM, Hallam-Baker, Phillip wrote: > Given the time I would expect people to be here on Monday evening. > Anyone interested in a DIX dinner meetup? > Certainly. Suggested destination? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 15:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuOl-0001S3-2H; Thu, 02 Mar 2006 15:27:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuOk-0001OK-99 for dix@ietf.org; Thu, 02 Mar 2006 15:27:42 -0500 Received: from imo-d21.mx.aol.com ([205.188.144.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuOj-00069I-Mc for dix@ietf.org; Thu, 02 Mar 2006 15:27:42 -0500 Received: from THayes0993@aol.com by imo-d21.mx.aol.com (mail_out_v38_r7.3.) id l.241.7dc9c86 (15899) for ; Thu, 2 Mar 2006 15:27:34 -0500 (EST) Received: from FWM-R32 (fwm-r32.webmail.aol.com [152.163.181.136]) by air-id09.mx.aol.com (vx) with ESMTP id MAILINID92-3e1b440755363d5; Thu, 02 Mar 2006 15:27:34 -0500 Date: Thu, 02 Mar 2006 15:27:33 -0500 Message-Id: <8C80C4EDEF80BFA-10C0-1BD@FWM-R32.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD3797C82E@MOU1WNEXMB04.vcorp.ad.vrsn.com> <0C7B5547-2722-47E3-A535-1B4B9324EFAB@osafoundation.org> Received: from 10.169.155.114 by FWM-R32.sysops.aol.com (152.163.181.136) with HTTP (WebMailUI); Thu, 02 Mar 2006 15:27:33 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <0C7B5547-2722-47E3-A535-1B4B9324EFAB@osafoundation.org> X-Mailer: AOL WebMail 16641 Subject: Re: [dix] Federated Digest Auth MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 152.163.181.136 X-Spam-Flag: NO X-Spam-Score: 1.2 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0237210248==" Errors-To: dix-bounces@ietf.org --===============0237210248== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C80C4EDEF80BFA_10C0_1AB_FWM-R32.sysops.aol.com" ----------MailBlocks_8C80C4EDEF80BFA_10C0_1AB_FWM-R32.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This discussion of Federated Auth has moved us too far away from one of the key drivers of the DIX effort (in my opinion). The identity exchange protocol needs to support the case where there no account or other profile data stored at the relying party. Every attribute of the identity of the user (client) needs to be sent to the relying party as part of the current interaction. In addition, it should not be required to send an identifier as one of the attributes. The federated auth discussion has put too much weight on an attribute that is a unique identifier. In a previous email Phillip proposed a definition for identity: "An identity is a set of assertions concerning a particular subject identifier." I disagree with this. Later on in the same email, he "factored out" the identifier in a collection of statements, which resulted in statements like "That dude is Canadian" and "That dude has blood group Z". I believe these statements form the identity that DIX is dealing with. To those statements you can add "That dude authenticated as dick@sxip.com" (which essentially a SAML authentication assertion). In the example that Lisa gives for a shared calendar, the attribute of the identity that needs to be transferred is "That dude is allowed to look at Lisa's calendar". From the DIX point of view this is a third party assertion but in most cases will have been issued by the relying party (the calendar service) to be used by itself. Maybe what we need to talk about are self-issued and non-self-issued assertions. The most direct representation of the required attribute is the bearer ticket that Lisa described. It needs to be handled carefully, but it also has the ability to provide anonymous access to the service and continues to work even if my email address changes. A different approach would be to tie the assertion to some other attribute of the identity, which would then need to be shown separately. This requires more information to be released to the relying party, but may be acceptible in many cases. DIX needs to define how to exchange identity attributes. It does not need to define a way to federate a credential-based authentication scheme. Terry -----Original Message----- From: Lisa Dusseault To: Digital Identity Exchange Sent: Thu, 2 Mar 2006 11:09:42 -0800 Subject: Re: [dix] Federated Digest Auth There are a number of protocols where there are placeholders or places for user identity to appear. I'm most familiar with how this works in WebDAV though it certainly crops up in other areas. WebDAV then, as an example, has tags for containing URLs that refer to principals. For example, the holder of a lock could advertise their identity with a URL in such an tag, but if it were not a URL, we'd have to invent something new. One of the exciting applications for something like DIX, in WebDAV, is the possibility to share with people across organizations properly. If I wanted to share my OSAF calendar with you, Phillip, but not share it publicly, how could I do that? Right now some WebDAV servers have a solution that would horrify security experts -- they have tickets such that I could ask the server for a ticket granting read access to the calendar, and the bearer of that ticket gets access. Then I send the ticket to you over email, attached to a URL to the calendar, and you use that to see my calendar. Obviously not very secure. Instead, imagine that I could enter your federated identity URL into my calendar permissions configuration page, and grant read access to that identity. Then when I send you the URL to my calendar, or you browse to it, my server asks "who are you" and you provide the same identity URL. My server checks that with your identity provider and allows read access to the calendar. Much better than a publicly readable calendar, much better than tickets. Reasonably usable. And it might even work without any protocol changes to WebDAV ACL. I am quite sure there are a lot of ways to simplify user interfaces while also supporting URL format. For example, a very simple Web signup form could look like this: "If you have an account elsewhere that you can log in here, please enter: Username: ___lisa______ Identity domain: ___osafoundation.org_____" This might be too simple because it doesn't allow any substructure inside one domain but it's certainly a possibility. The code handling this form would follow whatever rules DIX specifies to put this together into a URL: e.g. lookup osafoundation.org's identity server in DNS and discover that it's "users.osafoundation.org", concatenate the user name as "users.osafoundation.org/lisa", prefix with a scheme to have "dix://users.osafoundation.org/lisa", and now you're ready to go with a URL. lisa On Mar 2, 2006, at 10:32 AM, Hallam-Baker, Phillip wrote: > >> The username passed is the persona-url >> Authorization: Digest username="dix:/sxip.com/employees/dick", > > Sure we could do that. > > But why are folk so intent on using a URL when it is guaranteed to > result in a shitty user experience? > > What additional information is there in the URL you give that could > not > be returned as an attribute? > > > I agree that the canonical form of the identifier should be > dix:{something that includes dick, sxip.com} but why are you so intent > on exposing that to the user? > > We didn't even use fully qualified URIs in the HTTP protocol until > v1.1. > We don't expose URIs to the user in SMTP, NNTP or FTP. > > URIs are a machine interface. They are NOT a USER interface. > > >>> realm="low@portableidentifier", >>> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", >>> uri="/dir/index.html", >>> qop=auth, >>> nc=00000001, >>> cnonce="0a4f113b", >>> response="6629fae49393a05397450978507c4ef1" >>> >> The relying party locates a homesite-url for the persona-url >> using the persona document. (What if there is more than one >> homesite?) >> >> The relying party makes a call to the homesite-url with a >> "dix:/message-type" of "dix:/verify-digest-request". It also >> passes parameters for realm, nonce, ha2, qop, nc, cnonce and >> response. >> >> The homesite responds with a dix:/true or dix:/false as >> outlined in section 5.10.3.4. of dmd0 > > I agree that using a separate result code from the HTTP result code > may > well be a good thing. We have had some issues with registry services > going offline and the host server reporting '200 success' for all > queries as a result. > > _______________________________________________ > 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 ----------MailBlocks_8C80C4EDEF80BFA_10C0_1AB_FWM-R32.sysops.aol.com Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
This discussion of Federated Auth has moved us too far away from one of the key drivers of the DIX effort (in my opinion).  The identity exchange protocol needs to support the case where there no account or other profile data stored at the relying party.  Every attribute of the identity of the user (client) needs to be sent to the relying party as part of the current interaction.  In addition, it should not be required to send an identifier as one of the attributes.  The federated auth discussion has put too much weight on an attribute that is a unique identifier.
 
In a previous email Phillip proposed a definition for identity: "An identity is a set of assertions concerning a particular subject identifier."  I disagree with this.  Later on in the same email, he "factored out" the identifier in a collection of statements, which resulted in statements like "That dude is Canadian" and "That dude has blood group Z".  I believe these statements form the identity that DIX is dealing with.  To those statements you can add "That dude authenticated as dick@sxip.com" (which essentially a SAML authentication assertion).
 
In the example that Lisa gives for a shared calendar, the attribute of the identity that needs to be transferred is "That dude is allowed to look at Lisa's calendar".  From the DIX point of view this is a third party assertion but in most cases will have been issued by the relying party (the calendar service) to be used by itself.  Maybe what we need to talk about are self-issued and non-self-issued assertions.
 
The most direct representation of the required attribute is the bearer ticket that Lisa described.  It needs to be handled carefully, but it also has the ability to provide anonymous access to the service and continues to work even if my email address changes.  A different approach would be to tie the assertion to some other attribute of the identity, which would then need to be shown separately.  This requires more information to be released to the relying party, but may be acceptible in many cases.
 
DIX needs to define how to exchange identity attributes.  It does not need to define a way to federate a credential-based authentication scheme.
 
Terry

-----Original Message-----
From: Lisa Dusseault <lisa@osafoundation.org>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Thu, 2 Mar 2006 11:09:42 -0800
Subject: Re: [dix] Federated Digest Auth

There are a number of protocols where there are placeholders or places for user identity to appear. I'm most familiar with how this works in WebDAV though it certainly crops up in other areas. WebDAV then, as an example, has <href/> tags for containing URLs that refer to principals. For example, the holder of a lock could advertise their identity with a URL in such an <href/> tag, but if it were not a URL, we'd have to invent something new. 
 
One of the exciting applications for something like DIX, in WebDAV, is the possibility to share with people across organizations properly. If I wanted to share my OSAF calendar with you, Phillip, but not share it publicly, how could I do that? Right now some WebDAV servers have a solution that would horrify security experts -- they have tickets such that I could ask the server for a ticket granting read access to the calendar, and the bearer of that ticket gets access. Then I send the ticket to you over email, attached to a URL to the calendar, and you use that to see my calendar. Obviously not very secure. 
 
Instead, imagine that I could enter your federated identity URL into my calendar permissions configuration page, and grant read access to that identity. Then when I send you the URL to my calendar, or you browse to it, my server asks "who are you" and you provide the same identity URL. My server checks that with your identity provider and allows read access to the calendar. Much better than a publicly readable calendar, much better than tickets. Reasonably usable. And it might even work without any protocol changes to WebDAV ACL. 
 
I am quite sure there are a lot of ways to simplify user interfaces while also supporting URL format. For example, a very simple Web signup form could look like this: 
 
  "If you have an account elsewhere that you can log in here, please enter: 
  Username: ___lisa______ 
  Identity domain: ___osafoundation.org_____" 
 
This might be too simple because it doesn't allow any substructure inside one domain but it's certainly a possibility. The code handling this form would follow whatever rules DIX specifies to put this together into a URL: e.g. lookup osafoundation.org's identity server in DNS and discover that it's "users.osafoundation.org", concatenate the user name as "users.osafoundation.org/lisa", prefix with a scheme to have "dix://users.osafoundation.org/lisa", and now you're ready to go with a URL. 
 
lisa 
 
On Mar 2, 2006, at 10:32 AM, Hallam-Baker, Phillip wrote: 
 
> 
>> The username passed is the persona-url 
>> Authorization: Digest username="dix:/sxip.com/employees/dick", 
> 
> Sure we could do that. 
> 
> But why are folk so intent on using a URL when it is guaranteed to 
> result in a shitty user experience? 
> 
> What additional information is there in the URL you give that could > not 
> be returned as an attribute? 
> 
> 
> I agree that the canonical form of the identifier should be 
> dix:{something that includes dick, sxip.com} but why are you so intent 
> on exposing that to the user? 
> 
> We didn't even use fully qualified URIs in the HTTP protocol until > v1.1. 
> We don't expose URIs to the user in SMTP, NNTP or FTP. 
> 
> URIs are a machine interface. They are NOT a USER interface. 
> 
> 
>>> realm="low@portableidentifier", 
>>> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 
>>> uri="/dir/index.html", 
>>> qop=auth, 
>>> nc=00000001, 
>>> cnonce="0a4f113b", 
>>> response="6629fae49393a05397450978507c4ef1" 
>>> 
>> The relying party locates a homesite-url for the persona-url 
>> using the persona document. (What if there is more than one 
>> homesite?) 
>> 
>> The relying party makes a call to the homesite-url with a 
>> "dix:/message-type" of "dix:/verify-digest-request". It also 
>> passes parameters for realm, nonce, ha2, qop, nc, cnonce and >> response. 
>> 
>> The homesite responds with a dix:/true or dix:/false as 
>> outlined in section 5.10.3.4. of dmd0 
> 
> I agree that using a separate result code from the HTTP result code > may 
> well be a good thing. We have had some issues with registry services 
> going offline and the host server reporting '200 success' for all 
> queries as a result. 
> 
> _______________________________________________ 
> 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 
----------MailBlocks_8C80C4EDEF80BFA_10C0_1AB_FWM-R32.sysops.aol.com-- --===============0237210248== 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 --===============0237210248==-- From dix-bounces@ietf.org Thu Mar 02 22:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF10s-0004Tu-II; Thu, 02 Mar 2006 22:31:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF10r-0004TZ-F3 for dix@ietf.org; Thu, 02 Mar 2006 22:31: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 1FF10q-00082U-4P for dix@ietf.org; Thu, 02 Mar 2006 22:31:29 -0500 Received: from [192.168.2.113] (adsl-69-226-234-82.dsl.pltn13.pacbell.net [69.226.234.82]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k233VPID025832 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 19:31:27 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <9eff565afb3b174963bfc5c2ec3a4163@cisco.com> References: <9eff565afb3b174963bfc5c2ec3a4163@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A8D0E3-8E58-431A-BBC1-4790AEE5984A@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] background: system with similar goals: Higgins Date: Thu, 2 Mar 2006 19:31: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: 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 1-Mar-06, at 4:09 PM, John Schnizlein wrote: > It might be useful to look at another open source effort to empower > users. One point where the description at the following URL seems > to diverge from recent discussion here is its explicit support for > multiple identities. Yeah, Higgins is good stuff (tm). I'm in favor of multiple identities... in the sense that an identity can have multiple identifiers, which I think is technically what Higgins supports, and what I think dmd0 supports. I confess I don't know what format a Higgins identifier is, but I imagine it's just a string, with an associated known type. In dmd0 I specced it as a URL and then went into detail about how a URL based identifier scheme would work. I'm sure other schemes could be made to work too. > One never knows what an announcement of support such as that from > IBM and Novell might mean for the project. Not quite sure what that statement means. Project being DIX? For sure if if the Higgins team are interested in DIX I should think that to be a positive thing. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 02 23:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1gL-0006LJ-R8; Thu, 02 Mar 2006 23:14:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1gK-0006JE-PY for dix@ietf.org; Thu, 02 Mar 2006 23:14:20 -0500 Received: from toad.mtbrook.bozemanpass.com ([69.145.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF1gH-00015z-D4 for dix@ietf.org; Thu, 02 Mar 2006 23:14:20 -0500 Received: from [69.145.82.218] (unknown [69.145.82.218]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id 44F29110393 for ; Thu, 2 Mar 2006 20:14:16 -0800 (PST) Message-ID: <4407C299.107@boreham.org> Date: Thu, 02 Mar 2006 21:14:17 -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] background: system with similar goals: Higgins References: <9eff565afb3b174963bfc5c2ec3a4163@cisco.com> In-Reply-To: <9eff565afb3b174963bfc5c2ec3a4163@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 John Schnizlein wrote: > It might be useful to look at another open source effort to empower > users. One point where the description at the following URL seems to > diverge from recent discussion here is its explicit support for > multiple identities. Interesting. But if I were trying so solve 'the identity problem' I don't think I'd want to do it by defining a Java API... Protocol-based solutions seem more productive. Reading the material on the site, I'm not 100% convinced that there is anything profound there wrt multiple and related identities : to me it seems that there is the notion of a query ('get me the stuff for the identities in my buddy list' is the example given), and there's a notion of an identity hierarchy. Having worked with LDAP for some time, I can attest that any attempt to define a (single) hierarchy will not succeed because everyone has a different idea of how the hierarchy should be structured. The query concept is potentially useful. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 09:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBHA-0002v2-CE; Fri, 03 Mar 2006 09:29:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBH9-0002ux-F4 for dix@ietf.org; Fri, 03 Mar 2006 09:28:59 -0500 Received: from wproxy.gmail.com ([64.233.184.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBH8-0007Mj-6c for dix@ietf.org; Fri, 03 Mar 2006 09:28:59 -0500 Received: by wproxy.gmail.com with SMTP id i28so663273wra for ; Fri, 03 Mar 2006 06:28:57 -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=WPQwf9BzNfnX+qkxvlq/jGpH+9kCr2RZMeG+wPmHQRpT9Upw1WZQnbx6RJVMZ9+CIdWylotB4kwug7T0rGMuEilbmEDnSatL5z5SjG2nXwBU8bMCHMtPs+2JB6+ezkBGV85va0zbdOPeMYtl1NjcmF4vWU9ugjVFYK3AHb6yZis= Received: by 10.54.66.18 with SMTP id o18mr2382623wra; Fri, 03 Mar 2006 06:28:57 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 28sm3518696wrl.2006.03.03.06.28.55; Fri, 03 Mar 2006 06:28:56 -0800 (PST) Message-ID: <440852A6.8070008@gmail.com> Date: Fri, 03 Mar 2006 09:28:54 -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: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [dix] DIX in the extranet X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Acme corp utilizes monster.com for its hiring process. Acme has a site license for access to monster.com, however the agreement limits acme to 10 concurrent users. To keep within this contraint Acme limits the employees that can access monster.com. It utilizes dmd0 and achieves this by having a user property called dix:/monster.com/user-key. Employees that are allowed to use monster.com have this property set. An acme employee with the right to access monster.com goes to that site's login page. Here, they type in their homesite "intranet.acme.com", a homesite on acme's intranet. Monster.com requests the attribute "dix:/monster.com/user-key" via DIX. The user is bounced to their homesite, they authenticate and then they get bounced back to the membersite monster.com with the property set and the message signed. The interesting aspect of the above scenario is that monster.com cannot communicate with the server "intranet.acme.com" it is behind the companies firewall. It is also worth mentioning that acme, like all large multinationals, has "intranet.acme.com" locked away deep inside a data center. It can talk to its ldap server and a database server, but nothing else and certainly not "monster.com" It is in scenarios such as these that "push" excels. However in the current draft the verification step is a "pull" step and so dmd0 cannot support acme. Has there been any thoughts as to how DIX can allow parties to sign the message without requiring the "pull" verification step? I could imagine specifying in core or in an extension attributes such as dix:/signature-X509, dix:/signature-X509-subjectname and dix:/signature-X509-certificate. Then monster and acme can relay messages without any "pull" operation. What is preventing these extensions at the moment is the current canonicalization algorithm and so I guess all of this was a very long winded way of asking whether the canonicalization algorithm described in section 5.10.2.7 can be changed to something like. "For each name-value pair within the message, with the exception of any parameters starting with "dix:/signature", treat as a ......... " Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 09:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBIW-00045T-9s; Fri, 03 Mar 2006 09:30:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBIV-00045D-AU for dix@ietf.org; Fri, 03 Mar 2006 09:30:23 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBIU-0007Pj-Aj for dix@ietf.org; Fri, 03 Mar 2006 09:30:23 -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 k23EULxr021201 for ; Fri, 3 Mar 2006 06:30:21 -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); Fri, 3 Mar 2006 06:30:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] Federated Digest Auth Date: Fri, 3 Mar 2006 06:30:20 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797C953@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Federated Digest Auth Thread-Index: AcY+N8yFQlTSJoTiTRyiKFowI2cZFwAlbPrw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 03 Mar 2006 14:30:21.0582 (UTC) FILETIME=[00990AE0:01C63ECF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1952698200==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1952698200== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63ECF.004170B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63ECF.004170B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The distinction you appear to be drawing here is between schemes where the identifier itself is exposed to the relying party and schemes where it is not. =20 We are still at the requirements stage AFIK, lets get all the optionson the table and see where we would like to go. =20 =20 The problem with the pure attributes approach (which I certainly endorse as a goal in some cases) is that in most of the use cases in the Web the relying party is interested in unique visitors. =20 Very early on in the Web people started to want tracking data bound to a unique identifier. I proposed a mechanism (95 for prior art purposes, so the patent trolls need not bother to get their perjuring hats on today) for an unlinkable identifier bound into the browser. The basic idea was to use MD5 (username, relyingparty) as a fixed unlinkable identifier. =20 =20 There are better schemes we could use but the patent issues would be very complex. I don't think the group wants to go there. ________________________________ From: thayes0993@aol.com [mailto:thayes0993@aol.com]=20 Sent: Thursday, March 02, 2006 3:28 PM To: dix@ietf.org Subject: Re: [dix] Federated Digest Auth =09 =09 This discussion of Federated Auth has moved us too far away from one of the key drivers of the DIX effort (in my opinion). The identity exchange protocol needs to support the case where there no account or other profile data stored at the relying party. Every attribute of the identity of the user (client) needs to be sent to the relying party as part of the current interaction. In addition, it should not be required to send an identifier as one of the attributes. The federated auth discussion has put too much weight on an attribute that is a unique identifier. =20 In a previous email Phillip proposed a definition for identity: "An identity is a set of assertions concerning a particular subject identifier." I disagree with this. Later on in the same email, he "factored out" the identifier in a collection of statements, which resulted in statements like "That dude is Canadian" and "That dude has blood group Z". I believe these statements form the identity that DIX is dealing with. To those statements you can add "That dude authenticated as dick@sxip.com" (which essentially a SAML authentication assertion). =20 In the example that Lisa gives for a shared calendar, the attribute of the identity that needs to be transferred is "That dude is allowed to look at Lisa's calendar". From the DIX point of view this is a third party assertion but in most cases will have been issued by the relying party (the calendar service) to be used by itself. Maybe what we need to talk about are self-issued and non-self-issued assertions. =20 The most direct representation of the required attribute is the bearer ticket that Lisa described. It needs to be handled carefully, but it also has the ability to provide anonymous access to the service and continues to work even if my email address changes. A different approach would be to tie the assertion to some other attribute of the identity, which would then need to be shown separately. This requires more information to be released to the relying party, but may be acceptible in many cases. =20 DIX needs to define how to exchange identity attributes. It does not need to define a way to federate a credential-based authentication scheme. =20 Terry -----Original Message----- From: Lisa Dusseault To: Digital Identity Exchange Sent: Thu, 2 Mar 2006 11:09:42 -0800 Subject: Re: [dix] Federated Digest Auth =09 =09 There are a number of protocols where there are placeholders or places for user identity to appear. I'm most familiar with how this works in WebDAV though it certainly crops up in other areas. WebDAV then, as an example, has tags for containing URLs that refer to principals. For example, the holder of a lock could advertise their identity with a URL in such an tag, but if it were not a URL, we'd have to invent something new.=20 =20 One of the exciting applications for something like DIX, in WebDAV, is the possibility to share with people across organizations properly. If I wanted to share my OSAF calendar with you, Phillip, but not share it publicly, how could I do that? Right now some WebDAV servers have a solution that would horrify security experts -- they have tickets such that I could ask the server for a ticket granting read access to the calendar, an d the bearer of that ticket gets access. Then I send the ticket to you over email, attached to a URL to the calendar, and you use that to see my calendar. Obviously not very secure.=20 =20 Instead, imagine that I could enter your federated identity URL into my calendar permissions configuration page, and grant read access to that identity. Then when I send you the URL to my calendar, or you browse to it, my server asks "who are you" and you provide the same identity URL. My server checks that with your identity provider and allows read access to the calendar. Much better than a publicly readable calendar, much better than tickets. Reasonably usable. And it might even work without any protocol changes to WebDAV ACL.=20 =20 I am quite sure there are a lot of ways to simplify user interfaces while also supporting URL format. For example, a very simple Web signup form could look like this:=20 =20 "If you have an account elsewhere that y ou can log in here, please enter:=20 Username: ___lisa______=20 Identity domain: ___osafoundation.org_____"=20 =20 This might be too simple because it doesn't allow any substructure inside one domain but it's certainly a possibility. The code handling this form would follow whatever rules DIX specifies to put this together into a URL: e.g. lookup osafoundation.org's identity server in DNS and discover that it's "users.osafoundation.org", concatenate the user name as "users.osafoundation.org/lisa", prefix with a scheme to have "dix://users.osafoundation.org/lisa", and now you're ready to go with a URL.=20 =20 lisa=20 =20 On Mar 2, 2006, at 10:32 AM, Hallam-Baker, Phillip wrote:=20 =20 >=20 >> The username passed is the persona-url=20 >> Authorization: Digest username=3D"dix:/sxip.com/employees/dick",=20 >=20 > Sure we could do that.=20 >=20 > But why are folk so intent on using a URL when it is guaranteed to=20 > result in a shitty user experience?=20 >=20 > What additional information is there in the URL you give that could > not=20 > be returned as an attribute?=20 >=20 >=20 > I agree that the canonical form of the identifier should be=20 > dix:{something that includes dick, sxip.com} but why are you so intent=20 > on exposing that to the user?=20 >=20 > We didn't even use fully qualified URIs in the HTTP protocol until > v1.1.=20 > We don't expose URIs to the user in SMTP, NNTP or FTP.=20 >=20 > URIs are a machine interface. They are NOT a USER interface.=20 >=20 >=20 >>> realm=3D"low@portableidentifier",=20 >>> nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093",=20 >>> uri=3D"/dir/index.html",=20 >>> qop=3Dauth, ; >>> nc=3D00000001,=20 >>> cnonce=3D"0a4f113b",=20 >>> response=3D"6629fae49393a05397450978507c4ef1"=20 >>>=20 >> The relying party locates a homesite-url for the persona-url=20 >> using the persona document. (What if there is more than one=20 >> homesite?)=20 >>=20 >> The relying party makes a call to the homesite-url with a=20 >> "dix:/message-type" of "dix:/verify-digest-request". It also=20 >> passes parameters for realm, nonce, ha2, qop, nc, cnonce and >> response.=20 >>=20 >> The homesite responds with a dix:/true or dix:/false as=20 >> outlined in section 5.10.3.4. of dmd0=20 >=20 > I agree that using a separate result code from the HTTP result code > may=20 > well be a good thing. We have had some issues with registry services=20 > going offline and the host server reporting '200 success' for all=20 > queries as a result.=20 >=20 > _______________________________________________=20 > dix mailing list=20 > dix@ietf.org =20 > https://www1.ietf.org/mailman/listinfo/dix=20 =20 _______________________________________________=20 dix mailing list=20 dix@ietf.org =20 https://www1.ietf.org/mailman/listinfo/dix=20 =09 ------_=_NextPart_001_01C63ECF.004170B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The distinction you appear to be drawing here = is between=20 schemes where the identifier itself is exposed to the relying party and = schemes=20 where it is not.
 
We are still at the requirements stage AFIK, = lets get all=20 the optionson the table and see where we would like to = go.
 
 
The problem with the pure attributes approach = (which I=20 certainly endorse as a goal in some cases) is that in most of the use = cases in=20 the Web the relying party is interested in unique = visitors.
 
Very early on in the Web people started to want = tracking=20 data bound to a unique identifier. I proposed a mechanism (95 for = prior art=20 purposes, so the patent trolls need not bother to get their perjuring = hats on=20 today) for an unlinkable identifier bound into the browser. The basic = idea was=20 to use MD5 (username, relyingparty) as a fixed unlinkable=20 identifier.
 
 
There=20 are better schemes we could use but the patent issues would be very = complex. I don't think the group wants to go there.

From: thayes0993@aol.com=20 [mailto:thayes0993@aol.com]
Sent: Thursday, March 02, 2006 = 3:28=20 PM
To: dix@ietf.org
Subject: Re: [dix] Federated = Digest=20 Auth

This discussion of Federated Auth has moved us too far away=20 from one of the key drivers of the DIX effort (in my = opinion).  The=20 identity exchange protocol needs to support the case where there no = account=20 or other profile data stored at the relying = party.  Every=20 attribute of the identity of the user (client) needs to be = sent to=20 the relying party as part of the current interaction.  In=20 addition, it should not be required to send an identifier = as one of=20 the attributes.  The federated auth discussion has put too much = weight on=20 an attribute that is a unique identifier.
 
In a previous email Phillip proposed a definition for identity: = "An=20 identity is a set of assertions concerning a particular subject=20 identifier."  I disagree with this.  Later on in the same = email, he=20 "factored out" the identifier in a collection of statements, which = resulted in=20 statements like "That dude is Canadian" and "That dude has blood group = Z".  I believe these statements form the identity that DIX is = dealing=20 with.  To those statements you can add "That dude authenticated = as=20 dick@sxip.com" (which essentially a SAML authentication = assertion).
 
In the example that Lisa gives for a shared calendar, the = attribute of=20 the identity that needs to be transferred is "That dude is allowed to = look at=20 Lisa's calendar".  From the DIX point of view this is a third = party=20 assertion but in most cases will have been issued by the relying party = (the=20 calendar service) to be used by itself.  Maybe what we need = to talk=20 about are self-issued and non-self-issued assertions.
 
The most direct representation of the required attribute is the = bearer=20 ticket that Lisa described.  It needs to be handled carefully, = but it=20 also has the ability to provide anonymous access to the service and = continues=20 to work even if my email address changes.  A different approach = would be=20 to tie the assertion to some other attribute of the identity, which = would then=20 need to be shown separately.  This requires more information to = be=20 released to the relying party, but may be acceptible in many = cases.
 
DIX needs to define how to exchange identity attributes.  It = does=20 not need to define a way to federate a credential-based authentication = scheme.
 
Terry

-----Original Message-----
From: Lisa Dusseault=20 <lisa@osafoundation.org>
To: Digital Identity Exchange=20 <dix@ietf.org>
Sent: Thu, 2 Mar 2006 11:09:42 = -0800
Subject: Re:=20 [dix] Federated Digest Auth

There are a = number of=20 protocols where there are placeholders or places for user identity to = appear.=20 I'm most familiar with how this works in WebDAV though it certainly = crops up=20 in other areas. WebDAV then, as an example, has <href/> tags for = containing URLs that refer to principals. For example, the holder of a = lock=20 could advertise their identity with a URL in such an <href/> = tag, but if=20 it were not a URL, we'd have to invent something = new. 
 
One=20 of the exciting applications for something like DIX, in WebDAV, is the = possibility to share with people across organizations properly. If I = wanted to=20 share my OSAF calendar with you, Phillip, but not share it publicly, = how could=20 I do that? Right now some WebDAV servers have a solution that would = horrify=20 security experts -- they have tickets such that I could ask the server = for a=20 ticket granting read access to the calendar, an d the bearer of that = ticket=20 gets access. Then I send the ticket to you over email, attached to a = URL to=20 the calendar, and you use that to see my calendar. Obviously not very=20 secure. 
 
Instead, imagine that I could enter your = federated=20 identity URL into my calendar permissions configuration page, and = grant read=20 access to that identity. Then when I send you the URL to my calendar, = or you=20 browse to it, my server asks "who are you" and you provide the same = identity=20 URL. My server checks that with your identity provider and allows read = access=20 to the calendar. Much better than a publicly readable calendar, much = better=20 than tickets. Reasonably usable. And it might even work without any = protocol=20 changes to WebDAV ACL. 
 
I am quite sure there are a = lot of=20 ways to simplify user interfaces while also supporting URL format. For = example, a very simple Web signup form could look like=20 this: 
 
  "If you have an account elsewhere that = y ou=20 can log in here, please enter: 
  Username:=20 ___lisa______ 
  Identity domain:=20 ___osafoundation.org_____" 
 
This might be too simple = because=20 it doesn't allow any substructure inside one domain but it's certainly = a=20 possibility. The code handling this form would follow whatever rules = DIX=20 specifies to put this together into a URL: e.g. lookup = osafoundation.org's=20 identity server in DNS and discover that it's = "users.osafoundation.org",=20 concatenate the user name as "users.osafoundation.org/lisa", prefix = with a=20 scheme to have "dix://users.osafoundation.org/lisa", and now you're = ready to=20 go with a URL. 
 
lisa 
 
On Mar 2, = 2006, at=20 10:32 AM, Hallam-Baker, Phillip=20 wrote: 
 
> 
>> The username passed = is the=20 persona-url 
>> Authorization: Digest=20 username=3D"dix:/sxip.com/employees/dick", 
> 
> = Sure we=20 could do that. 
> 
> But why are folk so intent = on using=20 a URL when it is guaranteed to 
> result in a shitty user=20 experience? 
> 
> What additional information is = there=20 in the URL you give that could > not 
> be returned as = an=20 attribute? 
> 
> 
> I agree that the=20 canonical form of the identifier should be 
> = dix:{something that=20 includes dick, sxip.com} but why are you so intent 
> on = exposing=20 that to the user? 
> 
> We didn't even use fully = qualified URIs in the HTTP protocol until > v1.1. 
> We = don't=20 expose URIs to the user in SMTP, NNTP or = FTP. 
> 
> URIs=20 are a machine interface. They are NOT a USER=20 interface. 
> 
> 
>>>=20 realm=3D"low@portableidentifier", 
>>>=20 nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", 
>>>=20 uri=3D"/dir/index.html", 
>>> qop=3Dauth,  = ;
>>>=20 nc=3D00000001, 
>>> = cnonce=3D"0a4f113b", 
>>>=20 = response=3D"6629fae49393a05397450978507c4ef1" 
>>> =
>>=20 The relying party locates a homesite-url for the = persona-url 
>>=20 using the persona document. (What if there is more than = one 
>>=20 homesite?) 
>> 
>> The relying party makes = a call=20 to the homesite-url with a 
>> "dix:/message-type" of=20 "dix:/verify-digest-request". It also 
>> passes = parameters for=20 realm, nonce, ha2, qop, nc, cnonce and >>=20 response. 
>> 
>> The homesite responds = with a=20 dix:/true or dix:/false as 
>> outlined in section = 5.10.3.4. of=20 dmd0 
> 
> I agree that using a separate result = code=20 from the HTTP result code > may 
> well be a good thing. = We have=20 had some issues with registry services 
> going offline and = the=20 host server reporting '200 success' for all 
> queries as a = result. 
> 
>=20 _______________________________________________ 
> dix = mailing=20 list 
> dix@ietf.org 
> https://www1.ietf.org/mailman/listinfo/dix 
&= nbsp;
_______________________________________________ 
dix=20 mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 
<= /DIV>
------_=_NextPart_001_01C63ECF.004170B0-- --===============1952698200== 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 --===============1952698200==-- From dix-bounces@ietf.org Fri Mar 03 14:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFdp-0008WU-EL; Fri, 03 Mar 2006 14:08:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFdo-0008WF-NO for dix@ietf.org; Fri, 03 Mar 2006 14:08:40 -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 1FFFdn-00012H-BS for dix@ietf.org; Fri, 03 Mar 2006 14:08:40 -0500 Received: from [192.168.1.110] (adsl-66-121-149-134.dsl.snfc21.pacbell.net [66.121.149.134]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k23J8bh1053892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Mar 2006 11:08:38 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440852A6.8070008@gmail.com> References: <440852A6.8070008@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] DIX in the extranet Date: Fri, 3 Mar 2006 11:08: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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 3-Mar-06, at 6:28 AM, Robert Yates wrote: > Acme corp utilizes monster.com for its hiring process. Acme has a > site license for access to monster.com, however the agreement > limits acme to 10 concurrent users. To keep within this contraint > Acme limits the employees that can access monster.com. It utilizes > dmd0 and achieves this by having a user property called dix:/ > monster.com/user-key. Employees that are allowed to use > monster.com have this property set. > > An acme employee with the right to access monster.com goes to that > site's login page. Here, they type in their homesite > "intranet.acme.com", a homesite on acme's intranet. Monster.com > requests the attribute "dix:/monster.com/user-key" via DIX. The > user is bounced to their homesite, they authenticate and then they > get bounced back to the membersite monster.com with the property > set and the message signed. > > The interesting aspect of the above scenario is that monster.com > cannot communicate with the server "intranet.acme.com" it is behind > the companies firewall. It is also worth mentioning that acme, > like all large multinationals, has "intranet.acme.com" locked away > deep inside a data center. It can talk to its ldap server and a > database server, but nothing else and certainly not "monster.com" Correct. With dmd0 the enterprise would have to put its Homesite (HS) endpoint out in the DMZ and punch a hole through the firewall so that the HS code can talk to the enterprise IdM stack. It was a deliberate compromise to simplify the implementation of a Membersite (MS). > It is in scenarios such as these that "push" excels. However in > the current draft the verification step is a "pull" step and so > dmd0 cannot support acme. Has there been any thoughts as to how > DIX can allow parties to sign the message without requiring the > "pull" verification step? Yes... we've thought about this... > I could imagine specifying in core or in an extension attributes > such as dix:/signature-X509, dix:/signature-X509-subjectname and > dix:/signature-X509-certificate. Then monster and acme can relay > messages without any "pull" operation. For sure digital signatures and certificates are a solution, but I'm not sure I'd go about it in exactly that way. John > What is preventing these extensions at the moment is the current > canonicalization algorithm and so I guess all of this was a very > long winded way of asking whether the canonicalization algorithm > described in section 5.10.2.7 can be changed to something like. > > "For each name-value pair within the message, with the exception of > any parameters starting with "dix:/signature", treat as a ......... " _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 14:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGIm-0002Ph-Qq; Fri, 03 Mar 2006 14:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGIl-0002Pc-4W for dix@ietf.org; Fri, 03 Mar 2006 14:50:59 -0500 Received: from toad.mtbrook.bozemanpass.com ([69.145.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFGIj-0002bD-Ne for dix@ietf.org; Fri, 03 Mar 2006 14:50:59 -0500 Received: from [69.145.82.218] (unknown [69.145.82.218]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id 8C101110393 for ; Fri, 3 Mar 2006 11:50:56 -0800 (PST) Message-ID: <44089E22.6050006@boreham.org> Date: Fri, 03 Mar 2006 12:50: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] DIX in the extranet References: <440852A6.8070008@gmail.com> In-Reply-To: <440852A6.8070008@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Robert Yates wrote: > It is in scenarios such as these that "push" excels. However in the > current draft the verification step is a "pull" step and so dmd0 > cannot support acme. Has there been any thoughts as to how DIX can > allow parties to sign the message without requiring the "pull" > verification step? Acme.com could push its data to a third party that does have the means to make it available to monster.com. There's probably a nice business to be made acting as such a third party. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 15:00:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGSQ-0000cm-MJ; Fri, 03 Mar 2006 15:00:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGSP-0000ch-VO for dix@ietf.org; Fri, 03 Mar 2006 15:00:57 -0500 Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFGSN-0002iy-Mq for dix@ietf.org; Fri, 03 Mar 2006 15:00:57 -0500 Received: by wproxy.gmail.com with SMTP id 55so982379wri for ; Fri, 03 Mar 2006 12:00:53 -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=ZvJboqgd4xwSmtFU9HDg4d+faEL3AIO0t+K6wYFCS4weFN83d9p2Hc6OH2dRT0JkDLZXDipJIyTfjZkaUJvEaZDLBqqn8EAi0tv2Kmn6HKTfphTVZNQGZzZ/3re3oiTa2Z2tKfLy0XZvh5zz7uuryj8aNfrQzSRTppzau9zyIQs= Received: by 10.54.150.16 with SMTP id x16mr2592831wrd; Fri, 03 Mar 2006 12:00:53 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id g3sm2943268wra.2006.03.03.12.00.52; Fri, 03 Mar 2006 12:00:53 -0800 (PST) Message-ID: <4408A066.60809@gmail.com> Date: Fri, 03 Mar 2006 15:00:38 -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] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> In-Reply-To: <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) 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 John Merrells wrote: > > On 3-Mar-06, at 6:28 AM, Robert Yates wrote: > >> Acme corp utilizes monster.com for its hiring process. Acme has a >> site license for access to monster.com, however the agreement limits >> acme to 10 concurrent users. To keep within this contraint Acme >> limits the employees that can access monster.com. It utilizes dmd0 >> and achieves this by having a user property called dix:/ >> monster.com/user-key. Employees that are allowed to use monster.com >> have this property set. >> >> An acme employee with the right to access monster.com goes to that >> site's login page. Here, they type in their homesite >> "intranet.acme.com", a homesite on acme's intranet. Monster.com >> requests the attribute "dix:/monster.com/user-key" via DIX. The >> user is bounced to their homesite, they authenticate and then they >> get bounced back to the membersite monster.com with the property set >> and the message signed. >> >> The interesting aspect of the above scenario is that monster.com >> cannot communicate with the server "intranet.acme.com" it is behind >> the companies firewall. It is also worth mentioning that acme, like >> all large multinationals, has "intranet.acme.com" locked away deep >> inside a data center. It can talk to its ldap server and a database >> server, but nothing else and certainly not "monster.com" > > > Correct. With dmd0 the enterprise would have to put its Homesite (HS) > endpoint out in the DMZ and punch a hole through the firewall so that > the HS code can talk to the enterprise IdM stack. It was a deliberate > compromise to simplify the implementation of a Membersite (MS). I understand the compromise and yes, so monster can verify messages from acme, but how does acme verify messages from monster? Is it acceptable for enterprises to allow their servers to access the internet? > > For sure digital signatures and certificates are a solution, but I'm > not sure I'd go about it in exactly that way. I guess what I'm asking here is a scope question. Is it within the scope of DIX to allow the message signature to be a signature that can be verified without a remote call? and if it isn't within the scope of core, is it expected that an extension to the core could do it? Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 16:35:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHw3-0001Ga-Ca; Fri, 03 Mar 2006 16:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHlT-000116-0n for dix@ietf.org; Fri, 03 Mar 2006 16:24: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 1FFHap-00082Z-KX for dix@ietf.org; Fri, 03 Mar 2006 16:13:44 -0500 Received: from [192.168.0.115] (dsl092-001-192.sfo1.dsl.speakeasy.net [66.92.1.192]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k23LDftY059161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Mar 2006 13:13:42 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4408A066.60809@gmail.com> References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DC8E7EB-3E07-451A-A5A1-1A3567DD90DE@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] DIX in the extranet Date: Fri, 3 Mar 2006 13:13:40 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 3-Mar-06, at 12:00 PM, Robert Yates wrote: >> For sure digital signatures and certificates are a solution, but >> I'm not sure I'd go about it in exactly that way. > > I guess what I'm asking here is a scope question. Is it within the > scope of DIX to allow the message signature to be a signature that > can be verified without a remote call? and if it isn't within the > scope of core, is it expected that an extension to the core could > do it? I think it's out of scope for DIX, but that whatever comes of out of DIX should provide extension points for layering alternative verification mechanisms on top. So, for example, in dmd0 we have the capabilities definition, discovery, and publishing mechanism, so that the HS can advertise alternative mechanisms. A great alternative mechanisms would perhaps be a shared secret... or certificates. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 17:16:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIZ6-0005Ox-Gv; Fri, 03 Mar 2006 17:16:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIZ6-0005Mc-2Z for dix@ietf.org; Fri, 03 Mar 2006 17:16:00 -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 1FFIZ4-0007oc-LF for dix@ietf.org; Fri, 03 Mar 2006 17:16:00 -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 k23MFvvb061747 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Mar 2006 14:15:57 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4408A066.60809@gmail.com> References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@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] DIX in the extranet Date: Fri, 3 Mar 2006 14:15: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: 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 3-Mar-06, at 12:00 PM, Robert Yates wrote: >> >> Correct. With dmd0 the enterprise would have to put its Homesite >> (HS) endpoint out in the DMZ and punch a hole through the >> firewall so that the HS code can talk to the enterprise IdM >> stack. It was a deliberate compromise to simplify the >> implementation of a Membersite (MS). > > I understand the compromise and yes, so monster can verify messages > from acme, but how does acme verify messages from monster? Is it > acceptable for enterprises to allow their servers to access the > internet? Good question. My experience is that it is often the case, but I don't know for sure. > >> >> For sure digital signatures and certificates are a solution, but >> I'm not sure I'd go about it in exactly that way. > > I guess what I'm asking here is a scope question. Is it within the > scope of DIX to allow the message signature to be a signature that > can be verified without a remote call? and if it isn't within the > scope of core, is it expected that an extension to the core could > do it? I think making PKI a requirement would be a mistake for DIX. I think PKI is a logical extension. Your example can be solved without PKI in this way though: Internally at acme.com, intranet.acme.com resolves to the Homesite. Externally, intranet.acme.com resolves to a host that provides only capability discovery and message verification services. The internal and external hosts share a secret used to respectively sign and verify messages. We have a demo of a Firefox plug-in where the data is on the user machine, and there is a server that shares a secret with the user's machine, that is able to verify messages. ie. this works. :) -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 03 18:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJS2-0004DN-Fh; Fri, 03 Mar 2006 18:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJS1-0004DI-97 for dix@ietf.org; Fri, 03 Mar 2006 18:12:45 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFIo3-0000O2-Az for dix@ietf.org; Fri, 03 Mar 2006 17:31:27 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FFI58-0006Mj-9u for dix@ietf.org; Fri, 03 Mar 2006 16:45:03 -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 k23Lj17g008786 for ; Fri, 3 Mar 2006 16:45:01 -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 k23Lj1116481 for ; Fri, 3 Mar 2006 16:45:01 -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 k23Lj0mG005908 for ; Fri, 3 Mar 2006 16:45:00 -0500 Message-ID: <4408B8DB.6050701@redhat.com> Date: Fri, 03 Mar 2006 13:44:59 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> In-Reply-To: <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1753590776==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1753590776== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070907070300030607090001" This is a cryptographically signed message in MIME format. --------------ms070907070300030607090001 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: >> The interesting aspect of the above scenario is that monster.com >> cannot communicate with the server "intranet.acme.com" it is behind >> the companies firewall. It is also worth mentioning that acme, like >> all large multinationals, has "intranet.acme.com" locked away deep >> inside a data center. It can talk to its ldap server and a database >> server, but nothing else and certainly not "monster.com" > > > Correct. With dmd0 the enterprise would have to put its Homesite (HS) > endpoint out in the DMZ and punch a hole through the firewall so that > the HS code can talk to the enterprise IdM stack. It was a deliberate > compromise to simplify the implementation of a Membersite (MS). Having just implemented a dmd0 homesite that is intended to be behind the firewall I have thought a little on this. It seems to me that there is nothing preventing the verification code alone from being in the DMZ, with the business end of the homesite behind the firewall. This could be achieved I suspect by a little script redirection trickery which perhaps redirects internal requests to an intranet server acting as the homesite. Though I confess I have not attempted this I don't see any problem with it in theory. -- Pete --------------ms070907070300030607090001 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMDMyMTQ0NTlaMCMGCSqGSIb3DQEJBDEWBBRw28FEYM/OGflL GYSb3CoIP577RjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAM56Rwkas84k1Jh2AhpYBjv05kgMtXm7RdqennJXa8jHH5lHcWBlVuTCOXgUf uRqyOM18NG94jZ9ex6pGmzLAmy0fVeoFWN/r+sBd4yXuONbNrKW2FfW+AkW+rwmg7uIgKtdL zmJZz54sRBDEcOHUgeMtOxrk9K4xiTo92irRkHPev/ZmwowE5jCbHZe8xxuPhjO8ChnxV1VF J1JERFcZMLgqO3LEenYwCPQVbtA+YD/Vc1hCVebDwDQUmrtugLXgFYKMn3UIwxh5XkHA4JCv vVVBl8P8LtgxS1Y2RLnPr0OTOKBVuEasRJFscM2s0XhfYquG1RbYCu4GFoKihB4lhQAAAAAA AA== --------------ms070907070300030607090001-- --===============1753590776== 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 --===============1753590776==-- From dix-bounces@ietf.org Fri Mar 03 20:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFLmC-0003wl-3V; Fri, 03 Mar 2006 20:41:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFLjW-0005nX-FL for dix@ietf.org; Fri, 03 Mar 2006 20:38: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 1FFLXQ-00040j-2u for dix@ietf.org; Fri, 03 Mar 2006 20:26:29 -0500 Received: from [192.168.2.113] (adsl-69-226-219-146.dsl.pltn13.pacbell.net [69.226.219.146]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k241QK72069467 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Mar 2006 17:26:26 -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: Fri, 3 Mar 2006 17:26:14 -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: d6b246023072368de71562c0ab503126 Subject: [dix] DIX BOF Agenda X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 putting together a more detailed agenda for the DIX BOF and would like to solicit your participation. One area of obvious interest to all is existing technologies and standards that apply to this space. Some possibilities, in no particular order... SAML, Liberty Alliance, Shibboleth, YADIS, LID, OpenID, WS-Trust, Infocard/Metasystm, Higgins, LDAP, RADIUS/DIAMETER, PKIX, SIP/Identity, SXIP(dmd0)... Others? I think they've all been mentioned on this list over the past few months. I'd like people to step forward and offer to present details they feel are relevant to this effort. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 05 16:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG0qE-0001Se-VX; Sun, 05 Mar 2006 16:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG0qD-0001MQ-Jn for dix@ietf.org; Sun, 05 Mar 2006 16:32:37 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG0qD-0002WW-89 for dix@ietf.org; Sun, 05 Mar 2006 16:32:37 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k25LWawk002900 for ; Sun, 5 Mar 2006 13:32:36 -0800 Received: from MOU1WNEXMB07.vcorp.ad.vrsn.com ([10.25.13.193]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 13:32:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] DIX BOF Agenda Date: Sun, 5 Mar 2006 13:30:57 -0800 Message-ID: <4C370D5BB9EB474C8F32EAD3B257E70BA57CCE@MOU1WNEXMB07.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] DIX BOF Agenda Thread-Index: AcY/LM81T9zxdT4RSzSmAVvwW8ilAABb0fGV From: "Krall, Gary" To: "Digital Identity Exchange" , "Digital Identity Exchange" X-OriginalArrivalTime: 05 Mar 2006 21:32:36.0102 (UTC) FILETIME=[51F98260:01C6409C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0208270911==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0208270911== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6409C.51B91769" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6409C.51B91769 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John: =20 I would also consider some of the JanRain activities around what they = are calling "OPX" ("Open Profile Exchange"). =20 Gary. ________________________________ From: John Merrells [mailto:merrells@sxip.com] Sent: Fri 3/3/2006 5:26 PM To: Digital Identity Exchange Subject: [dix] DIX BOF Agenda I'm putting together a more detailed agenda for the DIX BOF and would=20 like to solicit your participation. One area of obvious interest to all is existing technologies and=20 standards that apply to this space. Some possibilities, in no particular order... SAML, Liberty Alliance, Shibboleth, YADIS, LID, OpenID, WS-Trust,=20 Infocard/Metasystm, Higgins, LDAP, RADIUS/DIAMETER, PKIX, SIP/Identity, SXIP(dmd0)...=20 Others? I think they've all been mentioned on this list over the past few=20 months. I'd like people to step forward and offer to present details they feel are relevant to=20 this effort. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ------_=_NextPart_001_01C6409C.51B91769 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [dix] DIX BOF Agenda=0A= =0A= =0A=
=0A=
John:
=0A=
 
=0A=
I would also consider some of = the JanRain =0A= activities around what they are calling "OPX" ("Open Profile =0A= Exchange").
=0A=
 
=0A=
Gary.
=0A=

=0A=
=0A= From: John Merrells =0A= [mailto:merrells@sxip.com]
Sent: Fri 3/3/2006 5:26 = PM
To: =0A= Digital Identity Exchange
Subject: [dix] DIX BOF =0A= Agenda

=0A=

=0A=

I'm putting together a more detailed agenda for the = DIX BOF and =0A= would 
like to solicit your participation.
One area of = obvious =0A= interest to all is existing technologies and 
standards that = apply to =0A= this space.
Some possibilities, in no particular = order...

SAML, =0A= Liberty Alliance, Shibboleth, YADIS, LID, OpenID, =0A= WS-Trust, 
Infocard/Metasystm,
Higgins, LDAP, = RADIUS/DIAMETER, PKIX, =0A= SIP/Identity, SXIP(dmd0)... 
Others?

I think they've all = been =0A= mentioned on this list over the past few 
months. I'd like = people =0A= to
step forward and offer to present details they feel are relevant =0A= to 
this =0A= effort.

John


__________________________________________= _____
dix =0A= mailing list
dix@ietf.org
https://www1.ietf.org= /mailman/listinfo/dix

=0A= =0A= =0A= ------_=_NextPart_001_01C6409C.51B91769-- --===============0208270911== 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 --===============0208270911==-- From dix-bounces@ietf.org Mon Mar 06 12:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJbm-0000jB-6Y; Mon, 06 Mar 2006 12:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGJbk-0000j6-Ce for dix@ietf.org; Mon, 06 Mar 2006 12:34:56 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGJbj-0002pn-1u for dix@ietf.org; Mon, 06 Mar 2006 12:34:56 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 35A591E8C4C; Mon, 6 Mar 2006 09:34:54 -0800 (PST) To: Digital Identity Exchange Subject: Re: [dix] DIX BOF Agenda References: From: Eric Rescorla Date: Mon, 06 Mar 2006 09:34:54 -0800 In-Reply-To: (John Merrells's message of "Fri, 3 Mar 2006 17:26:14 -0800") Message-ID: <86u0ab8ojl.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: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: dix-bounces@ietf.org John Merrells writes: > I'm putting together a more detailed agenda for the DIX BOF and would > like to solicit your participation. > One area of obvious interest to all is existing technologies and > standards that apply to this space. > Some possibilities, in no particular order... > > SAML, Liberty Alliance, Shibboleth, YADIS, LID, OpenID, WS-Trust, > Infocard/Metasystm, > Higgins, LDAP, RADIUS/DIAMETER, PKIX, SIP/Identity, SXIP(dmd0)... > Others? > > I think they've all been mentioned on this list over the past few > months. I'd like people to > step forward and offer to present details they feel are relevant to > this effort. Hmm.... This seems like an awful lot of material. It's a 150 minute session, and you've listed 14 different technologies. It's traditional to leave at least a third of the time for open discussion and so this leaves what, 7 minutes per technology? I'm not sure how useful that would be. My sense is that while there are a lot of different protocols in this space, there are only a few basic architectures. So, hearing about all the protocol details isn't really that illuminating. I would encourage you to focus on high level requirements and architecture rather than having a bunch of presentations on specific technologies. This lets people focus on what's important (the trust/threat model and dataflow) rather than on the bits on the wire--which aren't really that important at this stage of the game. It also avoids having a bunch of presentations which say in essence "my protocol is just like protocol X except that it's written in XML rather than ASN.1". With that in mind, I would suggest something along the following lines: Time Topic ----------------------------------------------- 10 Agenda bash 10 Motivating application 1 10 Motivating application 2 40 Overall requirements/goals 20 Survey of architectural options 10 Example protocol 1 10 Example protocol 2 10 Example protocol 3 30 Discussion (Charter?) -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 07 11:46:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfKE-0008I2-47; Tue, 07 Mar 2006 11:46:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfKC-0008Bp-4v for dix@ietf.org; Tue, 07 Mar 2006 11:46:16 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGfKB-0001V7-Hf for dix@ietf.org; Tue, 07 Mar 2006 11:46:16 -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 k27GkEXd008222; Tue, 7 Mar 2006 08:46:14 -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, 7 Mar 2006 08:46:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] DIX BOF Agenda Date: Tue, 7 Mar 2006 08:46:13 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797CC12@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] DIX BOF Agenda Thread-Index: AcZBRE5XZoVPaYOGQYi/yakoyCSDeAAv99XA From: "Hallam-Baker, Phillip" To: "EKR" , "Digital Identity Exchange" X-OriginalArrivalTime: 07 Mar 2006 16:46:14.0874 (UTC) FILETIME=[A5FDABA0:01C64206] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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="===============2094898416==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============2094898416== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C641DC.BC5D75D0" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C641DC.BC5D75D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with Eric. At some point we need to do a bakeoff, but first we have to decide what the judging criteria are. If we are not careful we will end up with a meta-meta framework which is not good. In particular I would like to disabuse folk of the notion that the purpose of DIX is to provide the deployment roll out for stuff that has been sitting on the shelf unused. The objective here is to solve a problem for end users and for site operators. Rather than have the champions of each technology present them I would suggest that we have one or two people provide an overview of the problem space and show the part(s) of the space that it is proposed to address. One of the problems here is that every project in the space comes to the table with powerpoint that describes the whole solution space but the code and the deployment constituency only cover one corner of the canvas. I would like to reuse work that is already done but I am not interested in doing the protocol equivalent of turning a DeLorean into a hovercraft especially while someone is shouting that it already is a hovercraft. The objective here is to design and build something that provides a flexible, lightweight infrastructure that can just be plugged into the existing Web and maybe work a bit better or provide a bit more privacy control with some lightweight client side extensions. Done right this can create a stepping stone for the systems that are designed to provide a comprehensive federated auth framework. But that is an entirely different thing from profiling a comprehensive framework. > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Monday, March 06, 2006 12:35 PM > To: Digital Identity Exchange > Subject: Re: [dix] DIX BOF Agenda > > John Merrells writes: > > > I'm putting together a more detailed agenda for the DIX BOF > and would > > like to solicit your participation. > > One area of obvious interest to all is existing technologies and > > standards that apply to this space. > > Some possibilities, in no particular order... > > > > SAML, Liberty Alliance, Shibboleth, YADIS, LID, OpenID, WS-Trust, > > Infocard/Metasystm, Higgins, LDAP, RADIUS/DIAMETER, PKIX, > > SIP/Identity, SXIP(dmd0)... > > Others? > > > > I think they've all been mentioned on this list over the past few > > months. I'd like people to step forward and offer to > present details > > they feel are relevant to this effort. > > Hmm.... This seems like an awful lot of material. It's a 150 > minute session, and you've listed 14 different technologies. > It's traditional to leave at least a third of the time for > open discussion and so this leaves what, 7 minutes per > technology? I'm not sure how useful that would be. My sense > is that while there are a lot of different protocols in this > space, there are only a few basic architectures. > So, hearing about all the protocol details isn't really that > illuminating. > > I would encourage you to focus on high level requirements and > architecture rather than having a bunch of presentations on > specific technologies. This lets people focus on what's > important (the trust/threat model and dataflow) rather than > on the bits on the wire--which aren't really that important > at this stage of the game. > It also avoids having a bunch of presentations which say in > essence "my protocol is just like protocol X except that it's > written in XML rather than ASN.1". > > With that in mind, I would suggest something along the following > lines: > > Time Topic > ----------------------------------------------- > 10 Agenda bash > 10 Motivating application 1 > 10 Motivating application 2 > 40 Overall requirements/goals > 20 Survey of architectural options > 10 Example protocol 1 > 10 Example protocol 2 > 10 Example protocol 3 > 30 Discussion (Charter?) > > -Ekr > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > ------=_NextPart_000_0008_01C641DC.BC5D75D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDcxNjQ2MTNaMCMGCSqGSIb3DQEJBDEWBBTF mMwygubI+NZtLBHlH0R5+GYmCzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAbC1biE7lRMxBQIsKcInMD42Gk KGdH8oyM/IMDQpCKjXOWIf1v/0SzlVvyfZukfoThalHQ3mKXV7ZoKpR1P71mwzrLW/SU1y3c0Omq p9emZqiYYQQf6hkeu7od5li/y58FNpyIh/yQqbbGG3aS5VEcWqtZdfInc8eWZgDwvKwd4AAAAAAA AA== ------=_NextPart_000_0008_01C641DC.BC5D75D0-- --===============2094898416== 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 --===============2094898416==-- From dix-bounces@ietf.org Tue Mar 07 23:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGqEi-0000d3-Mp; Tue, 07 Mar 2006 23:25:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGqEh-0000cv-HG for dix@ietf.org; Tue, 07 Mar 2006 23:25:19 -0500 Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGqEh-0004Qu-8C for dix@ietf.org; Tue, 07 Mar 2006 23:25:19 -0500 Received: by wproxy.gmail.com with SMTP id i31so92946wra for ; Tue, 07 Mar 2006 20:25:18 -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=C3svhw4fh82fv+icabydY2mIyxIqytZmmUow2r5dnXCRNYUTogwRB1uPbmD7lHTa0N0vRopB6aS7RM/ZBjsNmHATvk+qEbtlevpTMNlD63vBQJynDlfEa9lxNFxqQgiHztTrgII5up2f7sGZhbGRsdzoZaESN7O/R6mpcWeqGDo= Received: by 10.54.76.10 with SMTP id y10mr228380wra; Tue, 07 Mar 2006 20:25:18 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id g5sm289929wra.2006.03.07.20.25.07; Tue, 07 Mar 2006 20:25:10 -0800 (PST) Message-ID: <440E5CA2.5080708@gmail.com> Date: Tue, 07 Mar 2006 23:25:06 -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] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: > > On 3-Mar-06, at 12:00 PM, Robert Yates wrote: > >> I understand the compromise and yes, so monster can verify messages >> from acme, but how does acme verify messages from monster? Is it >> acceptable for enterprises to allow their servers to access the >> internet? > > > Good question. My experience is that it is often the case, but I > don't know for sure. I have asked this question to some folks who setup data centers and am waiting on a response, I'll post the response to the mailing list when I get it. However, one colleague that I have discussed this with mentioned that enterprises may be reluctant to allow their servers access to the internet as they can become susceptible to DoS attacks. He looked at the current draft and came up with the following potential DoS attack that could be mounted against any membersite (intranet or internet based). An attacker sets up rogue homesites that respond very slowly, if at all, to verify requests and requests for persona-urls. The attacker then peppers a membersite with messages that need verification from the rogue homesites and that also potentially need to resolve rogue persona-urls. Given that the homesites are responding slowly to these requests, the requests coming out of the membersite start to build up and eventually exhaust the servers resources, most notably the threads. Is this a valid DoS attack? and if so, what approaches are available to the membersite to mitigate its effect? >> I guess what I'm asking here is a scope question. Is it within the >> scope of DIX to allow the message signature to be a signature that >> can be verified without a remote call? and if it isn't within the >> scope of core, is it expected that an extension to the core could do >> it? > > I think making PKI a requirement would be a mistake for DIX. I think > PKI is a logical extension. I agree that making PKI a MUST requirement would probably be a mistake, but if it turns out that enterprises do not allow their intranet servers to access the internet and if making a verify request or retrieving a persona-url renders the homesite vulnerable to a DoS attack then it may be worth considering PKI as an optional part of the specification. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 08 08:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz2v-00076E-3i; Wed, 08 Mar 2006 08:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz2t-000769-Nn for dix@ietf.org; Wed, 08 Mar 2006 08:49:43 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz2s-0001dJ-Ao for dix@ietf.org; Wed, 08 Mar 2006 08:49:43 -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 k28Dnf2J028598 for ; Wed, 8 Mar 2006 05:49:41 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 05:49:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] DIX in the extranet Date: Wed, 8 Mar 2006 05:49:39 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797CD1E@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] DIX in the extranet Thread-Index: AcZCaFagOI+oe53aQF+8XV5isq/IMAATSkmg From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 08 Mar 2006 13:49:41.0529 (UTC) FILETIME=[26474090:01C642B7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1252690723==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1252690723== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C6428D.3BC6BCE0" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C6428D.3BC6BCE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I agree that making PKI a MUST requirement would probably be > a mistake, but if it turns out that enterprises do not allow > their intranet servers to access the internet and if making a > verify request or retrieving a persona-url renders the > homesite vulnerable to a DoS attack then it may be worth > considering PKI as an optional part of the specification. I don't think that the design is far enough advanced to know what authentication techniques are required, let alone to throw out an entire class of solutions. IPSEC uses PKI and there is not a major problem. There are certainly ways in which PKI can be applied that should prevent this providing more of a denial of service attack than already exists. ------=_NextPart_000_0000_01C6428D.3BC6BCE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDgxMzQ5MzhaMCMGCSqGSIb3DQEJBDEWBBTN 9mfImy7KvzWCalOuFbishHGYszBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYBMBgZhoExwnr4KnfwYyl9iyQvS t5iniPZIhdqodJ77pXNBGEJiyBtykHrxGO78GidEtagHrul7dGxUeuSxyyQnR080l+Eg54C0uwAL dSSzN1Zw/NMdcQyaG/dTGnZC0v4dw3XLYlW3JZZE24hj63TYxhP9+Ik2c5uu+PtnGBJ9tgAAAAAA AA== ------=_NextPart_000_0000_01C6428D.3BC6BCE0-- --===============1252690723== 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 --===============1252690723==-- From dix-bounces@ietf.org Wed Mar 08 10:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0XV-0006GE-8J; Wed, 08 Mar 2006 10:25:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0XT-0006Ei-Ai for dix@ietf.org; Wed, 08 Mar 2006 10:25:23 -0500 Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0XS-0005La-2P for dix@ietf.org; Wed, 08 Mar 2006 10:25:23 -0500 Received: by wproxy.gmail.com with SMTP id 58so446245wri for ; Wed, 08 Mar 2006 07:25:21 -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=dFXJ8CFpUpJxyVd6DCHzXdFDJ9Ejpf0r1g+VCcsTTp3Sq48+MhhLLQcHB5K3ajlt/DhFeiHXhkzci3UCPMwJbpzDWRymqWNhYJFCtyl5AVjeFU9tV3A7ic+ea8hVi35kb2Iod0m3cTORXdmaWGvgQc1d3RLQxMG+KD78wy2px44= Received: by 10.54.149.14 with SMTP id w14mr774318wrd; Wed, 08 Mar 2006 07:25:20 -0800 (PST) Received: from ?9.33.67.77? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 6sm1379461wrl.2006.03.08.07.25.19; Wed, 08 Mar 2006 07:25:20 -0800 (PST) Message-ID: <440EF75D.4050503@gmail.com> Date: Wed, 08 Mar 2006 10:25:17 -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] DIX in the extranet References: <198A730C2044DE4A96749D13E167AD3797CD1E@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD3797CD1E@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: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: >I don't think that the design is far enough advanced to know what >authentication techniques are required, let alone to throw out an entire >class of solutions. > > I didn't mean to imply that we throw anything out, am just asking if others think that there is a DoS vulnerability in the current draft. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 08 13:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3Vb-0007io-HU; Wed, 08 Mar 2006 13:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3VZ-0007bX-VJ for dix@ietf.org; Wed, 08 Mar 2006 13:35:37 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3VY-0003aa-KF for dix@ietf.org; Wed, 08 Mar 2006 13:35:37 -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 k28IZZH9007265 for ; Wed, 8 Mar 2006 13:35:35 -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 k28IZZ132245 for ; Wed, 8 Mar 2006 13:35:35 -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 k28IZXmG004033 for ; Wed, 8 Mar 2006 13:35:33 -0500 Message-ID: <440F23EF.6070908@redhat.com> Date: Wed, 08 Mar 2006 10:35:27 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@gmail.com> <440E5CA2.5080708@gmail.com> In-Reply-To: <440E5CA2.5080708@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0638529831==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0638529831== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040909080709050302070506" This is a cryptographically signed message in MIME format. --------------ms040909080709050302070506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Yates wrote: > An attacker sets up rogue homesites that respond very slowly, if at > all, to verify requests and requests for persona-urls. The attacker > then peppers a membersite with messages that need verification from > the rogue homesites and that also potentially need to resolve rogue > persona-urls. Given that the homesites are responding slowly to these > requests, the requests coming out of the membersite start to build up > and eventually exhaust the servers resources, most notably the threads. > > Is this a valid DoS attack? and if so, what approaches are available > to the membersite to mitigate its effect? I don't think it is, other than the resources expended processing the request message - which is akin to a DSA on a web site by requesting lots of pages. The important point to note is that the DMD0 protocol is stateless and that for the most part the participants have no need to keep any kind of state during a transaction, or indeed to care if the transaction is completed, simply dealing with responses as they arrive is sufficient. So there is no point at which any thread will be blocked waiting for a response - that would be a broken implementation anyway. -- Pete --------------ms040909080709050302070506 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMDgxODM1MjdaMCMGCSqGSIb3DQEJBDEWBBTwU8RoV0yDbU7k sAkqtPlmeQJjrzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEACnNmzSFG6jWGqiUizCyPFUQIqJzafuIuEXV+x67M3Pcknf+c5L+FL18x2CNo PmBDiPZLsASN6/P+BUad8nv6pu+mH/QfA5xwPxJcTqulGpwaa+NsTy0JGSnQ/668brAs8x+6 ckupmWEgAPd1SWT07oUMx89wzMUyR7mtlRwFf6MZJBfz27TLl+48kPRlcjx3A8t6onC4iify QYRXPia3+BwT6+e9C8NjKWbP+vOUXOL6a5dFZfInfUrc+0X3NoDzOedzpJzZGCDp6+1cuk5t P8RhWy00+Fv390KivPkj7Da2W70fvw9TLR5M7DPpWbhlaZVD/lc6W78UdKyiR6wxEQAAAAAA AA== --------------ms040909080709050302070506-- --===============0638529831== 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 --===============0638529831==-- From dix-bounces@ietf.org Wed Mar 08 13:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3r1-0002yP-Ov; Wed, 08 Mar 2006 13:57:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3r0-0002yK-Oo for dix@ietf.org; Wed, 08 Mar 2006 13:57:46 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3qz-00049w-Aa for dix@ietf.org; Wed, 08 Mar 2006 13:57:46 -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 k28Ivip1010542 for ; Wed, 8 Mar 2006 10:57:44 -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, 8 Mar 2006 10:57:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] DIX in the extranet Date: Wed, 8 Mar 2006 10:57:43 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] DIX in the extranet Thread-Index: AcZCxIodRoAy1LT+T5Op/Et5PmZP1wAFpxAw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 08 Mar 2006 18:57:44.0173 (UTC) FILETIME=[2ECAE9D0:01C642E2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1773087278==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1773087278== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0021_01C642B8.44D0FB40" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C642B8.44D0FB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think that DoS attacks are going to be a major issue that any protocol in this space is going to have to cope with. In particular attacks against the auth provider are going to require serious attention. I am less worried about auth providers attacking relying parties. The relying parties should soon learn not to connect to abusive auth providers. PKI is one of the tools we can use to help here. * The large auth providers are the ones most likely to be attacked, the small fry are probably not worth bothering with. * PKI should only be used to establish a framework of trust, after an initial bilateral key exchange using PKI the credentials can be cached for future use. Just so folk are straight here, VeriSign is not an exclusive provider of PKI based authentication, we have a large and growing symmetric key based product line. I am just as happy with the idea of managing a kerberos style key distribution based system as PKI, there are cases where that is the right approach. > -----Original Message----- > From: Robert Yates [mailto:robyates70@gmail.com] > Sent: Wednesday, March 08, 2006 10:25 AM > To: Digital Identity Exchange > Subject: Re: [dix] DIX in the extranet > > Hallam-Baker, Phillip wrote: > > >I don't think that the design is far enough advanced to know what > >authentication techniques are required, let alone to throw out an > >entire class of solutions. > > > > > I didn't mean to imply that we throw anything out, am just > asking if others think that there is a DoS vulnerability in > the current draft. > > Rob > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > ------=_NextPart_000_0021_01C642B8.44D0FB40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDgxODU3NDJaMCMGCSqGSIb3DQEJBDEWBBTb MMgxLOXQTkNLNYWF2V1bOrYj0DBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYC19jvemOPRVtLeOWbrv8DYwQiB umywjOWPLZ3YOmwrRkGNKfMx5Sart8Y5fls2zdNfli3gkl99BghiINlf3SOpyl7wKd4ppwuQrPJN P3mOKLslG2NH/ZmOBVcYB+wSoPGBAUjd43o5aIQc3jC5Vt2AfV0t/j0P3cXtwZKxlDNoXwAAAAAA AA== ------=_NextPart_000_0021_01C642B8.44D0FB40-- --===============1773087278== 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 --===============1773087278==-- From dix-bounces@ietf.org Wed Mar 08 14:00:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3u2-0005v5-Gc; Wed, 08 Mar 2006 14:00:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3u0-0005v0-Ma for dix@ietf.org; Wed, 08 Mar 2006 14:00:52 -0500 Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3tz-0004Dc-Ch for dix@ietf.org; Wed, 08 Mar 2006 14:00:52 -0500 Received: by wproxy.gmail.com with SMTP id 68so471339wra for ; Wed, 08 Mar 2006 11:00:51 -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=ESP/EiiZAddYiZmzyj9rLKo3tPwd7aSC7xR+LWOlR4mfY8aBMAV/VPaznt6Us49NRnOobLn3tKkNYkX7TMH6ghj1A+TN1al+BlFnX5j1O4uGy5GlbFBVfs/t+/vfNAfH7lYgf1qYmbXU57R8v+nYLx+ZgX7qsFk3D/O46eMWm/Y= Received: by 10.54.125.1 with SMTP id x1mr2089065wrc; Wed, 08 Mar 2006 11:00:51 -0800 (PST) Received: from ?9.33.67.77? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 11sm2147958wrl.2006.03.08.11.00.50; Wed, 08 Mar 2006 11:00:50 -0800 (PST) Message-ID: <440F29E1.7040103@gmail.com> Date: Wed, 08 Mar 2006 14:00:49 -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] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@gmail.com> <440E5CA2.5080708@gmail.com> <440F23EF.6070908@redhat.com> In-Reply-To: <440F23EF.6070908@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Pete Rowley wrote: > I don't think it is, other than the resources expended processing the > request message - which is akin to a DSA on a web site by requesting > lots of pages. The important point to note is that the DMD0 protocol > is stateless and that for the most part the participants have no need > to keep any kind of state during a transaction, or indeed to care if > the transaction is completed, simply dealing with responses as they > arrive is sufficient. So there is no point at which any thread will > be blocked waiting for a response - that would be a broken > implementation anyway. Let's say I am trying to log into amazon.com as gmail.com/robyates. I go to amazon and type in my homesite gmail.com. I am bounced to gmail, I authenticate and then I am bounced back to amazon. Amazon must now validate that I am in fact gmail.com/robyates. To do this it must make two requests, one to retrieve my persona document to check that the homesite can make this assertion and then again to verify the message signature and it must do all this before letting me in as gmail.com/amazon. Isn't amazon's thread (the thread servicing my login attempt) blocked on those two requests? and if an attacker controls the homesite then can't he block those threads for quite a while? Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 08 20:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAD9-0001jv-W3; Wed, 08 Mar 2006 20:45:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHABe-0008Hi-9U for dix@ietf.org; Wed, 08 Mar 2006 20:43:30 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHA3P-0005YG-Hg for dix@ietf.org; Wed, 08 Mar 2006 20:35:00 -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 k291Yxl5011130 for ; Wed, 8 Mar 2006 20:34:59 -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 k291Yw103620 for ; Wed, 8 Mar 2006 20:34:58 -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 k291YvmG025695 for ; Wed, 8 Mar 2006 20:34:57 -0500 Message-ID: <440F8640.7000109@redhat.com> Date: Wed, 08 Mar 2006 17:34: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: [dix] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@gmail.com> <440E5CA2.5080708@gmail.com> <440F23EF.6070908@redhat.com> <440F29E1.7040103@gmail.com> In-Reply-To: <440F29E1.7040103@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0418875200==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0418875200== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000309080800020903000003" This is a cryptographically signed message in MIME format. --------------ms000309080800020903000003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Yates wrote: > Isn't amazon's thread (the thread servicing my login attempt) blocked > on those two requests? One thread can be made to handle all such requests, so yes, the thread would be blocked, but it wouldn't scale to a denial of service through thread exhaustion - file handles are another matter, but again this is an implementation detail which can be coded for, rather than an inherent weakness in the protocol. It might be useful to identify such forms of attack in order that such implementation traps are avoided for any officially designated DIX protocol. -- Pete --------------ms000309080800020903000003 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMDkwMTM0NTZaMCMGCSqGSIb3DQEJBDEWBBQVH0pYV7l9qhUE eU52HxnMhf78hzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAAG8bUm0iTt1x3aFJwXnIDjaI09tHcs4BPDRzCVnSmBBazM+q4ae5PLz+vzRZ vKuPDhL7HSTrwgGE2DrCdNHut2jlBc0JczDUwDgE4nqK29Gxbkajxqj0vAgp/uomOtQ2Nq0M Ow8k5rqKgYXzLEQc7455yqSQyjZ4tDXpBM09fCBcHLHg0kJWwCqjamUsHCbnwOrHNEEKJYGn BZLUo3bmrP3Kufbqbxxb0xM2aD0WYQe+h48shtZy89fxQFpc+nPoTl6lQKw4jIhkFSCd6LaV LnIGDglO05mSRTLojiYoWyxzUOwi8l/bauFjNYcubPxp3OoiQ9Nw4wM/7bdhRH6JZAAAAAAA AA== --------------ms000309080800020903000003-- --===============0418875200== 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 --===============0418875200==-- From dix-bounces@ietf.org Thu Mar 09 08:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKx3-0007xK-0v; Thu, 09 Mar 2006 08:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKx1-0007xF-VM for dix@ietf.org; Thu, 09 Mar 2006 08:13:07 -0500 Received: from chico.rediris.es ([130.206.1.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKx0-00019F-ES for dix@ietf.org; Thu, 09 Mar 2006 08:13:07 -0500 Received: from [10.8.0.38] (login.rediris.es [130.206.1.21]) by chico.rediris.es (8.12.10/8.9.1) with ESMTP id k29DD4ao028928 for ; Thu, 9 Mar 2006 14:13:05 +0100 (CET) Message-ID: <44102A51.2020104@rediris.es> Date: Thu, 09 Mar 2006 14:14:57 +0100 From: "Diego R. Lopez" User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX in the extranet References: <440852A6.8070008@gmail.com> <0AFF7CAB-DA9A-4204-B91C-41C041EE8ECD@sxip.com> <4408A066.60809@gmail.com> <440E5CA2.5080708@gmail.com> <440F23EF.6070908@redhat.com> <440F29E1.7040103@gmail.com> <440F8640.7000109@redhat.com> In-Reply-To: <440F8640.7000109@redhat.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=B8CD62D1; url=http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xB8CD62D1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Pete Rowley wrote: > Robert Yates wrote: > >> Isn't amazon's thread (the thread servicing my login attempt) blocked >> on those two requests? > > One thread can be made to handle all such requests, so yes, the thread > would be blocked, but it wouldn't scale to a denial of service through > thread exhaustion - file handles are another matter, but again this is > an implementation detail which can be coded for, rather than an inherent > weakness in the protocol. It might be useful to identify such forms of > attack in order that such implementation traps are avoided for any > officially designated DIX protocol. Furthermore, if you use a RESTish model, you don't need to have any thread awaiting at amazon if you pass forth and back a cryptographically protected session id... -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: drlopez@im.rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 09 15:44:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRzp-0001pq-Q1; Thu, 09 Mar 2006 15:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRzo-0001pQ-Eh for dix@ietf.org; Thu, 09 Mar 2006 15:44:28 -0500 Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRzn-00075g-5A for dix@ietf.org; Thu, 09 Mar 2006 15:44:28 -0500 Received: by wproxy.gmail.com with SMTP id i31so513421wra for ; Thu, 09 Mar 2006 12:44:26 -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=eeufmoz6hhOkAT0CoI6VnZnapX1gaUCOdi6zO/YRbyR5UWodeeSPrBRGNn6dHVlz2EjYkoHnu/FpvLo176eOWlt0V/8Pbl09S8vrwCCSZT5PxIc6Enat0e/ZTqTu+SQmfaXYK59etMCuxgXG7yXJECLzHmRXSDf+gLIAdOrkUOw= Received: by 10.54.142.13 with SMTP id p13mr2716869wrd; Thu, 09 Mar 2006 12:44:26 -0800 (PST) Received: from ?9.33.157.42? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 39sm558787wrl.2006.03.09.12.44.25; Thu, 09 Mar 2006 12:44:26 -0800 (PST) Message-ID: <441093A5.40005@gmail.com> Date: Thu, 09 Mar 2006 15:44:21 -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 References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD3797CD9B@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [dix] DoS in dmd0 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: >I think that DoS attacks are going to be a major issue that any protocol in >this space is going to have to cope with. > Agreed, I apologize for bringing this up again, but I think it very important that we get this right and am interested in the thoughts of others as to whether dmd0 should be tightened to help protect against DoS attacks. As far as I can make out, it is going to be fairly hard to protect against DoS if we develop a protocol that requires a membersite's thread to block wait (either directly or indirectly) on the retrieval of two urls from potentially unknown and untrusted sources. I know that Phillip mentioned that membersites could "learn" not to trust certain sources, but should we instead look at ways of avoiding these calls? I guess what I am asking is whether it should be a design consideration of DIX to minimize the synchronous calls that must be made to untrusted sites when verifying messages, particularly those messages asserting a persona-url? If this is a consideration worth persuing then I wanted to jot down a few approaches to reducing the need for these calls and see what others think.. 1) PKI, this would obviously remove the need to make the verify call, but I agree that PKI should not be a MUST requirement. 2) Only call the remote site once to generate a shared secret and then use the secret to verify signatures coming from that site. This would be akin to openid's associate mode. 3) Use Phillip's suggestion of SRV records as a discovery mechanism, instead of looking up the persona-url. Just some thoughts, Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 09 20:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW6p-0002UN-7I; Thu, 09 Mar 2006 20:07:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW6n-0002UE-LE for dix@ietf.org; Thu, 09 Mar 2006 20:07:57 -0500 Received: from imo-d21.mx.aol.com ([205.188.144.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHW6m-0001ek-DH for dix@ietf.org; Thu, 09 Mar 2006 20:07:57 -0500 Received: from THayes0993@aol.com by imo-d21.mx.aol.com (mail_out_v38_r7.3.) id l.65.56c209f5 (15703) for ; Thu, 9 Mar 2006 20:07:51 -0500 (EST) Received: from FWM-R33 (fwm-r33.webmail.aol.com [152.163.181.137]) by air-id05.mx.aol.com (vx) with ESMTP id MAILINID54-3d574410d167110; Thu, 09 Mar 2006 20:07:51 -0500 Date: Thu, 09 Mar 2006 20:07:51 -0500 Message-Id: <8C811F6304BB8F5-1140-164@FWM-R33.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> Received: from 10.169.155.114 by FWM-R33.sysops.aol.com (152.163.181.137) with HTTP (WebMailUI); Thu, 09 Mar 2006 20:07:51 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <441093A5.40005@gmail.com> X-Mailer: AOL WebMail 16884 Subject: What does verification mean? (was Re: [dix] DoS in dmd0) MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 152.163.181.137 X-Spam-Flag: NO X-Spam-Score: 1.0 (+) 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: , Content-Type: multipart/mixed; boundary="===============0273052167==" Errors-To: dix-bounces@ietf.org --===============0273052167== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C811F6304BB8F5_1140_17C_FWM-R33.sysops.aol.com" ----------MailBlocks_8C811F6304BB8F5_1140_17C_FWM-R33.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The thread on DoS in dmd0 got me thinking about the meaning of the verification step in dmd0. As stated in that thread, the verification step might be a concern, since a membersite may be blocking on a response from an unknown homesite. I started to think about eliminating the verification (and the signature that goes with it). What requirement is the verification step meeting? At the most basic level, a DIX protocol is simply providing a convenient way to transfer a set of self-asserted attributes from the user to the membersite - by way of the homesite. In this model the homesite is simply storing the attributes on the user behalf and, consistantly with Identity Law #1, revealing them only with the user's consent. It does not do any checking that they correctly represent the user in any way. At this level the only thing the signature means is "I sent this exact set of attributes because the user asked me to." This just doesn't seem very useful to the membersite. The entire set of attributes could be replaced by a MITM that runs its own homesite, or that has an account at the specified homesite. Can we agree that for this level of requirement, the signature and verification are not required? Things get more interesting when properties (attributes) like Persona URL come into play. I'll try to write up some thoughts on that tomorrow. Terry Hayes AOL Corp. ----------MailBlocks_8C811F6304BB8F5_1140_17C_FWM-R33.sysops.aol.com Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
The thread on DoS in dmd0 got me thinking about the meaning of the verification step in dmd0.  As stated in that thread, the verification step might be a concern, since a membersite may be blocking on a response from an unknown homesite.  I started to think about eliminating the verification (and the signature that goes with it).  What requirement is the verification step meeting?
 
At the most basic level, a DIX protocol is simply providing a convenient way to transfer a set of self-asserted attributes from the user to the membersite - by way of the homesite.  In this model the homesite is simply storing the attributes on the user behalf and, consistantly with Identity Law #1, revealing them only with the user's consent.  It does not do any checking that they correctly represent the user in any way.
 
At this level the only thing the signature means is "I sent this exact set of attributes because the user asked me to."  This just doesn't seem very useful to the membersite.  The entire set of attributes could be replaced by a MITM that runs its own homesite, or that has an account at the specified homesite.
 
Can we agree that for this level of requirement, the signature and verification are not required?
 
Things get more interesting when properties (attributes) like Persona URL come into play.  I'll try to write up some thoughts on that tomorrow.
 
Terry Hayes
AOL Corp.
 
----------MailBlocks_8C811F6304BB8F5_1140_17C_FWM-R33.sysops.aol.com-- --===============0273052167== 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 --===============0273052167==-- From dix-bounces@ietf.org Thu Mar 09 22:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHYHB-0003Hz-RJ; Thu, 09 Mar 2006 22:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHYHB-0003Hu-0b for dix@ietf.org; Thu, 09 Mar 2006 22:26:49 -0500 Received: from pproxy.gmail.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHYH9-0005uF-Bv for dix@ietf.org; Thu, 09 Mar 2006 22:26:48 -0500 Received: by pproxy.gmail.com with SMTP id w49so333770pyg for ; Thu, 09 Mar 2006 19:26:45 -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=mY97iumEqCCa70v/vxFYryJai2teqZ6hqt7K7mtXkU1Jutp36XzuZMrUMtApKeLZaozfO6Svaa3vbOmbt4ivrc6gMIzl/mzFmfnnnGCpq/pVFGT8AOBQP+TTASUqLp9AJ2oXyu5E7KjWd6Nw/wei2DUl21pix8KJrWvhkDAwL7U= Received: by 10.65.44.6 with SMTP id w6mr338262qbj; Thu, 09 Mar 2006 19:26:44 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id z21sm1378160qbc.2006.03.09.19.26.42; Thu, 09 Mar 2006 19:26:44 -0800 (PST) Message-ID: <4410F1F1.50709@gmail.com> Date: Thu, 09 Mar 2006 22:26:41 -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: What does verification mean? (was Re: [dix] DoS in dmd0) References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> <8C811F6304BB8F5-1140-164@FWM-R33.sysops.aol.com> In-Reply-To: <8C811F6304BB8F5-1140-164@FWM-R33.sysops.aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 thayes0993@aol.com wrote: > The thread on DoS in dmd0 got me thinking about the meaning of the > verification step in dmd0. As stated in that thread, the verification > step might be a concern, since a membersite may be blocking on a > response from an unknown homesite. I started to think about > eliminating the verification (and the signature that goes with it). > What requirement is the verification step meeting? > > At the most basic level, a DIX protocol is simply providing a > convenient way to transfer a set of self-asserted attributes from the > user to the membersite - by way of the homesite. In this model the > homesite is simply storing the attributes on the user behalf and, > consistantly with Identity Law #1, revealing them only with the user's > consent. It does not do any checking that they correctly represent > the user in any way. > > At this level the only thing the signature means is "I sent this exact > set of attributes because the user asked me to." This just doesn't > seem very useful to the membersite. The entire set of attributes > could be replaced by a MITM that runs its own homesite, or that has an > account at the specified homesite. > > Can we agree that for this level of requirement, the signature and > verification are not required? Am not sure that I agree with this. There are instances where it is important whom the homesite is i.e. who is making the assertion about the attributes. I also don't believe that the attributes are always self-asserted and have been assuming that a user probably has many sites that assert attributes about the user and act as homesites, e.g. my bank, my state, etc. A classic example is the driving license analogy. The membersite wants to know how old the user is. They are not going to accept an assertion about the users age from any homesite. It has to be from some "homesite" that they trust, in my case, as I live in mass, probably "http://www.mass.gov". For these cases they need the verification step. I agree that there are many instances where the verification step is not required, but I think it is important step for many more attributes than just the persona-url. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 10 00:12:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZvT-0003xy-Qg; Fri, 10 Mar 2006 00:12:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZvS-0003xt-Jq for dix@ietf.org; Fri, 10 Mar 2006 00:12:30 -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 1FHZvS-0000Ob-8C for dix@ietf.org; Fri, 10 Mar 2006 00:12:30 -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 k2A5CS7m026160 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Mar 2006 21:12:29 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <441093A5.40005@gmail.com> References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9861ABE3-BABB-4251-8E35-82037577E1A9@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] DoS in dmd0 Date: Thu, 9 Mar 2006 15:46:42 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 9-Mar-06, at 12:44 PM, Robert Yates wrote: > Hallam-Baker, Phillip wrote: > >> I think that DoS attacks are going to be a major issue that any >> protocol in >> this space is going to have to cope with. >> > Agreed, I apologize for bringing this up again, but I think it very > important that we get this right and am interested in the thoughts > of others as to whether dmd0 should be tightened to help protect > against DoS attacks. > > As far as I can make out, it is going to be fairly hard to protect > against DoS if we develop a protocol that requires a membersite's > thread to block wait (either directly or indirectly) on the > retrieval of two urls from potentially unknown and untrusted > sources. I know that Phillip mentioned that membersites could > "learn" not to trust certain sources, but should we instead look at > ways of avoiding these calls? > > I guess what I am asking is whether it should be a design > consideration of DIX to minimize the synchronous calls that must be > made to untrusted sites when verifying messages, particularly those > messages asserting a persona-url? > > If this is a consideration worth persuing then I wanted to jot down > a few approaches to reducing the need for these calls and see what > others think.. > > 1) PKI, this would obviously remove the need to make the verify > call, but I agree that PKI should not be a MUST requirement. PKI resolves the requirement for the MS to call other servers. It would be possible for a MS to only work with Homesites that used PKI for verification. This would allow a Membersite to choose the methodology used for verification, without requiring ALL membersites to support PKI. > 2) Only call the remote site once to generate a shared secret and > then use the secret to verify signatures coming from that site. > This would be akin to openid's associate mode. I think having a shared secret mode is a good option for improving performance. Just as in OpenID, having it as an option rather then a requirement is best as it requires state management and additional overhead if little interaction between that Homesite and Membersite. Note that it does not solve DoS since bad server can repeatedly fail to provide shared secret. > 3) Use Phillip's suggestion of SRV records as a discovery > mechanism, instead of looking up the persona-url. Does not solve DoS as bad server can withhold returning SRV records. Completely agree that we need to consider these types of attacks. Given that we have not got a WG started yet, I'm wondering if we are getting ahead of ourselves though? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 10 01:06:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHalZ-0004CD-8o; Fri, 10 Mar 2006 01:06:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHalX-00047U-Kc for dix@ietf.org; Fri, 10 Mar 2006 01:06:19 -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 1FHalU-0001bN-6s for dix@ietf.org; Fri, 10 Mar 2006 01:06:19 -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 k2A645XP028127 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Mar 2006 22:06:14 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4410F1F1.50709@gmail.com> References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> <8C811F6304BB8F5-1140-164@FWM-R33.sysops.aol.com> <4410F1F1.50709@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FB2C481-717D-4933-9B8E-E4A2470C92AE@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0) Date: Thu, 9 Mar 2006 22:04:06 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 9-Mar-06, at 7:26 PM, Robert Yates wrote: > thayes0993@aol.com wrote: > >> The thread on DoS in dmd0 got me thinking about the meaning of the >> verification step in dmd0. As stated in that thread, the >> verification step might be a concern, since a membersite may be >> blocking on a response from an unknown homesite. I started to >> think about eliminating the verification (and the signature that >> goes with it). What requirement is the verification step meeting? >> At the most basic level, a DIX protocol is simply providing a >> convenient way to transfer a set of self-asserted attributes from >> the user to the membersite - by way of the homesite. In this >> model the homesite is simply storing the attributes on the user >> behalf and, consistantly with Identity Law #1, revealing them only >> with the user's consent. It does not do any checking that they >> correctly represent the user in any way. >> At this level the only thing the signature means is "I sent this >> exact set of attributes because the user asked me to." This just >> doesn't seem very useful to the membersite. The entire set of >> attributes could be replaced by a MITM that runs its own homesite, >> or that has an account at the specified homesite. >> Can we agree that for this level of requirement, the signature >> and verification are not required? The Homesite is authoritative that the user is the persona-url. If the persona-url is in the message, then the Membersite needs to verify that the Homesite did make the claim that the user is that persona-url. I agree with you that that Membersite does not need to verify the message if only self asserted claims are coming from the user. > > Am not sure that I agree with this. There are instances where it > is important whom the homesite is i.e. who is making the assertion > about the attributes. I also don't believe that the attributes are > always self-asserted and have been assuming that a user probably > has many sites that assert attributes about the user and act as > homesites, e.g. my bank, my state, etc. > > A classic example is the driving license analogy. The membersite > wants to know how old the user is. They are not going to accept an > assertion about the users age from any homesite. It has to be from > some "homesite" that they trust, in my case, as I live in mass, > probably "http://www.mass.gov". For these cases they need the > verification step. I would call this an Authoritative Site. In these cases I think using PKI is appropriate. > > I agree that there are many instances where the verification step > is not required, but I think it is important step for many more > attributes than just the persona-url. As I mention above, the verification is required if the persona-url is in the message. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 10 09:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHiaq-0001uI-Km; Fri, 10 Mar 2006 09:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHiap-0001uD-8L for dix@ietf.org; Fri, 10 Mar 2006 09:27:47 -0500 Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHiao-00008Q-00 for dix@ietf.org; Fri, 10 Mar 2006 09:27:47 -0500 Received: by wproxy.gmail.com with SMTP id i31so679274wra for ; Fri, 10 Mar 2006 06:27:45 -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=AckcxmW5H4g8lKHEYdHNfRfh+fnfacCjaf3Eve5NTnW2NwY38znzPsNTMEEj/cN0yIdUTOhnxcv7/EQ0V5tQGonQdFrCaOwg+Rw+Dl0fTEYy7qEqyNP4a+Y9AyjHFOd/rUQy+lwUNHzYgWD0NvrdUiJdkSDZlttxq2ELq9PvfRo= Received: by 10.54.116.8 with SMTP id o8mr883284wrc; Fri, 10 Mar 2006 06:27:45 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 40sm1887913wrl.2006.03.10.06.27.44; Fri, 10 Mar 2006 06:27:44 -0800 (PST) Message-ID: <44118CDE.8010408@gmail.com> Date: Fri, 10 Mar 2006 09:27:42 -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] DoS in dmd0 References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> <9861ABE3-BABB-4251-8E35-82037577E1A9@sxip.com> In-Reply-To: <9861ABE3-BABB-4251-8E35-82037577E1A9@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) 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 Dick Hardt wrote: >> 2) Only call the remote site once to generate a shared secret and >> then use the secret to verify signatures coming from that site. >> This would be akin to openid's associate mode. > > I think having a shared secret mode is a good option for improving > performance. Just as in OpenID, having it as an option rather then a > requirement is best as it requires state management and additional > overhead if little interaction between that Homesite and Membersite. > Note that it does not solve DoS since bad server can repeatedly fail > to provide shared secret. > >> 3) Use Phillip's suggestion of SRV records as a discovery mechanism, >> instead of looking up the persona-url. > > Does not solve DoS as bad server can withhold returning SRV records. I agree that the above two suggestions do not eliminate the possibility of DoS. The intent behind the suggestions was that they should make it easier to detect/protect against a DoS. The thinking being that fewer calls need to be made during normal operation to remote sites. The membersite only needs to establish a shared secret or lookup a homesites SRV record once. If it finds that many requests are waiting for shared secrets or SRV record responses it can abort further requests for these items until the backlog has cleared. It can, however, still continue normal operations to homesites with which it already shares a secret and whose SRV record has been cached. > Given that we have not got a WG started yet, I'm wondering if we are > getting ahead of ourselves though? Point taken, apologies, Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 10 12:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlP9-00039v-P1; Fri, 10 Mar 2006 12:27:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHlP8-00039q-Ms for dix@ietf.org; Fri, 10 Mar 2006 12:27:54 -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 1FHlP8-0006F1-3U for dix@ietf.org; Fri, 10 Mar 2006 12:27:54 -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 k2AHRpdJ047584 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 10 Mar 2006 09:27:52 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44118CDE.8010408@gmail.com> References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> <9861ABE3-BABB-4251-8E35-82037577E1A9@sxip.com> <44118CDE.8010408@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23AE4A33-3480-4CBA-8B86-7B66520298EF@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] DoS in dmd0 Date: Fri, 10 Mar 2006 09:27:53 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 10-Mar-06, at 6:27 AM, Robert Yates wrote: > Dick Hardt wrote: > >>> 2) Only call the remote site once to generate a shared secret >>> and then use the secret to verify signatures coming from that >>> site. This would be akin to openid's associate mode. >> >> I think having a shared secret mode is a good option for >> improving performance. Just as in OpenID, having it as an option >> rather then a requirement is best as it requires state management >> and additional overhead if little interaction between that >> Homesite and Membersite. Note that it does not solve DoS since >> bad server can repeatedly fail to provide shared secret. >> >>> 3) Use Phillip's suggestion of SRV records as a discovery >>> mechanism, instead of looking up the persona-url. >> >> Does not solve DoS as bad server can withhold returning SRV records. > > I agree that the above two suggestions do not eliminate the > possibility of DoS. The intent behind the suggestions was that > they should make it easier to detect/protect against a DoS. The > thinking being that fewer calls need to be made during normal > operation to remote sites. The membersite only needs to establish > a shared secret or lookup a homesites SRV record once. If it finds > that many requests are waiting for shared secrets or SRV record > responses it can abort further requests for these items until the > backlog has cleared. It can, however, still continue normal > operations to homesites with which it already shares a secret and > whose SRV record has been cached. Similiarly, a Homesite that takes a long time to respond or does not respond can be logged and the Membersite could prompt the user when that Homesite is used and ask them if they really want to use that Homesite, or ask the user for another Homesite. Just as the SRV record is cached, the the Homesite and persona-url document could be cached using standard HTTP caching or some caching meta data in the document. There is lots more to discuss here. Please don't interpret my comments that I think dmd0 is *the* way to solve the problem. Hopefully we will get a WG so that more people are looking at the solution space. > >> Given that we have not got a WG started yet, I'm wondering if we >> are getting ahead of ourselves though? > > Point taken, apologies, None needed. Good discussion. I think it is a good indication that a WG would make sense! :-) -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 10 15:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHo0z-00072t-A6; Fri, 10 Mar 2006 15:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHo0M-0006VC-9I for dix@ietf.org; Fri, 10 Mar 2006 15:14:30 -0500 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHnm9-00024B-8s for dix@ietf.org; Fri, 10 Mar 2006 14:59:51 -0500 Received: from THayes0993@aol.com by imo-d03.mx.aol.com (mail_out_v38_r7.3.) id l.208.140c67ea (15898) for ; Fri, 10 Mar 2006 14:59:41 -0500 (EST) Received: from FWM-M19 (fwm-m19.webmail.aol.com [64.12.168.83]) by air-id09.mx.aol.com (vx) with ESMTP id MAILINID91-3e1a4411daad35b; Fri, 10 Mar 2006 14:59:41 -0500 Date: Fri, 10 Mar 2006 14:59:41 -0500 Message-Id: <8C812944DEA9598-12C0-1C94C@FWM-M19.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> <8C811F6304BB8F5-1140-164@FWM-R33.sysops.aol.com> <4410F1F1.50709@gmail.com> Received: from 10.169.155.114 by FWM-M19.sysops.aol.com (64.12.168.83) with HTTP (WebMailUI); Fri, 10 Mar 2006 14:59:41 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <4410F1F1.50709@gmail.com> X-Mailer: AOL WebMail 15106 Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0) MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 64.12.168.83 X-Spam-Flag: NO X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1050970489==" Errors-To: dix-bounces@ietf.org --===============1050970489== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C812944DEA9598_12C0_1BB4F_FWM-M19.sysops.aol.com" ----------MailBlocks_8C812944DEA9598_12C0_1BB4F_FWM-M19.sysops.aol.com Content-Type: text/plain; charset="us-ascii" What I meant by "most basic level" was storage and transfer of attributes asserted by the user. You could design a DIX protocol where that is the only service provided. In that case, there is no need for verification. From their responses, I think both Dick and Rob agree with this. To summarize: a DIX protocol could be defined that allowed the signature to be optional in the Exchange Process. This protocol would support transfer of self-asserted attributes. The Verification Process would not be required. This eliminates the need for the membersite to communicate with an arbitrary (untrusted?) homesite, and eliminates a potential DoS problem. I know that there are many times that attributes cannot be self-asserted. Carl Ellison made the case for that many years ago in his SPKI proposals - and I'm sure he wasn't first or last to do so. In those cases, it's clearly important to determine who made the assertion, whether they can be trusted, and whether the assertion is valid. Verification will be necessary in this case. However, as Phillip pointed out, a DoS problem is not likely to last very long in this case. The membersite will just stop trusting the homesite to make assertions. Terry Hayes AOL Corp. -----Original Message----- From: Robert Yates To: Digital Identity Exchange Sent: Thu, 09 Mar 2006 22:26:41 -0500 Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0) thayes0993@aol.com wrote: > The thread on DoS in dmd0 got me thinking about the meaning of the > verification step in dmd0. As stated in that thread, the verification > step might be a concern, since a membersite may be blocking on a > response from an unknown homesite. I started to think about > eliminating the verification (and the signature that goes with it). > What requirement is the verification step meeting? > > At the most basic level, a DIX protocol is simply providing a > convenient way to transfer a set of self-asserted attributes from the > user to the membersite - by way of the homesite. In this model the > homesite is simply storing the attributes on the user behalf and, > consistantly with Identity Law #1, revealing them only with the user's > consent. It does not do any checking that they correctly represent > the user in any way. > > At this level the only thing the signature means is "I sent this exact > set of attributes because the user asked me to." This just doesn't > seem very useful to the membersite. The entire set of attributes > could be replaced by a MITM that runs its own homesite, or that has an > account at the specified homesite. > > Can we agree that for this level of requirement, the signature and > verification are not required? Am not sure that I agree with this. There are instances where it is important whom the homesite is i.e. who is making the assertion about the attributes. I also don't believe that the attributes are always self-asserted and have been assuming that a user probably has many sites that assert attributes about the user and act as homesites, e.g. my bank, my state, etc. A classic example is the driving license analogy. The membersite wants to know how old the user is. They are not going to accept an assertion about the users age from any homesite. It has to be from some "homesite" that they trust, in my case, as I live in mass, probably "http://www.mass.gov". For these cases they need the verification step. I agree that there are many instances where the verification step is not required, but I think it is important step for many more attributes than just the persona-url. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ----------MailBlocks_8C812944DEA9598_12C0_1BB4F_FWM-M19.sysops.aol.com Content-Type: text/html; charset="us-ascii"
What I meant by "most basic level" was storage and transfer of attributes asserted by the user.  You could design a DIX protocol where that is the only service provided.  In that case, there is no need for verification.  From their responses, I think both Dick and Rob agree with this.
 
To summarize:  a DIX protocol could be defined that allowed the signature to be optional in the Exchange Process.  This protocol would support transfer of self-asserted attributes.  The Verification Process would not be required.  This eliminates the need for the membersite to communicate with an arbitrary (untrusted?) homesite, and eliminates a potential DoS problem.
 
I know that there are many times that attributes cannot be self-asserted.  Carl Ellison made the case for that many years ago in his SPKI proposals - and I'm sure he wasn't first or last to do so.  In those cases, it's clearly important to determine who made the assertion, whether they can be trusted, and whether the assertion is valid.  Verification will be necessary in this case.  However, as Phillip pointed out, a DoS problem is not likely to last very long in this case.  The membersite will just stop trusting the homesite to make assertions.
 
Terry Hayes
AOL Corp.
 
-----Original Message-----
From: Robert Yates <robyates70@gmail.com>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Thu, 09 Mar 2006 22:26:41 -0500
Subject: Re: What does verification mean? (was Re: [dix] DoS in dmd0)

thayes0993@aol.com wrote: 
 
> The thread on DoS in dmd0 got me thinking about the meaning of the > verification step in dmd0. As stated in that thread, the verification > step might be a concern, since a membersite may be blocking on a > response from an unknown homesite. I started to think about > eliminating the verification (and the signature that goes with it). > What requirement is the verification step meeting? 
> > At the most basic level, a DIX protocol is simply providing a > convenient way to transfer a set of self-asserted attributes from the > user to the membersite - by way of the homesite. In this model the > homesite is simply storing the attributes on the user behalf and, > consistantly with Identity Law #1, revealing them only with the user's > consent. It does not do any checking that they correctly represent > the user in any way. 
> > At this level the only thing the signature means is "I sent this exact > set of attributes because the user asked me to." This just doesn't > seem very useful to the membersite. The entire set of attributes > could be replaced by a MITM that runs its own homesite, or that has an > account at the specified homesite. 
> > Can we agree that for this level of requirement, the signature and > verification are not required? 
 
Am not sure that I agree with this. There are instances where it is important whom the homesite is i.e. who is making the assertion about the attributes. I also don't believe that the attributes are always self-asserted and have been assuming that a user probably has many sites that assert attributes about the user and act as homesites, e.g. my bank, my state, etc. 
 
A classic example is the driving license analogy. The membersite wants to know how old the user is. They are not going to accept an assertion about the users age from any homesite. It has to be from some "homesite" that they trust, in my case, as I live in mass, probably "http://www.mass.gov". For these cases they need the verification step. 
 
I agree that there are many instances where the verification step is not required, but I think it is important step for many more attributes than just the persona-url. 
 
Rob 
 
_______________________________________________ 
dix mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 
----------MailBlocks_8C812944DEA9598_12C0_1BB4F_FWM-M19.sysops.aol.com-- --===============1050970489== 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 --===============1050970489==-- From dix-bounces@ietf.org Fri Mar 10 15:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHoHn-0004eY-8T; Fri, 10 Mar 2006 15:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHoHm-0004bA-Ad for dix@ietf.org; Fri, 10 Mar 2006 15:32:30 -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 1FHoHk-0002uJ-OK for dix@ietf.org; Fri, 10 Mar 2006 15:32:30 -0500 Received: from [192.168.1.65] (adsl-69-106-253-68.dsl.pltn13.pacbell.net [69.106.253.68]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2AKWQ4v057280 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 10 Mar 2006 12:32:27 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <8C812944DEA9598-12C0-1C94C@FWM-M19.sysops.aol.com> References: <198A730C2044DE4A96749D13E167AD3797CD9B@MOU1WNEXMB04.vcorp.ad.vrsn.com> <441093A5.40005@gmail.com> <8C811F6304BB8F5-1140-164@FWM-R33.sysops.aol.com> <4410F1F1.50709@gmail.com> <8C812944DEA9598-12C0-1C94C@FWM-M19.sysops.aol.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A569597-FEB9-4DA7-A3E3-01DE400199A7@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Date: Fri, 10 Mar 2006 12:32:26 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [dix] Re: What does verification mean? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 10-Mar-06, at 11:59 AM, thayes0993@aol.com wrote: > What I meant by "most basic level" was storage and transfer of > attributes asserted by the user. You could design a DIX protocol > where that is the only service provided. In that case, there is no > need for verification. From their responses, I think both Dick and > Rob agree with this. I think you've teased out a simple but important point there Terry. > To summarize: a DIX protocol could be defined that allowed the > signature to be optional in the Exchange Process. This protocol > would support transfer of self-asserted attributes. The > Verification Process would not be required. This eliminates the > need for the membersite to communicate with an arbitrary > (untrusted?) homesite, and eliminates a potential DoS problem. I'm interested in the idea that a useful protocol could be defined just for moving identity data items around. And then those could be either self-asserted attribute values or signed claims, and there could be multiple ways of encoding a claim and multiple ways of verifying that claim. In these terms, in dmd0, we have the HS generating an authentication claim, which is encoded in some message parameters, and then verified via a call-back mechanism. It might have been interesting for us to have taken a more generic approach and to have defined that as a simple-claim-verified-by-callback mechanism layered on top of the protocol that could have been used for other things. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 11:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCQB-00082G-9g; Tue, 14 Mar 2006 11:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCQA-00082B-Oi for dix@ietf.org; Tue, 14 Mar 2006 11:30:54 -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 1FJCQ8-0006Vd-EH for dix@ietf.org; Tue, 14 Mar 2006 11:30:54 -0500 Received: from [151.155.8.71] (wifi.provo.novell.com [192.94.118.227]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2EGUolq098138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 08:30:51 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <80779A94-32C5-48D6-A2EE-32C5F08FC404@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 14 Mar 2006 08:30:48 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [dix] draft-merrells-dix-01.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 I've reflected the feedback from the list on dmd0 into a revised draft... http://dixs.org/index.php/Draft-merrells-dix-01.txt Thanks for your comments. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 11:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCUv-0001dL-RR; Tue, 14 Mar 2006 11:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCUu-0001bj-Sx for dix@ietf.org; Tue, 14 Mar 2006 11:35:48 -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 1FJCUt-0006ZQ-Hc for dix@ietf.org; Tue, 14 Mar 2006 11:35:48 -0500 Received: from [151.155.8.71] (wifi.provo.novell.com [192.94.118.227]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2EGZhYc098419 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 08:35:44 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <81FC6941-9953-451F-B334-827310AB2E4F@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 14 Mar 2006 08:35:43 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [dix] dmd1 code X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 the interests of the ietf mantra... 'running code and rough consensus'... here's some code. Sxip has released development kits that implement dmd1: http://sxip.org/index.php?title=Downloads And there are some sample endpoints Sxip are hosting for people to play with: http://sxip.org/index.php/Community And Sxip have built a sample application called 'Sxore': http://sxore.com/ Any comments on DIX and dmd1 should be to this list, anything wrt Sxip and their code/endpoints/apps should be sent to dev@sxip.org. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 12:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDXE-0001cY-SG; Tue, 14 Mar 2006 12:42:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDXD-0001cT-ND for dix@ietf.org; Tue, 14 Mar 2006 12:42:15 -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 1FJDXC-0008OT-5P for dix@ietf.org; Tue, 14 Mar 2006 12:42:15 -0500 Received: from [151.155.8.71] (wifi.provo.novell.com [192.94.118.227]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2EHgA7S000956 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 09:42:13 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <734C0A42-F573-4C15-9076-C9CA65D4CDB7@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 14 Mar 2006 09:42:09 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dix] dmd1 & SAML X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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've been playing with describing a digitally signed third-party claim in SAML and moving that over dmd1. I've mapped what I think should be in a claim into the SAMLv2 schema... but I'm not sure it's exactly right. Also, I believe it's out of scope for DIX, but I want to ensure that this functionality can be layered on top. How about an off-list conversation to discuss this? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 13:53:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEeU-0000zn-18; Tue, 14 Mar 2006 13:53:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEeT-0000zi-36 for dix@ietf.org; Tue, 14 Mar 2006 13:53:49 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJEeR-0001qn-Sl for dix@ietf.org; Tue, 14 Mar 2006 13:53:49 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k2EIrl6g026725 for ; Tue, 14 Mar 2006 13:53:47 -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 k2EIrg114744 for ; Tue, 14 Mar 2006 13:53:42 -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 k2EIrehg010620 for ; Tue, 14 Mar 2006 13:53:41 -0500 Message-ID: <44171134.1000302@redhat.com> Date: Tue, 14 Mar 2006 10:53:40 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] dmd1 & SAML References: <734C0A42-F573-4C15-9076-C9CA65D4CDB7@sxip.com> In-Reply-To: <734C0A42-F573-4C15-9076-C9CA65D4CDB7@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1133867271==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1133867271== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010505000508070204010801" This is a cryptographically signed message in MIME format. --------------ms010505000508070204010801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Merrells wrote: > > I've been playing with describing a digitally signed third-party > claim in SAML > and moving that over dmd1. I've mapped what I think should be in a claim > into the SAMLv2 schema... but I'm not sure it's exactly right. Also, > I believe > it's out of scope for DIX, but I want to ensure that this > functionality can be > layered on top. How about an off-list conversation to discuss this? Is it really out of scope? DIX would need to be capable of carrying such traffic so I think it is useful to demonstrate methods of doing so, if for nothing else than to be sure that it can be done. -- Pete --------------ms010505000508070204010801 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMTQxODUzNDBaMCMGCSqGSIb3DQEJBDEWBBQ90PMIu6rH/1VP hqiTXDDkJv4ykDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAufP6bXXc1dtYkvBXrYrVDWEgtcRg9wEwG67YgxmF5jlT4PDAsm2L1UWilywl etgpAkuvFxwDZs6esv37365oUSBF1I0FuhDvciTGb5Ud4R1O3LsWIyDb6LPouXOXaeFZXX63 4DMpbm8Cct7juVpW+85ZEsaRS5KpgUyOu//jYLcyY1R1YlndlVTKtgLb/0UiJOYfyc+5TBj9 y41YtQiG/68Br+ZHS4UKTNOnaxFy3jthz+dzzabroPw9wQDRLOAJRjtqiN+QfpsHX3MwzxZv yDFQMPffiq84TdFjhIJL4ftFF9G81fv+BpNF7WTNAyfEeHvpl3Cy9CNyk4jxJiJupAAAAAAA AA== --------------ms010505000508070204010801-- --===============1133867271== 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 --===============1133867271==-- From dix-bounces@ietf.org Tue Mar 14 14:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEv7-0008RJ-K7; Tue, 14 Mar 2006 14:11:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJEv6-0008RE-64 for dix@ietf.org; Tue, 14 Mar 2006 14:11:00 -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 1FJEv4-0002YX-KF for dix@ietf.org; Tue, 14 Mar 2006 14:10:59 -0500 Received: from [151.155.8.71] (wifi.provo.novell.com [192.94.118.227]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2EJAtJK004591 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 11:10:57 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44171134.1000302@redhat.com> References: <734C0A42-F573-4C15-9076-C9CA65D4CDB7@sxip.com> <44171134.1000302@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] dmd1 & SAML Date: Tue, 14 Mar 2006 11:10:54 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com 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 14-Mar-06, at 10:53 AM, Pete Rowley wrote: > John Merrells wrote: > >> >> I've been playing with describing a digitally signed third-party >> claim in SAML >> and moving that over dmd1. I've mapped what I think should be in a >> claim >> into the SAMLv2 schema... but I'm not sure it's exactly right. >> Also, I believe >> it's out of scope for DIX, but I want to ensure that this >> functionality can be >> layered on top. How about an off-list conversation to discuss this? > > Is it really out of scope? DIX would need to be capable of > carrying such traffic so I think it is useful to demonstrate > methods of doing so, if for nothing else than to be sure that it > can be done. We'll that's my intent, I'm just not sure the details of the conversation should be here. Here I'd like to focus on the moving things about aspects without worrying too much about what the things are. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 15:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJGcY-0007gd-Gw; Tue, 14 Mar 2006 15:59:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJGcX-0007gY-M5 for dix@ietf.org; Tue, 14 Mar 2006 15:59: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 1FJGcW-0005Of-88 for dix@ietf.org; Tue, 14 Mar 2006 15:59:57 -0500 Received: from [151.155.8.71] (wifi.provo.novell.com [192.94.118.227]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2EKxq2P008332 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 12:59:55 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) 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> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> Content-Transfer-Encoding: quoted-printable From: John Merrells Subject: Re: [dix] What is "identity"? Date: Tue, 14 Mar 2006 12:59:51 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) 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 I just wanted to close out a thread and check there's agreement: On 28-Feb-06, at 2:46 AM, 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 =93the identity=94, but several of them." A couple of list members (Jefsey, Dick) seconded this definition. I can go with this too, although it seems a little complex. Consensus on moving forward based on this definition? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 16:46:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJHLz-0003pj-Vr; Tue, 14 Mar 2006 16:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJHLy-0003pe-Vo for dix@ietf.org; Tue, 14 Mar 2006 16:46:54 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJHLx-0006YH-Nv for dix@ietf.org; Tue, 14 Mar 2006 16:46:54 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k2ELkrZc027082 for ; Tue, 14 Mar 2006 16:46:53 -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 k2ELkq108424 for ; Tue, 14 Mar 2006 16:46:52 -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 k2ELkphg020231 for ; Tue, 14 Mar 2006 16:46:51 -0500 Message-ID: <441739C9.6090102@redhat.com> Date: Tue, 14 Mar 2006 13:46: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: [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> <44042A05.30208@algroup.co.uk> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> In-Reply-To: <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0257828867==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0257828867== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010403030307000606040207" This is a cryptographically signed message in MIME format. --------------ms010403030307000606040207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit John Merrells wrote: > > I just wanted to close out a thread and check there's agreement: > > On 28-Feb-06, at 2:46 AM, 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." > > "An identity is any subset of attributes of an individual which *uniquely* identifies *that* individual *in* any *one *set of individuals. So usually there is no such thing as “the identity”, but several of them." Changed text to be more precise. Seems a reasonable working definition. -- Pete --------------ms010403030307000606040207 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMTQyMTQ2NDlaMCMGCSqGSIb3DQEJBDEWBBSkbZjHe/b/+Wys q4b8/rcDK7iJyTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAmyTiBluv5FaxlT83OLOP1GZlBSRavJXeGh4NpYYbsJdq54LyRI3LX5Gde8GD 7uLj4DXgfV0+zbfadpdD3Q5mQN0OJIltqEA/N7QTQo6mGBi1e+Qmb5UgHJ0vAwWq7KmXjdcL dY63gBC6sI7Rv4cL4dCioJMoLrI3UfzSkZkBqliZvAxnfWyyL/Vw47mePfZAw8DmDuvYaphs 400HZDmVeGqbwz4eBsbtzvwN2jUglp9yW2lUwgHdNCBnNpRIJP8kAdrp+8OUHN5tB8OyP1+m lz2k1eQ0QG1YPzXo0W+Jb7P8CqwrOvteQA0Hg0NmQTEcj7OIe17RoL8Ey/oXO5R8bAAAAAAA AA== --------------ms010403030307000606040207-- --===============0257828867== 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 --===============0257828867==-- From dix-bounces@ietf.org Tue Mar 14 17:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJHgh-0005wn-C4; Tue, 14 Mar 2006 17:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJHgg-0005wi-53 for dix@ietf.org; Tue, 14 Mar 2006 17:08:18 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJHge-0007Po-QL for dix@ietf.org; Tue, 14 Mar 2006 17:08:18 -0500 Received: from [192.168.0.2] (adsl-71-131-40-72.dsl.sntc01.pacbell.net [71.131.40.72]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2EM8kSk017930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Mar 2006 14:08:47 -0800 Message-ID: <44173EC8.50602@dcrocker.net> Date: Tue, 14 Mar 2006 14:08:08 -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] 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> <44042A05.30208@algroup.co.uk> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> <441739C9.6090102@redhat.com> In-Reply-To: <441739C9.6090102@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k2EM8kSk017930 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 any subset of attributes of an individual which *unique= ly* > identifies *that* individual *in* any *one *set of individuals. So usua= lly > there is no such thing as =93the identity=94, but several of them." >=20 > Changed text to be more precise. I think it's an improvement. However the problem with this sort of a definition is that I have no idea= how to=20 apply it to any standards effort that is useful. In other words, a definition like this cannot be made in isolation. It n= eeds to=20 be made in a context of other definitions and requirements, with enough o= f a=20 proposal to convince folks that it can be practical to implement and use. d/ --=20 Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 14 17:32:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJI4Q-0001BB-RS; Tue, 14 Mar 2006 17:32:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJI4N-00016V-6M for dix@ietf.org; Tue, 14 Mar 2006 17:32:47 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJI4L-00087h-Nl for dix@ietf.org; Tue, 14 Mar 2006 17:32:47 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k2EMWiRg013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Mar 2006 14:32:44 -0800 X-Auth-Received: from D-140-142-21-2.dhcp4.washington.edu (D-140-142-21-2.dhcp4.washington.edu [140.142.21.2]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k2EMWiuu017732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Mar 2006 14:32:44 -0800 Date: Tue, 14 Mar 2006 14:32:59 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Digital Identity Exchange Subject: Re: [dix] What is "identity"? In-Reply-To: <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> Message-ID: 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> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1977352811-1142371964=:2605" Content-ID: X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1977352811-1142371964=:2605 Content-Type: TEXT/PLAIN; CHARSET=utf-8; FORMAT=flowed Content-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mxout2.cac.washington.edu id k2EMWiRg013872 > Consensus on moving forward based on this definition? Eh, no. This definition encapsulates the unfortunate confabulation of "identity"=20 and "identifier" that appears to me to be the cause of much of the=20 confusion in discussions about this stuff. An identity is any subset of attributes of an individual which identifies this individual within any set of individuals. Set A is the set of all people in the building I'm in now. We're all=20 employees of the University of Washington. So my attribute "employee of=20 the UW" doesn't identify me within Set A, hence is not part of my identit= y=20 by this defintion. Set B is the set of people attending next week's bar=20 bof. Only one of them, me, is a UW employee, so my attribute "employee o= f=20 the UW" does distinguish me, hence is part of my identity. So when I sen= d=20 "UW employee" on the wire, am I sending "identity information" or not? This is a useless definition for doing a protocol design, because it's=20 only meaningful in the context of a particular interpreting party (ie, th= e=20 party that wants to "identify" (more accurately, distinguish) one=20 individual from another in a set they are using (and it's especially=20 useless because that party isn't even referred to in the definition).=20 What's useful in a protocol design is a definition that refers to the=20 information being transmitted. In fact the useful definition is the one that has already been promoted=20 by Kim Cameron and subjected to endless discussion in the identitygang=20 context (http://www.identitygang.org/DigitalIdentity): Digital Identity Definition: The digital representation of a set of Claims made by one Party about itself or another Digital Subject. where I would modify this slightly and say that it is exactly the=20 definition of "digital identity exchange": The transmission of digital representation of a set of Claims made by one Party about itself or another Digital Subject, to one or more othe= r Parties. which is supposedly what we're here to talk about. The distinction that the "subset of attributes" definition is grasping at= =20 but failing to address is that between (1) the entire mass of "stuff abou= t=20 me" that constitutes a Subject's (aka entity's/individual's) identity=20 (subsets of which constitute an identity in any particular context), and=20 (2) those attributes that are specifically designed to distinguish one=20 Subject from another, which we call "identifiers" (eg username, UUID, SSN= ,=20 Subject Name, etc). Authentication operations have traditionally involve= d=20 the use of identifiers, so people tend to associate them with "identity",= =20 and obviously identifier attributes are often useful in any real identity= =20 system. But in the modern world we observe that identifiers may or may not be=20 needed in any particular act of system access or personal info exchange,=20 hence the importance of opening up "digital identity exchange" to be=20 potentially any "stuff about me". That is, in many cases the relying=20 party doesn't need "attributes that identify this individual within a set= =20 of individuals", it just needs enough info to do its job. This is why modern systems like SAML put emphasis on including attributes= =20 in authentication operations, and define identifier values that=20 specifically mean "not a useful identifier for you" (see section 8.3.8 of= =20 SAML 2.0 Core). - RL "Bob" On Tue, 14 Mar 2006, John Merrells wrote: > > I just wanted to close out a thread and check there's agreement: > > On 28-Feb-06, at 2:46 AM, 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 =93the identity=94, but several of them." > > A couple of list members (Jefsey, Dick) seconded this definition. > > I can go with this too, although it seems a little complex. > > Consensus on moving forward based on this definition? > > John > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > --8323328-1977352811-1142371964=:2605 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 --8323328-1977352811-1142371964=:2605-- From dix-bounces@ietf.org Tue Mar 14 20:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJKZK-0007So-HO; Tue, 14 Mar 2006 20:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJKZJ-0007Sj-Jp for dix@ietf.org; Tue, 14 Mar 2006 20:12:53 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJKZI-0004a3-D4 for dix@ietf.org; Tue, 14 Mar 2006 20:12:53 -0500 Received: from [127.0.0.1] (stdhcp-197.va.neustar.com [10.31.13.197]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2F1ClBY006379 for ; Wed, 15 Mar 2006 01:12:52 GMT Message-ID: <44176A07.5050501@neustar.biz> Date: Tue, 14 Mar 2006 17:12:39 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] dmd1 & SAML References: <734C0A42-F573-4C15-9076-C9CA65D4CDB7@sxip.com> <44171134.1000302@redhat.com> 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: > > Here I'd like to focus on the moving things about aspects without > worrying too much about what the things are. Well, that -- not worrying about "what the things are" -- doesn't work when one is designing a security protocol (which is what an identity protocol is). What is in the objects being exchanged, and the semantics attached to it/them, are of utmost importance to the meaning of the protocol. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 15 00:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOH6-000890-6G; Wed, 15 Mar 2006 00:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOH5-00088v-3k for dix@ietf.org; Wed, 15 Mar 2006 00:10:19 -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 1FJOH0-00033B-NZ for dix@ietf.org; Wed, 15 Mar 2006 00:10:19 -0500 Received: from [172.28.171.153] ([12.14.65.2]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2F5AC0j024592 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 21:10:13 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <44176A07.5050501@neustar.biz> References: <734C0A42-F573-4C15-9076-C9CA65D4CDB7@sxip.com> <44171134.1000302@redhat.com> <44176A07.5050501@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CA08442-CE45-48A2-AD64-2933E128B976@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] dmd1 & SAML Date: Tue, 14 Mar 2006 21:10:00 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 14-Mar-06, at 5:12 PM, Jeff Hodges wrote: > Well, that -- not worrying about "what the things are" -- doesn't > work when one is designing a security protocol (which is what an > identity protocol is). What is in the objects being exchanged, and > the semantics attached to it/them, are of utmost importance to the > meaning of the protocol. Not sure where you're coming from there. By analogy LDAP moves attributes around and we don't concern ourselves in the protocol specification with what they actually are. I think DIX can achieve the same positive effect.... it moves attributes from the user's identity agent to some consuming website. I'm thinking that that attribute value could be a SAML token, in this case an attribute assertion. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 15 00:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOXg-0007CD-Sy; Wed, 15 Mar 2006 00:27:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJOXf-0007Bi-Nx for dix@ietf.org; Wed, 15 Mar 2006 00:27: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 1FJOXd-0003DP-J0 for dix@ietf.org; Wed, 15 Mar 2006 00:27:27 -0500 Received: from [172.28.171.153] ([12.14.65.2]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2F5RJFl024827 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Mar 2006 21:27:20 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 14 Mar 2006 21:27:18 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Subject: [dix] problem / goals / benefits / requirements / use cases X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org OK, I just had a long plane ride, so I dumped all my thoughts about=20=20 the above into a single message. The problem statement is actually from the most recent draft of the=20=20 proposed charter. Everything else came from reading through all the DIX messages and=20=20 from my head. I hope that it represents our collective thoughts... but I'm sure it=20=20 doesn't and so I'm sure you'll be letting me know. :) John ---- Problem Statement The Internet is host to many online information sources and services.=20=20 There is a growing demand for users to identify, and provide=20=20 information about themselves. Users bear the burden of managing their=20=20 own authentication materials and repeatedly providing their identity=20=20 information. Signing in to web pages and completing user registration=20=20 forms is an example. Goals Benefit Internet Users Protocol adoption Benefits Benefits to the End User Browsing Efficiency =96 Reuse of Identity Data and authentication Browsing Efficiency =96 Consistency of User Experience for providing data Reuse of Identity Data =96 Less data entry Reuse of Authentication =96 Single Sign-On Reuse of an Identifier =96 Persona and reputation building Security =96 Consistent user experience Security =96 Stronger authentication more viable Privacy =96 Choice over what is stored where and released to whom Privacy =96 Choice over the degree of relationship with a site:=20=20 anonymous, pseudo-anonymous, or public. [todo: see terms in Ben=92s=20=20 referenced document.] Reuse of Verification Processes =96 By moving third-party claims=20=20 between authority and site Benefits to the Website Operator Data quality, quantity, and richness. Lower latency in workflows for verifying self asserted data. Higher conversion rates Requirements Requirements for Benefits Goal Presentation of identity data from user to site Storage of identity data from site to user Identifier scheme enables individual to aggregate data Identifier scheme enables individual to create one-to-one relationships Authentication that the user owns an identifier Separation of identifier from information storage User choice of what information is released to whom No predetermined relationship between the site and the Identity Agent No need to provide identifier with the identity data. No need for the site to store the identity data between sessions Separation of authentication from resource Requirements for Adoption Goal Meets the =91Seven Laws of an Identity Architecture=92 Zero code on the browser at a minimum Minimal Website code Works with existing Website code Secure Extensibility Reuses existing technology Definitions Beth =96 Our protagonist and a typical Internet user, but she=92s a bit=20= =20 of a geek. Identity - Ben quotes from =91Anonymity, Unlinkability,=20=20 Unobservability, Pseudonymity, and Identity Management - A=20=20 Consolidated Proposal for Terminology=92: =93An identity is any subset=20= =20 of attributes of an individual which identifies this individual=20=20 within any set of individuals. So usually there is no such thing as=20=20 "the identity", but several of them.=94 http://dud.inf.tu-dresden.de/=20 Anon_Terminology.shtml Digital Identity =96 Kim=92s definition from =91The Identity Gang=92. =93Th= e=20=20 digital representation of a set of Claims made by one Party about=20=20 itself or another Digital Subject.=94 Digital Identity =96 Bob=92s rewrite of the above. =93The transmission of= =20=20 digital representation of a set of Claims made by one Party about=20=20 itself or another Digital Subject, to one or more other Parties.=94 Identifier =96 an identifying attribute for a set of attributes. Identity Data =96 a set of attributes Identity Agent =96 An agent acting on behalf of Beth. Use Cases The use cases describe various scenarios to illustrate the benefits=20=20 of solving this problem. Some use cases are dependant upon others, so=20=20 should be perused in order. 1) Beth receives an email from a friend introducing her to a new=20=20 website, geeknews.com, a site that publishes techie news articles.=20=20 She browses the site and decides to read some articles. She sees an=20=20 IN button, which she clicks. [Insert step 1.1, called out as it=92s=20=20 reused in many use cases.] Her identity agent displays a screen=20=20 informing her that geeknews.com is requesting some data, her first=20=20 name. She enters =91Beth=92 at the prompt, provides consent and the data=20= =20 is sent to the site. [Benefits: Choice of what is stored where and=20=20 released to whom. Benefits: Consistent User Experience =96 She sees her=20= =20 agent=92s user interface every time she is asked for information.] 1.1) Her identity agent performs an authentication process to ensure=20=20 that it is representing Beth, and not an imposter. The authentication=20=20 mechanism used is implementation dependent. The identity agent may=20=20 provide the benefit of caching the authentication for the duration of=20=20 Beth=92s internet browsing session. [Benefit: Reuse of authentication,=20= =20 when coupled with other aspects provides single sign-on.] 2) Beth browses to geekdate.com, she clicks an IN button. [1.1] Her=20=20 identity agent displays a screen informing her that geekdate.com is=20=20 requesting some data, her first name. From [1] her agent already has=20=20 this data. She provides consent and the data is sent to the site.=20=20 [Benefit: Less data entry. Benefit: Reuse of identity data. Benefit:=20=20 Quality data.] 3) Beth decides to create a profile at geekdate.com. Geekdate.com=20=20 displays a registration form. One field requests a URL of a photo of=20=20 her. Beside it is a SAVE button. She enters the UTL and clicks the=20=20 button. [1.1] Her identity agent displays a screen informing her that=20=20 this data item can be stored. She provides consent and the data is=20=20 stored by her agent. [Benefit: Reuse of Identity Data. Benefits:=20=20 Enabled stateless sites that request the data they need for each=20=20 session. Benefit: Persona building. Benefit: Choice of what is stored=20=20 where.] 4) Geeknews.com offers Beth the option to build up a readership=20=20 preferences profile overtime, the benefit being that the site will=20=20 tailor its content to her interests. She decides to take up the=20=20 offer, she sees an IN button, which she clicks. [1.1] Her identity=20=20 agent displays a screen informing her that geeknews.com is requesting=20=20 some data, an Identifier. See takes options 4.1 or 4.2. She provides=20=20 consent and the data is sent to the site. [Benefit: Reuse of=20=20 authentication - Beth doesn=92t have to remember account details, such=20= =20 as username and password, for the site. Benefit: Reputation building.] 4.1) Her identity agent creates an identifier specific to her=20=20 relationship with geeknews.com. [Benefit: Privacy =96 Choice over=20=20 degree of relationship. Uni-directional identity guards against the=20=20 site correlating the data it aggregates about the identifier with=20=20 other parties beyond this relationship. ] 4.2) She selects an existing identifier that represents a subset of=20=20 her identity, which is used for a subset of the sites she has a=20=20 relationship with. [Requirement: Multiple Identifiers for a person.=20=20 Benefit: Privacy =96 Choice over degree of relationship.=20=20 Compartmentalization of identity. Easier management of identity data.=20=20 Benefit: Persona building.] 5) [Assumptions: Beth has visited geeknews and geekdate before and=20=20 has informed her identity agent that she consents to a relationship=20=20 with them.] Beth starts her day with a strong coffee and a perusal of=20=20 geeknews.com. She starts her computer and authenticates herself to=20=20 the operating system. By that authentication mechanism she has also=20=20 authenticated herself to her identity agent, as her vendor of that=20=20 system has hooked it into the operating system=92s authentication=20=20 system. She browses to geeknews.com and clicks the IN button and is=20=20 directly shown the content, no further clicks. She then browses to=20=20 geekdate.com, she clicks the IN button and is directly presented with=20=20 her profile no further clicks. [Benefits: Separation of=20=20 authentication from resource and reuse of authentication provides=20=20 single sign-on across multiple sites.] 6) Beth=92s identity agent prompts her to provide a =91spoken name=92.=20= =20 Using the multimedia capabilities of her computer she records her=20=20 spoken name; an mp3 of Beth saying =91Beth=92. She later browses to=20=20 voicebox.com, which runs a voicemail service, she opts to create an=20=20 account and the site requests some properties, amongst which is a=20=20 request for her spoken name. [Benefits: Richer Data.] 7) Beth purchases a book from an online store, as she=92s checking out=20= =20 the store makes her an offer: 10% for completion of a demographic=20=20 survey. She=92s tempted, but how many data fields are there? One=20=20 hundred! Too many to be worth the effort, but it=92s commonly requested=20= =20 data and she has already submitted most of the data during previous=20=20 exchanges with other sites. She completes the remaining fields,=20=20 saving them to her identity agent for future reuse. [Benefit Reuse of=20=20 data. Benefit: More data for the site.] 8) Beth has invested significant effort in building up a persona and=20=20 reputation around a specific identifier, her =91home=92 identifier. But,=20= =20 she has become dissatisfied with her identity agent and so decides to=20=20 switch vendors. She establishes the new agent and migrates her=20=20 identity data from the old one to the new one. She then administers=20=20 her identifier so that her new identity agent is authoritative for=20=20 authentication and provision of identity data. [Benefit: Choice of=20=20 Identity Agent - Separation of identifier from information storage.] Benefits in Detail For the End User The browsing experience is more seamless for the end user as their=20=20 identity data at their identity agent can be reused for automatic=20=20 form completion, and the consistent user experience of data entry=20=20 makes data entry more familiar. By reusing an identifier across multiple relationships the user can=20=20 build up a reputation around that identifier, which could be parlayed=20=20 into preferential treatment and privileged access. An identity agent can provide for authentication reuse across=20=20 multiple identifiers and multiple sites, providing the end user with=20=20 a single sign-on experience. Security against identity data theft can be provided to the user=20=20 through a consistent user experience, as the user is less likely to=20=20 be fooled by a fake site, as is commonly used in phishing attacks. Security can also be enhanced by identity agents that provide=20=20 stronger forms of authentication mechanisms, such as two-factor=20=20 devices. This solution makes these more expensive mechanisms more=20=20 viable as the cost is amortized across all the sites that consume=20=20 authentication claims from the agent. Individual privacy is enhanced in a number of ways. The user has=20=20 choice over the degree of relationship they have with a site:=20=20 anonymous, pseudo-anonymous, or public. The user also has choice over=20=20 what data is stored where and released to whom. The automated=20=20 presentation of data means that a site need no longer store identity=20=20 data between sessions, thus reducing the risk of a security breach at=20=20 the site revealing identity data. [todo =96 this is probably an essay=20=20 better written by Ben.] By supporting the movement of third-party claims between authority=20=20 sites and a relying party verification processes can be reused. For=20=20 example, a site could request a claim of verified email, rather than=20=20 verify the email address themselves, thus introducing latency into=20=20 the workflow by having to wait or some out-of-band process to complete. For the Website Operator When website operators request a user complete a form they introduce=20=20 a barrier to the user continuing that interaction. By automating data=20=20 release and reusing identity data a site can ask for common data=20=20 items without introducing a barrier, thus increasing the quantity of=20=20 data acquired and improving conversion ratios. Because the user can reuse their identity data across many sites they=20=20 are more likely to maintain correct data, thus improving the quality=20=20 of the data collected. By not storing identity data between sessions a site can mitigate its=20=20 risk of losing sensitive identity data and can ensure that the data=20=20 it is operating with is up to date, rather than stale. Since data provision is automated identity data items that would not=20=20 or could not normally be asked of a user can be requested. For=20=20 example, long URLs, an image, or an audio clip. By supporting the movement of third-party claims between authority=20=20 sites and a relying party verification processes can be reused. =20=20 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 15 10:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXrc-0000rE-HW; Wed, 15 Mar 2006 10:24:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXrb-0000qK-5D for dix@ietf.org; Wed, 15 Mar 2006 10:24:39 -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 1FJXrX-0004SA-IE for dix@ietf.org; Wed, 15 Mar 2006 10:24:38 -0500 Received: from [10.10.20.48] (pool-68-237-223-6.ny325.east.verizon.net [68.237.223.6]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2FFOV9Z040139 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Mar 2006 07:24:33 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: 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> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65566E24-8F39-4923-B2C3-5E34A8A8182A@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] What is "identity"? Date: Wed, 15 Mar 2006 07:24:20 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) 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 On 14-Mar-06, at 2:32 PM, RL 'Bob' Morgan wrote: > In fact the useful definition is the one that has already been > promoted by Kim Cameron and subjected to endless discussion in the > identitygang context (http://www.identitygang.org/DigitalIdentity): > > Digital Identity > > Definition: The digital representation of a set of Claims made by > one > Party about itself or another Digital Subject. > > where I would modify this slightly and say that it is exactly the > definition of "digital identity exchange": > > The transmission of digital representation of a set of Claims > made by > one Party about itself or another Digital Subject, to one or more > other > Parties. > > which is supposedly what we're here to talk about. So how do people feel about this as a definition? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 15 11:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYnq-0008Vr-Re; Wed, 15 Mar 2006 11:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYnp-0008VE-RZ for dix@ietf.org; Wed, 15 Mar 2006 11:24:49 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJYno-0006zA-Fm for dix@ietf.org; Wed, 15 Mar 2006 11:24:49 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Mar 2006 17:24:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] What is "identity"? Date: Wed, 15 Mar 2006 17:24:46 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC203FDE266@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] What is "identity"? Thread-Index: AcZIRJYj9B0O+tXqS7+UueCHWMWamwABTYsA From: "BAILLEUX Benoit RD-BIZZ-CAE" To: "Digital Identity Exchange" X-OriginalArrivalTime: 15 Mar 2006 16:24:45.0994 (UTC) FILETIME=[F91030A0:01C6484C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: John Merrells [mailto:merrells@sxip.com]=20 > Sent: Wednesday, March 15, 2006 4:24 PM >=20 > On 14-Mar-06, at 2:32 PM, RL 'Bob' Morgan wrote: >=20 > > In fact the useful definition is the one that has already been =20 > > promoted by Kim Cameron and subjected to endless discussion in the =20 > > identitygang context (http://www.identitygang.org/DigitalIdentity): > > > > Digital Identity > > > > Definition: The digital representation of a set of Claims=20 > made by =20 > > one > > Party about itself or another Digital Subject. > > > > where I would modify this slightly and say that it is exactly the =20 > > definition of "digital identity exchange": > > > > The transmission of digital representation of a set of Claims =20 > > made by > > one Party about itself or another Digital Subject, to one=20 > or more =20 > > other > > Parties. > > > > which is supposedly what we're here to talk about. >=20 > So how do people feel about this as a definition? >=20 I feel quite good with this defintion, but I have 2 questions about it : - do you want to define just "digital identity" or "digital identity = exchange" ? - this definition seems to not imply that the "other party" can = identify uniquely the issuing party. I mean that the initial party can = provide a set of claims where nothing can be found that identify it. For = example, a set of claims conveying geographical informations don't = identifiy the party. I may be necessary (but I may be wrong or have = misunderstood the needs) to add something like that : Digital Identity Definition: The digital representation of a set of Claims made by one Party about itself or another Digital Subject. A least one of those = claims allow one or more other Parties to uniquely identifies the initial Party. Hence, another definition, less restrictive, may be needed to apply to = personal info *exchange*, as proposed by RL "Bob" Morgan. Am I totally wrong with that, or not ? sincerely, --=20 Beno=EEt BAILLEUX France T=E9l=E9com, R&D division _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 15 11:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZES-0004Re-EG; Wed, 15 Mar 2006 11:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJZEQ-0004Pm-GQ for dix@ietf.org; Wed, 15 Mar 2006 11:52:18 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJZEP-0007Yu-VG for dix@ietf.org; Wed, 15 Mar 2006 11:52:18 -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 k2FGqHYm004678 for ; Wed, 15 Mar 2006 08:52:17 -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, 15 Mar 2006 08:52:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] What is "identity"? Date: Wed, 15 Mar 2006 08:52:16 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797D2D4@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] What is "identity"? Thread-Index: AcZHtz1izA8oUnQqSses91mSdYV+CgAiu3Aw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 15 Mar 2006 16:52:17.0147 (UTC) FILETIME=[D13A24B0:01C64850] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0502527500==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0502527500== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01C64818.DC515310" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C64818.DC515310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with Bob, the term identifier is unambiguous for the semantic described, the term identity has other meanings. For example anyone who reads the Boondocks is familiar with Hughy's 'identity politics' definition of identity. Dick's membership of Star Alliance Gold is apparently central to his concept of self identity. I am all up for writing a protocol that resolves identifiers for people if that is what people want to do first. But if we are only doing that I really want to avoid terms like 'identity' altogether. > -----Original Message----- > From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu] > Sent: Tuesday, March 14, 2006 5:33 PM > To: Digital Identity Exchange > Subject: Re: [dix] What is "identity"? > > > > Consensus on moving forward based on this definition? > > Eh, no. > > This definition encapsulates the unfortunate confabulation of > "identity" > and "identifier" that appears to me to be the cause of much > of the confusion in discussions about this stuff. > > An identity is any subset of attributes of an individual which > identifies this individual within any set of individuals. > > Set A is the set of all people in the building I'm in now. > We're all employees of the University of Washington. So my > attribute "employee of the UW" doesn't identify me within Set > A, hence is not part of my identity by this defintion. Set B > is the set of people attending next week's bar bof. Only one > of them, me, is a UW employee, so my attribute "employee of > the UW" does distinguish me, hence is part of my identity. > So when I send "UW employee" on the wire, am I sending > "identity information" or not? > > This is a useless definition for doing a protocol design, > because it's only meaningful in the context of a particular > interpreting party (ie, the party that wants to "identify" > (more accurately, distinguish) one individual from another in > a set they are using (and it's especially useless because > that party isn't even referred to in the definition). > What's useful in a protocol design is a definition that > refers to the information being transmitted. > > In fact the useful definition is the one that has already > been promoted by Kim Cameron and subjected to endless > discussion in the identitygang context > (http://www.identitygang.org/DigitalIdentity): > > Digital Identity > > Definition: The digital representation of a set of Claims > made by one > Party about itself or another Digital Subject. > > where I would modify this slightly and say that it is exactly > the definition of "digital identity exchange": > > The transmission of digital representation of a set of > Claims made by > one Party about itself or another Digital Subject, to one > or more other > Parties. > > which is supposedly what we're here to talk about. > > The distinction that the "subset of attributes" definition is > grasping at but failing to address is that between (1) the > entire mass of "stuff about me" that constitutes a Subject's > (aka entity's/individual's) identity (subsets of which > constitute an identity in any particular context), and > (2) those attributes that are specifically designed to > distinguish one Subject from another, which we call > "identifiers" (eg username, UUID, SSN, Subject Name, etc). > Authentication operations have traditionally involved the use > of identifiers, so people tend to associate them with > "identity", and obviously identifier attributes are often > useful in any real identity system. > > But in the modern world we observe that identifiers may or > may not be needed in any particular act of system access or > personal info exchange, hence the importance of opening up > "digital identity exchange" to be potentially any "stuff > about me". That is, in many cases the relying party doesn't > need "attributes that identify this individual within a set > of individuals", it just needs enough info to do its job. > > This is why modern systems like SAML put emphasis on > including attributes in authentication operations, and define > identifier values that specifically mean "not a useful > identifier for you" (see section 8.3.8 of SAML 2.0 Core). > > - RL "Bob" > > On Tue, 14 Mar 2006, John Merrells wrote: > > > > > I just wanted to close out a thread and check there's agreement: > > > > On 28-Feb-06, at 2:46 AM, 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." > > > > A couple of list members (Jefsey, Dick) seconded this definition. > > > > I can go with this too, although it seems a little complex. > > > > Consensus on moving forward based on this definition? > > > > John > > > > > > _______________________________________________ > > dix mailing list > > dix@ietf.org > > https://www1.ietf.org/mailman/listinfo/dix > > > ------=_NextPart_000_0009_01C64818.DC515310 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTUxNTExNDNaMCMGCSqGSIb3DQEJBDEWBBSH gxRul4c3oNDkNRYOlVuJMgI4oDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAbf2PRAsEy0oiyKUIx+fElOImR 55Do7iS11+lRW0YL+Q7XARvXMaoRJv1hst/fX9tcPL6O7stePtRYqOJm6PPKXFHXwAkUMPqSkfyc dejiDeWRmLUdjYaVrVXYBsw8MHvVCume5eGatamG+pEblEnibmOEBN2iY5XrDhJDKolQ6QAAAAAA AA== ------=_NextPart_000_0009_01C64818.DC515310-- --===============0502527500== 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 --===============0502527500==-- From dix-bounces@ietf.org Fri Mar 17 03:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAP5-0000Gf-GL; Fri, 17 Mar 2006 03:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAP4-0000Ga-Mn for dix@ietf.org; Fri, 17 Mar 2006 03:33: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 1FKAP0-00061J-AZ for dix@ietf.org; Fri, 17 Mar 2006 03:33:43 -0500 Received: from [192.168.1.100] (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 k2H8Xekh008677 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 00:33:40 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.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> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <623CD8DD-8D87-4943-84DA-9C165A2F780E@sxip.com> Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Fri, 17 Mar 2006 00:33:38 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com 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 don't like it all that much, wonder if we should kill using the term=20=20 that much? ... but the statement really does not mean much since we=20=20 do not want it to mean "uniquely" identifies the user On 14-Mar-06, at 12:59 PM, John Merrells wrote: > > I just wanted to close out a thread and check there's agreement: > > On 28-Feb-06, at 2:46 AM, 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 =93the identity=94, but several of them." > > A couple of list members (Jefsey, Dick) seconded this definition. > > I can go with this too, although it seems a little complex. > > Consensus on moving forward based on this definition? > > John > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 03:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKARR-0001KT-FH; Fri, 17 Mar 2006 03:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKARQ-0001F6-6H for dix@ietf.org; Fri, 17 Mar 2006 03:36:12 -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 1FKARN-000639-PH for dix@ietf.org; Fri, 17 Mar 2006 03:36:12 -0500 Received: from [192.168.1.100] (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 k2H8a8Sd008757 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 00:36:08 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <623CD8DD-8D87-4943-84DA-9C165A2F780E@sxip.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> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> <623CD8DD-8D87-4943-84DA-9C165A2F780E@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Fri, 17 Mar 2006 00:36:07 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 am a spas. Hit send while still reading the thread, please ignore=20=20 the previous message. On 17-Mar-06, at 12:33 AM, Dick Hardt wrote: > don't like it all that much, wonder if we should kill using the=20=20 > term that much? ... but the statement really does not mean much=20=20 > since we do not want it to mean "uniquely" identifies the user > > > On 14-Mar-06, at 12:59 PM, John Merrells wrote: > >> >> I just wanted to close out a thread and check there's agreement: >> >> On 28-Feb-06, at 2:46 AM, 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 =93the identity=94, but several of them." >> >> A couple of list members (Jefsey, Dick) seconded this definition. >> >> I can go with this too, although it seems a little complex. >> >> Consensus on moving forward based on this definition? >> >> John >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> >> > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 03:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAWY-0007Dl-1p; Fri, 17 Mar 2006 03:41:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAWW-0007Dg-MV for dix@ietf.org; Fri, 17 Mar 2006 03:41:28 -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 1FKAWU-00066v-PY for dix@ietf.org; Fri, 17 Mar 2006 03:41:28 -0500 Received: from [192.168.1.100] (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 k2H8fOKn008913 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 00:41:25 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC203FDE266@ftrdmel3.rd.francetelecom.fr> References: <941BA0BF46DB8F4983FF7C8AFE800BC203FDE266@ftrdmel3.rd.francetelecom.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63462209-51D0-4D98-AFFB-E87A9BEC323D@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Fri, 17 Mar 2006 00:41:23 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com 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 15-Mar-06, at 8:24 AM, BAILLEUX Benoit RD-BIZZ-CAE wrote: > > I feel quite good with this defintion, but I have 2 questions about > it : > - do you want to define just "digital identity" or "digital > identity exchange" ? > - this definition seems to not imply that the "other party" can > identify uniquely the issuing party. I mean that the initial party > can provide a set of claims where nothing can be found that > identify it. For example, a set of claims conveying geographical > informations don't identifiy the party. I may be necessary (but I > may be wrong or have misunderstood the needs) to add something like > that : > > Digital Identity > > Definition: The digital representation of a set of Claims made > by one > Party about itself or another Digital Subject. A least one of > those claims > allow one or more other Parties to uniquely identifies the initial > Party. I don't think you need that last sentence. I don't think you need to uniquely identify the issuing party. I may just need to prove that I am over 21, or part of Star Alliance. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 03:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAbs-0008IR-CU; Fri, 17 Mar 2006 03:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAbr-0008IM-Bz for dix@ietf.org; Fri, 17 Mar 2006 03:46:59 -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 1FKAbn-0006BJ-Qf for dix@ietf.org; Fri, 17 Mar 2006 03:46:59 -0500 Received: from [192.168.1.100] (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 k2H8kr4r009075 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 00:46:53 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: 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> <592E1BCA-560E-41AB-BE86-F4E9D91A428C@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <5743C2D5-680A-4F49-9BEF-8DCF1B68853B@sxip.com> Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Fri, 17 Mar 2006 00:46:51 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 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: , Errors-To: dix-bounces@ietf.org On 14-Mar-06, at 2:32 PM, RL 'Bob' Morgan wrote: > >> Consensus on moving forward based on this definition? > > Eh, no. I retract my previous consensus and agree with Bob's points below. I=20=20 think defining Digital Identity Exchange rather then just Identity=20=20 allows us to define what we are solving. > > This definition encapsulates the unfortunate confabulation of=20=20 > "identity" and "identifier" that appears to me to be the cause of=20=20 > much of the confusion in discussions about this stuff. > > An identity is any subset of attributes of an individual which > identifies this individual within any set of individuals. > > Set A is the set of all people in the building I'm in now. We're=20=20 > all employees of the University of Washington. So my attribute=20=20 > "employee of the UW" doesn't identify me within Set A, hence is not=20=20 > part of my identity by this defintion. Set B is the set of people=20=20 > attending next week's bar bof. Only one of them, me, is a UW=20=20 > employee, so my attribute "employee of the UW" does distinguish me,=20=20 > hence is part of my identity. So when I send "UW employee" on the=20=20 > wire, am I sending "identity information" or not? > > This is a useless definition for doing a protocol design, because=20=20 > it's only meaningful in the context of a particular interpreting=20=20 > party (ie, the party that wants to "identify" (more accurately,=20=20 > distinguish) one individual from another in a set they are using=20=20 > (and it's especially useless because that party isn't even referred=20=20 > to in the definition). What's useful in a protocol design is a=20=20 > definition that refers to the information being transmitted. > > In fact the useful definition is the one that has already been=20=20 > promoted by Kim Cameron and subjected to endless discussion in the=20=20 > identitygang context (http://www.identitygang.org/DigitalIdentity): > > Digital Identity > > Definition: The digital representation of a set of Claims made by=20=20 > one > Party about itself or another Digital Subject. > > where I would modify this slightly and say that it is exactly the=20=20 > definition of "digital identity exchange": > > The transmission of digital representation of a set of Claims=20=20 > made by > one Party about itself or another Digital Subject, to one or more=20=20 > other > Parties. > > which is supposedly what we're here to talk about. > > The distinction that the "subset of attributes" definition is=20=20 > grasping at but failing to address is that between (1) the entire=20=20 > mass of "stuff about me" that constitutes a Subject's (aka entity's/=20 > individual's) identity (subsets of which constitute an identity in=20=20 > any particular context), and (2) those attributes that are=20=20 > specifically designed to distinguish one Subject from another,=20=20 > which we call "identifiers" (eg username, UUID, SSN, Subject Name,=20=20 > etc). Authentication operations have traditionally involved the=20=20 > use of identifiers, so people tend to associate them with=20=20 > "identity", and obviously identifier attributes are often useful in=20=20 > any real identity system. > > But in the modern world we observe that identifiers may or may not=20=20 > be needed in any particular act of system access or personal info=20=20 > exchange, hence the importance of opening up "digital identity=20=20 > exchange" to be potentially any "stuff about me". That is, in many=20=20 > cases the relying party doesn't need "attributes that identify this=20=20 > individual within a set of individuals", it just needs enough info=20=20 > to do its job. > > This is why modern systems like SAML put emphasis on including=20=20 > attributes in authentication operations, and define identifier=20=20 > values that specifically mean "not a useful identifier for=20=20 > you" (see section 8.3.8 of SAML 2.0 Core). > > - RL "Bob" > > On Tue, 14 Mar 2006, John Merrells wrote: > >> >> I just wanted to close out a thread and check there's agreement: >> >> On 28-Feb-06, at 2:46 AM, 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 =93the identity=94, but several of them." >> >> A couple of list members (Jefsey, Dick) seconded this definition. >> >> I can go with this too, although it seems a little complex. >> >> Consensus on moving forward based on this definition? >> >> John >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 04:06:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAul-0007OU-Pr; Fri, 17 Mar 2006 04:06:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAuk-0007OP-5k for dix@ietf.org; Fri, 17 Mar 2006 04:06:30 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKAui-0006tR-Q5 for dix@ietf.org; Fri, 17 Mar 2006 04:06:30 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 10:06:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] What is "identity"? Date: Fri, 17 Mar 2006 10:06:26 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC2040218AE@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] What is "identity"? Thread-Index: AcZJnry1aQhaDOhiTqyLHtkwq0vx1gAAaEcA From: "BAILLEUX Benoit RD-BIZZ-CAE" To: "Digital Identity Exchange" X-OriginalArrivalTime: 17 Mar 2006 09:06:27.0503 (UTC) FILETIME=[12C46BF0:01C649A2] 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 > -----Original Message----- > From: Dick Hardt [mailto:dick@sxip.com]=20 > Sent: Friday, March 17, 2006 9:41 AM >=20 >=20 > On 15-Mar-06, at 8:24 AM, BAILLEUX Benoit RD-BIZZ-CAE wrote: > > > > I feel quite good with this defintion, but I have 2=20 > questions about =20 > > it : > > - do you want to define just "digital identity" or "digital =20 > > identity exchange" ? > > - this definition seems to not imply that the "other party" can =20 > > identify uniquely the issuing party. I mean that the initial party =20 > > can provide a set of claims where nothing can be found that =20 > > identify it. For example, a set of claims conveying geographical =20 > > informations don't identifiy the party. I may be necessary (but I =20 > > may be wrong or have misunderstood the needs) to add=20 > something like =20 > > that : > > > > Digital Identity > > > > Definition: The digital representation of a set of Claims made =20 > > by one > > Party about itself or another Digital Subject. A least one of =20 > > those claims > > allow one or more other Parties to uniquely identifies=20 > the initial > > Party. >=20 > I don't think you need that last sentence. I don't think you need to =20 > uniquely identify the issuing party. I may just need to prove that I =20 > am over 21, or part of Star Alliance. >=20 > -- Dick Ok. I suppose the goal was not well defined, or I misunderstood it. However, I understand that the required definition is not for "Digital Identity" (which, I persist to think, embed a notion of "uniqueness"), but rather for something like "exchange of parts of a digital identity". I am right ? A stable (but may be arbitrary, after all) definition of "digital identity" should be useful, when defining "exchange of parts of a digital identity". Shouldn't it ? --=20 BB _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 04:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBJa-0007wF-Qi; Fri, 17 Mar 2006 04:32:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBJZ-0007v5-G4 for dix@ietf.org; Fri, 17 Mar 2006 04:32:09 -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 1FKBJY-0007vv-5X for dix@ietf.org; Fri, 17 Mar 2006 04:32:09 -0500 Received: from [192.168.1.100] (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 k2H9W65S010197 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 01:32:06 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC2040218AE@ftrdmel3.rd.francetelecom.fr> References: <941BA0BF46DB8F4983FF7C8AFE800BC2040218AE@ftrdmel3.rd.francetelecom.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46ED1FEB-4A78-41A4-861D-1FA4B6500C2E@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Fri, 17 Mar 2006 01:32:05 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 17-Mar-06, at 1:06 AM, BAILLEUX Benoit RD-BIZZ-CAE wrote: > Ok. I suppose the goal was not well defined, or I misunderstood it. > However, I understand that the required definition is not for "Digital > Identity" (which, I persist to think, embed a notion of "uniqueness"), > but rather for something like "exchange of parts of a digital > identity". > I am right ? > A stable (but may be arbitrary, after all) definition of "digital > identity" should be useful, when defining "exchange of parts of a > digital identity". Shouldn't it ? I think of my identity as everything about me that expresses who I am. Being Canadian is part of my identity. Dick Hardt is part of my identity. Given that, a Digital Identity Exchange is a way of presenting or receiving digital representations of part of my identity with a host. Does that clarify anything or add to the confusion? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 05:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBsJ-0001qE-Sz; Fri, 17 Mar 2006 05:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBsI-0001nJ-OQ for dix@ietf.org; Fri, 17 Mar 2006 05:08:02 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBsH-0000mW-DD for dix@ietf.org; Fri, 17 Mar 2006 05:08:02 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 11:08:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] What is "identity"? Date: Fri, 17 Mar 2006 11:07:58 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC2040219A1@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] What is "identity"? Thread-Index: AcZJpaz1G5nhQh5iR3ivc6c3SoQeVQAA7XGg From: "BAILLEUX Benoit RD-BIZZ-CAE" To: "Digital Identity Exchange" X-OriginalArrivalTime: 17 Mar 2006 10:08:00.0160 (UTC) FILETIME=[ABC32A00:01C649AA] 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 > -----Original Message----- > From: Dick Hardt [mailto:dick@sxip.com]=20 > Sent: Friday, March 17, 2006 10:32 AM >=20 > On 17-Mar-06, at 1:06 AM, BAILLEUX Benoit RD-BIZZ-CAE wrote: >=20 > > Ok. I suppose the goal was not well defined, or I misunderstood it. > > However, I understand that the required definition is not=20 > for "Digital > > Identity" (which, I persist to think, embed a notion of=20 > "uniqueness"), > > but rather for something like "exchange of parts of a digital =20 > > identity". > > I am right ? > > A stable (but may be arbitrary, after all) definition of "digital > > identity" should be useful, when defining "exchange of parts of a > > digital identity". Shouldn't it ? >=20 > I think of my identity as everything about me that expresses who I am. >=20 > Being Canadian is part of my identity. >=20 > Dick Hardt is part of my identity. >=20 > Given that, a Digital Identity Exchange is a way of presenting or =20 > receiving digital representations of part of my identity with a host. >=20 > Does that clarify anything or add to the confusion? >=20 > -- Dick Yes, pretty clear. But after wandering through the initial (and now long) thread, I'm still not sure if a definition to "Identity" (and not only for "identity exchange", which seems to be clear) must be found. John Merrells has been asking for a consensus about the definition of "identity". Is it achieved ? BTW, should I stop babbling about that ? --=20 BB _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 10:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGsm-0007Ot-Ah; Fri, 17 Mar 2006 10:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGsk-0007Oo-VZ for dix@ietf.org; Fri, 17 Mar 2006 10:28:50 -0500 Received: from wproxy.gmail.com ([64.233.184.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGsi-0002ON-Ke for dix@ietf.org; Fri, 17 Mar 2006 10:28:50 -0500 Received: by wproxy.gmail.com with SMTP id 36so633947wra for ; Fri, 17 Mar 2006 07:28:48 -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=QPv1wKCaw+sfuk0HX5Mt7NeKp44SVpHU2RvmqKuQtJmFQfE1Cch295szw5aye4Fgs7HdH3LD3U/zNBaxe39yrawYhqVq3Z0qMZkPzWJLahx9vZIxOn/rCG+7qCjLRUBLccuUsNMdY77JoTcwi+WZWLQbzu/npsEjP8i6zyYFx5M= Received: by 10.54.105.17 with SMTP id d17mr81074wrc; Fri, 17 Mar 2006 07:28:48 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 14sm2304779wrl.2006.03.17.07.28.46; Fri, 17 Mar 2006 07:28:47 -0800 (PST) Message-ID: <441AD5B0.2010306@gmail.com> Date: Fri, 17 Mar 2006 10:28:48 -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: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [dix] use cases / requirements for extranet collaborations X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 One of the reasons that we are interested in DIX is that it may help our collaborative products span corporations. Before the BOF next week I wanted to jot down some use cases that we have so the discussion can see whether it thinks that these areas lie within the scope of the DIX protocol. There is a set of collaborative applications that allow a group of individuals to collaborate privately with each other. They provide a space where the individuals can post documents, discussions threads, project milestones, etc.. Access to this space is limited to members of the space, so the data is not publicly available. Examples of this kind of software include Microsoft Sharepoint (Team Sites), Lotus Quickplace and private Wikis. Typically, the membership of the space is managed by the spaces owner(s) (business end users) and today this membership list is typically limited to the employees of the corporation that has deployed the software. Many corporations however are increasingly seeking the capability to collaborate with their partners / vendors within these spaces and so they wish the spaces to be accessible both to their own employees and the employees of their partners. Below I outline some typical flows that exist in this type of application today. These flows are, today, only available to employees in the intranet. We would like to see whether DIX can enable these capabilities across the extranet. 1. The space owner adds a new member to the space. The new member is e-mailed a url link to the space along with a welcome message from the space owner. 2. Members of the space need to authenticate before being allowed access to the space. Their id is checked against the list of members allowed into a particular space. 3. The spaces membership list is available to all members of the space. This list also makes available the contact details of the members so that other members can contact them easily. This includes contact information such as business telephone, e-mail and jabber id. 4. All postings to the space display who made the posting. 5. Members keep track of activity in the space by subscribing to the space's feed. Some observations of these requirements and dmd1. Requirements 2 and 4 are met by dmd1 Requirements 1 and 3 cannot currently be met by dmd1. There's a couple of interesting point here. Namely that it is the enterprise, not the individual that makes the decision about whether to release certain attributes about an individual. It also determines to whom (i.e. which partners) those attributes can be released. Also, the individuals contact details needs to be available prior to the individual logging into the space. As soon as an individual is added to the membership list their contact information should be available to other members in the space. Requirement 5 is not met by dmd1 as "Rich Clients" are presently not in scope. Let me know what you think, Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 12:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIc5-0008IT-EE; Fri, 17 Mar 2006 12:19:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIc4-0008I8-Of for dix@ietf.org; Fri, 17 Mar 2006 12:19: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 1FKIc3-0006cu-6u for dix@ietf.org; Fri, 17 Mar 2006 12:19:44 -0500 Received: from [192.168.1.100] (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 k2HHJfG4023052 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 09:19:41 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC2040219A1@ftrdmel3.rd.francetelecom.fr> References: <941BA0BF46DB8F4983FF7C8AFE800BC2040219A1@ftrdmel3.rd.francetelecom.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CCD870A-BDA0-4BD1-81B8-781511F6692E@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] What is "identity"? Date: Fri, 17 Mar 2006 09:19:40 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 17-Mar-06, at 2:07 AM, BAILLEUX Benoit RD-BIZZ-CAE wrote: > But after wandering through the initial (and now long) thread, I'm > still > not sure if a definition to "Identity" (and not only for "identity > exchange", which seems to be clear) must be found. John Merrells has > been asking for a consensus about the definition of "identity". Is it > achieved ? I would propose that we define "Digital Identity Exchange" per Bob's suggestion and not try and define "Identity" -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 12:49:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJ4N-00077x-Vg; Fri, 17 Mar 2006 12:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJ4N-00077m-5N for dix@ietf.org; Fri, 17 Mar 2006 12:48:59 -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 1FKJ4M-0007BR-Q4 for dix@ietf.org; Fri, 17 Mar 2006 12:48:59 -0500 Received: from [192.168.1.100] (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 k2HHmuLt024175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 09:48:57 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <441AD5B0.2010306@gmail.com> References: <441AD5B0.2010306@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] use cases / requirements for extranet collaborations Date: Fri, 17 Mar 2006 09:48:56 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 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 On 17-Mar-06, at 7:28 AM, Robert Yates wrote: > 1. The space owner adds a new member to the space. The new member > is e-mailed a url link to the space along with a welcome message > from the space owner. > 2. Members of the space need to authenticate before being allowed > access to the space. Their id is checked against the list of > members allowed into a particular space. > 3. The spaces membership list is available to all members of the > space. This list also makes available the contact details of the > members so that other members can contact them easily. This > includes contact information such as business telephone, e-mail and > jabber id. > 4. All postings to the space display who made the posting. > 5. Members keep track of activity in the space by subscribing to > the space's feed. > > Some observations of these requirements and dmd1. > > Requirements 2 and 4 are met by dmd1 > Requirements 1 and 3 cannot currently be met by dmd1. There's a > couple of interesting point here. Namely that it is the > enterprise, not the individual that makes the decision about > whether to release certain attributes about an individual. It also > determines to whom (i.e. which partners) those attributes can be > released. Also, the individuals contact details needs to be > available prior to the individual logging into the space. As soon > as an individual is added to the membership list their contact > information should be available to other members in the space. > Requirement 5 is not met by dmd1 as "Rich Clients" are presently > not in scope. Personally, I think that a goal of DIX would be to provide the basis for your to solve your problem above. Some of the aspects are part of your application, rather then the protocol. From what I gather from the problem statement, an email address is likely the easier identifier for identifying users. A SAML assertion linking the email address and the persona-url could be made by a third party, either the server at the domain of the email address or a trusted 3rd party. This allows the space owner to add email address to the space. The new member gets the email, and logs in proving they own they email by providing the SAML assertion and their persona-url. I think this covers (1) above. (3) is covered by the application displaying the list of email addresses of the members. (5) would be nice to solve real-soon-now. Not sure what is appropriate or standard within IETF for setting up a subgroup to work on that. We still don't have a WG for the core stuff in DIX. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 14:23:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKXk-00085L-Pl; Fri, 17 Mar 2006 14:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKXj-00083b-A9 for dix@ietf.org; Fri, 17 Mar 2006 14:23:23 -0500 Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKKXj-0002Su-1x for dix@ietf.org; Fri, 17 Mar 2006 14:23:23 -0500 Received: by wproxy.gmail.com with SMTP id 36so675716wra for ; Fri, 17 Mar 2006 11:23:22 -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=E2XXmIwotxd5LRL2iwhYbJY0WoUj+C/Fnr2PXGNZbtifG4cHw+BKYpsLMbktFrOvPJ2xByBiAVQ2mKwcFbWPRLWQvXMAgRnY5ON2sPKuEjOCsilrw+Cdcz4afPIjlaLlqYRZgmyGdaY2g8pvh12WrcrjYQF/KqodGcPA0dE2Cl8= Received: by 10.54.79.10 with SMTP id c10mr2814335wrb; Fri, 17 Mar 2006 11:23:22 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id 44sm1399470wri.2006.03.17.11.23.21; Fri, 17 Mar 2006 11:23:22 -0800 (PST) Message-ID: <441B0CA0.8030705@gmail.com> Date: Fri, 17 Mar 2006 14:23:12 -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] use cases / requirements for extranet collaborations References: <441AD5B0.2010306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: > > On 17-Mar-06, at 7:28 AM, Robert Yates wrote: > >> 1. The space owner adds a new member to the space. The new member >> is e-mailed a url link to the space along with a welcome message >> from the space owner. >> 2. Members of the space need to authenticate before being allowed >> access to the space. Their id is checked against the list of members >> allowed into a particular space. >> 3. The spaces membership list is available to all members of the >> space. This list also makes available the contact details of the >> members so that other members can contact them easily. This >> includes contact information such as business telephone, e-mail and >> jabber id. >> 4. All postings to the space display who made the posting. >> 5. Members keep track of activity in the space by subscribing to the >> space's feed. > > > Personally, I think that a goal of DIX would be to provide the basis > for your to solve your problem above. Some of the aspects are part of > your application, rather then the protocol. Agreed, that some of what I wrote above is part of our application e.g the e-mailing aspect, but steps 1 and 3 depend on the flow of identifiers about an individual from a domain that knows them to a domain that wants to know them. Our application needs to know part of the users Digital Identity, namely their e-mail, their display name, and their jabber-id. Shouldn't DIX be capable of moving this information about? Is that not core to the DIX protocol? From the DIX charter: /"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." /It's certainly within DIX scope to request this information for the user at the browser. How is the delineation being made that the use case above is not considered core and would require SAML to provide a solution? Is it due to the fact that it is the users corporation that has provided consent to release these attributes and not the user? Is it that the user is not currently at the browser? I just wonder where the line is being drawn and would be interested in seeing this discussed at the BOF. > From what I gather from the problem statement, an email address is > likely the easier identifier for identifying users. A SAML assertion > linking the email address and the persona-url could be made by a > third party, either the server at the domain of the email address or > a trusted 3rd party. I agree that an e-mail address is potentially easier from an end user perspective, but let's say its o.k. for the space owner to identify members by their persona-url. All our application now needs is the ability to look up other parts of this user's identity, namely their e-mail, their display name and their jabber-id for a given persona-url? Is this not within the scope of DIX? > > This allows the space owner to add email address to the space. The > new member gets the email, and logs in proving they own they email by > providing the SAML assertion and their persona-url. I think this > covers (1) above. (3) is covered by the application displaying the > list of email addresses of the members. 3 is not quite covered as we need more than just e-mails, we need a display name, their jabber id so they can be instant messaged and also their phone number. > > (5) would be nice to solve real-soon-now. Not sure what is > appropriate or standard within IETF for setting up a subgroup to work > on that. We still don't have a WG for the core stuff in DIX. understood, am just wanting to put some requirements on the table prior to the BOF. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 14:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKei-0003Ry-7m; Fri, 17 Mar 2006 14:30:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKKeh-0003R6-4i for dix@ietf.org; Fri, 17 Mar 2006 14:30: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 1FKKeg-0002Wq-Fv for dix@ietf.org; Fri, 17 Mar 2006 14:30:34 -0500 Received: from [192.168.6.215] (dhcp215.sxip.com [192.168.6.215]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2HJUW2c029444 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 11:30:33 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <441B0CA0.8030705@gmail.com> References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] use cases / requirements for extranet collaborations Date: Fri, 17 Mar 2006 11:30:27 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 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: , Errors-To: dix-bounces@ietf.org On 17-Mar-06, at 11:23 AM, Robert Yates wrote: > Dick Hardt wrote: > >> >> On 17-Mar-06, at 7:28 AM, Robert Yates wrote: >> >>> 1. The space owner adds a new member to the space. The new >>> member is e-mailed a url link to the space along with a welcome >>> message from the space owner. >>> 2. Members of the space need to authenticate before being >>> allowed access to the space. Their id is checked against the >>> list of members allowed into a particular space. >>> 3. The spaces membership list is available to all members of the >>> space. This list also makes available the contact details of >>> the members so that other members can contact them easily. >>> This includes contact information such as business telephone, e- >>> mail and jabber id. >>> 4. All postings to the space display who made the posting. >>> 5. Members keep track of activity in the space by subscribing to >>> the space's feed. >> >> >> Personally, I think that a goal of DIX would be to provide the >> basis for your to solve your problem above. Some of the aspects >> are part of your application, rather then the protocol. > > Agreed, that some of what I wrote above is part of our application > e.g the e-mailing aspect, but steps 1 and 3 depend on the flow of > identifiers about an individual from a domain that knows them to a > domain that wants to know them. Our application needs to know part > of the users Digital Identity, namely their e-mail, their display > name, and their jabber-id. Shouldn't DIX be capable of moving this > information about? Is that not core to the DIX protocol? > > From the DIX charter: > > /"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." > > /It's certainly within DIX scope to request this information for > the user at the browser. How is the delineation being made that > the use case above is not considered core and would require SAML to > provide a solution? Is it due to the fact that it is the users > corporation that has provided consent to release these attributes > and not the user? Is it that the user is not currently at the > browser? I just wonder where the line is being drawn and would be > interested in seeing this discussed at the BOF. I agree that DIX should be able to move around all the identity data you describe. SAML comes in when you want the data verified by a third party, as opposed to the user. > >> From what I gather from the problem statement, an email address >> is likely the easier identifier for identifying users. A SAML >> assertion linking the email address and the persona-url could be >> made by a third party, either the server at the domain of the >> email address or a trusted 3rd party. > > I agree that an e-mail address is potentially easier from an end > user perspective, but let's say its o.k. for the space owner to > identify members by their persona-url. All our application now > needs is the ability to look up other parts of this user's > identity, namely their e-mail, their display name and their jabber- > id for a given persona-url? Is this not within the scope of DIX? Yes it is, except that DIX as proposed has the user present the email, display name, jabber-id, to the application rather then the application "looking it up". > >> >> This allows the space owner to add email address to the space. >> The new member gets the email, and logs in proving they own they >> email by providing the SAML assertion and their persona-url. I >> think this covers (1) above. (3) is covered by the application >> displaying the list of email addresses of the members. > > 3 is not quite covered as we need more than just e-mails, we need a > display name, their jabber id so they can be instant messaged and > also their phone number. Do you want those verified by a third party as well, or are you ok that the user asserts those? If verified, then they would be need be in an assertion. If not, then it is easy to move. Either case, I think your problem statement is in scope for DIX. > >> >> (5) would be nice to solve real-soon-now. Not sure what is >> appropriate or standard within IETF for setting up a subgroup to >> work on that. We still don't have a WG for the core stuff in DIX. > > understood, am just wanting to put some requirements on the table > prior to the BOF. Good to hear them! -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 15:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLM8-0000s6-Ti; Fri, 17 Mar 2006 15:15:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLM6-0000s1-VA for dix@ietf.org; Fri, 17 Mar 2006 15:15:26 -0500 Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKLM5-0004P7-NN for dix@ietf.org; Fri, 17 Mar 2006 15:15:26 -0500 Received: by zproxy.gmail.com with SMTP id q3so644432nzb for ; Fri, 17 Mar 2006 12:15:25 -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=ffgNapU/yPevB923Pn20iq+FwE63Z8cnhjbwACFwusRe/H43DaPrXonB4DUeT9aYfj3BiB/pZ7mHcJWNgFfPttmdjgMN05f39e4Ub7IF5J8u8hXIZJgBQ7RbgU7o8YOGDTIqOjTyt5+QSZdvj6trX1jMxP0+jJqe863+PDcWou0= Received: by 10.64.210.2 with SMTP id i2mr483639qbg; Fri, 17 Mar 2006 12:15:24 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id e13sm777531qba.2006.03.17.12.15.23; Fri, 17 Mar 2006 12:15:24 -0800 (PST) Message-ID: <441B18CE.3050203@gmail.com> Date: Fri, 17 Mar 2006 15:15:10 -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] use cases / requirements for extranet collaborations References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> In-Reply-To: <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Dick Hardt wrote: > I agree that DIX should be able to move around all the identity data > you describe. great, but I just want to clarify a point. dmd1 today can move around all this identity data. The reason that dmd1 doesn't yet fulfill our requirements is that it moves it too late in this process for it to be useful to us. We need the data moved the moment that a space owner adds a new user to the space. Do you also agree that DIX should allow the identity data to be moved at this point? > Yes it is, except that DIX as proposed has the user present the > email, display name, jabber-id, to the application rather then the > application "looking it up". do you envision a future draft with the "lookup" capability? in the use case, as described, the identity data is needed and the user is not around to present it. >> 3 is not quite covered as we need more than just e-mails, we need a >> display name, their jabber id so they can be instant messaged and >> also their phone number. > > Do you want those verified by a third party as well, or are you ok > that the user asserts those? If verified, then they would be need be > in an assertion. If not, then it is easy to move. Either case, I > think your problem statement is in scope for DIX. Am a little confused here. If our application is installed by Company X who wants to collaborate with members of Partner Y then it is important that when we get identity information about a user from Partner Y that it is Partner Y's homesite that is making the assertions. Rob p.s. just to be clear I am not a "pull" junkie. I just have problems :) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 15:32:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLd1-0005hB-BL; Fri, 17 Mar 2006 15:32:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLd0-0005gC-25 for dix@ietf.org; Fri, 17 Mar 2006 15:32:54 -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 1FKLcx-0004dk-EY for dix@ietf.org; Fri, 17 Mar 2006 15:32:53 -0500 Received: from [10.0.1.5] (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 k2HKWnJB032329 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 12:32:50 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: quoted-printable Message-Id: <98E1FCEC-C8AC-4770-BC2D-634A5D23B7C8@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Fri, 17 Mar 2006 12:32:48 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [dix] diff dmd0 dmd1 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Lisa suggested I should detail the changes between the draft revisions: http://dixs.org/index.php/Draft-merrells-dix-00.txt and http://dixs.org/index.php/Draft-merrells-dix-01.txt I tried to remember who'd suggested what changes... John 3 Added interaction diagram (Eric) 5.9.1.1 Added more detail for description of dix:/core#1. 5.10.1.2 Changed User Form CLASS value from =91DIX=92, which incorrectly=20= =20 uses upper case characters, to =91sxip=92. (Note that this draft is an=20= =20 individual submission that describes how we=92re solving this problem=20=20 at Sxip Identity.) 5.10.2.1 Made FORM auto-submission via Javascript a suggestion.=20=20 (Nick, and others) 5.10.2.1 Stated that same mechanism (redirected-POST) is used for the=20=20 Membersite to Homesite communication. 5.10.2.3 Added statement that the signature is a HMAC. (Eric) 5.10.2.4 Added reference to ECMAscript. (Eric) 5.10.2.6 FORMS must be UTF-8 encoded. (Nick) 5.10.2.7 New and improved canonicalization algorithm. (Keith at Sxip?) 5.10.2.8 Added reference to datetime format in RFC1123. (Marius at=20=20 Sxip?) 5.10.2.8 Added dix:/membersite-logo-url to fetch-request message. 5.10.2.9 Explicit definition of signature encoding, lower-case hex=20=20 with no prefix. (Marius at Sxip) 5.10.2.9 A blank value if returned for a property that is requested,=20=20 but which has no value. 5.10.2.12 Added dix:/membersite-logo-url to store-request message. 5.10.2.12 Added dix:/membersite-explanation to dix:/membersite-logo-url. 5.10.2.12 Removed spurious =911=92 character. 5.10.2.12 Made dix:/signature optional. (My error.) 5.10.3 Clarified that verification process could be done in both=20=20 directions. 5.10.3.2 Change Homesite Tag REL tag value to dix:/homesite, as it=20=20 was badly named. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 18:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOCD-0005Ef-Vq; Fri, 17 Mar 2006 18:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOCC-0005Ea-Qx for dix@ietf.org; Fri, 17 Mar 2006 18:17:24 -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 1FKOC9-0000sK-5b for dix@ietf.org; Fri, 17 Mar 2006 18:17:24 -0500 Received: from [10.0.1.5] (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 k2HNHIZT037124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Mar 2006 15:17:18 -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: Content-Transfer-Encoding: 7bit From: John Merrells Date: Fri, 17 Mar 2006 15:17:02 -0800 To: Dan Connolly X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dix@ietf.org, uri@w3.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt > says "This document has no IANA Actions." but section 3.2.6. DIX > URI Namespace > introduces a new URI scheme. My understanding of this is that because the document is an individual submission and not a working group document that there can be no IANA actions from it. If it were a working group document then this document would have to call out 'dix' registration as an action. I'm happy to add a comment to the draft to make that clearer though. > Introducing a new URI scheme just for DIX is not a good use of > scarce community resources; > let's not do the DAV: thing again. > > Instead of > dix:/homesite > just use something like > http://dixs.org/terms#homesite This issue then becomes who owns that domain. > There are some IANA considerations around dixs.org; IANA should > make sure that name is reserved for this purpose in perpetuity if this > spec is adopted. Or the DIX profile should use iana.org or ietf.org . > (There's a BCP that says to use urn:ietf , but I recommend against > that; > I intend to renew the internet draft that argues for http/dns rather > than urn:ietf: .) > > The draft charter also doesn't say that DIX is introducing a new > URI scheme. > http://dixs.org/index.php/DIX_Charter > Please add something to the charter about getting review for the > dix: scheme. Note that draft-merrells-dix-01 (aka dmd1) is a write up of an example solution to the problem space we're considering here. If a WG were to be created then dmd1 would just be source material for another set of documents written to describe the WG's collective solution to the problem. The consensus of the group may or may not be to base that work on dmd1 and may or may not want to use URI's in that way and may or may not want to register a new scheme. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 18:40:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOYg-00081E-2e; Fri, 17 Mar 2006 18:40:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOYf-000819-8J for dix@ietf.org; Fri, 17 Mar 2006 18:40:37 -0500 Received: from eastrmmtao01.cox.net ([68.230.240.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKOYc-00026o-V9 for dix@ietf.org; Fri, 17 Mar 2006 18:40:37 -0500 Received: from charger ([68.100.55.187]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060317234028.SUHV4894.eastrmmtao01.cox.net@charger>; Fri, 17 Mar 2006 18:40:28 -0500 From: "Scott Hollenbeck" To: "'Digital Identity Exchange'" , "'Dan Connolly'" Subject: RE: [dix] Re: on the dix: URI scheme for DIX/SXIP Date: Fri, 17 Mar 2006 18:40:27 -0500 Message-ID: <000001c64a1c$2bbd3e00$0623520a@charger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcZKGPvAdUMwuDEDRpmfLJmuObXG3gAAuvjQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: uri@w3.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: , Errors-To: dix-bounces@ietf.org > -----Original Message----- > From: John Merrells [mailto:merrells@sxip.com] > Sent: Friday, March 17, 2006 6:17 PM > To: Dan Connolly > Cc: dix@ietf.org; uri@w3.org > Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP > > > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > > > Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt > > says "This document has no IANA Actions." but section > 3.2.6. DIX URI > > Namespace introduces a new URI scheme. > > My understanding of this is that because the document is an > individual submission and not a working group document that > there can be no IANA actions from it. If it were a working > group document then this document would have to call out > 'dix' registration as an action. > > I'm happy to add a comment to the draft to make that clearer though. Individual submission drafts can have IANA actions. It happens all the time. I do agree that minting a URI scheme is probably not a good idea if other alternatives are available. -Scott- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 18:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOZt-00019q-4S; Fri, 17 Mar 2006 18:41:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOZs-00017w-1G for dix@ietf.org; Fri, 17 Mar 2006 18:41:52 -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 1FKOZq-00028D-Mf for dix@ietf.org; Fri, 17 Mar 2006 18:41:52 -0500 Received: from [10.0.1.5] (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 k2HNfmr8038114 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Mar 2006 15:41:49 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: <9c3013570416d0aeecce05962b90eedb@w3.org> References: <9c3013570416d0aeecce05962b90eedb@w3.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <222B6BC4-5443-4D5E-9FBA-AE1A37C00A97@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Date: Fri, 17 Mar 2006 15:41:47 -0800 To: Dan Connolly X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Digital Identity Exchange , public-ietf-w3c@w3.org Subject: [dix] Re: DIX/SXIP delegation tag, HTML LINK rel, 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 On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > I note the draft doesn't include a normative reference to any HTML > specifications. Please > add one. Yes, my error. I will add to the next draft. > Also, the proposed charter ( http://dixs.org/index.php/ > DIX_Charter ) does not make > any connection to HTML. Please add something to note that use of > HTML syntax, > especially extensibility mechanisms like rel and profile, is in > scope, in order to attract > review from relevant experts. That might be presumptive... the charter only mentions HTML in the context of a HTTP transport binding and then only as an example way of encoding a message. The current interest in improving/extending/fixing HTTP-AUTH comes to mind as a possible alternative/substitute mechanism. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 17 18:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOam-0001oq-5f; Fri, 17 Mar 2006 18:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKOak-0001je-Lg for dix@ietf.org; Fri, 17 Mar 2006 18:42: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 1FKOaj-00029S-Af for dix@ietf.org; Fri, 17 Mar 2006 18:42:46 -0500 Received: from [10.0.1.5] (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 k2HNfmr9038114 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Mar 2006 15:42:44 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: <000001c64a1c$2bbd3e00$0623520a@charger> References: <000001c64a1c$2bbd3e00$0623520a@charger> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F1C15CE-4754-4DF9-838B-F9E90BBE9A56@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: on the dix: URI scheme for DIX/SXIP Date: Fri, 17 Mar 2006 15:42:44 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: uri@w3.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: , Errors-To: dix-bounces@ietf.org On 17-Mar-06, at 3:40 PM, Scott Hollenbeck wrote: > Individual submission drafts can have IANA actions. It happens all > the > time. My misunderstanding then. I'll add a required action to the next draft. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 01:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKUUz-0003GX-Rx; Sat, 18 Mar 2006 01:01:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKUUy-0003FI-An for dix@ietf.org; Sat, 18 Mar 2006 01:01:12 -0500 Received: from parth.bcnadsl.com ([217.147.80.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKUUx-00050Z-RJ for dix@ietf.org; Sat, 18 Mar 2006 01:01:12 -0500 Received: from adsl-64-175-131-138.dsl.snfc21.pacbell.net ([64.175.131.138] helo=[10.0.1.5]) by zeus.parthcomp.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1FKUUu-0007Eb-C6 for dix@ietf.org; Sat, 18 Mar 2006 06:01:10 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <441B18CE.3050203@gmail.com> References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> <441B18CE.3050203@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] use cases / requirements for extranet collaborations Date: Fri, 17 Mar 2006 22:01:03 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -3.3 (---) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 17-Mar-06, at 12:15 PM, Robert Yates wrote: > The reason that dmd1 doesn't yet fulfill our requirements is that > it moves it too late in this process for it to be useful to us. We > need the data moved the moment that a space owner adds a new user > to the space. Why is that? So that other members of the space can browse the details of the other members before those members have actually entered the space for the first time? > Do you also agree that DIX should allow the identity data to be > moved at this point? I'm not sure it needs to be. > do you envision a future draft with the "lookup" capability? in the > use case, as described, the identity data is needed and the user is > not around to present it. SPML comes to mind for pushing provisioning data from a directory out to an application. (Although I should state that I haven't looked at SPML for a couple of years now.) > >>> 3 is not quite covered as we need more than just e-mails, we need >>> a display name, their jabber id so they can be instant messaged >>> and also their phone number. >> >> Do you want those verified by a third party as well, or are you >> ok that the user asserts those? If verified, then they would be >> need be in an assertion. If not, then it is easy to move. Either >> case, I think your problem statement is in scope for DIX. > > Am a little confused here. If our application is installed by > Company X who wants to collaborate with members of Partner Y then > it is important that when we get identity information about a user > from Partner Y that it is Partner Y's homesite that is making the > assertions. Your solution above sounds like X pushes a statement about user A having some attributes to Partner Y. Dick's suggesting that X creates that same statement but that it digitally signs it (perhaps making a SAML assertion), then User A can move the assertion themselves to Partner Y when they first enter the space. User A can't modify the statement in any way, so Y is assured that X is making the statement. In the scenario X is serving as A's Homesite and Y is the Membersite. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 01:29:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKUwD-0007PF-0p; Sat, 18 Mar 2006 01:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKUwB-0007Nf-42 for dix@ietf.org; Sat, 18 Mar 2006 01:29:19 -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 1FKUrn-0005z5-CD for dix@ietf.org; Sat, 18 Mar 2006 01:24:47 -0500 Received: from [192.168.1.102] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2I6OjLH049253 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Mar 2006 22:24:45 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <441B18CE.3050203@gmail.com> References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> <441B18CE.3050203@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2FECD234-3ECF-4811-AF4A-6220BAE222BD@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] use cases / requirements for extranet collaborations Date: Fri, 17 Mar 2006 22:24:44 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 17-Mar-06, at 12:15 PM, Robert Yates wrote: > >> I agree that DIX should be able to move around all the identity >> data you describe. > > great, but I just want to clarify a point. dmd1 today can move > around all this identity data. The reason that dmd1 doesn't yet > fulfill our requirements is that it moves it too late in this > process for it to be useful to us. We need the data moved the > moment that a space owner adds a new user to the space. To echo John's comments, why do you need this? > Do you also agree that DIX should allow the identity data to be > moved at this point? I think to move the data as you describe, a tight coupling between all parties is required. > >> Yes it is, except that DIX as proposed has the user present the >> email, display name, jabber-id, to the application rather then >> the application "looking it up". > > do you envision a future draft with the "lookup" capability? in the > use case, as described, the identity data is needed and the user is > not around to present it. Would be interested in hearing use cases for where this is needed where the user had not already been there. > >>> 3 is not quite covered as we need more than just e-mails, we need >>> a display name, their jabber id so they can be instant messaged >>> and also their phone number. >> >> Do you want those verified by a third party as well, or are you >> ok that the user asserts those? If verified, then they would be >> need be in an assertion. If not, then it is easy to move. Either >> case, I think your problem statement is in scope for DIX. > > Am a little confused here. If our application is installed by > Company X who wants to collaborate with members of Partner Y then > it is important that when we get identity information about a user > from Partner Y that it is Partner Y's homesite that is making the > assertions. The Homesite is the users agent for managing their data. Liberty deployments typically combine the identifier authentication and property assertion operations. DIX is wanting to separate those so that you can provide third party claims from many authoritative sites in a single request, and that the Homesite does NOT need to be trusted. ie. AT&T may claim that my persona has a phone number, VeriSign that I have a specific email address, and Air Canada that I am Star Alliance Gold. Company X needs to trust AT&T, VeriSign and Star Alliance -- but not my Homesite. > > p.s. just to be clear I am not a "pull" junkie. I just have > problems :) Don't we all? I'm no exception to having problems. ;-) -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 01:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKV21-0003q4-QO; Sat, 18 Mar 2006 01:35:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMVp-0007qW-Vd for dix@ietf.org; Fri, 17 Mar 2006 16:29:33 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMVo-0006Nx-O2 for dix@ietf.org; Fri, 17 Mar 2006 16:29:33 -0500 Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 228E94F454; Fri, 17 Mar 2006 16:29:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9c3013570416d0aeecce05962b90eedb@w3.org> Content-Transfer-Encoding: 7bit From: Dan Connolly Date: Fri, 17 Mar 2006 16:29:31 -0500 To: John Merrells , Lisa Dusseault X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Sat, 18 Mar 2006 01:35:20 -0500 Cc: dix@ietf.org, public-ietf-w3c@w3.org Subject: [dix] DIX/SXIP delegation tag, HTML LINK rel, 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 John, Lisa, It was good to see you at the W3C authorization workshop this week. http://www.w3.org/2005/Security/usability-ws/program I'm pretty excited about DIX/SXIP and related web-like authorization mechanisms, but I don't think I can swing a trip to Dallas for the BOF next week. http://www3.ietf.org/proceedings/06mar/agenda/dix.html It's great that DIX/SXIP uses URIs for naming, and that it delegates via DNS. But the way it's done in section 5.10.3.2. Delegation Tag of http://dixs.org/index.php/Draft-merrells-dix-01.txt ... ... isn't using HTML as designed and specified. In HTML 4, we added a profile attribute to the head element for this purpose. section 7.4.4.3 Meta data profiles http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h -7.4.4.3 So I suggest in stead: (more on dix: vs dixs.org separately.) I note the draft doesn't include a normative reference to any HTML specifications. Please add one. Also, the proposed charter ( http://dixs.org/index.php/DIX_Charter ) does not make any connection to HTML. Please add something to note that use of HTML syntax, especially extensibility mechanisms like rel and profile, is in scope, in order to attract review from relevant experts. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 01:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKV22-0003rP-Ke; Sat, 18 Mar 2006 01:35:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMmz-0005AS-Mm for dix@ietf.org; Fri, 17 Mar 2006 16:47:17 -0500 Received: from mxsf13.cluster1.charter.net ([209.225.28.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMmx-0006ax-E0 for dix@ietf.org; Fri, 17 Mar 2006 16:47:17 -0500 Received: from mxip28a.cluster1.charter.net (mxip28a.cluster1.charter.net [209.225.28.187]) by mxsf13.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id k2HLl4KA020346 for ; Fri, 17 Mar 2006 16:47:07 -0500 Received: from 68-112-233-63.dhcp.oxfr.ma.charter.com (HELO localhost.localdomain) ([68.112.233.63]) by mxip28a.cluster1.charter.net with ESMTP; 17 Mar 2006 16:47:03 -0500 X-IronPort-AV: i="4.03,105,1141621200"; d="scan'208"; a="915334659:sNHT75249858" Received: from ndw by localhost.localdomain with local (Exim 4.60) (envelope-from ) id 1FKMmj-0006S1-CP; Fri, 17 Mar 2006 16:47:01 -0500 From: Norman Walsh To: Dan Connolly References: X-URL: http://www.sun.com/ Date: Fri, 17 Mar 2006 16:47:01 -0500 In-Reply-To: (Dan Connolly's message of "Fri, 17 Mar 2006 16:29:55 -0500") Message-ID: <878xr8agmi.fsf@nwalsh.com> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Sat, 18 Mar 2006 01:35:20 -0500 Cc: dix@ietf.org, uri@w3.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0992188011==" Errors-To: dix-bounces@ietf.org --===============0992188011== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Dan Connolly was heard to say: [...] | Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt | says "This document has no IANA Actions." but section 3.2.6. DIX URI | Namespace | introduces a new URI scheme. | | Introducing a new URI scheme just for DIX is not a good use of scarce | community resources; | let's not do the DAV: thing again. [...] | Please add something to the charter about getting review for the dix: | scheme. +1 Be seeing you, norm =2D-=20 Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc. NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEGy5VOyltUcwYWjsRAqhWAKCF6JwCy+T1d9eR95SX2q8jWR4xcQCeNrWd IeAxeNvlTffi30OvG9UaOwQ= =17S1 -----END PGP SIGNATURE----- --=-=-=-- --===============0992188011== 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 --===============0992188011==-- From dix-bounces@ietf.org Sat Mar 18 01:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKV22-0003qJ-Es; Sat, 18 Mar 2006 01:35:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMWC-0007wB-Cu for dix@ietf.org; Fri, 17 Mar 2006 16:29:56 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMWC-0006OH-5y for dix@ietf.org; Fri, 17 Mar 2006 16:29:56 -0500 Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id BBBA24F480; Fri, 17 Mar 2006 16:29:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dan Connolly Date: Fri, 17 Mar 2006 16:29:55 -0500 To: John Merrells , Lisa Dusseault X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Sat, 18 Mar 2006 01:35:20 -0500 Cc: dix@ietf.org, uri@w3.org Subject: [dix] on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 learned at a W3C authorization workshop this week http://www.w3.org/2005/Security/usability-ws/program that there's a SXIP/DIX BOF at the IETF next week. http://www3.ietf.org/proceedings/06mar/agenda/dix.html I'm pretty excited about DIX/SXIP and related web-like authorization mechanisms, but I don't think I can swing the trip to Dallas. Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt says "This document has no IANA Actions." but section 3.2.6. DIX URI Namespace introduces a new URI scheme. Introducing a new URI scheme just for DIX is not a good use of scarce community resources; let's not do the DAV: thing again. Instead of dix:/homesite just use something like http://dixs.org/terms#homesite There are some IANA considerations around dixs.org; IANA should make sure that name is reserved for this purpose in perpetuity if this spec is adopted. Or the DIX profile should use iana.org or ietf.org . (There's a BCP that says to use urn:ietf , but I recommend against that; I intend to renew the internet draft that argues for http/dns rather than urn:ietf: .) The draft charter also doesn't say that DIX is introducing a new URI scheme. http://dixs.org/index.php/DIX_Charter Please add something to the charter about getting review for the dix: scheme. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 02:03:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKVTA-0006sP-MX; Sat, 18 Mar 2006 02:03:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKVRo-0005zG-Mb for dix@ietf.org; Sat, 18 Mar 2006 02:02:00 -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 1FKVJ1-0006bP-3m for dix@ietf.org; Sat, 18 Mar 2006 01:53:00 -0500 Received: from [192.168.1.102] (d207-216-142-242.bchsia.telus.net [207.216.142.242]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2I6qrTO050001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Mar 2006 22:52:53 -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=US-ASCII; delsp=yes; format=flowed Message-Id: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP Date: Fri, 17 Mar 2006 22:52:52 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: uri@w3.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: , Errors-To: dix-bounces@ietf.org On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > ntroducing a new URI scheme just for DIX is not a good use of > scarce community resources; > let's not do the DAV: thing again. > > Instead of > dix:/homesite > just use something like > http://dixs.org/terms#homesite Thanks for the input Dan. Sorry you won't make Dallas. I'm not familiar with what happened with DAV: -- is there somewhere you can point for enlightenment? Agree that we need to make good use of scarce community resources. Not being a standards guy, I am sure that I will be butchering terminology -- please correct me! The reasoning behind introducing a new scheme was we need an escape sequence for processing the name/value pairs and to differentiate data from constants etc.. Anything starting with "dix:" is known to be a constant. Anything else is not. :) -- one of the reasons for this is that we want to be able to pass through name/value pairs that a web application may be using to preserve state. We think the likelihood that any existing app have strings that start with "dix:/" to be, well, really really small. One might think that we could just use "http://dixs.org" as the escape sequence, but we wanted anyone to be able to extend DIX, so having a new scheme allows the scheme to be the escape, and the namespace and hence the definition of properties that can be stored and retrieved to be distributed rather then centralized. We reserved the use of dix:/foo style constants (no name space) for ones that are defined in the DIX spec. Does this make sense? Do you have a suggestion for another approach that provides an escape mechanism and allows decentralized property / capability extension? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 06:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKZQX-0001Mq-2k; Sat, 18 Mar 2006 06:16:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKZQV-0001Ml-UQ for dix@ietf.org; Sat, 18 Mar 2006 06:16:55 -0500 Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKZQU-0006VT-Ed for dix@ietf.org; Sat, 18 Mar 2006 06:16:55 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9923833C40; Sat, 18 Mar 2006 11:16:53 +0000 (GMT) Message-ID: <441BEBAD.5000506@algroup.co.uk> Date: Sat, 18 Mar 2006 11:14:53 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP References: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> In-Reply-To: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: uri@w3.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: , Errors-To: dix-bounces@ietf.org Dick Hardt wrote: > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > >> ntroducing a new URI scheme just for DIX is not a good use of scarce >> community resources; What is scarce? n-letter combinations? This seems unlikely! >> let's not do the DAV: thing again. >> >> Instead of >> dix:/homesite >> just use something like >> http://dixs.org/terms#homesite > > Thanks for the input Dan. Sorry you won't make Dallas. I'm not familiar > with what happened with DAV: -- is there somewhere you can point for > enlightenment? Hmmm. Not sure what happened, but the outcome was that DAV uses the HTTP namespace and adds extra headers and methods to the requests. > Agree that we need to make good use of scarce community resources. > > Not being a standards guy, I am sure that I will be butchering > terminology -- please correct me! > > The reasoning behind introducing a new scheme was we need an escape > sequence for processing the name/value pairs and to differentiate data > from constants etc.. Anything starting with "dix:" is known to be a > constant. Anything else is not. :) -- one of the reasons for this is > that we want to be able to pass through name/value pairs that a web > application may be using to preserve state. We think the likelihood that > any existing app have strings that start with "dix:/" to be, well, > really really small. > > One might think that we could just use "http://dixs.org" as the escape > sequence, but we wanted anyone to be able to extend DIX, so having a new > scheme allows the scheme to be the escape, and the namespace and hence > the definition of properties that can be stored and retrieved to be > distributed rather then centralized. We reserved the use of dix:/foo > style constants (no name space) for ones that are defined in the DIX spec. > > Does this make sense? Do you have a suggestion for another approach that > provides an escape mechanism and allows decentralized property > /capability extension? It sounds to me like you could do this all with HTTP headers. Obviously that doesn't help with other protocols, of course! Cheers, Ben. -- 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 Sat Mar 18 13:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfvg-0006tv-Lx; Sat, 18 Mar 2006 13:13:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKfvf-0006tj-Rq for dix@ietf.org; Sat, 18 Mar 2006 13:13:31 -0500 Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKfve-000253-0E for dix@ietf.org; Sat, 18 Mar 2006 13:13:31 -0500 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4F5A733C40; Sat, 18 Mar 2006 18:13:25 +0000 (GMT) Message-ID: <441C4D4D.6010404@algroup.co.uk> Date: Sat, 18 Mar 2006 18:11:25 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "McDonald, Ira" Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Digital Identity Exchange , uri@w3.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: , Errors-To: dix-bounces@ietf.org McDonald, Ira wrote: > Hi Ben, > > With respect to "scarce": > > Although I have mixed feelings about the logic, the brand > new RFC 4395 "Guidelines and Registration Procedures for > New URI Schemes" argues that the bar should be very high > for a new 'Permanent' URI scheme, because so many browsers > and other bits of client software will have to updated for > the URI scheme to become widely deployed and used. I guess that DIX is an example of a proposal that drives a truck through that argument. Clearly all that s/w has to be changed _no matter how_ you represent DIX. It seems likely to me that this is generally true, too, but I'm not planning to make a stand against 4395 on that basis :-) Cheers, Ben. -- 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 Sat Mar 18 16:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKioS-0008Df-VQ; Sat, 18 Mar 2006 16:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKioR-0008B5-MG for dix@ietf.org; Sat, 18 Mar 2006 16:18:15 -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 1FKioQ-0008EQ-8g for dix@ietf.org; Sat, 18 Mar 2006 16:18:15 -0500 Received: from [204.96.114.115] ([204.96.114.115]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2ILIBOO070417 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 18 Mar 2006 13:18:12 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <878xr8agmi.fsf@nwalsh.com> References: <878xr8agmi.fsf@nwalsh.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Sat, 18 Mar 2006 13:18:06 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [dix] Dinner Saturday in Dallas? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Anyone else here (Hilton Anatole) that is interested in dinner tonight? -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 17:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjrJ-0005Jb-Pb; Sat, 18 Mar 2006 17:25:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjrI-0005JW-Tv for dix@ietf.org; Sat, 18 Mar 2006 17:25:16 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKjrH-0001kR-E2 for dix@ietf.org; Sat, 18 Mar 2006 17:25:16 -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 k2IMPESL016530; Sat, 18 Mar 2006 14:25:14 -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); Sat, 18 Mar 2006 14:25:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] on the dix: URI scheme for DIX/SXIP Date: Sat, 18 Mar 2006 14:25:12 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797D6B2@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] on the dix: URI scheme for DIX/SXIP Thread-Index: AcZKVi0k8BR/lIfOTeuF+t/IwUbZ1gAhAhjw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" , "John Merrells" , "Lisa Dusseault" X-OriginalArrivalTime: 18 Mar 2006 22:25:14.0220 (UTC) FILETIME=[D3BAD2C0:01C64ADA] X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: uri@w3.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="===============1039897769==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1039897769== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01C64AB0.E9E44AB0" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C64AB0.E9E44AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I disagree. I think that it is a bad idea to tie this particular URL to one protocol. http:// urls are a pain, it would have been better to have web:// URLs that could map onto HTTP1.x, HTTP-NG, DIME, etc. I really don't like the idea of the dixs.org hack here. People should have a first class URL. I would prefer something like UN:: or something like it. Then that could map from the identifier to SAML, WS-*, DIX... > -----Original Message----- > From: Dan Connolly [mailto:connolly@w3.org] > Sent: Friday, March 17, 2006 4:30 PM > To: John Merrells; Lisa Dusseault > Cc: dix@ietf.org; uri@w3.org > Subject: [dix] on the dix: URI scheme for DIX/SXIP > > I learned at a W3C authorization workshop this week > http://www.w3.org/2005/Security/usability-ws/program > that there's a SXIP/DIX BOF at the IETF next week. > http://www3.ietf.org/proceedings/06mar/agenda/dix.html > > I'm pretty excited about DIX/SXIP and related web-like > authorization mechanisms, but I don't think I can swing the > trip to Dallas. > > Section 7 of http://dixs.org/index.php/Draft-merrells-dix-01.txt > says "This document has no IANA Actions." but section 3.2.6. > DIX URI Namespace introduces a new URI scheme. > > Introducing a new URI scheme just for DIX is not a good use > of scarce community resources; let's not do the DAV: thing again. > > Instead of > dix:/homesite > just use something like > http://dixs.org/terms#homesite > > There are some IANA considerations around dixs.org; IANA > should make sure that name is reserved for this purpose in > perpetuity if this spec is adopted. Or the DIX profile should > use iana.org or ietf.org . > (There's a BCP that says to use urn:ietf , but I recommend > against that; I intend to renew the internet draft that > argues for http/dns rather than urn:ietf: .) > > The draft charter also doesn't say that DIX is introducing a > new URI scheme. > http://dixs.org/index.php/DIX_Charter > Please add something to the charter about getting review for the dix: > scheme. > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > ------=_NextPart_000_0016_01C64AB0.E9E44AB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTgyMjI1MTJaMCMGCSqGSIb3DQEJBDEWBBTf Hs7FB261Q0W33qnr8RN10UAxrjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAMxq0xqk4DpmY8HLTTyrgBsFcE 1mOb3W7a+F781II2qDHVrdBDgRX9PLybvrEkvCTtC4qKwwJLOPthUcn8asEGxgTvvGp5S3wThlPu zCBfGWvHKf8cLMFEhwYAqtrnSP0p4s0X4+pl7tWSI9hAhgb+AZleXuY0v0Ey2/ojmd1J7gAAAAAA AA== ------=_NextPart_000_0016_01C64AB0.E9E44AB0-- --===============1039897769== 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 --===============1039897769==-- From dix-bounces@ietf.org Sat Mar 18 17:28:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjuh-0005ey-CG; Sat, 18 Mar 2006 17:28:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKjuf-0005et-D2 for dix@ietf.org; Sat, 18 Mar 2006 17:28:45 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKjuf-0001pZ-1A for dix@ietf.org; Sat, 18 Mar 2006 17:28:45 -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 k2IMSgZK016608; Sat, 18 Mar 2006 14:28:42 -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); Sat, 18 Mar 2006 14:28:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] on the dix: URI scheme for DIX/SXIP Date: Sat, 18 Mar 2006 14:28:40 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3797D6B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] on the dix: URI scheme for DIX/SXIP Thread-Index: AcZKt7JpwOD0ESziRCuvNMHYLGgiCQAI0omQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" , "McDonald, Ira" X-OriginalArrivalTime: 18 Mar 2006 22:28:42.0018 (UTC) FILETIME=[4F964820:01C64ADB] X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: uri@w3.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="===============0687524557==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0687524557== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001B_01C64AB1.65F3C860" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C64AB1.65F3C860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It seems to me that tying the URL to the DIX protocol is a bad idea for the reason Dan gives. Tying the URL to a DNS indirection to the DIX/SAML/WS-*/whatever protocol is much more future proof. Who was it who said every problem in computer science can be solved... Phill > -----Original Message----- > From: Ben Laurie [mailto:ben@algroup.co.uk] > Sent: Saturday, March 18, 2006 1:11 PM > To: McDonald, Ira > Cc: Digital Identity Exchange; uri@w3.org > Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP > > McDonald, Ira wrote: > > Hi Ben, > > > > With respect to "scarce": > > > > Although I have mixed feelings about the logic, the brand > new RFC 4395 > > "Guidelines and Registration Procedures for New URI Schemes" argues > > that the bar should be very high for a new 'Permanent' URI scheme, > > because so many browsers and other bits of client software > will have > > to updated for the URI scheme to become widely deployed and used. > > I guess that DIX is an example of a proposal that drives a > truck through that argument. Clearly all that s/w has to be > changed _no matter how_ you represent DIX. It seems likely to > me that this is generally true, too, but I'm not planning to > make a stand against 4395 on that basis :-) > > Cheers, > > Ben. > > -- > 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 > > ------=_NextPart_000_001B_01C64AB1.65F3C860 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMTgyMjI4NDBaMCMGCSqGSIb3DQEJBDEWBBSo QX7z361ysuygY5vB/0gNTo63FzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYB7bg1iAlBThRmspR7JKihi15ro D+aMWCD8bmP85y+GooluBdtKQA2Vvrd1Hym8TfBS/WtlQfJz2srIntolarVizMq5WA50DbElthKu XZ4wNLiDpqtZ8D8C+N65420qIBkKvqv3URB3KeC11HFKkAZ7q206c7tYl9aRR4H40h61lgAAAAAA AA== ------=_NextPart_000_001B_01C64AB1.65F3C860-- --===============0687524557== 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 --===============0687524557==-- From dix-bounces@ietf.org Sat Mar 18 21:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKo4E-0004VH-Nz; Sat, 18 Mar 2006 21:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKeM2-0003eE-1V for dix@ietf.org; Sat, 18 Mar 2006 11:32:38 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKeM0-0007Ja-JR for dix@ietf.org; Sat, 18 Mar 2006 11:32:38 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2IGWHtK019005; Sat, 18 Mar 2006 08:32:17 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 18 Mar 2006 08:32:17 -0800 Message-ID: From: "McDonald, Ira" To: "'Ben Laurie'" , Digital Identity Exchange Subject: RE: [dix] on the dix: URI scheme for DIX/SXIP Date: Sat, 18 Mar 2006 08:32:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-Mailman-Approved-At: Sat, 18 Mar 2006 21:54:52 -0500 Cc: uri@w3.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: , Errors-To: dix-bounces@ietf.org Hi Ben, With respect to "scarce": Although I have mixed feelings about the logic, the brand new RFC 4395 "Guidelines and Registration Procedures for New URI Schemes" argues that the bar should be very high for a new 'Permanent' URI scheme, because so many browsers and other bits of client software will have to updated for the URI scheme to become widely deployed and used. Note that RFC 4395 also defines and allows registration of 'Provisional' URI schemes with a fairly low bar. Anyone defining or attempting to register a new URI scheme needs to carefully read RFC 4395 and understand the new guidelines. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Ben > Laurie > Sent: Saturday, March 18, 2006 8:39 AM > To: Digital Identity Exchange > Cc: uri@w3.org > Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP > > > > Dick Hardt wrote: > > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > > > >> ntroducing a new URI scheme just for DIX is not a good use > of scarce > >> community resources; > > What is scarce? n-letter combinations? This seems unlikely! > > >> let's not do the DAV: thing again. > >> > >> Instead of > >> dix:/homesite > >> just use something like > >> http://dixs.org/terms#homesite > > > > Thanks for the input Dan. Sorry you won't make Dallas. I'm > not familiar > > with what happened with DAV: -- is there somewhere you can point for > > enlightenment? > > Hmmm. Not sure what happened, but the outcome was that DAV > uses the HTTP > namespace and adds extra headers and methods to the requests. > > > Agree that we need to make good use of scarce community resources. > > > > Not being a standards guy, I am sure that I will be butchering > > terminology -- please correct me! > > > > The reasoning behind introducing a new scheme was we need an escape > > sequence for processiFrom dix-bounces@ietf.org Sat Mar 18 21:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKo4E-0004VH-Nz; Sat, 18 Mar 2006 21:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKeM2-0003eE-1V for dix@ietf.org; Sat, 18 Mar 2006 11:32:38 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKeM0-0007Ja-JR for dix@ietf.org; Sat, 18 Mar 2006 11:32:38 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2IGWHtK019005; Sat, 18 Mar 2006 08:32:17 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 18 Mar 2006 08:32:17 -0800 Message-ID: From: "McDonald, Ira" To: "'Ben Laurie'" , Digital Identity Exchange Subject: RE: [dix] on the dix: URI scheme for DIX/SXIP Date: Sat, 18 Mar 2006 08:32:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-Mailman-Approved-At: Sat, 18 Mar 2006 21:54:52 -0500 Cc: uri@w3.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: , Errors-To: dix-bounces@ietf.org Hi Ben, With respect to "scarce": Although I have mixed feelings about the logic, the brand new RFC 4395 "Guidelines and Registration Procedures for New URI Schemes" argues that the bar should be very high for a new 'Permanent' URI scheme, because so many browsers and other bits of client software will have to updated for the URI scheme to become widely deployed and used. Note that RFC 4395 also defines and allows registration of 'Provisional' URI schemes with a fairly low bar. Anyone defining or attempting to register a new URI scheme needs to carefully read RFC 4395 and understand the new guidelines. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Ben > Laurie > Sent: Saturday, March 18, 2006 8:39 AM > To: Digital Identity Exchange > Cc: uri@w3.org > Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP > > > > Dick Hardt wrote: > > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > > > >> ntroducing a new URI scheme just for DIX is not a good use > of scarce > >> community resources; > > What is scarce? n-letter combinations? This seems unlikely! > > >> let's not do the DAV: thing again. > >> > >> Instead of > >> dix:/homesite > >> just use something like > >> http://dixs.org/terms#homesite > > > > Thanks for the input Dan. Sorry you won't make Dallas. I'm > not familiar > > with what happened with DAV: -- is there somewhere you can point for > > enlightenment? > > Hmmm. Not sure what happened, but the outcome was that DAV > uses the HTTP > namespace and adds extra headers and methods to the requests. > > > Agree that we need to make good use of scarce community resources. > > > > Not being a standards guy, I am sure that I will be butchering > > terminology -- please correct me! > > > > The reasoning behind introducing a new scheme was we need an escape > > sequence for processing the name/value pairs and to > differentiate data > > from constants etc.. Anything starting with "dix:" is known to be a > > constant. Anything else is not. :) -- one of the reasons for this is > > that we want to be able to pass through name/value pairs that a web > > application may be using to preserve state. We think the > likelihood that > > any existing app have strings that start with "dix:/" to be, well, > > really really small. > > > > One might think that we could just use "http://dixs.org" as > the escape > > sequence, but we wanted anyone to be able to extend DIX, so > having a new > > scheme allows the scheme to be the escape, and the > namespace and hence > > the definition of properties that can be stored and retrieved to be > > distributed rather then centralized. We reserved the use of dix:/foo > > style constants (no name space) for ones that are defined > in the DIX spec. > > > > Does this make sense? Do you have a suggestion for another > approach that > > provides an escape mechanism and allows decentralized property > > /capability extension? > > It sounds to me like you could do this all with HTTP headers. > Obviously > that doesn't help with other protocols, of course! > > Cheers, > > Ben. > > -- > 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 Sat Mar 18 21:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKo4E-0004VM-S4; Sat, 18 Mar 2006 21:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKnsz-0002gh-FT for dix@ietf.org; Sat, 18 Mar 2006 21:43:17 -0500 Received: from exprod6og10.obsmtp.com ([64.18.1.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKnsx-0001d2-SS for dix@ietf.org; Sat, 18 Mar 2006 21:43:17 -0500 Received: from source ([192.150.11.134]) by exprod6ob10.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 18 Mar 2006 18:43:14 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2J2gRBl018654 for ; Sat, 18 Mar 2006 18:42:27 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2J2hEHZ015888 for ; Sat, 18 Mar 2006 18:43:14 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IWC000SUSW1AY@mailsj-v1.corp.adobe.com> for dix@ietf.org; Sat, 18 Mar 2006 18:43:14 -0800 (PST) Received: from MasinterT43p ([10.7.240.213]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IWC0097OSW1KK@mailsj-v1.corp.adobe.com> for dix@ietf.org; Sat, 18 Mar 2006 18:43:13 -0800 (PST) Date: Sat, 18 Mar 2006 18:43:05 -0800 From: Larry Masinter In-reply-to: To: "'Dan Connolly'" , "'John Merrells'" , "'Lisa Dusseault'" Message-id: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZKCkqyP8hURcG1T/Cf2ummdoDlzgA0gckg X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Sat, 18 Mar 2006 21:54:52 -0500 Cc: dix@ietf.org, uri@w3.org Subject: [dix] RE: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange differentiate data > > from constants etc.. Anything starting with "dix:" is known to be a > > constant. Anything else is not. :) -- one of the reasons for this is > > that we want to be able to pass through name/value pairs that a web > > application may be using to preserve state. We think the > likelihood that > > any existing app have strings that start with "dix:/" to be, well, > > really really small. > > > > One might think that we could just use "http://dixs.org" as > the escape > > sequence, but we wanted anyone to be able to extend DIX, so > having a new > > scheme allows the scheme to be the escape, and the > namespace and hence > > the definition of properties that can be stored and retrieved to be > > distributed rather then centralized. We reserved the use of dix:/foo > > style constants (no name space) for ones that are defined > in the DIX spec. > > > > Does this make sense? Do you have a suggestion for another > approach that > > provides an escape mechanism and allows decentralized property > > /capability extension? > > It sounds to me like you could do this all with HTTP headers. > Obviously > that doesn't help with other protocols, of course! > > Cheers, > > Ben. > > -- > 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 Sat Mar 18 21:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKo4E-0004VM-S4; Sat, 18 Mar 2006 21:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKnsz-0002gh-FT for dix@ietf.org; Sat, 18 Mar 2006 21:43:17 -0500 Received: from exprod6og10.obsmtp.com ([64.18.1.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKnsx-0001d2-SS for dix@ietf.org; Sat, 18 Mar 2006 21:43:17 -0500 Received: from source ([192.150.11.134]) by exprod6ob10.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 18 Mar 2006 18:43:14 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2J2gRBl018654 for ; Sat, 18 Mar 2006 18:42:27 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k2J2hEHZ015888 for ; Sat, 18 Mar 2006 18:43:14 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IWC000SUSW1AY@mailsj-v1.corp.adobe.com> for dix@ietf.org; Sat, 18 Mar 2006 18:43:14 -0800 (PST) Received: from MasinterT43p ([10.7.240.213]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IWC0097OSW1KK@mailsj-v1.corp.adobe.com> for dix@ietf.org; Sat, 18 Mar 2006 18:43:13 -0800 (PST) Date: Sat, 18 Mar 2006 18:43:05 -0800 From: Larry Masinter In-reply-to: To: "'Dan Connolly'" , "'John Merrells'" , "'Lisa Dusseault'" Message-id: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcZKCkqyP8hURcG1T/Cf2ummdoDlzgA0gckg X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Sat, 18 Mar 2006 21:54:52 -0500 Cc: dix@ietf.org, uri@w3.org Subject: [dix] RE: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 just having a hard time figuring out what 'dix:' URIs are supposed to mean and how they're intended to be used. What does 'dix:/core#1' mean? What is the namespace for 'core', and where is it registered? Can I make up one of my own? What if two people decide to do so but assign different meanings? Or is there just a limited set of these things, all listed in the 'dix' document? It really looks like you're defining an authentication protocol and trying to pack all of the parameters of authentication requests into a URI. But it's not really clear you need a URI scheme at all. What if you just got rid of the four characters 'dix:' and used the rest of the string everywhere that expected a dix? Wouldn't it work just as well? In which circumstances might I find a URI which would possibly be a 'dix:' and possibly be something else? As a side note, the document contains a lot of trademarks 'google.com', 'amazon.com', 'yahoo.com', 'homesite' which you might want to avoid. Larry _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix f.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I'm just having a hard time figuring out what 'dix:' URIs are supposed to mean and how they're intended to be used. What does 'dix:/core#1' mean? What is the namespace for 'core', and where is it registered? Can I make up one of my own? What if two people decide to do so but assign different meanings? Or is there just a limited set of these things, all listed in the 'dix' document? It really looks like you're defining an authentication protocol and trying to pack all of the parameters of authentication requests into a URI. But it's not really clear you need a URI scheme at all. What if you just got rid of the four characters 'dix:' and used the rest of the string everywhere that expected a dix? Wouldn't it work just as well? In which circumstances might I find a URI which would possibly be a 'dix:' and possibly be something else? As a side note, the document contains a lot of trademarks 'google.com', 'amazon.com', 'yahoo.com', 'homesite' which you might want to avoid. Larry _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 18 22:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKopA-0005jK-G5; Sat, 18 Mar 2006 22:43:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKop8-0005jF-Su for dix@ietf.org; Sat, 18 Mar 2006 22:43: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 1FKop6-0003V0-6T for dix@ietf.org; Sat, 18 Mar 2006 22:43:22 -0500 Received: from [204.96.114.64] ([204.96.114.64]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2J3hCOi078157 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 18 Mar 2006 19:43:14 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> References: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Sat, 18 Mar 2006 19:43:12 -0800 To: Larry Masinter X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: uri@w3.org, dix@ietf.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 18-Mar-06, at 6:43 PM, Larry Masinter wrote: > > I'm just having a hard time figuring out what 'dix:' URIs > are supposed to mean and how they're intended to be used. From dmd1: (http://dixs.org/index.php/Draft-merrells-dix-01.txt) The DIX protocol uses DIX URI Names for: o Capability Names o Property References o Message Parameters o Constant Values > > What does 'dix:/core#1' mean? What is the namespace for > 'core', and where is it registered? Can I make up one > of my own? What if two people decide to do so but > assign different meanings? Or is there just a limited > set of these things, all listed in the 'dix' document? From dmd1: Extensibility stems from the authority. Anyone with a registered domain name can create DIX URI Names using their own domain name as the authority in the URI. ... To elaborate, anything starting with dix:/ would be reserved for identifiers in the DIX standard. eg. dix:/core#1 Anyone with a domain name can define their own. eg. dix://acm.org/foobar > It really looks like you're defining an authentication > protocol and trying to pack all of the parameters of > authentication requests into a URI. DIX is NOT a authentication protocol. The parameters are NOT in a URI. > But it's not really > clear you need a URI scheme at all. What if you just > got rid of the four characters 'dix:' and used the rest > of the string everywhere that expected a dix? Wouldn't > it work just as well? In which circumstances might I > find a URI which would possibly be a 'dix:' and possibly > be something else? Having the scheme allows the string values to be globally unique so that DIX values can be recognized. I think we are getting ahead of ourselves here as we still don't have a WG for DIX. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 00:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKqHJ-0007as-EZ; Sun, 19 Mar 2006 00:16:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKqHI-0007ai-BK for dix@ietf.org; Sun, 19 Mar 2006 00:16:32 -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 1FKqHF-0006TE-02 for dix@ietf.org; Sun, 19 Mar 2006 00:16:32 -0500 Received: from [10.0.1.5] (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 k2J5GQLp079892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 18 Mar 2006 21:16:26 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <1F84E204-00C2-4A79-829C-0AA4EA8B1DEA@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Digital Identity Exchange From: John Merrells Date: Sat, 18 Mar 2006 21:16:24 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dix] text conferencing for DIX BOF X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 --- Specific Info The DIX BOF ''chat room' will be here: March 21st at 0900 CST, UTC -6 dix@rooms.jabber.ietf.org --- Generic Info http://www.ietf.org/meetings/text_conf.html _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 00:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKqHJ-0007an-Ax; Sun, 19 Mar 2006 00:16:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKqHI-0007ad-4r for dix@ietf.org; Sun, 19 Mar 2006 00:16:32 -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 1FKqHF-0006TH-FX for dix@ietf.org; Sun, 19 Mar 2006 00:16:31 -0500 Received: from [10.0.1.5] (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 k2J5GQLq079892 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 18 Mar 2006 21:16:28 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: quoted-printable Message-Id: <5AE41C9C-B9B0-4838-870D-BCE76B786B93@sxip.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Sat, 18 Mar 2006 21:16:25 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [dix] audio conferencing for DIX BOF X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 --- Specifc Info The DIX BOF is in the =91Chantilly West=92 =91room, so will be broadcast on= =20=20 channel 6. March 21st at 0900 CST, UTC -6 http://videolab.uoregon.edu/events/ietf/ietf656.m3u --- Generic Info The IETF 65 working group meetings will be streamed and recorded in=20=20 Dallas TX begining March 20th at 0900 CST, UTC -6. Streams will be 64Kb/s or lower httpd streamed mp3 audio, a format=20=20 playable by some client on virtually any platform capable of=20=20 supporting internet radio type applications. More information can be found at: http://videolab.uoregon.edu/events/ietf/ The broadcast schedule will be fleshed out as the impending date=20=20 approaches. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 09:46:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzAo-0002Qb-6x; Sun, 19 Mar 2006 09:46:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKzAn-0002QQ-7s for dix@ietf.org; Sun, 19 Mar 2006 09:46:25 -0500 Received: from pproxy.gmail.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKzAm-0004tU-Uz for dix@ietf.org; Sun, 19 Mar 2006 09:46:25 -0500 Received: by pproxy.gmail.com with SMTP id n25so86501pyg for ; Sun, 19 Mar 2006 06:46:24 -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=mzgg+0UUxTWaJB5SZxzOdTZxkaaLKqIzMJn5jIlOBAZq2WnqyV8iPkSkmiGYewFbVKIh2HCWkUowz2tO6gBsmobGiKZ8XoiACkR0EvoTxsxiKYkejQk0MqaX/Rj2JQBZ1TU7YSvUahTwZFPe+ZUAPwFbCTuJ5JbAEV8Ep0RguPM= Received: by 10.35.105.18 with SMTP id h18mr1638217pym; Sun, 19 Mar 2006 06:46:24 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id b43sm1592594pyb.2006.03.19.06.46.23; Sun, 19 Mar 2006 06:46:24 -0800 (PST) Message-ID: <441D6EBE.9010107@gmail.com> Date: Sun, 19 Mar 2006 09:46:22 -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] use cases / requirements for extranet collaborations References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> <441B18CE.3050203@gmail.com> <2FECD234-3ECF-4811-AF4A-6220BAE222BD@sxip.com> In-Reply-To: <2FECD234-3ECF-4811-AF4A-6220BAE222BD@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) 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: , Errors-To: dix-bounces@ietf.org Dick Hardt wrote: >> great, but I just want to clarify a point. dmd1 today can move >> around all this identity data. The reason that dmd1 doesn't yet >> fulfill our requirements is that it moves it too late in this >> process for it to be useful to us. We need the data moved the >> moment that a space owner adds a new user to the space. > > To echo John's comments, why do you need this? When the space administrator adds a new member to the space, the following things currently happen. Note that at this point in time the new member is no where in sight. 1) The new member gets added to the access control for the space. 2) The new member is e-mailed with a welcome message and a link to the space. 3) The new member's contact details e.g. phone number, e-mail address, jabber id are available to other space members from the space's membership list. Note also that there are some space members that log into the space extremely infrequently and with the advent of feeds some may never log into the space via a browser. They're just "observers" of what is taking place. However it is important that their contact details be available to other members of the space. > I think to move the data as you describe, a tight coupling between > all parties is required. Not sure why you think the coupling is any tighter than the coupling between a homesite and membersite. We're just requesting a set of user properties. >> do you envision a future draft with the "lookup" capability? in the >> use case, as described, the identity data is needed and the user is >> not around to present it. > > > Would be interested in hearing use cases for where this is needed > where the user had not already been there. see above. We want the user's properties to move when the space admin adds them to the membership list, so we can send them an e-mail, and so that their contact details are available to others. This is how the products work today, the difference is that today all the members are in the corporate LDAP and so the application just "pulls" the data from there. > The Homesite is the users agent for managing their data. Liberty > deployments typically combine the identifier authentication and > property assertion operations. DIX is wanting to separate those so > that you can provide third party claims from many authoritative sites > in a single request, and that the Homesite does NOT need to be trusted. > > ie. AT&T may claim that my persona has a phone number, VeriSign that > I have a specific email address, and Air Canada that I am Star > Alliance Gold. Company X needs to trust AT&T, VeriSign and Star > Alliance -- but not my Homesite. k, sorry, have been slow at grasping this fact (as demonstrated by an earlier posting of mine), thanks for the explanation. Rob p.s. I notice this statement in the DIX charter. "The end-user should have control over their identity information and always be providing consent for the exchange of any of their information." I just wonder whether this holds true in the corporation to corporation use cases. In these instances it is the end-user's corporation that provides consent for the exchange of their employee's identity information. I think this is an important distinction from the consumer space. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 14:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL413-0002g3-Nj; Sun, 19 Mar 2006 14:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL412-0002av-7O for dix@ietf.org; Sun, 19 Mar 2006 14:56:40 -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 1FL40z-0007sj-Pz for dix@ietf.org; Sun, 19 Mar 2006 14:56:40 -0500 Received: from [130.129.133.203] (DHCP-Wired-133-203.ietf65.org [130.129.133.203] (may be forged)) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2JJuY59099169 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 19 Mar 2006 11:56:36 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <441D6EBE.9010107@gmail.com> References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> <441B18CE.3050203@gmail.com> <2FECD234-3ECF-4811-AF4A-6220BAE222BD@sxip.com> <441D6EBE.9010107@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] use cases / requirements for extranet collaborations Date: Sun, 19 Mar 2006 13:56:27 -0600 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 19-Mar-06, at 8:46 AM, Robert Yates wrote: > Dick Hardt wrote: > >>> great, but I just want to clarify a point. dmd1 today can move >>> around all this identity data. The reason that dmd1 doesn't yet >>> fulfill our requirements is that it moves it too late in this >>> process for it to be useful to us. We need the data moved the >>> moment that a space owner adds a new user to the space. >> >> To echo John's comments, why do you need this? > > When the space administrator adds a new member to the space, the > following things currently happen. Note that at this point in time > the new member is no where in sight. > > 1) The new member gets added to the access control for the space. > 2) The new member is e-mailed with a welcome message and a link to > the space. > 3) The new member's contact details e.g. phone number, e-mail > address, jabber id are available to other space members from the > space's membership list. > > Note also that there are some space members that log into the space > extremely infrequently and with the advent of feeds some may never > log into the space via a browser. They're just "observers" of what > is taking place. However it is important that their contact > details be available to other members of the space. Ok, I think I understand your use case. Essentially you are saying that someone can be added to a space without their permission? :-) Seriously though, I'm sure there are situations where your use case makes sense. In order to solve the other aspects of the identity problem, I would expect that server to server communication would currently be out of scope > >> I think to move the data as you describe, a tight coupling >> between all parties is required. > > Not sure why you think the coupling is any tighter than the > coupling between a homesite and membersite. We're just requesting > a set of user properties. The site with the data MUST trust the site requesting the data. ie, there is an existing relationship between them. In dmd1, the membersite and homesite don't need to have any prior relationship, and the user can use one homesite one day, and another another day > >>> do you envision a future draft with the "lookup" capability? in >>> the use case, as described, the identity data is needed and the >>> user is not around to present it. >> >> >> Would be interested in hearing use cases for where this is needed >> where the user had not already been there. > > see above. We want the user's properties to move when the space > admin adds them to the membership list, so we can send them an e- > mail, and so that their contact details are available to others. > This is how the products work today, the difference is that today > all the members are in the corporate LDAP and so the application > just "pulls" the data from there. Sounds like LDAP is a solution now. Why not keep using it? > >> The Homesite is the users agent for managing their data. Liberty >> deployments typically combine the identifier authentication and >> property assertion operations. DIX is wanting to separate those >> so that you can provide third party claims from many >> authoritative sites in a single request, and that the Homesite >> does NOT need to be trusted. >> >> ie. AT&T may claim that my persona has a phone number, VeriSign >> that I have a specific email address, and Air Canada that I am >> Star Alliance Gold. Company X needs to trust AT&T, VeriSign and >> Star Alliance -- but not my Homesite. > > k, sorry, have been slow at grasping this fact (as demonstrated by > an earlier posting of mine), thanks for the explanation. > Rob > > p.s. I notice this statement in the DIX charter. > > "The end-user should have control over their identity information > and always be providing consent for the exchange of any of their > information." > > I just wonder whether this holds true in the corporation to > corporation use cases. In these instances it is the end-user's > corporation that provides consent for the exchange of their > employee's identity information. I think this is an important > distinction from the consumer space. I agree there are differences. I have found this useful discussion. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 15:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4sn-0006gV-SC; Sun, 19 Mar 2006 15:52:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4sm-0006gQ-QA for dix@ietf.org; Sun, 19 Mar 2006 15:52:12 -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 1FL4sl-0001bN-F1 for dix@ietf.org; Sun, 19 Mar 2006 15:52:12 -0500 Received: from [130.129.133.203] (DHCP-Wired-133-203.ietf65.org [130.129.133.203] (may be forged)) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2JKq9ZH000603 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 19 Mar 2006 12:52:10 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: Dick Hardt Date: Sun, 19 Mar 2006 14:52:02 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dix] WG scope? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Robert Yates comments have prompted me to provide this rough, but concise scope definition: 1) A programatic method for a service to request identity data from a user and the user to provide that identity data, and only that identity data, to the service. Initially, the service is a web server and the protocol for moving the data is HTTP/HTTPS. 2) A method for any party to independently create new schema for representing identity data. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 18:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7Zi-00014d-Nq; Sun, 19 Mar 2006 18:44:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL7Zh-00012v-MA for dix@ietf.org; Sun, 19 Mar 2006 18:44:41 -0500 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL7Zh-0008Ig-EF for dix@ietf.org; Sun, 19 Mar 2006 18:44:41 -0500 Received: by pproxy.gmail.com with SMTP id e30so1534603pya for ; Sun, 19 Mar 2006 15:44:41 -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=UdP/A/tAQpl0ux2noF8rocvPrNShO+uuCM8UuBh45cdiylDMfxdvT3yxX0+kd+2w8ojHO6HdO8pDMInJfHpECOHlFvMx8/6CaNsH9J9iUy3gBpu24qG83zruNkeXlSJ9vutLigIzXEtOtsX+4Z00OIfe0Dne3qsr00K8D9Sg9oM= Received: by 10.35.36.13 with SMTP id o13mr791233pyj; Sun, 19 Mar 2006 15:44:40 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id s72sm10500pyc.2006.03.19.15.44.39; Sun, 19 Mar 2006 15:44:40 -0800 (PST) Message-ID: <441DECE5.8010105@gmail.com> Date: Sun, 19 Mar 2006 18:44:37 -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] use cases / requirements for extranet collaborations References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> <441B18CE.3050203@gmail.com> <2FECD234-3ECF-4811-AF4A-6220BAE222BD@sxip.com> <441D6EBE.9010107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: > Essentially you are saying that someone can be added to a space > without their permission? :-) Yes :) there are a lot of similar use cases in the consumer space that I think DIX needs to accommodate, e.g. in flickr I can share photos with a limited set of contacts, in kodak gallery the same thing. These sites all send the user an e-mail stating something like "Rob has shared some photos with you, click here to access the photos". I can imagine ways that this could work with dmd1, I could type in the user's e-mail address and their persona-url, or some secret in the mail message the user receives could be used that allows the user to type in their persona-url and then the service associates this e-mail with that persona-url. These approaches however seem a little strained to me. Is there something special about an e-mail address that needs to be better reflected in future revisions of dmd1? >>> I think to move the data as you describe, a tight coupling between >>> all parties is required. >> >> Not sure why you think the coupling is any tighter than the coupling >> between a homesite and membersite. We're just requesting a set of >> user properties. > > The site with the data MUST trust the site requesting the data. ie, > there is an existing relationship between them. In dmd1, the > membersite and homesite don't need to have any prior relationship, > and the user can use one homesite one day, and another another day Am not sure that I would describe an existing relationship as a "tight coupling". How different is this to me instructing my homesite that it can always release my credit card information to amazon.com, and that it can do so without requiring me to confirm its release. I have always been assuming that this is why the membersite can optionally send its signature. Given this fact, dmd1 is within sniffing distance of being able to fulfill the use case that I have described previously. Our server could issue a fetch request directly to the homesite url. The homesite could check that the request is coming from a membersite with which an existing relationship exists and hence immediately returns the form to post. Although ugly and not an approach that I would advocate our server can parse the form in the response from the homesite and get the information that it requires. If a WG is formed, and I wish you all the best of luck this week in Dallas, then I think it worth exploring some options to see if these use cases can be accommodated without placing a significant burden on homesites. Given how close dmd1 is to meeting these requirements we may surprise ourselves and find an easy solution. I would not be too hasty in removing these use cases from scope. > Sounds like LDAP is a solution now. Why not keep using it? Is possible, but I don't think enterprises like placing their ldaps on the public internet. Securely proxying http requests is well understood. Am not sure that the same can yet be said for ldap. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 23:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLBkR-0001UW-HD; Sun, 19 Mar 2006 23:12:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLBkR-0001UR-1s for dix@ietf.org; Sun, 19 Mar 2006 23:12:03 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLBkP-0008Hy-LE for dix@ietf.org; Sun, 19 Mar 2006 23:12:03 -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 k2K4C0t3001683 for ; Sun, 19 Mar 2006 20:12:00 -0800 Received: from MOU1WNEXMB02.vcorp.ad.vrsn.com ([10.25.12.244]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Mar 2006 20:12: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 Date: Sun, 19 Mar 2006 20:11:59 -0800 Message-ID: <45D459DDA07DC442A499A4D46F4939BA0171CC92@MOU1WNEXMB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some dmd1 comments Thread-Index: AcZLrxsb4hLqNe/9S0yYl2jwTiDSuQAIDe+A From: "Granqvist, Hans" To: "Digital Identity Exchange" X-OriginalArrivalTime: 20 Mar 2006 04:12:00.0438 (UTC) FILETIME=[6F9D7D60:01C64BD4] X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [dix] some dmd1 comments X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Just a few comments/questions while reading the latest draft, which by the way is *not* in text but html format at http://dixs.org/index.php/Draft-merrells-dix-01.txt (grrr) --- In 5.3. Capability URI : If capability is equal to '1*ALPHA' then it's impossible to say whether a capability is dix or non-dix since a capability could contain a dot ('.'). (Perhaps 'ALPHA' is not properly defined -- the character set of ALPHA used elsewhere contains=20 the dot.) --- In 5.8. Capability Revisions=20 "From that point in the document onwards is what is included in=20 'dix://sxip.net/simple#34'."=20 I had to read this sentence a few times to understand. Can it be reworded? --- In 5.9.1.1. dix:/core#1=20 "Core DIX protocol capabilities. The simple usage profile. Our=20 assumptions are: low security, low risk identity transaction, data is moving over HTTP(S), low risk from replay attack." What do these assumptions mean, for example "low security"? And is it=20 possible to assume which transport is used -- does it even make sense=20 if DIX is defined to be transport agnostic? =20 --- 5.10.1.1. Membersite Cookie (Dumb Client)=20 "Once a user has visited a Membersite and identified the name of their=20 Homesite that Membersite can cookie the user with their choice of=20 Homesite, so that it can be filled in automatically for them in the=20 future."=20 The verb "to cookie someone" seems a bit over the top. :) =20 --- 5.10.1.2. User Prompt=20 "Homsite Path" Just a spelling mistake. "The attributes of the FORM tag are:=20 o CLASS attribute must contain 'sxip', which denotes to a smart=20 client that the form was generated by a DIX aware Membersite."=20 There is a 'sxip' reference requirement here that I don't understand. --- 5.10.1.4. Homesite Inspection=20 "The Membersite must now determine the Endpoint URL and the=20 Capabilities of the User's Homesite. The Membersite uses the Homesite Tag Inspection Algorithm to discover the Homesite Tag."=20 This algorithm is undefined by name in the document. "The Homesite Tag is used to specify the Endpoint URL and Capabilities=20 of a Homesite. The HTML LINK tag is used for this. The LINK tag is . . ." All of a sudden there is a dependency on HTML here, which really should=20 be stated up-front in the document, I think. =20 --- 5.10.2.2. Digest Generation=20 "th'dix:/signature'" Another spelling mistake (I hope! ;) "Signature =3D T ( S + Digest )" =20 I am sure this is intentionally simplified in the document, but since this is technically not a correct HMAC, it should be=20 reworded. (The concat is different, see RFC2104) --- 5.10.2.7. Message Canonicalization=20 '. apply the following URI encodings to keys and values:=20 . all "=3D" are encoded to "%3D", note the uppercase 'D'=20 . all "&" are encoded to "%26"=20 . all "%" are encoded to "%25"' What about other characters that are normally encoded? Are they intentionally excluded? =20 '. byte-order sort all joined pairs=20 . join all joined pairs into one string with "&" as a separator' I am confused what this means. An example would help! That's it so far . . .=20 Hans _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 19 23:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLCQm-0002ZY-Rj; Sun, 19 Mar 2006 23:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLCQl-0002ZM-Pj for dix@ietf.org; Sun, 19 Mar 2006 23:55: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 1FLCQl-000145-DA for dix@ietf.org; Sun, 19 Mar 2006 23:55:47 -0500 Received: from [130.129.133.203] (DHCP-Wired-133-203.ietf65.org [130.129.133.203] (may be forged)) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2K4tiB2009870 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 19 Mar 2006 20:55:46 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <441DECE5.8010105@gmail.com> References: <441AD5B0.2010306@gmail.com> <441B0CA0.8030705@gmail.com> <34F8EE15-05E3-4B1E-96D9-F2027014A4A3@sxip.com> <441B18CE.3050203@gmail.com> <2FECD234-3ECF-4811-AF4A-6220BAE222BD@sxip.com> <441D6EBE.9010107@gmail.com> <441DECE5.8010105@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19B36DC6-44CB-4108-A6CE-F76879AA9841@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] use cases / requirements for extranet collaborations Date: Sun, 19 Mar 2006 22:55:38 -0600 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 19-Mar-06, at 5:44 PM, Robert Yates wrote: > Dick Hardt wrote: > >> Essentially you are saying that someone can be added to a space >> without their permission? :-) > > Yes :) there are a lot of similar use cases in the consumer space > that I think DIX needs to accommodate, e.g. in flickr I can share > photos with a limited set of contacts, in kodak gallery the same > thing. These sites all send the user an e-mail stating something > like "Rob has shared some photos with you, click here to access the > photos". I can imagine ways that this could work with dmd1, I > could type in the user's e-mail address and their persona-url, or > some secret in the mail message the user receives could be used > that allows the user to type in their persona-url and then the > service associates this e-mail with that persona-url. These > approaches however seem a little strained to me. Is there > something special about an e-mail address that needs to be better > reflected in future revisions of dmd1? Not sure what you mean about something being special about the email. Per my earlier email, providing the email as an identifier to bootstrap a user account was something I envisioned would happen. All other aspects about the user are provided by the user when they login the first time. btw: Funny you mention flickr having been the first outside investor and board member ... they were on track to put in SXIP until Yahoo! bought them. > >>>> I think to move the data as you describe, a tight coupling >>>> between all parties is required. >>> >>> Not sure why you think the coupling is any tighter than the >>> coupling between a homesite and membersite. We're just >>> requesting a set of user properties. >> >> The site with the data MUST trust the site requesting the data. >> ie, there is an existing relationship between them. In dmd1, the >> membersite and homesite don't need to have any prior >> relationship, and the user can use one homesite one day, and >> another another day > > Am not sure that I would describe an existing relationship as a > "tight coupling". How different is this to me instructing my > homesite that it can always release my credit card information to > amazon.com, and that it can do so without requiring me to confirm > its release. I have always been assuming that this is why the > membersite can optionally send its signature. Currently, the membersite does not need to have any method of proving who it is, which lowers the barrier to adoption. > If a WG is formed, and I wish you all the best of luck this week in > Dallas, then I think it worth exploring some options to see if > these use cases can be accommodated without placing a significant > burden on homesites. Given how close dmd1 is to meeting these > requirements we may surprise ourselves and find an easy solution. I > would not be too hasty in removing these use cases from scope. I have heard from quite a few people that we need to keep a narrow scope. >> Sounds like LDAP is a solution now. Why not keep using it? > > Is possible, but I don't think enterprises like placing their ldaps > on the public internet. agreed > Securely proxying http requests is well understood. Am not sure > that the same can yet be said for ldap. LDAP over TLS can be done. For the same reasons why they don't want to put their LDAP servers out there, I think you have the same issues around "pulling" data using any other protocol. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 00:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLD8K-0004ZJ-3M; Mon, 20 Mar 2006 00:40:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9Vf-0000SZ-TK for dix@ietf.org; Sun, 19 Mar 2006 20:48:39 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL9Ve-0003nH-NB for dix@ietf.org; Sun, 19 Mar 2006 20:48:39 -0500 Received: from localhost.localdomain (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 47C2A4F11E; Sun, 19 Mar 2006 20:48:38 -0500 (EST) To: John Cowan From: Sandro Hawke In-reply-to: <20060320005737.GG4271@ccil.org> References: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> <20060320005737.GG4271@ccil.org> Comments: In-reply-to John Cowan message dated "Sun, 19 Mar 2006 19:57:37 -0500." X-Mailer: MH-E 7.82; nmh 1.1; GNU Emacs 21.4.1 Date: Sun, 19 Mar 2006 20:48:35 -0500 Message-Id: <20060320014838.47C2A4F11E@homer.w3.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 20 Mar 2006 00:40:46 -0500 Cc: Larry Masinter , uri@w3.org, dix@ietf.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 scripsit: > > > To elaborate, anything starting with dix:/ would be reserved for > > identifiers in the DIX standard. eg. dix:/core#1 > > Anyone with a domain name can define their own. eg. dix://acm.org/foobar > > It looks like the tag: URI scheme would be appropriate: it's used for > identifying > rather than locating, and anyone with a domain name or email address > can assign one. Indeed, if it's important to have the URIs not be dereferenceable, tags URIs (RFC 4151, which I co-wrote) are a fine choice. On the other hand, it's often very useful to provide information about the identified thing, via URI dereference, so I strongly recommend using an HTTP one, even though it can feel like like a strange approach. -- sandro _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 00:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLD8J-0004X7-Lg; Mon, 20 Mar 2006 00:40:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL8iN-0003Wm-4H for dix@ietf.org; Sun, 19 Mar 2006 19:57:43 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL8iK-000265-T9 for dix@ietf.org; Sun, 19 Mar 2006 19:57:43 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FL8iH-00089u-Sg; Sun, 19 Mar 2006 19:57:37 -0500 Date: Sun, 19 Mar 2006 19:57:37 -0500 To: Dick Hardt Message-ID: <20060320005737.GG4271@ccil.org> References: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Mon, 20 Mar 200From dix-bounces@ietf.org Mon Mar 20 00:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLD8K-0004ZJ-3M; Mon, 20 Mar 2006 00:40:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9Vf-0000SZ-TK for dix@ietf.org; Sun, 19 Mar 2006 20:48:39 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL9Ve-0003nH-NB for dix@ietf.org; Sun, 19 Mar 2006 20:48:39 -0500 Received: from localhost.localdomain (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 47C2A4F11E; Sun, 19 Mar 2006 20:48:38 -0500 (EST) To: John Cowan From: Sandro Hawke In-reply-to: <20060320005737.GG4271@ccil.org> References: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> <20060320005737.GG4271@ccil.org> Comments: In-reply-to John Cowan message dated "Sun, 19 Mar 2006 19:57:37 -0500." X-Mailer: MH-E 7.82; nmh 1.1; GNU Emacs 21.4.1 Date: Sun, 19 Mar 2006 20:48:35 -0500 Message-Id: <20060320014838.47C2A4F11E@homer.w3.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 20 Mar 2006 00:40:46 -0500 Cc: Larry Masinter , uri@w3.org, dix@ietf.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 scripsit: > > > To elaborate, anything starting with dix:/ would be reserved for > > identifiers in the DIX standard. eg. dix:/core#1 > > Anyone with a domain name can define their own. eg. dix://acm.org/foobar > > It looks like the tag: URI scheme would be appropriate: it's used for > identifying > rather than locating, and anyone with a domain name or email address > can assign one. Indeed, if it's important to have the URIs not be dereferenceable, tags URIs (RFC 4151, which I co-wrote) are a fine choice. On the other hand, it's often very useful to provide information about the identified thing, via URI dereference, so I strongly recommend using an HTTP one, even though it can feel like like a strange approach. -- sandro _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 00:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLD8J-0004X7-Lg; Mon, 20 Mar 2006 00:40:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL8iN-0003Wm-4H for dix@ietf.org; Sun, 19 Mar 2006 19:57:43 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL8iK-000265-T9 for dix@ietf.org; Sun, 19 Mar 2006 19:57:43 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FL8iH-00089u-Sg; Sun, 19 Mar 2006 19:57:37 -0500 Date: Sun, 19 Mar 2006 19:57:37 -0500 To: Dick Hardt Message-ID: <20060320005737.GG4271@ccil.org> References: <001801c64afe$d9c73ea0$d5f0070a@corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Mon, 20 Mar 2006 00:40:46 -0500 Cc: Larry Masinter , uri@w3.org, dix@ietf.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 scripsit: > To elaborate, anything starting with dix:/ would be reserved for > identifiers in the DIX standard. eg. dix:/core#1 > Anyone with a domain name can define their own. eg. dix://acm.org/foobar It looks like the tag: URI scheme would be appropriate: it's used for identifying rather than locating, and anyone with a domain name or email address can assign one. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall http://www.ap.org buy a piece of the rope for a keepsake. cowan@ccil.org _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix 6 00:40:46 -0500 Cc: Larry Masinter , uri@w3.org, dix@ietf.org Subject: [dix] Re: on the dix: URI scheme for DIX/SXIP X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 scripsit: > To elaborate, anything starting with dix:/ would be reserved for > identifiers in the DIX standard. eg. dix:/core#1 > Anyone with a domain name can define their own. eg. dix://acm.org/foobar It looks like the tag: URI scheme would be appropriate: it's used for identifying rather than locating, and anyone with a domain name or email address can assign one. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall http://www.ap.org buy a piece of the rope for a keepsake. cowan@ccil.org _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 08:17:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKGj-0000Bt-NF; Mon, 20 Mar 2006 08:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKGi-0000Be-4i for dix@ietf.org; Mon, 20 Mar 2006 08:17:56 -0500 Received: from pproxy.gmail.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKGg-0001lz-U2 for dix@ietf.org; Mon, 20 Mar 2006 08:17:56 -0500 Received: by pproxy.gmail.com with SMTP id s49so1589809pyc for ; Mon, 20 Mar 2006 05:17:54 -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=DzBb7xfMngbV33rsW9RL9ottS87ZuufUYZ0XTvjb+JqGJudP0x5RKQbjBOtVimcl1DGnsClmHlsHtkXeBquqidRxDI5j81O2NxRshcde6jQz9n3YZrj1M/NOETyXRCaIbRfjDFu8UoZz85iX2DQwyyhWON4oUHEg9stnXBXFsYg= Received: by 10.35.49.4 with SMTP id b4mr2139953pyk; Mon, 20 Mar 2006 05:17:53 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id k62sm20148pyk.2006.03.20.05.17.53; Mon, 20 Mar 2006 05:17:53 -0800 (PST) Message-ID: <441EAB80.5020709@gmail.com> Date: Mon, 20 Mar 2006 08:17:52 -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] WG scope? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: > Robert Yates comments have prompted me to provide this rough, but > concise scope definition: > > 1) A programatic method for a service to request identity data from a > user and the user to provide that identity data, and only that > identity data, to the service. Initially, the service is a web server > and the protocol for moving the data is HTTP/HTTPS. -1. I think it premature to rule out the possibility of any "pull" approach in DIX. IMO the working group needs to have the flexibility to examine the use cases in this space and determine if there are some of significant importance that require a "pull" approach. I would advocate that we stick with the text in the current DIX charter. "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." Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 10:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLM2d-0007zV-CY; Mon, 20 Mar 2006 10:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLM2c-0007zQ-0q for dix@ietf.org; Mon, 20 Mar 2006 10:11:30 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLM2Y-0005yQ-JN for dix@ietf.org; Mon, 20 Mar 2006 10:11:30 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k2KFBITN013754; Mon, 20 Mar 2006 16:11:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 20 Mar 2006 16:11:16 +0100 To: IETF DIX list X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [dix] Apparea meeting: Questions about DIX in meeting now! X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 If you are in Dallas, run, not walk, to Cortez A -- there will be some pre-BOF discussion of DIX in the apparea meeting. Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 10:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLM67-0001lF-BO; Mon, 20 Mar 2006 10:15:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLM66-0001kD-0I for dix@ietf.org; Mon, 20 Mar 2006 10:15:06 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLM64-00064L-Q6 for dix@ietf.org; Mon, 20 Mar 2006 10:15:05 -0500 Received: from lavazza.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 301434F1F8; Mon, 20 Mar 2006 10:15:04 -0500 (EST) Received: from roessler by lavazza.does-not-exist.org with local (Exim 4.60) (envelope-from ) id 1FLM63-0008Qm-DQ; Mon, 20 Mar 2006 16:15:03 +0100 Date: Mon, 20 Mar 2006 16:15:02 +0100 From: Thomas Roessler To: Carsten Bormann Subject: Re: [dix] Apparea meeting: Questions about DIX in meeting now! Message-ID: <20060320151502.GY29498@lavazza.does-not-exist.org> Mail-Followup-To: Carsten Bormann , IETF DIX list References: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF DIX list X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 jabber room corresponds to this meeting? -- Thomas Roessler, W3C On 2006-03-20 16:11:16 +0100, Carsten Bormann wrote: > From: Carsten Bormann > To: IETF DIX list > Cc: > Date: Mon, 20 Mar 2006 16:11:16 +0100 > Subject: [dix] Apparea meeting: Questions about DIX in meeting now! > Reply-To: Digital Identity Exchange > List-Id: Digital Identity Exchange > X-Spam-Level: > > If you are in Dallas, run, not walk, to Cortez A -- there will be > some pre-BOF discussion of DIX in the apparea meeting. > > Gruesse, Carsten > > > _______________________________________________ > 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 Mar 20 10:17:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLM83-0003Fe-7u; Mon, 20 Mar 2006 10:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLM82-0003FZ-3T for dix@ietf.org; Mon, 20 Mar 2006 10:17:06 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLM80-00066j-Qq for dix@ietf.org; Mon, 20 Mar 2006 10:17:06 -0500 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2KFH4Qj021889 for ; Mon, 20 Mar 2006 08:17:04 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2KFH3da012266 for ; Mon, 20 Mar 2006 08:17:03 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2KFH16m029352 for ; Mon, 20 Mar 2006 09:17:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2KFH1Kd029351 for dix@ietf.org; Mon, 20 Mar 2006 09:17:01 -0600 (CST) Date: Mon, 20 Mar 2006 09:17:01 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] Apparea meeting: Questions about DIX in meeting now! Message-ID: <20060320151700.GO27125@binky.Central.Sun.COM> References: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> User-Agent: Mutt/1.5.7i 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 On Mon, Mar 20, 2006 at 04:11:16PM +0100, Carsten Bormann wrote: > If you are in Dallas, run, not walk, to Cortez A -- there will be > some pre-BOF discussion of DIX in the apparea meeting. I can't get on the room. What's wrong with it? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 10:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMBK-0005ES-7v; Mon, 20 Mar 2006 10:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMBJ-0005EN-4D for dix@ietf.org; Mon, 20 Mar 2006 10:20:29 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMBH-0006E8-NJ for dix@ietf.org; Mon, 20 Mar 2006 10:20:29 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k2KFKJjC018220; Mon, 20 Mar 2006 16:20:20 +0100 (CET) In-Reply-To: <20060320151502.GY29498@lavazza.does-not-exist.org> References: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> <20060320151502.GY29498@lavazza.does-not-exist.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [dix] Apparea meeting: Questions about DIX in meeting now! Date: Mon, 20 Mar 2006 16:20:18 +0100 To: Thomas Roessler X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF DIX list X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Mar 20 2006, at 16:15 , Thomas Roessler wrote: > What jabber room corresponds to this meeting? apparea at rooms.jabber.ietf.org Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 10:20:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMBm-0005TP-F8; Mon, 20 Mar 2006 10:20:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMBl-0005QQ-DY for dix@ietf.org; Mon, 20 Mar 2006 10:20:57 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMBl-0006Es-0O for dix@ietf.org; Mon, 20 Mar 2006 10:20:57 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k2KFKJjD018220; Mon, 20 Mar 2006 16:20:53 +0100 (CET) In-Reply-To: <20060320151700.GO27125@binky.Central.Sun.COM> References: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> <20060320151700.GO27125@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [dix] Apparea meeting: Questions about DIX in meeting now! Date: Mon, 20 Mar 2006 16:20:50 +0100 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Mar 20 2006, at 16:17 , Nicolas Williams wrote: > I can't get on the room. What's wrong with it? The physical room is in the Westend part of the Hotel. Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 11:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNAK-0001vZ-6f; Mon, 20 Mar 2006 11:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNAJ-0001vU-Aq for dix@ietf.org; Mon, 20 Mar 2006 11:23:31 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNAF-0000EU-2t for dix@ietf.org; Mon, 20 Mar 2006 11:23:31 -0500 Received: from dirk.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 54CEC4F255; Mon, 20 Mar 2006 11:23:26 -0500 (EST) From: Dan Connolly To: John Merrells In-Reply-To: <222B6BC4-5443-4D5E-9FBA-AE1A37C00A97@sxip.com> References: <9c3013570416d0aeecce05962b90eedb@w3.org> <222B6BC4-5443-4D5E-9FBA-AE1A37C00A97@sxip.com> Content-Type: text/plain Organization: World Wide Web Consortium (http://www.w3.org/) Date: Mon, 20 Mar 2006 10:23:25 -0600 Message-Id: <1142871805.12963.57.camel@dirk.w3.org> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Digital Identity Exchange , public-ietf-w3c@w3.org Subject: [dix] Re: DIX/SXIP delegation tag, HTML LINK rel, 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 On Fri, 2006-03-17 at 15:41 -0800, John Merrells wrote: > On 17-Mar-06, at 1:29 PM, Dan Connolly wrote: > > > I note the draft doesn't include a normative reference to any HTML > > specifications. Please > > add one. > > Yes, my error. I will add to the next draft. > > > Also, the proposed charter ( http://dixs.org/index.php/ > > DIX_Charter ) does not make > > any connection to HTML. Please add something to note that use of > > HTML syntax, > > especially extensibility mechanisms like rel and profile, is in > > scope, in order to attract > > review from relevant experts. > > That might be presumptive... the charter only mentions HTML in the > context of a > HTTP transport binding and then only as an example way of encoding a > message. OK, but if the charter does _not_ mention work on HTML, then HTML experts will not get signalled to take a look. I'm OK with that *only* if the DIX WG is bound to *not use* any HTML syntax in order to interoperate. My understanding is that DIX is currently deployed, to some extent, and that to interoperate with the deployed services, you have to do some HTML stuff. The charter should err on the side of noting all communities of experties that might be relevant. > The current interest in improving/extending/fixing HTTP-AUTH comes to > mind as > a possible alternative/substitute mechanism. > > John -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 12:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNnu-0005YT-Fq; Mon, 20 Mar 2006 12:04:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLNnh-0005YI-7A for dix@ietf.org; Mon, 20 Mar 2006 12:04:13 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLNnf-0001w6-QL for dix@ietf.org; Mon, 20 Mar 2006 12:04:13 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k2KH47Rf020399; Mon, 20 Mar 2006 18:04:08 +0100 (CET) In-Reply-To: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> References: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Mon, 20 Mar 2006 11:04:06 -0600 To: Carsten Bormann X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF DIX list Subject: [dix] Re: Apparea meeting: Questions about DIX in meeting now! X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Mar 20 2006, at 09:11 , Carsten Bormann wrote: > If you are in Dallas, run, not walk, to Cortez A -- there will be > some pre-BOF discussion of DIX in the apparea meeting. Damage was limited. Not many people there who knew what DIX is trying to do (and those who did know didn't want to fuel premature discussion). Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 12:54:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOaP-0004iX-Dn; Mon, 20 Mar 2006 12:54:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLMWx-0001af-5d for dix@ietf.org; Mon, 20 Mar 2006 10:42:51 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLMWt-00071f-4k for dix@ietf.org; Mon, 20 Mar 2006 10:42:50 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2KFgk8u008503 for ; Mon, 20 Mar 2006 08:42:46 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWF00G01NJ77500@mail-amer.sun.com> (original mail from tbray@textuality.com) for dix@ietf.org; Mon, 20 Mar 2006 08:42:46 -0700 (MST) Received: from [192.168.1.39] ([216.113.204.157]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWF008W4NN92JK2@mail-amer.sun.com>; Mon, 20 Mar 2006 08:42:45 -0700 (MST) Date: Mon, 20 Mar 2006 07:42:57 -0800 From: Tim Bray Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP In-reply-to: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> To: Dick Hardt Message-id: <8024A864-1867-434B-98E2-FC244309280E@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Mon, 20 Mar 2006 12:54:32 -0500 Cc: Digital Identity Exchange , uri@w3.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: , Errors-To: dix-bounces@ietf.org On Mar 20, 2006, at 6:54 AM, Dick Hardt wrote: > Agree that we need to make good use of scarce community resources. On top of which, using an "http:" URI has the huge advantage that you can put something useful there that a human being can point their browser at and learn something about what this string means. I'd advise those who are promoting the new URI scheme to check out the remarks about URI schemes in http://www.w3.org/TR/webarch/ and in particular http://www.w3.org/TR/webarch/#URI-scheme - when you are doing something that flies in the face of a SHOULD recommendation in the "Architecture of the World Wide Web", you need to have really thought it through. > The reasoning behind introducing a new scheme was we need an escape > sequence for processing the name/value pairs and to differentiate > data from constants etc.. Anything starting with "dix:" is known to > be a constant. Anything else is not. :) -- one of the reasons for > this is that we want to be able to pass through name/value pairs > that a web application may be using to preserve state. We think the > likelihood that any existing app have strings that start with > "dix:/" to be, well, really really small. You're saying that you need a reliable way to ascertain that this identifier contains name-value pairs that should be processed per DIX? Can this be established by context? Any other signaling mechanisms? If not, then why are you buying into all the expectations and culture that go with using a URI, why not just use an opaque string or a chunk of XML or ";"-separated name-value pairs or whatever? A URI is supposed to identify a resource, and a common expectation is that one way or another, you can use it to retrieve information. If you avoid specifying one particular scheme, you leave the door open for different modes of information retrieval down the road. > Does this make sense? Do you have a suggestion for another approach > that provides an escape mechanism and allows decentralized > property /capability extension? In general, naming things with URIs is a good and Web-friendly thing to do; as you point out, the use of the authority field allows distributed authority over parts of the namespace. In particular, HTTP URIs have a lot of advantages. -Tim _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 12:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOd3-00064F-1t; Mon, 20 Mar 2006 12:57:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOd1-00063c-6c for dix@ietf.org; Mon, 20 Mar 2006 12:57:15 -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 1FLOcz-0003uA-Nu for dix@ietf.org; Mon, 20 Mar 2006 12:57:15 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id F2E674C6396; Mon, 20 Mar 2006 10:57:17 -0700 (MST) Message-ID: <441EECFD.5070506@jabber.org> Date: Mon, 20 Mar 2006 10:57:17 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP References: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> <8024A864-1867-434B-98E2-FC244309280E@textuality.com> In-Reply-To: <8024A864-1867-434B-98E2-FC244309280E@textuality.com> 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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: uri@w3.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="===============1630427163==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1630427163== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090301030604090901060406" This is a cryptographically signed message in MIME format. --------------ms090301030604090901060406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Bray wrote: > On Mar 20, 2006, at 6:54 AM, Dick Hardt wrote: > >> Agree that we need to make good use of scarce community resources. > > On top of which, using an "http:" URI has the huge advantage that you > can put something useful there that a human being can point their > browser at and learn something about what this string means. > > I'd advise those who are promoting the new URI scheme to check out the > remarks about URI schemes in http://www.w3.org/TR/webarch/ and in > particular http://www.w3.org/TR/webarch/#URI-scheme - when you are doing > something that flies in the face of a SHOULD recommendation in the > "Architecture of the World Wide Web", you need to have really thought it > through. Agreed. See also RFC 4395: http://www.ietf.org/rfc/rfc4395.txt Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEHuz9NF1RSzyt3NURAhuSAKDZ8LYX7/h0xLilr3oo8JisQVNi2gCffZww Xfs0dgJziy9VM0PD6uVuLG4= =S80K -----END PGP SIGNATURE----- --------------ms090301030604090901060406 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 hkiG9w0BCQUxDxcNMDYwMzIwMTc1NzE3WjAjBgkqhkiG9w0BCQQxFgQUnPSdsJL59p0linK8 HD9aFV/eP+UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBALf7c+ZKm04iUZhza3uEL/q+n5rzj1vL t5RU1S3v169YDSZl6Ausa5ZU9o88BlIvPml/GkKxjd9Qopn7JgaslRnx5EAcZN+QxP5dahKF v5OBTDgh8Z7YxQW7sqCr43R6tlCDMd5ow+2FZiWy6YlOrr+FyZZh9YU5qKEcY7aAK0U3akPV sr2UQ/ZrR8SjocUksvz3bZl5TWIw0akMT1JdDhih2LG3wISs6Fg36FziGAX4/4WIYGBHu/C/ rW6LyHi4p4HCmuL/72J6PjYR7WecmAWyu3rueQH9gga7lbaaFqwonqy1GNBislwbXK63IQor gEuBqFVX3vTRqPwnJpNcVy4AAAAAAAA= --------------ms090301030604090901060406-- --===============1630427163== 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 --===============1630427163==-- From dix-bounces@ietf.org Mon Mar 20 13:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOoI-00069w-VT; Mon, 20 Mar 2006 13:08:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOoH-00067l-F7 for dix@ietf.org; Mon, 20 Mar 2006 13:08:53 -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 1FLOoF-0004Qs-Mn for dix@ietf.org; Mon, 20 Mar 2006 13:08:53 -0500 Received: from [10.0.1.2] ([204.96.115.70]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2KI8mvs031757 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 20 Mar 2006 10:08:49 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <45D459DDA07DC442A499A4D46F4939BA0171CC92@MOU1WNEXMB02.vcorp.ad.vrsn.com> References: <45D459DDA07DC442A499A4D46F4939BA0171CC92@MOU1WNEXMB02.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CE38B18-2295-4993-955A-02FA41E0A714@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] some dmd1 comments Date: Mon, 20 Mar 2006 12:08:44 -0600 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 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: , Errors-To: dix-bounces@ietf.org On 19-Mar-06, at 10:11 PM, Granqvist, Hans wrote: > Just a few comments/questions while reading the latest draft, > which by the way is *not* in text but html format at > http://dixs.org/index.php/Draft-merrells-dix-01.txt (grrr) Sorry, that revision was too late to be published through ietf.org. You'll find 00 here: http://www.ietf.org/internet-drafts/draft-merrells-dix-00.txt Thanks for the rest of your comments. I'll reply and reflect them into an updated draft after the DIX BOF tomorrow. John > --- > In 5.3. Capability URI : > > If capability is equal to '1*ALPHA' then it's impossible to say > whether a capability is dix or non-dix since a capability > could contain a dot ('.'). (Perhaps 'ALPHA' is not properly > defined -- the character set of ALPHA used elsewhere contains > the dot.) > --- > > In 5.8. Capability Revisions > > "From that point in the document onwards is what is included in > 'dix://sxip.net/simple#34'." > > I had to read this sentence a few times to understand. Can it > be reworded? > --- > > In 5.9.1.1. dix:/core#1 > > "Core DIX protocol capabilities. The simple usage profile. Our > assumptions are: low security, low risk identity transaction, > data is > > moving over HTTP(S), low risk from replay attack." > > What do these assumptions mean, for example "low security"? And is it > possible to assume which transport is used -- does it even make sense > if DIX is defined to be transport agnostic? > --- > > 5.10.1.1. Membersite Cookie (Dumb Client) > > "Once a user has visited a Membersite and identified the name of > their > Homesite that Membersite can cookie the user with their choice of > Homesite, so that it can be filled in automatically for them in the > future." > > The verb "to cookie someone" seems a bit over the top. :) > --- > > 5.10.1.2. User Prompt > > "Homsite Path" > > Just a spelling mistake. > > "The attributes of the FORM tag are: > > o CLASS attribute must contain 'sxip', which denotes to a smart > client that the form was generated by a DIX aware Membersite." > > There is a 'sxip' reference requirement here that I don't understand. > --- > > 5.10.1.4. Homesite Inspection > > "The Membersite must now determine the Endpoint URL and the > Capabilities of the User's Homesite. The Membersite uses the > Homesite > > Tag Inspection Algorithm to discover the Homesite Tag." > > This algorithm is undefined by name in the document. > > "The Homesite Tag is used to specify the Endpoint URL and > Capabilities > of a Homesite. The HTML LINK tag is used for this. The LINK tag > is . > . ." > > All of a sudden there is a dependency on HTML here, which really > should > be stated up-front in the document, I think. > --- > > 5.10.2.2. Digest Generation > > "th'dix:/signature'" > > Another spelling mistake (I hope! ;) > > "Signature = T ( S + Digest )" > > I am sure this is intentionally simplified in the document, but > since this is technically not a correct HMAC, it should be > reworded. (The concat is different, see RFC2104) > --- > > 5.10.2.7. Message Canonicalization > > '. apply the following URI encodings to keys and values: > . all "=" are encoded to "%3D", note the uppercase 'D' > . all "&" are encoded to "%26" > . all "%" are encoded to "%25"' > > What about other characters that are normally encoded? Are they > intentionally excluded? > > '. byte-order sort all joined pairs > . join all joined pairs into one string with "&" as a separator' > > I am confused what this means. An example would help! > > > That's it so far . . . > Hans > > > > _______________________________________________ > 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 Mar 20 15:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR1S-0002SR-RU; Mon, 20 Mar 2006 15:30:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR1R-0002SM-MJ for dix@ietf.org; Mon, 20 Mar 2006 15:30:37 -0500 Received: from mx1.myoutlookonline.com ([69.25.74.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLR1Q-00020z-Cg for dix@ietf.org; Mon, 20 Mar 2006 15:30:37 -0500 Received: from be022.mail.lan ([10.109.209.122]) by mX1.myOutlookonline.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 15:30:35 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 15:30:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OpenID 1.1 Protocol Flow Diagram Thread-Index: AcZMXRaN7/IAaHwiTIiV9wlIkdJn7A== From: "David Recordon" To: "Yadis list" , X-OriginalArrivalTime: 20 Mar 2006 20:30:35.0642 (UTC) FILETIME=[249A9DA0:01C64C5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [dix] OpenID 1.1 Protocol Flow Diagram X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Created this flow diagram last night to document how the current OpenID spec works. Please let me know if you have questions or if I managed to mess something up in it. http://www.openid.net/pres/protocolflow-1.1.png --David _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 16:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRWj-00045x-8S; Mon, 20 Mar 2006 16:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRWh-00045k-8s for dix@ietf.org; Mon, 20 Mar 2006 16:02:55 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLR4O-000241-GQ for dix@ietf.org; Mon, 20 Mar 2006 15:33:40 -0500 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLQod-0003ZO-0G for dix@ietf.org; Mon, 20 Mar 2006 15:17:25 -0500 Received: from [10.0.1.3] ([204.96.115.70]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2KKHGpO037311 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 20 Mar 2006 12:17:18 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <2CABFB936653948534537D63@dhcp-wireless-131-69.ietf65.org> References: <2CABFB936653948534537D63@dhcp-wireless-131-69.ietf65.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Mon, 20 Mar 2006 14:17:15 -0600 To: Digital Identity Exchange , HTTP authentication list X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: -1.1 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Cyrus Daboo , Sam Hartman Subject: [dix] Dinner Logistics X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 We are thinking 8PM @ La Esquina (the mexican restaurant in Atrium II) John and I will be there @ 7 to score some tables if anyone wants to come by earlier. fyi: my cel is 415.846.4549 -- Dick On 20-Mar-06, at 3:11 PM, Cyrus Daboo wrote: > Hi Sam, > > --On March 20, 2006 11:16:12 AM -0500 Sam Hartman ietf@mit.edu> wrote: > >> Where are we meeting? > > I think we were planning on tying in with the DIX folks. Does > anyone know what there arrangements are? Failing that we just meet > at the message board after the last session and go from there... > > -- > Cyrus Daboo > > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 16:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRxD-0004G7-Vv; Mon, 20 Mar 2006 16:30:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRxC-0004FI-De for dix@ietf.org; Mon, 20 Mar 2006 16:30:18 -0500 Received: from [65.160.19.104] (helo=alfons.r-objects.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRx9-0004gI-1M for dix@ietf.org; Mon, 20 Mar 2006 16:30:18 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by alfons.r-objects.com (Postfix) with ESMTP id A8E2A28AA30 for ; Mon, 20 Mar 2006 13:30:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <1ECE9319-5006-40F9-8502-ACCFB35E77A6@netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: Johannes Ernst Date: Mon, 20 Mar 2006 13:30:07 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 2.5 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [dix] Yadis 1.0 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 [When asking for feedback on this from some of the Yadis folks, a number of people wanted to "sign up" to it ... their signatures are below... this is by no means an exhaustive list ... all errors are mine, of course.] Last October, Six Apart and NetMesh announced the Yadis project, an open community and protocol standard for making light-weight identity systems interoperable, starting with OpenID and LID. The i-names community (on the OASIS XRI standards track) joined immediately because they share much of the same vision, and the community has steadily grown since. As many on this mailing list are certainly aware already, the Yadis community has recently produced Yadis 1.0, a very simple but also very powerful specification that accomplishes this. (download from http://yadis.org/ ) So far there are about half dozen Yadis different implementations in a variety of languages from a variety of vendors, most of them open- source software. Some of the more visible sites that implement Yadis and one or more of the underling identity technologies (such as OpenID and LID): * livejournal.com * myopenid.com * schtuff.com * mylid.net There are many others, and this does not count sites that haven't upgraded to Yadis yet from OpenID or LID. It's a bit difficult to estimate how many Yadis/OpenID/LID/i-name- enabled identities are on-line, because Yadis is fully decentralized, but one number that has been given is about 15,000,000. I've been asked repeatedly how I think Yadis and any new IETF effort could and should relate. On one hand, there is certainly no lack of existing identity technologies. On the other hand, many good arguments have been made why any one of them does not apply to all scenarios. From our perspective, the most valuable effort would be to try to simplify and to bring them closer together, leveraging each other's work, instead of adding to the fragmentation that exists already by adding another incompatible protocol, whatever its merits. On the other hand, the IETF is probably better positioned to do work of that kind than many other identity standards organizations. So I'd like to provide the following input for the upcoming BOF: 1) Some information: the Yadis 1.0 specification, and the underlying OpenID and LID specifications. As a minimum, people contemplating a new IETF effort should be aware of these. 2) A question: do attendees prefer to add a new identity specification to the ever- growing list of identity specifications, or focus on their energies on simplifying and integrating what's there already? 3) An offer: to be aware of, and potentially get involved, with the Yadis community. See http://yadis.org/ Best regards, Johannes Ernst NetMesh Inc. Larry Drebes JanRain Inc. David Recordon LiveJournal Six Apart, Ltd. Kristopher Tate BlueBridge Inc Drummond Reed Cordance Corp. Scott Kveton Jason McKerr Open Source Labs - Oregon State _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 20 19:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUQV-00031z-QF; Mon, 20 Mar 2006 19:08:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUQU-00031p-Fk for dix@ietf.org; Mon, 20 Mar 2006 19:08:42 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUQT-00039j-4f for dix@ietf.org; Mon, 20 Mar 2006 19:08:42 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2L097UX002174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Mar 2006 16:09:10 -0800 Message-ID: <441F43FB.2030705@dcrocker.net> Date: Mon, 20 Mar 2006 18:08:27 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Re: Apparea meeting: Questions about DIX in meeting now! References: <4B0BA7D8-4DE9-4A49-B8D4-80DE136BF73C@tzi.org> 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: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >> If you are in Dallas, run, not walk, to Cortez A -- there will be some >> pre-BOF discussion of DIX in the apparea meeting. > > Damage was limited. Not many people there who knew what DIX is trying > to do (and those who did know didn't want to fuel premature discussion). I think there was no damage, nor should there have been any. As I said when I asked about DIX in that meeting, I was not seeking discussion. That's what the BOF is for. I merely wanted to gain wider awareness of the work, so that a broader range of Apps folks had some exposure to it. That goal was serviced nicely, 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 Mar 21 01:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLaVQ-0000Q2-D3; Tue, 21 Mar 2006 01:38:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLaVP-0000Pr-1e for dix@ietf.org; Tue, 21 Mar 2006 01:38:11 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLaVJ-0000Ci-B3 for dix@ietf.org; Tue, 21 Mar 2006 01:38:11 -0500 Received: from [198.18.101.77] ([12.5.73.162]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2L6cHJx009850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Mar 2006 22:38:33 -0800 Message-ID: <441F9F36.5030806@dcrocker.net> Date: Tue, 21 Mar 2006 00:37:42 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] problem / goals / benefits / requirements / use cases References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k2L6cHJx009850 X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd 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 Cautions: Lest anyone find themselves wondering, what follows is intended to = move towards explicit and precise language that we can all agree on. To do that, I had to question quite a bit of your text. The good news is that your text raised a lot of questions that I th= ink are basic and resolving them is likely to be extremely useful. Your extended example are quite good at making the usage of DIX concrete. (A minor question is how much group consensus there is that th= ese examples represent the range of DIX usage; I suspect the issue is not whe= ther the examples are "wrong" but whether they define the scope of DIX usage sufficiently.) I think the more terse language in the lists, at the beginning of y= our message, perhaps assume too much a priori understanding/context. Therefo= re, much of what I ask, in the following, is really intended to find languag= e for these lists that will have more common, immediate and precise meaning to = a wide range of readers. (By the way, the cost of your sending such a lengthy and thoughtful note = is a lengthy response. Whether it, too, is thoughtful, well... it tries to be= .) > Problem Statement >=20 > The Internet is host to many online information sources and services.=20 > There is a growing demand for users to identify, and provide informatio= n=20 > about themselves.=20 So, the focus of the DIX effort is about identification of users, as then= being able to (automatically) provide a range of attributes associated with tho= se users? (I believe others on the list see the scope as much more broad.) > Users bear the burden of managing their own > authentication materials and repeatedly providing their identity=20 > information. Signing in to web pages and completing user registration=20 > forms is an example. The examples are useful. However I clarifying what is meant by "authenti= cation=20 materials". Although I have my own guesses about what that term refers to, I suspect = each of us differs quite a bit in our guesses. And for a working group charter, = such guessing -- ie, non-overlap of basic terms of reference -- is highly prob= lematic. > Goals > Benefit Internet Users > Protocol adoption Unfortunately, the two goals you cite apply to all the work ever done for= IETF=20 standards. Hence the goals say nothing that is specific to this effort. That leaves us with an empty list of (distinctive) Goals. > Benefits ... > Browsing Efficiency =96 Reuse of Identity Data and authentication Browsing? So the focus of this group is strictly for web-based activity? No benefits for email, instant messaging, VOIP, etc? > Browsing Efficiency =96 Consistency of User Experience for providing da= ta What does this mean? > Reuse of Identity Data =96 Less data entry > Reuse of Authentication =96 Single Sign-On > Reuse of an Identifier =96 Persona and reputation building Does the group have consensus on the definition and use of "persona"? And what does it mean to do "persona building"? > Security =96 Consistent user experience This one sounds interesting. How does user experience consistency affect security? (Is there any empirical basis for this?) > Security =96 Stronger authentication more viable Really? How? Security people are rather demanding about justifications = for=20 such claims. > Privacy =96 Choice over what is stored where and released to whom > Privacy =96 Choice over the degree of relationship with a site: anonymo= us, > pseudo-anonymous, or public. [todo: see terms in Ben=92s referenced > document.] What work is DIX planning to do that will define and ensure that either o= f these happen? > Reuse of Verification Processes =96 By moving third-party claims betwee= n=20 > authority and site What do you mean 'third-party claims'? I assume that 'authority' refers = to whoever is making the claims? And what do you mean 'site'? > Data quality, quantity, and richness. > Lower latency in workflows for verifying self asserted data. > Higher conversion rates I do not understand any of these. > Identifier =96 an identifying attribute for a set of attributes. A single attribute is an identifier? I think that does not match the ear= lier definition. Plus, it seems a bit circular. An identifier is an identifying attribute? I don't really know what that means. > Identity Data =96 a set of attributes Any random set, or are their constraints? I suspect you mean some specif= ic=20 kinds of attributes. What are they? What attributes would NOT qualify? For example, I suspect you mean that the attributes are associated with t= he=20 entity being identified. > 1) Beth receives an email from a friend introducing her to a new=20 > website, geeknews.com, a site that publishes techie news articles. She=20 > browses the site and decides to read some articles. She sees an IN=20 > button, which she clicks. [Insert step 1.1, called out as it=92s reused= in=20 > many use cases.] Her identity agent displays a screen informing her tha= t=20 > geeknews.com is requesting some data, her first name. She enters =91Bet= h=92=20 > at the prompt, provides consent and the data is sent to the site.=20 > [Benefits: Choice of what is stored where and released to whom.=20 > Benefits: Consistent User Experience =96 She sees her agent=92s user=20 > interface every time she is asked for information.] This demonstrates how difficult it is to make the user experience "better= ". If the user must enter a variety of information, where only some of that information can be processed by DIX, then the user will experience the or= iginal form, generated by the server, AND the client-side DIX form. Having two different forms could be confusing and/or irritating to users,= =20 because it entails two different styles of forms. But notice that I said "could be". This is a usability question. I am c= ertain the problem is a possibility, but not certain it will occur. > 1.1) Her identity agent performs an authentication process to ensure=20 > that it is representing Beth, and not an imposter. The authentication=20 > mechanism used is implementation dependent. The identity agent may=20 > provide the benefit of caching the authentication for the duration of=20 > Beth=92s internet browsing session. [Benefit: Reuse of authentication,=20 > when coupled with other aspects provides single sign-on.] >=20 > 2) Beth browses to geekdate.com, she clicks an IN button. [1.1] Her=20 > identity agent displays a screen informing her that geekdate.com is=20 > requesting some data, her first name. From [1] her agent already has=20 > this data. She provides consent and the data is sent to the site.=20 > [Benefit: Less data entry. Benefit: Reuse of identity data. Benefit:=20 > Quality data.] "quality"? how the quality improved? > 3) Beth decides to create a profile at geekdate.com. Geekdate.com=20 > displays a registration form. One field requests a URL of a photo of=20 > her. Beside it is a SAVE button. She enters the UTL and clicks the=20 > button. [1.1] Her identity agent displays a screen informing her that=20 > this data item can be stored. She provides consent and the data is=20 > stored by her agent. [Benefit: Reuse of Identity Data. Benefits: Enable= d=20 > stateless sites that request the data they need for each session.=20 > Benefit: Persona building. Benefit: Choice of what is stored where.] How is this "persona building"? What does that mean? ... Here is what I'm getting from your text: DIX provides a standardized basis, for client-based interfaces: 1) to interact with the user and the user's environment, 2) to acquire a collection of information related to the user, based on r= equests=20 from servers, and 3) selectively provide this data to the requesting servers, based on user= =20 permissions and contextual aggregations specific to the relationship betw= een the=20 user and a particular service Are there functions i am missing or have gotten wrong? d/ --=20 Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 08:22:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLgok-0000hD-Ev; Tue, 21 Mar 2006 08:22:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLWwF-0001MT-Hz for dix@ietf.org; Mon, 20 Mar 2006 21:49:39 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLWwE-0000gN-0w for dix@ietf.org; Mon, 20 Mar 2006 21:49:39 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2L2nbTL017067 for ; Mon, 20 Mar 2006 21:49:37 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2L2qbwu137692 for ; Mon, 20 Mar 2006 19:52:37 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k2L2naEe003010 for ; Mon, 20 Mar 2006 19:49:37 -0700 Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k2L2naS6002992; Mon, 20 Mar 2006 19:49:36 -0700 Received: from wtfmail05a.lotus.com (wtfmail05a.lotus.com [9.33.9.125]) by internet1.lotus.com (8.13.2/8.13.2) with ESMTP id k2L2naW3015400; Mon, 20 Mar 2006 21:49:36 -0500 (EST) In-Reply-To: To: "McDonald, Ira" Subject: RE: [dix] on the dix: URI scheme for DIX/SXIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: noah_mendelsohn@us.ibm.com Date: Mon, 20 Mar 2006 21:49:34 -0500 X-MIMETrack: Serialize by Router on WTFMAIL05a/WTF/M/Lotus(Release 7.0.1|January 17, 2006) at 03/20/2006 09:49:34 PM, Serialize complete at 03/20/2006 09:49:34 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Tue, 21 Mar 2006 08:22:34 -0500 Cc: Digital Identity Exchange , uri@w3.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: , Errors-To: dix-bounces@ietf.org Ira McDonald writes: > Although I have mixed feelings about the logic, the brand new > RFC 4395 "Guidelines and Registration Procedures for > New URI Schemes" argues that the bar should be very high for a > new 'Permanent' URI scheme, because so many browsers > and other bits of client software will have to updated for the > URI scheme to become widely deployed and used. FWIW, I think that's sometimes among the reasons for viewing scheme names as scarce, but not the only reason or even the most widely applicable. As noted later in this thread, there are many potential schemes for which the required scheme-specific software would likely by quite isolated. As far as I'm concerned, the scheme names that are ultimately scarce are the ones that are simple to type and easy to remember, and especially those likely to be suggestive of particular real world concepts. If someone wanted to argue for schemes like: a1324987123904873209487: a8976872648574368573469848765: a3487687683687463874683: I would say they have a variety of important downsides, but scarcity isn't among them. (I'm showing scheme names with the trailing ":" even though that's not technically part of the name). On the other hand, if someone wants to have a scheme: phone: then that's it for all time. We can't come back in 20 years and decide we'd like to use the word phone for some more robust abstraction of phones, or for something entirely different. The situation with scheme names is aggravated by the fact that, like top level domain names, they are not fundamentally hierarchical per RFC 3986. One could build a hierarchical convention within scheme names (Roy occasionally suggests xxx.yyy), but then the xxx becomes the limited resource. Of all the potential uses of the three letters "dix" for a scheme name, is the proposed use likely to be among the most important over a period of, say, 50 years? If not, I think assignment of the scheme is suspect. It's in that sense that I see scheme names as scarce. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 08:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLh2x-0008W6-I0; Tue, 21 Mar 2006 08:37:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLh2w-0008Vi-B4 for dix@ietf.org; Tue, 21 Mar 2006 08:37:14 -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 1FLh2u-00085G-OP for dix@ietf.org; Tue, 21 Mar 2006 08:37:14 -0500 Received: from [10.0.1.2] ([204.96.115.70]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2LDb6Kd068491 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 21 Mar 2006 05:37:07 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <441F9F36.5030806@dcrocker.net> References: <441F9F36.5030806@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2FB44714-9733-401D-AD49-945D5DE6887C@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] problem / goals / benefits / requirements / use cases Date: Tue, 21 Mar 2006 07:37:00 -0600 To: dcrocker@bbiw.net, Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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-Mar-06, at 12:37 AM, Dave Crocker wrote: > Cautions: > > Lest anyone find themselves wondering, what follows is > intended to move > towards explicit and precise language that we can all agree on. > > To do that, I had to question quite a bit of your text. > > The good news is that your text raised a lot of questions that > I think are > basic and resolving them is likely to be extremely useful. Lots of really good questions Dave. Thanks! > Your extended example are quite good at making the usage of DIX > concrete. (A minor question is how much group consensus there is > that these > examples represent the range of DIX usage; I suspect the issue is > not whether > the examples are "wrong" but whether they define the scope of DIX > usage > sufficiently.) > > I think the more terse language in the lists, at the beginning > of your > message, perhaps assume too much a priori understanding/context. > Therefore, > much of what I ask, in the following, is really intended to find > language for > these lists that will have more common, immediate and precise > meaning to a wide > range of readers. Indeed. I should have perhaps defined terms up front and taken more time to edit into a clearer form. The good news is that my presentation materials for this morning's BOF are more focused and much clearer, especially wrt goals and benefits. I hope that they'll answer many of your questions. > (By the way, the cost of your sending such a lengthy and thoughtful > note is a > lengthy response. Whether it, too, is thoughtful, well... it tries > to be.) I'll reply more completely after the BOF. Thanks John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 09:07:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhWL-00063t-9Y; Tue, 21 Mar 2006 09:07:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhWK-00063o-N4 for dix@ietf.org; Tue, 21 Mar 2006 09:07:36 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhWJ-0000ae-Eb for dix@ietf.org; Tue, 21 Mar 2006 09:07:36 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BFDB11422B0; Tue, 21 Mar 2006 06:07:34 -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 27097-10; Tue, 21 Mar 2006 06:07:34 -0800 (PST) Received: from [130.129.133.236] (DHCP-Wireless-133-236.ietf65.org [130.129.133.236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 45C111422AD; Tue, 21 Mar 2006 06:07:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <441F9F36.5030806@dcrocker.net> References: <441F9F36.5030806@dcrocker.net> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <829DC2DD-A47A-45BF-A8F4-04ACCA2353C1@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [dix] problem / goals / benefits / requirements / use cases Date: Tue, 21 Mar 2006 08:07:29 -0600 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: 2409bba43e9c8d580670fda8b695204a 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 Mar 21, 2006, at 12:37 AM, Dave Crocker wrote: > >> Security =96 Consistent user experience > > This one sounds interesting. How does user experience consistency =20 > affect > security? (Is there any empirical basis for this?) > The good news is that there are certainly people working on =20 developing an empirical basis for this. At last week's W3C Workshop =20 on Web Authentication, this was a major topic of discussion in the =20 room and in several position papers . If you run into Stuart Schecter at this IETF, =20= be sure to talk to him about the work MIT Lincoln Labs are doing on =20 the topic. At the risk of oversimplifying, the argument is that if users are =20 very familiar with one frequently-used self-identification mechanism =20 (which may be a password login), then it will be that much more =20 difficult for bad actors to "phish" the user to provide credentials =20 to any agent other than the real provider of that mechanism. Lisa= _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 10:09:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiUe-0004L2-NR; Tue, 21 Mar 2006 10:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiUd-0004Jm-Cl for dix@ietf.org; Tue, 21 Mar 2006 10:09:55 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiUb-00037W-Vr for dix@ietf.org; Tue, 21 Mar 2006 10:09:55 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LFAGFY000754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 07:10:18 -0800 Message-ID: <44201737.2030309@dcrocker.net> Date: Tue, 21 Mar 2006 09:09:43 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [dix] problem / goals / benefits / requirements / use cases References: <441F9F36.5030806@dcrocker.net> <829DC2DD-A47A-45BF-A8F4-04ACCA2353C1@osafoundation.org> In-Reply-To: <829DC2DD-A47A-45BF-A8F4-04ACCA2353C1@osafoundation.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > At the risk of oversimplifying, the argument is that if users are very > familiar with one frequently-used self-identification mechanism (which > may be a password login), then it will be that much more difficult for > bad actors to "phish" the user to provide credentials to any agent other > than the real provider of that mechanism. Indeed that is a reasonable hypothesis. My constant question, about anything pertaining to user impact, is whether there is empirical data to support it. Users have this nasty tendency to react in unexpected way -- or rather, to be sensitive to issues that were not part of the model. Therefore, innovative UI design that predicts user behavior, without careful testing, usually fails. At any rate, thanks for the pointer. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 10:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLia8-0007N7-Uu; Tue, 21 Mar 2006 10:15:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLia7-0007My-I1 for dix@ietf.org; Tue, 21 Mar 2006 10:15:35 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLia6-0003Kz-5J for dix@ietf.org; Tue, 21 Mar 2006 10:15:35 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LFFxjo001739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 07:16:01 -0800 Message-ID: <4420188E.4020904@dcrocker.net> Date: Tue, 21 Mar 2006 09:15:26 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] problem / goals / benefits / requirements / use cases References: <441F9F36.5030806@dcrocker.net> In-Reply-To: <441F9F36.5030806@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 > Here is what I'm getting from your text: > > DIX provides a standardized basis, for client-based interfaces: > > 1) to interact with the user and the user's environment, > > 2) to acquire a collection of information related to the user, based on > requests from servers, and > > 3) selectively provide this data to the requesting servers, based on > user permissions and contextual aggregations specific to the > relationship between the user and a particular service A few more thoughts have occurred to me: User contact with remote services often requires that the user supply a variety of information. The information might be appropriate to supply to many different services or it might be specific to a particular relationship between that user and a single service. The DIX effort will define: a) a common framework for representing user-specific information, based on an attribute/value model (identity-related attribute format) b) an initial set of attribute definitions c) one or more means (protocols) for requesting and exchanging user-specific attributes on behalf of the user. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 12:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkjE-00086u-Ou; Tue, 21 Mar 2006 12:33:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkjD-00086n-Sr for dix@ietf.org; Tue, 21 Mar 2006 12:33:07 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkjC-0000i7-MT for dix@ietf.org; Tue, 21 Mar 2006 12:33:07 -0500 Received: from [127.0.0.1] (stdhcp-139.va.neustar.com [10.31.13.139]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2LHX49X002707 for ; Tue, 21 Mar 2006 17:33:06 GMT Message-ID: <442038CB.5080605@neustar.biz> Date: Tue, 21 Mar 2006 09:32:59 -0800 From: Jeff Hodges 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: multipart/mixed; boundary="------------030003010102030307040301" X-Spam-Score: 0.5 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [dix] fyi: SIP SAML Profile and Binding X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 a multi-part message in MIME format. --------------030003010102030307040301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: [security-services] fyi: SIP SAML Profile and Binding Date: Thu, 09 Mar 2006 10:03:23 -0800 From: Jeff Hodges To: oasis sstc Here is an example of crafting a new SAML profile and a new SAML binding in the context of some particular protocol family, in this case SIP. JeffH -------- Original Message -------- Subject: I-D ACTION:draft-tschofenig-sip-saml-05.txt Date: Wed, 08 Mar 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP SAML Profile and Binding Author(s) : H. Tschofenig, et al. Filename : draft-tschofenig-sip-saml-05.txt Pages : 43 Date : 2006-3-8 This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt --- end --------------030003010102030307040301 Content-Type: Message/External-body; name="draft-tschofenig-sip-saml-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-tschofenig-sip-saml-05.txt" Content-Type: text/plain Content-ID: <2006-3-8115828.I-D@ietf.org> --------------030003010102030307040301 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 --------------030003010102030307040301-- From dix-bounces@ietf.org Tue Mar 21 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 1FLlEA-0002yD-6g; Tue, 21 Mar 2006 13:05:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlE9-0002y8-EO for dix@ietf.org; Tue, 21 Mar 2006 13:05:05 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlE8-0002MI-21 for dix@ietf.org; Tue, 21 Mar 2006 13:05:05 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k2LI4wZq025683; Tue, 21 Mar 2006 19:04:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Tue, 21 Mar 2006 12:04:56 -0600 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [dix] So what went wrong? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 My biased, personal, quick-shot-from-the-hip diagnosis (and I'd love to hear different views): -- The problem was not made clear -- too much apple pie, too little slicing; too much focus on individual requirements and not enough on the big picture. -- The Web 2.0 use case (titled "blogosphere") was foreign to much of the audience. -- There was no attempt made at a convincing case that existing stuff does not cut it on its own. -- The organization of the BOF succumbed to early derailing attempts, so not enough of the substance was actually presented -- it was not possible to establish enough common ground for reasonable discussion. -- The whole time, apart from the many interested spectators, there were two fractions: 1) people who think in terms of a different problem space, already know the solutions for that and somehow are confident that the (not very clear) problems at hand can be solved with these as well, and 2) people who think in term of the DIX problem space but were inhibited from talking about how their solutions have significantly different properties from the Enterprise ones. In the end I felt like I sat in a BOF trying to sell SMTP to an X.400 crowd (and yes, I'm old enough to have been there). Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 13:18:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlRW-0002v7-Up; Tue, 21 Mar 2006 13:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlRW-0002v2-Fj for dix@ietf.org; Tue, 21 Mar 2006 13:18:54 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLlRW-0002oj-0Y for dix@ietf.org; Tue, 21 Mar 2006 13:18:54 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k2LIIqJ3018496 for ; Tue, 21 Mar 2006 13:18:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] So what went wrong? Date: Tue, 21 Mar 2006 13:18:52 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5160A06@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] So what went wrong? Thread-Index: AcZNEgnxpGd/M/YvSY6ve65LkglO3AAASuVM References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> From: "Michael Slavitch" To: "Digital Identity Exchange" , "Digital Identity Exchange" X-Spam-Score: 0.00 () [Tag at 15.00] HTML_MESSAGE X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1503611261==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1503611261== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64D13.E888768E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64D13.E888768E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Disposition: inline Q29tZSB0byB0aGUgUDJQU2xQIEJPRi4gWW91IHdpbGwgZmVlbCAgd2VsY29t ZS4NCkZpbmQgbWUgYW5kIGxsJ2xsIGV4cGxhaW4uDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFp bHRvOmNhYm9AdHppLm9yZ10NClNlbnQ6IFR1ZSAyMS8wMy8yMDA2IDE6MDQg UE0NClRvOiBEaWdpdGFsIElkZW50aXR5IEV4Y2hhbmdlDQpTdWJqZWN0OiBb ZGl4XSBTbyB3aGF0IHdlbnQgd3Jvbmc/DQogDQpNeSBiaWFzZWQsIHBlcnNv bmFsLCBxdWljay1zaG90LWZyb20tdGhlLWhpcCBkaWFnbm9zaXMgKGFuZCBJ J2QgbG92ZSAgDQp0byBoZWFyIGRpZmZlcmVudCB2aWV3cyk6DQoNCi0tIFRo ZSBwcm9ibGVtIHdhcyBub3QgbWFkZSBjbGVhciAtLSB0b28gbXVjaCBhcHBs ZSBwaWUsIHRvbyBsaXR0bGUgIA0Kc2xpY2luZzsgDQp0b28gbXVjaCBmb2N1 cyBvbiBpbmRpdmlkdWFsIHJlcXVpcmVtZW50cyBhbmQgbm90IGVub3VnaCBv biB0aGUgYmlnICANCnBpY3R1cmUuDQoNCi0tIFRoZSBXZWIgMi4wIHVzZSBj YXNlICh0aXRsZWQgImJsb2dvc3BoZXJlIikgd2FzIGZvcmVpZ24gdG8gbXVj aCBvZiAgDQp0aGUgYXVkaWVuY2UuDQoNCi0tIFRoZXJlIHdhcyBubyBhdHRl bXB0IG1hZGUgYXQgYSBjb252aW5jaW5nIGNhc2UgdGhhdCBleGlzdGluZyBz dHVmZiAgDQpkb2VzIG5vdCBjdXQgaXQgb24gaXRzIG93bi4NCg0KLS0gVGhl IG9yZ2FuaXphdGlvbiBvZiB0aGUgQk9GIHN1Y2N1bWJlZCB0byBlYXJseSBk ZXJhaWxpbmcgYXR0ZW1wdHMsICANCnNvIG5vdCBlbm91Z2ggb2YgdGhlIHN1 YnN0YW5jZSB3YXMgYWN0dWFsbHkgcHJlc2VudGVkIC0tIGl0IHdhcyBub3Qg IA0KcG9zc2libGUgdG8gZXN0YWJsaXNoIGVub3VnaCBjb21tb24gZ3JvdW5k IGZvciByZWFzb25hYmxlIGRpc2N1c3Npb24uDQoNCi0tIFRoZSB3aG9sZSB0 aW1lLCBhcGFydCBmcm9tIHRoZSBtYW55IGludGVyZXN0ZWQgc3BlY3RhdG9y cywgdGhlcmUgIA0Kd2VyZSB0d28gZnJhY3Rpb25zOiANCg0KMSkgcGVvcGxl IHdobyB0aGluayBpbiB0ZXJtcyBvZiBhIGRpZmZlcmVudCBwcm9ibGVtIHNw YWNlLCBhbHJlYWR5ICANCmtub3cgdGhlIHNvbHV0aW9ucyBmb3IgdGhhdCBh bmQgc29tZWhvdyBhcmUgY29uZmlkZW50IHRoYXQgdGhlIChub3QgIA0KdmVy eSBjbGVhcikgcHJvYmxlbXMgYXQgaGFuZCBjYW4gYmUgc29sdmVkIHdpdGgg dGhlc2UgYXMgd2VsbCwgYW5kDQoNCjIpIHBlb3BsZSB3aG8gdGhpbmsgaW4g dGVybSBvZiB0aGUgRElYIHByb2JsZW0gc3BhY2UgYnV0IHdlcmUgIA0KaW5o aWJpdGVkIGZyb20gdGFsa2luZyBhYm91dCBob3cgdGhlaXIgc29sdXRpb25z IGhhdmUgc2lnbmlmaWNhbnRseSAgDQpkaWZmZXJlbnQgcHJvcGVydGllcyBm cm9tIHRoZSBFbnRlcnByaXNlIG9uZXMuDQoNCkluIHRoZSBlbmQgSSBmZWx0 IGxpa2UgSSBzYXQgaW4gYSBCT0YgdHJ5aW5nIHRvIHNlbGwgU01UUCB0byBh biBYLjQwMCAgDQpjcm93ZCAoYW5kIHllcywgSSdtIG9sZCBlbm91Z2ggdG8g aGF2ZSBiZWVuIHRoZXJlKS4NCg0KR3J1ZXNzZSwgQ2Fyc3Rlbg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpkaXggbWFpbGluZyBsaXN0DQpkaXhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpeA0KDQoNCi0tIA0KDQoN CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9u LCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJv dGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBp bmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFu eW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJv aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Np b24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3Ig cmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5k ZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiANCg0KQW55IHZpZXdzLCBvcGluaW9ucyBhbmQgY29udGVudCBw cmVzZW50ZWQgaW4gdGhpcyBlLW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0 aGUgYXV0aG9yIGFuZCBtYXkgbm90IHJlcHJlc2VudCB0aG9zZSBvZiBPYmpl Y3R3b3JsZCBDb21tdW5pY2F0aW9ucyBDb3JwLiAK ------_=_NextPart_001_01C64D13.E888768E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 Content-Disposition: inline PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8v RU4iPg0KPEhUTUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRl bnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4N CjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhjaGFuZ2Ug U2VydmVyIHZlcnNpb24gNi41Ljc2MzguMSI+DQo8VElUTEU+UkU6IFtkaXhd IFNvIHdoYXQgd2VudCB3cm9uZz88L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+ DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0K DQo8UD48Rk9OVCBTSVpFPTI+Q29tZSB0byB0aGUgUDJQU2xQIEJPRi4gWW91 IHdpbGwgZmVlbCZuYnNwOyB3ZWxjb21lLjxCUj4NCkZpbmQgbWUgYW5kIGxs J2xsIGV4cGxhaW4uPEJSPg0KPEJSPg0KPEJSPg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08QlI+DQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gWzxBIEhS RUY9Im1haWx0bzpjYWJvQHR6aS5vcmciPm1haWx0bzpjYWJvQHR6aS5vcmc8 L0E+XTxCUj4NClNlbnQ6IFR1ZSAyMS8wMy8yMDA2IDE6MDQgUE08QlI+DQpU bzogRGlnaXRhbCBJZGVudGl0eSBFeGNoYW5nZTxCUj4NClN1YmplY3Q6IFtk aXhdIFNvIHdoYXQgd2VudCB3cm9uZz88QlI+DQo8QlI+DQpNeSBiaWFzZWQs IHBlcnNvbmFsLCBxdWljay1zaG90LWZyb20tdGhlLWhpcCBkaWFnbm9zaXMg KGFuZCBJJ2QgbG92ZSZuYnNwOzxCUj4NCnRvIGhlYXIgZGlmZmVyZW50IHZp ZXdzKTo8QlI+DQo8QlI+DQotLSBUaGUgcHJvYmxlbSB3YXMgbm90IG1hZGUg Y2xlYXIgLS0gdG9vIG11Y2ggYXBwbGUgcGllLCB0b28gbGl0dGxlJm5ic3A7 PEJSPg0Kc2xpY2luZzs8QlI+DQp0b28gbXVjaCBmb2N1cyBvbiBpbmRpdmlk dWFsIHJlcXVpcmVtZW50cyBhbmQgbm90IGVub3VnaCBvbiB0aGUgYmlnJm5i c3A7PEJSPg0KcGljdHVyZS48QlI+DQo8QlI+DQotLSBUaGUgV2ViIDIuMCB1 c2UgY2FzZSAodGl0bGVkICZxdW90O2Jsb2dvc3BoZXJlJnF1b3Q7KSB3YXMg Zm9yZWlnbiB0byBtdWNoIG9mJm5ic3A7PEJSPg0KdGhlIGF1ZGllbmNlLjxC Uj4NCjxCUj4NCi0tIFRoZXJlIHdhcyBubyBhdHRlbXB0IG1hZGUgYXQgYSBj b252aW5jaW5nIGNhc2UgdGhhdCBleGlzdGluZyBzdHVmZiZuYnNwOzxCUj4N CmRvZXMgbm90IGN1dCBpdCBvbiBpdHMgb3duLjxCUj4NCjxCUj4NCi0tIFRo ZSBvcmdhbml6YXRpb24gb2YgdGhlIEJPRiBzdWNjdW1iZWQgdG8gZWFybHkg ZGVyYWlsaW5nIGF0dGVtcHRzLCZuYnNwOzxCUj4NCnNvIG5vdCBlbm91Z2gg b2YgdGhlIHN1YnN0YW5jZSB3YXMgYWN0dWFsbHkgcHJlc2VudGVkIC0tIGl0 IHdhcyBub3QmbmJzcDs8QlI+DQpwb3NzaWJsZSB0byBlc3RhYmxpc2ggZW5v dWdoIGNvbW1vbiBncm91bmQgZm9yIHJlYXNvbmFibGUgZGlzY3Vzc2lvbi48 QlI+DQo8QlI+DQotLSBUaGUgd2hvbGUgdGltZSwgYXBhcnQgZnJvbSB0aGUg bWFueSBpbnRlcmVzdGVkIHNwZWN0YXRvcnMsIHRoZXJlJm5ic3A7PEJSPg0K d2VyZSB0d28gZnJhY3Rpb25zOjxCUj4NCjxCUj4NCjEpIHBlb3BsZSB3aG8g dGhpbmsgaW4gdGVybXMgb2YgYSBkaWZmZXJlbnQgcHJvYmxlbSBzcGFjZSwg YWxyZWFkeSZuYnNwOzxCUj4NCmtub3cgdGhlIHNvbHV0aW9ucyBmb3IgdGhh dCBhbmQgc29tZWhvdyBhcmUgY29uZmlkZW50IHRoYXQgdGhlIChub3QmbmJz cDs8QlI+DQp2ZXJ5IGNsZWFyKSBwcm9ibGVtcyBhdCBoYW5kIGNhbiBiZSBz b2x2ZWQgd2l0aCB0aGVzZSBhcyB3ZWxsLCBhbmQ8QlI+DQo8QlI+DQoyKSBw ZW9wbGUgd2hvIHRoaW5rIGluIHRlcm0gb2YgdGhlIERJWCBwcm9ibGVtIHNw YWNlIGJ1dCB3ZXJlJm5ic3A7PEJSPg0KaW5oaWJpdGVkIGZyb20gdGFsa2lu ZyBhYm91dCBob3cgdGhlaXIgc29sdXRpb25zIGhhdmUgc2lnbmlmaWNhbnRs eSZuYnNwOzxCUj4NCmRpZmZlcmVudCBwcm9wZXJ0aWVzIGZyb20gdGhlIEVu dGVycHJpc2Ugb25lcy48QlI+DQo8QlI+DQpJbiB0aGUgZW5kIEkgZmVsdCBs aWtlIEkgc2F0IGluIGEgQk9GIHRyeWluZyB0byBzZWxsIFNNVFAgdG8gYW4g WC40MDAmbmJzcDs8QlI+DQpjcm93ZCAoYW5kIHllcywgSSdtIG9sZCBlbm91 Z2ggdG8gaGF2ZSBiZWVuIHRoZXJlKS48QlI+DQo8QlI+DQpHcnVlc3NlLCBD YXJzdGVuPEJSPg0KPEJSPg0KPEJSPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQpkaXggbWFpbGluZyBs aXN0PEJSPg0KZGl4QGlldGYub3JnPEJSPg0KPEEgSFJFRj0iaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGl4Ij5odHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXg8L0E+PEJSPg0KPEJS Pg0KPEJSPg0KLS08QlI+DQo8QlI+DQo8QlI+DQo8L0ZPTlQ+DQo8L1A+DQoN CjxociB3aWR0aD0iMTAwJSI+DQo8Zm9udCBzaXplPSItMiI+PHA+DQpUaGlz IHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRo ZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmls ZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4g QW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2Us IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9u IG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50 cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLjwvcD4N Cg0KPHA+QW55IHZpZXdzLCBvcGluaW9ucyBhbmQgY29udGVudCBwcmVzZW50 ZWQgaW4gdGhpcyBlLW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0 aG9yIGFuZCBtYXkgbm90IHJlcHJlc2VudCB0aG9zZSBvZiBPYmplY3R3b3Js ZCBDb21tdW5pY2F0aW9ucyBDb3JwLjwvcD4NCjwvZm9udD4KPC9CT0RZPg0K PC9IVE1MPg== ------_=_NextPart_001_01C64D13.E888768E-- --===============1503611261== 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 --===============1503611261==-- From dix-bounces@ietf.org Tue Mar 21 15:12:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnDe-0000dG-Mj; Tue, 21 Mar 2006 15:12:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnDd-0000cY-7E for dix@ietf.org; Tue, 21 Mar 2006 15:12:41 -0500 Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnDb-0006ue-TY for dix@ietf.org; Tue, 21 Mar 2006 15:12:41 -0500 Received: by zproxy.gmail.com with SMTP id z3so1430217nzf for ; Tue, 21 Mar 2006 12:12:39 -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=I9Cb+VJRAgM69T+R8xDlb9/LZa5WSB2KvVy/xleykF69DPX/SWz2xq9itaSz7AhdPU22uGDL68VA/cvVnu0+52DK19LL/C7gbse28MbdzJEkkF1lTPr2bbAjL7RDqwRQ3ULiJ8RV11ubthh/SnwULdDCzGEBCwxI6TnABzSXY80= Received: by 10.65.158.17 with SMTP id k17mr32381qbo; Tue, 21 Mar 2006 12:12:39 -0800 (PST) Received: from ?9.33.157.42? ( [129.33.1.37]) by mx.gmail.com with ESMTP id e18sm449863qba.2006.03.21.12.12.38; Tue, 21 Mar 2006 12:12:38 -0800 (PST) Message-ID: <44205E35.8000308@gmail.com> Date: Tue, 21 Mar 2006 15:12:37 -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: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [dix] DIX use cases X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org So from what I could make out DIX requires a set of use cases and a concrete reason why SAML et al doesn't cut it. I thought I'd give it a go while this is all fresh in my mind. Use Cases 1. Elliot's dad wants one userid and password for the web. 2. Elliot's dad wants to stop retyping his credit card information and shipping address every time he wants to buy something on the web 3. Elliot's dad wants to share his online pictures with me and elliot (and only me and elliot) 4. I want to subscribe to Elliot's dad's photocast so that as new photos become available they are automatically downloaded to my machine. http://www.apple.com/ilife/iphoto/features/photocasting.html 5. I want to print Elliot's dad's photos using a web photo printing website. The web site that I use to print the photos is different to the one that stores the photos. Observations 1&2 are accommodated by dmd1 and SAML, Liberty Alliance et al. SAML however requires some previous relationship between homesite and membersite (is this true? do they need a common CA?) 3. is almost covered by dmd1 and SAML but I still don't understand how I either get the persona-url from an e-mail or an e-mail from a persona-url. 4 is not presently covered by dmd1 or SAML (AFAIK). I honestly believe that authentication via feedreaders and other "rich clients" are a MUST have requirement. If the blogosphere forms part of the justification for DIX then not allowing bloggers to make blog postings using a rich client over atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt seems wrong. Phillip's suggestion around federated digest seems to make a lot of sense. If use case 4 makes it into the list of requirements for DIX then this would seem to be a significant differentiator between it and SAML. DIX can do REST, SAML can only do Web Services and we all know how popular those are at the moment http://www.loudthinking.com/arc/000575.html. 5. can be accomplished by SAML. This use case would probably not be in core DIX, but it should be possible to build atop the DIX foundation Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 15:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnQ8-00080E-1W; Tue, 21 Mar 2006 15:25:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhnb-000706-4Z for dix@ietf.org; Tue, 21 Mar 2006 09:25:27 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhnZ-0001RS-Cb for dix@ietf.org; Tue, 21 Mar 2006 09:25:27 -0500 Received: from [198.18.101.77] ([12.5.73.162]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LEPxPk028121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 06:26:00 -0800 Message-ID: <44200CD4.6050309@dcrocker.net> Date: Tue, 21 Mar 2006 08:25:24 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [dix] problem / goals / benefits / requirements / use cases References: <441F9F36.5030806@dcrocker.net> <829DC2DD-A47A-45BF-A8F4-04ACCA2353C1@osafoundation.org> In-Reply-To: <829DC2DD-A47A-45BF-A8F4-04ACCA2353C1@osafoundation.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Tue, 21 Mar 2006 15:25:34 -0500 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 > At the risk of oversimplifying, the argument is that if users are very > familiar with one frequently-used self-identification mechanism (which > may be a password login), then it will be that much more difficult for > bad actors to "phish" the user to provide credentials to any agent other > than the real provider of that mechanism. Indeed that is a reasonable hypothesis. My constant question, about anything pertaining to user impact, is whether there is empirical data to support it. Users have this nasty tendency to react in unexpected way -- or rather, to be sensitive to issues that were not part of the model. Therefore, innovative UI design that predicts user behavior, without careful testing, usually fails. At any rate, thanks for the pointer. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 15:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnU3-0002OA-F8; Tue, 21 Mar 2006 15:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnU2-0002O5-5E for dix@ietf.org; Tue, 21 Mar 2006 15:29:38 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnU0-0007a8-Pp for dix@ietf.org; Tue, 21 Mar 2006 15:29:38 -0500 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k2LKTauf007019 for ; Tue, 21 Mar 2006 13:29:36 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2LKTZda019006 for ; Tue, 21 Mar 2006 13:29:36 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2LKTZM0000903 for ; Tue, 21 Mar 2006 14:29:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2LKTZIB000902 for dix@ietf.org; Tue, 21 Mar 2006 14:29:35 -0600 (CST) Date: Tue, 21 Mar 2006 14:29:35 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] DIX use cases Message-ID: <20060321202935.GL29724@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44205E35.8000308@gmail.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Tue, Mar 21, 2006 at 03:12:37PM -0500, Robert Yates wrote: > So from what I could make out DIX requires a set of use cases and a > concrete reason why SAML et al doesn't cut it. I thought I'd give it a > go while this is all fresh in my mind. > > Use Cases > > 1. Elliot's dad wants one userid and password for the web. But in practice not every service will join the same federation, so I suspect that for market reasons we can do no better than a small number of identities and credentials, each for a set of many services. > 2. Elliot's dad wants to stop retyping his credit card information and > shipping address every time he wants to buy something on the web Note that Elliot's dad almost certainly has multiple credit cards and will sometimes want to use one and sometimes another, and there won't be a pattern the browser/whatever can discern (e.g., "this card's balance got too high and I'll carry some over, so let's make charges on this other card for a while"). In other words: the identity selection problem simply won't go away, and at the limit always requires human interaction. > 3. Elliot's dad wants to share his online pictures with me and elliot > (and only me and elliot) > 4. I want to subscribe to Elliot's dad's photocast so that as new photos > become available they are automatically downloaded to my machine. > http://www.apple.com/ilife/iphoto/features/photocasting.html By "automatically downloaded" in (4) I assume you also mean "when I'm not around," by which you would probably mean that you want some form of authentication mechanism/credential that doesn't require human interaction to use. Have I guessed correctly? > 5. I want to print Elliot's dad's photos using a web photo printing > website. The web site that I use to print the photos is different to > the one that stores the photos. > > Observations > > 1&2 are accommodated by dmd1 and SAML, Liberty Alliance et al. SAML > however requires some previous relationship between homesite and > membersite (is this true? do they need a common CA?) > 3. is almost covered by dmd1 and SAML but I still don't understand how I > either get the persona-url from an e-mail or an e-mail from a persona-url. Presumably you'd be signing these e-mails somehow, no? S/MIME, or PGP? :) > 4 is not presently covered by dmd1 or SAML (AFAIK). I honestly believe > that authentication via feedreaders and other "rich clients" are a MUST > have requirement. If the blogosphere forms part of the justification > for DIX then not allowing bloggers to make blog postings using a rich > client over atompub > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt > seems wrong. Phillip's suggestion around federated digest seems to make > a lot of sense. If use case 4 makes it into the list of requirements > for DIX then this would seem to be a significant differentiator between > it and SAML. DIX can do REST, SAML can only do Web Services and we all > know how popular those are at the moment > http://www.loudthinking.com/arc/000575.html. I don't see why SAML can't handle (4), assuming I guess correctly what you meant by (4), since SAML doesn't handle authentication mechanisms directly, so that as long as you can authenticate to your IdP with some mechanism/credential that requires no interaction then SAML should not require interaction either. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 15:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnlB-0003mM-3h; Tue, 21 Mar 2006 15:47:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnl9-0003mE-U5 for dix@ietf.org; Tue, 21 Mar 2006 15:47:19 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnl9-0008Bs-HJ for dix@ietf.org; Tue, 21 Mar 2006 15:47:19 -0500 Received: from [130.129.128.209] (DHCP-Wireless-128-209.ietf65.org [130.129.128.209]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2LKlfEU018266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Mar 2006 12:47:42 -0800 Message-ID: <4420664C.5010208@dcrocker.net> Date: Tue, 21 Mar 2006 14:47:08 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> In-Reply-To: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.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: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Interesting list. Carsten Bormann wrote: > My biased, personal, quick-shot-from-the-hip diagnosis (and I'd love to > hear different views): > > -- The problem was not made clear -- too much apple pie, too little > slicing;too much focus on individual requirements and not enough on the > big picture. yes, though it was perhaps a bit more nuanced, because there was in fact some big picture. However I think it was not the right kind to be effective for this audience. > -- The Web 2.0 use case (titled "blogosphere") was foreign to much of > the audience. I did not see this case as causing anyone heartburn. So I can't guess what you saw that prompts this assessment. > -- There was no attempt made at a convincing case that existing stuff > does not cut it on its own. Agree. > -- The organization of the BOF succumbed to early derailing attempts, so > not enough of the substance was actually presented -- it was not > possible to establish enough common ground for reasonable discussion. Disagree. First, I saw very minor efforts to "derail", where I only count "stop the DIX effort" in that category. What I and others did attempt was to re-organize the focus, to deal with the concerns that many in the audience found higher priority, and therefore attempt to make the BOF productive. Those of us expressing this difference in priorities have been doing IETF work long enough to believe we have some understanding of how to fail and how to succeed within the IETF. For some of us, knowledge about how to fail entails very deep expertise, engendering a strong desire to spare that pain for the next guy... At any rate, this was *not* derailing. Rather, it is adapting to the audience, and since support of the IETF community is presumably the goal, then the preferences and needs of the IETF audience ought to be heeded. > -- The whole time, apart from the many interested spectators, there were > two fractions: > 1) people who think in terms of a different problem space, already know > the solutions for that and somehow are confident that the (not very > clear) problems at hand can be solved with these as well, and > > 2) people who think in term of the DIX problem space but were inhibited > from talking about how their solutions have significantly different > properties from the Enterprise ones. You left out the faction that I believe was dominant in the group: People who believe this is a very important problem space but a) do not see the seeds of success in DIX, yet, and b) want to fix a). > In the end I felt like I sat in a BOF trying to sell SMTP to an X.400 > crowd (and yes, I'm old enough to have been there). Excluding the few loud voices that expressed religious preference for some "established" solutions, I do not believe any of the active critics qualify for this model. It was, I think, more like trying to have an engineer sell a product to an end-user. There was a complete mismatch of agendas and (in some sense) skills. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 17:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLp52-0007Rc-RJ; Tue, 21 Mar 2006 17:11:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLp51-0007R7-1M for dix@ietf.org; Tue, 21 Mar 2006 17:11:55 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLoIJ-0003T0-E4 for dix@ietf.org; Tue, 21 Mar 2006 16:21:35 -0500 Received: from zproxy.gmail.com ([64.233.162.200]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLo75-0004Bx-Kb for dix@ietf.org; Tue, 21 Mar 2006 16:10:00 -0500 Received: by zproxy.gmail.com with SMTP id z3so1444516nzf for ; Tue, 21 Mar 2006 13:09:59 -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=Rd+n4kaTSTFa7MNEK65sMqkzO28jVo+JUFdxgOPHERRbOyHez/TYBez0akDt0PHJ2jmLeUCSJMytEIGAqZjCFYKPEegACsHJ7FtMLg4DqhWk/wB4EUs+8LBI+BjZNtXuJT8lq28BbvEclA2qpouLtc4RfgEa07AhOKODwrtG1ao= Received: by 10.65.180.11 with SMTP id h11mr74467qbp; Tue, 21 Mar 2006 13:09:58 -0800 (PST) Received: from ?9.33.49.136? ( [129.33.1.37]) by mx.gmail.com with ESMTP id f13sm3369041qba.2006.03.21.13.09.57; Tue, 21 Mar 2006 13:09:58 -0800 (PST) Message-ID: <44206BA4.7020908@gmail.com> Date: Tue, 21 Mar 2006 16:09:56 -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] DIX use cases References: <44205E35.8000308@gmail.com> <20060321202935.GL29724@binky.Central.Sun.COM> In-Reply-To: <20060321202935.GL29724@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Nicolas Williams wrote: >But in practice not every service will join the same federation, so I >suspect that for market reasons we can do no better than a small number >of identities and credentials, each for a set of many services. > > What federation? There is no federation in DIX. This is one of the reasons it is really important. >>Note that Elliot's dad almost certainly has multiple credit cards and >>will sometimes want to use one and sometimes another, and there won't be >>a pattern the browser/whatever can discern (e.g., "this card's balance >>got too high and I'll carry some over, so let's make charges on this >>other card for a while"). >> >>In other words: the identity selection problem simply won't go away, and >>at the limit always requires human interaction. >> Agreed, but these are details that are beyond the protocol and that are handled by the implementation of homesites. >By "automatically downloaded" in (4) I assume you also mean "when I'm >not around," by which you would probably mean that you want some form of >authentication mechanism/credential that doesn't require human >interaction to use. > >Have I guessed correctly? > > yes, 4 is actually an attempt to make two points, one is that I am not around, the other is that my "feedreader" is an http "rich client" i.e. it is NOT a browser. >>3. is almost covered by dmd1 and SAML but I still don't understand how I >>either get the persona-url from an e-mail or an e-mail from a persona-url. >> >> > >Presumably you'd be signing these e-mails somehow, no? S/MIME, or PGP? > >:) > > Sorry, I should clarify, added the word "address" to my statement below. I still don't understand how I either get the persona-url from an e-mail address or an e-mail address from a persona-url. >I don't see why SAML can't handle (4), assuming I guess correctly what >you meant by (4), since SAML doesn't handle authentication mechanisms >directly, so that as long as you can authenticate to your IdP with some >mechanism/credential that requires no interaction then SAML should not >require interaction either. > > There is a SOAP binding for SAML, but AFAIK no binding to straight http i.e. REST web services. It is not possible, for example to use SAML with feedreaders. So apple's iPhoto could not use SAML if it continues to use feeds for Photocasting. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 17:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSw-0000C9-Q6; Tue, 21 Mar 2006 17:36:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpSv-0000Br-Pb for dix@ietf.org; Tue, 21 Mar 2006 17:36:37 -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 1FLpSu-0007hm-Bd for dix@ietf.org; Tue, 21 Mar 2006 17:36:37 -0500 Received: from [10.0.1.2] ([204.96.115.70]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2LMaXro086067 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 21 Mar 2006 14:36:35 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <0BA74CED-EFD4-4229-B16F-FF89C8946D87@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 21 Mar 2006 16:36:29 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dix] big bof thank you X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Just a quick thank you to everyone who participated in the dix bof this morning at the ietf meeting in Dallas. Either in person, or on the audio or text channels. There was good attendance, and we had great conversations before, during, and after the bof. I have a set of draft meeting notes from Hans, which I'll edit into shape and publish soon. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 17:37:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpTt-00013r-2R; Tue, 21 Mar 2006 17:37:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpTr-00013m-Tj for dix@ietf.org; Tue, 21 Mar 2006 17:37: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 1FLpTq-0007kh-Fk for dix@ietf.org; Tue, 21 Mar 2006 17:37:35 -0500 Received: from [10.0.1.2] ([204.96.115.70]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2LMaXrp086067 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 21 Mar 2006 14:37:32 -0800 (PST) (envelope-from merrells@sxip.com) In-Reply-To: <1142871805.12963.57.camel@dirk.w3.org> References: <9c3013570416d0aeecce05962b90eedb@w3.org> <222B6BC4-5443-4D5E-9FBA-AE1A37C00A97@sxip.com> <1142871805.12963.57.camel@dirk.w3.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Date: Tue, 21 Mar 2006 16:37:33 -0600 To: Dan Connolly X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Digital Identity Exchange , public-ietf-w3c@w3.org Subject: [dix] Re: DIX/SXIP delegation tag, HTML LINK rel, 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 (Actually wrote this yesterday, but didn't see it on the list, apologies if this is a duplicate message) On 20-Mar-06, at 10:23 AM, Dan Connolly wrote: > OK, but if the charter does _not_ mention work on HTML, then HTML > experts will not get signalled to take a look. I'm OK with that > *only* if the DIX WG is bound to *not use* any HTML syntax > in order to interoperate. OK, I'm all for getting the right people at the table. > My understanding is that DIX is currently deployed, to some extent, > and that to interoperate with the deployed services, you have to > do some HTML stuff. DMD1 is deployed as part of the SXIP 2.0 protocol from Sxip Identity. And, yes DMD1 is based on HTTP/HTML... and DMD1 should call that out more clearly. I have that action for the next draft. > The charter should err on the side of noting all communities > of experties that might be relevant. Agreed, I will edit the proposed draft charter to reflect more strongly that HTTP/HTML is a likely transport layers for DIX. I hope that a result of the DIX BOF tomorrow will be increased clarity around the scope of DIX and that we can make some definitive statements around HTTP/HTML. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 18:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq5B-0008DL-L0; Tue, 21 Mar 2006 18:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq5A-0008DG-QU for dix@ietf.org; Tue, 21 Mar 2006 18:16:08 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLq59-0000Kl-9o for dix@ietf.org; Tue, 21 Mar 2006 18:16:08 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2LNG6dK015839 for ; Tue, 21 Mar 2006 15:16:06 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2LNG5ca008348 for ; Tue, 21 Mar 2006 16:16:05 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2LNG5Xk001093 for ; Tue, 21 Mar 2006 17:16:05 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2LNG52L001092 for dix@ietf.org; Tue, 21 Mar 2006 17:16:05 -0600 (CST) Date: Tue, 21 Mar 2006 17:16:05 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] DIX use cases Message-ID: <20060321231605.GC1010@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> <20060321202935.GL29724@binky.Central.Sun.COM> <44206BA4.7020908@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44206BA4.7020908@gmail.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Tue, Mar 21, 2006 at 04:09:56PM -0500, Robert Yates wrote: > Nicolas Williams wrote: > >By "automatically downloaded" in (4) I assume you also mean "when I'm > >not around," by which you would probably mean that you want some form of > >authentication mechanism/credential that doesn't require human > >interaction to use. > > > >Have I guessed correctly? > > > > > yes, 4 is actually an attempt to make two points, one is that I am not > around, the other is that my "feedreader" is an http "rich client" i.e. > it is NOT a browser. The second point to me translates as "forms&cookies is no good for authentication" and follows from the need, generally, for human interaction to properly fill in forms. > >>3. is almost covered by dmd1 and SAML but I still don't understand how I > >>either get the persona-url from an e-mail or an e-mail from a persona-url. > >> > >> > > > >Presumably you'd be signing these e-mails somehow, no? S/MIME, or PGP? > > > >:) > > > > > Sorry, I should clarify, added the word "address" to my statement below. I repeat my comment :) > I still don't understand how I either get the persona-url from an e-mail > address or an e-mail address from a persona-url. I haven't gotten that far with understanding the DIX materials, but I'd like to restate your point (3) as: users (and apps) need to be able to create access controls that refer to the identities (or attributes thereof) that they 'meet'. In your example the problem is that the 'meeting' happens in a context (e-mail) apart from the world where DIX is applicable. Is this restatement correct? > >I don't see why SAML can't handle (4), assuming I guess correctly what > >you meant by (4), since SAML doesn't handle authentication mechanisms > >directly, so that as long as you can authenticate to your IdP with some > >mechanism/credential that requires no interaction then SAML should not > >require interaction either. > > > > > There is a SOAP binding for SAML, but AFAIK no binding to straight http > i.e. REST web services. It is not possible, for example to use SAML > with feedreaders. So apple's iPhoto could not use SAML if it continues > to use feeds for Photocasting. Hmmm, I'm not sure this is right, but what is right is that the way to use SAML in HTTP is not as easily abstracted from the application as an authentication layer in the HTTP protocol would, and I'm not sure that DIX is any different from SAML in this sense. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 18:28:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqH6-0001Sq-38; Tue, 21 Mar 2006 18:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqH5-0001Sh-IV for dix@ietf.org; Tue, 21 Mar 2006 18:28: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 1FLqH2-0000sY-SG for dix@ietf.org; Tue, 21 Mar 2006 18:28:27 -0500 Received: from [10.0.1.2] ([204.96.115.70]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2LNSLgS088423 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 21 Mar 2006 15:28:23 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <788A964B-D4F8-4673-A22E-1BEB181A66C8@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 21 Mar 2006 17:28:22 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dix] fyi wiki X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 There's been quite a few people join the list in the past couple of weeks. Welcome! There's a wiki from which you can get to: docs, mailing list, etc... http://dixs.org John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 19:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrUd-0000Tl-HS; Tue, 21 Mar 2006 19:46:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrUc-0000TV-8I for dix@ietf.org; Tue, 21 Mar 2006 19:46:30 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrUb-0004J0-1J for dix@ietf.org; Tue, 21 Mar 2006 19:46:30 -0500 Received: from [127.0.0.1] (stdhcp-192.va.neustar.com [10.31.13.192]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2M0kABY011795 for ; Wed, 22 Mar 2006 00:46:28 GMT Message-ID: <44209E4C.4010403@neustar.biz> Date: Tue, 21 Mar 2006 16:46:04 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX use cases References: <44205E35.8000308@gmail.com> In-Reply-To: <44205E35.8000308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Robert Yates wrote: > SAML can only do Web Services Incorrect -- and where did that notion come from? The web browser SSO profile of SAML [1], employing either the SAML HTTP Redirect Binding or the HTTP POST Binding [2], are essentially RESTful, AFAIU. JeffH [1] SAMLv2 Profiles http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf [2] SAMLv2 Bindings http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 22:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtkI-0007QE-Ja; Tue, 21 Mar 2006 22:10:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLtkH-0007PU-7k for dix@ietf.org; Tue, 21 Mar 2006 22:10:49 -0500 Received: from pproxy.gmail.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLtkF-0000w0-T7 for dix@ietf.org; Tue, 21 Mar 2006 22:10:49 -0500 Received: by pproxy.gmail.com with SMTP id e30so14895pya for ; Tue, 21 Mar 2006 19:10:47 -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=smGRZ9NfV306pqlZUbL1fYtpFCvFn0gE53h/mrRZCsvzJ0aZW2NXpTs389YkwlRHoELfKBJ+XfE/AESxO4NoySg/8ysTSK+KvjixLmMRe9dZNZQDKICCa3gYm2wfUfdiTVyT2MFUmoBnBbDc2ZMZI6lzn5l+LvVP8AngNsLKqbs= Received: by 10.35.127.7 with SMTP id e7mr431091pyn; Tue, 21 Mar 2006 19:10:47 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id n80sm60932pye.2006.03.21.19.10.46; Tue, 21 Mar 2006 19:10:46 -0800 (PST) Message-ID: <4420C034.7090300@gmail.com> Date: Tue, 21 Mar 2006 22:10:44 -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] DIX use cases References: <44205E35.8000308@gmail.com> <44209E4C.4010403@neustar.biz> In-Reply-To: <44209E4C.4010403@neustar.biz> 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 Jeff Hodges wrote: > Robert Yates wrote: > > SAML can only do Web Services > > Incorrect -- and where did that notion come from? > > The web browser SSO profile of SAML [1], employing either the SAML > HTTP Redirect Binding or the HTTP POST Binding [2], are essentially > RESTful, AFAIU. agreed, but i think you may be quoting me out of context :). What I'm trying to state is that SAML cannot be used with non-browser REST based web services such as the atom publishing protocol. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 22:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuBR-0005kM-T1; Tue, 21 Mar 2006 22:38:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuBR-0005kH-JX for dix@ietf.org; Tue, 21 Mar 2006 22:38:53 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLuBQ-0001c9-BW for dix@ietf.org; Tue, 21 Mar 2006 22:38:53 -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 k2M3cqBW019513 for ; Wed, 22 Mar 2006 03:38:52 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 Mar 2006 22:38:51 -0500 Received: from 10.31.13.178 ([10.31.13.178]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Mar 2006 03:38:51 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 21 Mar 2006 22:38:48 -0500 Subject: Re: [dix] DIX use cases From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: [dix] DIX use cases Thread-Index: AcZNYiDbX7B/EblVEdqUSAANk3jHKA== In-Reply-To: <4420C034.7090300@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2006 03:38:51.0740 (UTC) FILETIME=[2315C1C0:01C64D62] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 3/21/2006 10:10 PM, "Robert Yates" wrote: > Jeff Hodges wrote: > >> Robert Yates wrote: >>> SAML can only do Web Services >> >> Incorrect -- and where did that notion come from? >> >> The web browser SSO profile of SAML [1], employing either the SAML >> HTTP Redirect Binding or the HTTP POST Binding [2], are essentially >> RESTful, AFAIU. > > agreed, but i think you may be quoting me out of context :). What I'm > trying to state is that SAML cannot be used with non-browser REST based > web services such as the atom publishing protocol. > As near as I can discern from atom-pub [1], it is, at it's heart, webDAV for ATOM-based representations. Which means a feed reader/editor is, by definition, an HTTP(s) user agent. The present atom-pub ID is ambiguous for UA support for 3xx class response codes (which would be required for the HTTP redirect binding). The POST binding carries no such dependencies on HTTP 3xx responses however. SAML POST only requires access to the POST and GET verbs of HTTP, and for convenience, support for response codes 3xx (redirect response codes), but those are not MTI for SAML POST to properly function. The defense RESTs ;-) =peterd (http://xri.net/=peterd) [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 21 23:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuYj-0005Xs-Rf; Tue, 21 Mar 2006 23:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuYj-0005Xn-GB for dix@ietf.org; Tue, 21 Mar 2006 23:02:57 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLuYi-0002Rk-9a for dix@ietf.org; Tue, 21 Mar 2006 23:02:57 -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 k2M42uBW020810 for ; Wed, 22 Mar 2006 04:02:56 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 Mar 2006 23:02:55 -0500 Received: from 10.31.13.178 ([10.31.13.178]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Mar 2006 04:02:55 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 21 Mar 2006 23:02:51 -0500 Subject: Risky term federation (was Re: [dix] DIX use cases) From: Peter Davis To: "Digital Identity Exchange " Message-ID: Thread-Topic: Risky term federation (was Re: [dix] DIX use cases) Thread-Index: AcZNZXzzu19sWrlYEdqUSAANk3jHKA== In-Reply-To: <44206BA4.7020908@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2006 04:02:55.0660 (UTC) FILETIME=[7FBA76C0:01C64D65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 3/21/2006 4:09 PM, "Robert Yates" wrote: > Nicolas Williams wrote: > >> But in practice not every service will join the same federation, so I >> suspect that for market reasons we can do no better than a small number >> of identities and credentials, each for a set of many services. >> >> > What federation? There is no federation in DIX. This is one of the > reasons it is really important. > FWIW, I'd avoid the term 'federation', as I think its definition differs in various communities. My personal interpretation, for example, involves parties agreeing (perhaps contractually) to the exchange of identity claims (note that here, identity may or may not equal principal), and recourse for false (or at least misleading) claims. dmd1 provides some groundwork for blindly requesting and responding to identity claims, where either or both of the parties involved may not ever have interacted in the past. This falls outside my personal definition of federation, but perhaps not others definitions. The value of these blind attestations, on the other hand, carry the burden of questionable reliability. In (my definition of) 'federations', this is mitigated by governing agreements and policies, which tend to underpin so called 'federations', in some attempt to ensure proper behavior of the parties involved. Blind attestations, in order to be believable, need measures of confidence applied (which may be as simple as the context of a deployment). Different deployments will require different levels of assurance, but should not rely on different protocols to request/respond with claims. =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 08:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3lG-0008SO-Nx; Wed, 22 Mar 2006 08:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3lG-0008Rx-6x for dix@ietf.org; Wed, 22 Mar 2006 08:52:30 -0500 Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3lE-0008I2-V0 for dix@ietf.org; Wed, 22 Mar 2006 08:52:30 -0500 Received: by zproxy.gmail.com with SMTP id z3so160658nzf for ; Wed, 22 Mar 2006 05:52:28 -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=gRUyaJObIo76yvl1EZq9/NRUNmsRpDN7AwTlpqI6pVX199EUID/wF8reJ77friEB+OxH4ziTqXncD1ID26sP2N1LC6wX9EAY6p6qKZ2qo390Iq/zrpctFIrPhcs9PczVsS2loyrBQOEjhwcCV0e+zFn0UDuJ1y/TG32cx/ooCcQ= Received: by 10.64.209.17 with SMTP id h17mr649125qbg; Wed, 22 Mar 2006 05:52:28 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id o32sm3753208qbe.2006.03.22.05.52.25; Wed, 22 Mar 2006 05:52:28 -0800 (PST) Message-ID: <44215697.5050805@gmail.com> Date: Wed, 22 Mar 2006 08:52:23 -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] DIX use cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Peter Davis wrote: >As near as I can discern from atom-pub [1], it is, at it's heart, webDAV for >ATOM-based representations. Which means a feed reader/editor is, by >definition, an HTTP(s) user agent. > > Agreed. >The present atom-pub ID is ambiguous for UA support for 3xx class response >codes (which would be required for the HTTP redirect binding). The POST >binding carries no such dependencies on HTTP 3xx responses however. > >SAML POST only requires access to the POST and GET verbs of HTTP, and for >convenience, support for response codes 3xx (redirect response codes), but >those are not MTI for SAML POST to properly function. > >The defense RESTs ;-) > Not so fast ;-) The SAML POST binding requires that the HTTP UA be a browser or at the very least it MUST be capable of rendering HTML forms and then making posts of media type `application/x-www-form-urlencoded'. There is no such requirement on atom clients, nor any HTTP UA. Google, for example, has an ATOM client that is a plugin for word http://buzz.blogger.com/bloggerforword.html. This certainly can't presently make use of SAML's POST binding. While it can be argued that these clients could make use of this binding I think the burden of being capable of parsing HTML Forms, forming a post of media type 'application/x-www-form-urlencoded' and dealing with all the character encoding pitfalls of html is too great when all they are trying to do is authenticate. The SAML redirect binding has more potential, as all HTTP UAs should honor the 3xx return codes. The problem with this binding, that is also shared with the POST binding, is how the user indicates to the SP the location of his IdP. One approach is that the url that the client initially hits (e.g. the feed url) contains the users IdP, so that the SP knows where to send the redirect (in use case 4, the user is not around). Embedding state into the urls of web resources is NOT REST based web services as it breaks one of the foundational assumptions. (this is getting religious). Practically speaking though, doing so creates a set of problems for Elliot's Dad, Elliot and I. Here's the problem. Elliot's dad's photostream has the following url. http://apple.com/photostreams/elliots-dad. He e-mails the url of this feed to Elliot and I. Now what? Am not sure you can REST just yet. Your witness ;-) Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 12:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM77T-0005n5-Qy; Wed, 22 Mar 2006 12:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM77R-0005mz-VZ for dix@ietf.org; Wed, 22 Mar 2006 12:27:37 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM77Q-0000cf-IV for dix@ietf.org; Wed, 22 Mar 2006 12:27:37 -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 k2MHRZ9o026666 for ; Wed, 22 Mar 2006 09:27:36 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 09:27:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] So what went wrong? Date: Wed, 22 Mar 2006 09:27:35 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD379E0AFF@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] So what went wrong? Thread-Index: AcZNKKkEZ8VKp8sDQvmaCHXdk9g52QApa3lQ From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 22 Mar 2006 17:27:35.0490 (UTC) FILETIME=[E8BFE220:01C64DD5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0761164035==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0761164035== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C64D9E.A5E0C320" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C64D9E.A5E0C320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Broadly agreeing with Dave here. The point of an IETF working group is not to do design, research or development. If you want to get the best spec possible there are much better forums. For example six people working together in a closed room. The alpha and omega of standards work is to establish a support constituency for deployment. It is easy to develop a great spec, much harder to get people to adopt it. Measured by the standard of getting agreement to deploy the DIX protocol the BOF did not make much progress. That is the wrong measure to use. Protocols are a dime a dozen here. Measured against the standard of focusing attention on a particular set of use cases and the longstanding failure to get Internet wide single sign on to deploy the BOF was a considerable success. That is the hard part - getting people to believe that the area 1) is important enough to work on 2) is capable of being solved. With so many Identity 2.0 protocols on offer some form of requirements definition / bake off was inevitable. The winner of the bake off is going to be the protocol that demonstrates it best meets the proposal and requires the least new mechanism. There are some new use cases here that are not addressed in SAML. The dispute is whether an extension to address them within the SAML framework is or is not possible given that a possible requirement is 'do not use XML angle brackets'. The best way to win such bake offs is to align with an existing constituency that has a different deployment base, provided of course this can be done without unacceptable cost (i.e. a spec that looks like a dog's breakfast). ------=_NextPart_000_0000_01C64D9E.A5E0C320 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjIxNjUyMDBaMCMGCSqGSIb3DQEJBDEWBBT4 8jypXf48VSss7OhmvW5sO3li4jBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYBPCglrwfCqznrNQ/JHJon9TlLT ekm44KK5UnE6v/DaYvymmYIL4LH2WmcW2PglTairKsHOXOcOh/AMef5JZ5/5c08pC01IjwWpBiWU ImI4X3VjEutnqGXz7XtvJaG/Qs6aIO+KvvGKsl/RqkXpShEljnTGxMIuO1sgFanRFanohgAAAAAA AA== ------=_NextPart_000_0000_01C64D9E.A5E0C320-- --===============0761164035== 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 --===============0761164035==-- From dix-bounces@ietf.org Wed Mar 22 14:22:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8uB-0007Qq-Lq; Wed, 22 Mar 2006 14:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8uA-0007QH-Dd for dix@ietf.org; Wed, 22 Mar 2006 14:22:02 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8u9-0006Dl-67 for dix@ietf.org; Wed, 22 Mar 2006 14:22:02 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2006 11:22:01 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="419296503:sNHT28701264" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2MJM0w1019758 for ; Wed, 22 Mar 2006 11:22:00 -0800 (PST) Received: from [130.129.129.148] (rcdn-vpn-cluster-1-74.cisco.com [10.89.16.74]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2MJMvtL031386 for ; Wed, 22 Mar 2006 11:22:57 -0800 Message-ID: <4421A3D7.9090403@cisco.com> Date: Wed, 22 Mar 2006 13:21:59 -0600 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX use cases References: <44205E35.8000308@gmail.com> In-Reply-To: <44205E35.8000308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=474; t=1143055377; x=1143487577; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20DIX=20use=20cases |To:Digital=20Identity=20Exchange=20; X=v=3Dmtcc.com=3B=20h=3DkVJuEJNGPwWyC26Q0cJxXG7Ix4A=3D; b=TW/vENoXrtkgSZIQVNgNEjGUfr53dBAzZY+aTOHjP59hWkl5Ni2VWKckqIt5kjQZ+9NyUa6s r2LzMliQY+uVJwZvSeM+TmltwBcqjSg2w3Qz9U6cVSa+0JPadp7ikqDutDmU5hH1KheDjtmd4Zv HwRlc2kkBsN49gT4m5UcCT7Q=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) 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 Robert, > Use Cases > > 1. Elliot's dad wants one userid and password for the web. Three clarifications: * My father doesn't mind multiple user names so long as those can be stored somewhere. * My father doesn't mind different systems having multiple passwords so long as he doesn't have to remember them. * It's "Eliot" ;-) There are other constraints to "Eliot's Dad" problem, but I'll go through those in another message. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 14:30:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM928-0004w0-7K; Wed, 22 Mar 2006 14:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM927-0004qr-3S for dix@ietf.org; Wed, 22 Mar 2006 14:30:15 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM925-0006Tv-S6 for dix@ietf.org; Wed, 22 Mar 2006 14:30:15 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2006 11:30:13 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="317014058:sNHT28278820" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2MJUD7T004237 for ; Wed, 22 Mar 2006 11:30:13 -0800 (PST) Received: from [130.129.129.148] (rcdn-vpn-cluster-1-74.cisco.com [10.89.16.74]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2MJV8Eo031511 for ; Wed, 22 Mar 2006 11:31:09 -0800 Message-ID: <4421A5C3.8070808@cisco.com> Date: Wed, 22 Mar 2006 13:30:11 -0600 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? Nothing References: <198A730C2044DE4A96749D13E167AD379E0AFF@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD379E0AFF@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=468; t=1143055870; x=1143488070; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20So=20what=20went=20wrong?=20=20Nothing |To:Digital=20Identity=20Exchange=20; X=v=3Dmtcc.com=3B=20h=3DJeX3Caan9ofsbmgDc3XrIFDeT9o=3D; b=QUuU2Q0sb0Q9GmVb9jbw36/rfdTMgVws+aVO/Cj/bFiId+9qcyDaqtxRCf3ZGmGpqgKosUm4 /EHA3WQ3vBrExTLWLigaaqblOSCRUSwRkWXuMqPFASYmRantvtBux4StM+cM7PwHJLdEz8yf3LN Hch5c/Ck1v1vEiTg9Te+ocPE=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 generally agree with Phillip and Dave. It seems to me that the use case discussion could provide a productive way forward. I'd propose that someone aggregate those into an internet draft and explain which technologies can solve which problems. In other words, as someone said in the BoF, a matrix would be a nice output. This will help articulate what work the IETF can do (if any), and what work needs to be done elsewhere (if any). Thanks, Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 14:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM95n-0007wq-92; Wed, 22 Mar 2006 14:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM95m-0007wM-Ix for dix@ietf.org; Wed, 22 Mar 2006 14:34:02 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM95l-0006gA-9n for dix@ietf.org; Wed, 22 Mar 2006 14:34:02 -0500 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2MJY0Qj022497 for ; Wed, 22 Mar 2006 12:34:00 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2MJY0da010270 for ; Wed, 22 Mar 2006 12:34:00 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2MJY0SW002358 for ; Wed, 22 Mar 2006 13:34:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2MJXxVk002357 for dix@ietf.org; Wed, 22 Mar 2006 13:33:59 -0600 (CST) Date: Wed, 22 Mar 2006 13:33:59 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] DIX use cases Message-ID: <20060322193359.GW1010@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> <4421A3D7.9090403@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4421A3D7.9090403@cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Wed, Mar 22, 2006 at 01:21:59PM -0600, Eliot Lear wrote: > > 1. Elliot's dad wants one userid and password for the web. > Three clarifications: > > * My father doesn't mind multiple user names so long as those can be > stored somewhere. > * My father doesn't mind different systems having multiple passwords > so long as he doesn't have to remember them. > * It's "Eliot" ;-) > > There are other constraints to "Eliot's Dad" problem, but I'll go > through those in another message. But your dad probably does mind the endless enrolments, and thinking up usernames and passwords that must be good, memorable for a few minutes, different from the others he already has and which he will never type in again. And he probably minds not being able to use any of these username/password tuples that he doesn't remember when he's using a computer other than his primary one. And he'd probably like to be able to use Internet kiosks (e.g., when travelling w/o a laptop) w/o endangering his credentials and associated resources. And he probably wants to be able to keep these username/password tuples when he re-installs his system(s) (which he probably also minds doing, but at least that's not a problem we'll concern ourselves with here). I think Robert meant that your dad wants to have to remember no more than one username and password, not that there mustn't be others under the covers. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 14:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9KN-0007vF-Mi; Wed, 22 Mar 2006 14:49:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9KM-0007vA-EK for dix@ietf.org; Wed, 22 Mar 2006 14:49:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9KL-0007MZ-6z for dix@ietf.org; Wed, 22 Mar 2006 14:49:06 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2006 11:49:05 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="1787372916:sNHT54281044" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2MJn4Yg007032 for ; Wed, 22 Mar 2006 11:49:04 -0800 (PST) Received: from [130.129.129.148] (rcdn-vpn-cluster-1-74.cisco.com [10.89.16.74]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2MJo1na031812 for ; Wed, 22 Mar 2006 11:50:01 -0800 Message-ID: <4421AA2F.6000607@cisco.com> Date: Wed, 22 Mar 2006 13:49:03 -0600 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX use cases References: <44205E35.8000308@gmail.com> <4421A3D7.9090403@cisco.com> <20060322193359.GW1010@binky.Central.Sun.COM> In-Reply-To: <20060322193359.GW1010@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=321; t=1143057001; x=1143489201; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20DIX=20use=20cases |To:Digital=20Identity=20Exchange=20; X=v=3Dmtcc.com=3B=20h=3DYrblOZY7Nx9npv2X5SqdoqSlJ7I=3D; b=BhI3BsUBschhsL7ItxTyoJonbUJ2rNOmbOhIIZgTMi3K5lds9bFbjXMj38MHGQvre8BrjAwR /tdCcys0ZTP4JBEbMl3pJ0TbARy7Sd8OigZZmz+L4w+L6e2SkQ1IgVphBsy5ISQkc0aMbtDcD8j qT3UCrnXS8Tb5SQd+mxdWErI=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Nicolas Williams wrote: > I think Robert meant that your dad wants to have to remember no more > than one username and password, not that there mustn't be others under > the covers. > This is the high order bit for him. Endless registration is also an issue, and these are two different problems. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 15:14:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9iU-00030I-BY; Wed, 22 Mar 2006 15:14:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9iT-0002zv-J0 for dix@ietf.org; Wed, 22 Mar 2006 15:14:01 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9iR-00009V-3j for dix@ietf.org; Wed, 22 Mar 2006 15:14:01 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id A3DFB3BEAB for ; Wed, 22 Mar 2006 21:13:58 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03715-02-19 for ; Wed, 22 Mar 2006 21:13:58 +0100 (CET) Received: from [130.129.129.217] (DHCP-Wireless-129-217.ietf65.org [130.129.129.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id D05C53BEA2 for ; Wed, 22 Mar 2006 21:13:57 +0100 (CET) Message-ID: <4421B003.70104@it.su.se> Date: Wed, 22 Mar 2006 21:13:55 +0100 From: Leif Johansson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> In-Reply-To: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.239 tagged_above=-99 required=7 tests=[AWL=0.426, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In the end I felt like I sat in a BOF trying to sell SMTP to an X.400 > crowd (and yes, I'm old enough to have been there). Ahem, well, more like beeing in the room trying to sell LDAP to X.500. Why I hear you say? I wasn't around when LDAP split off from X.500 but I was around a couple of years later (and ever since) in the IETF. The BOF felt like deja-vue all over again for me. In the dawn of time (smoke, also sprach zarathustra) the LDAP founding fathers sat down and said "this X.500 directory stuff is far to complex. Let us build a more simple directory". They went about building LDAP. LDAP became a big hit and attracted actual users and with them work in the IETF on all kinds of extensions, profiling etc etc. During the course of that work, and work on bringing LDAP to draft standard, it has become increasingly clear to those of us who came after the mythical progenitors of LDAP that some of the very choices that were made when adding the 'L' to 'DAP' (X.500 includes DAP which is the protocol for accessing an X.500 directory) were very very bad choices. Einstein once said - make things as simple as possible but no more simple than that. History has shown that it was possible to simplify X.400. Hence 821, 822,2821,2822 etc etc. History has also shown that LDAP was probably too simple. That is not to say that X.500 is the most simple directory model. I am saying that the obvious choices 'simplifying' a design aren't necessarily the right ones. A couple of lessons from the LDAP/X.500 (imvho as always): - - Simple doesn't necessary mean less code, text-based rather than 'binary' protocols, etc. The fact that you can debug your protocol by looking at tcpdump traces should not influence your design too much. - - Non-structured as opposed to structured (ASN.1, XML, etc) data is a non-issue. One of the major simplifications of LDAP was the choice to only support text-based attribute values. That is one of the major problem with LDAP today. - - Don't make design choices before fully understanding other solutions even remotely in the same space. My 2 cents. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIbAD8Jx8FtbMZncRAvq1AKCX/XYX2b6UDXQrpU+n93v4xvZWrgCfUvMq tYfaUPXUXpjzpzyhE8laSnc= =3r5T -----END PGP SIGNATURE----- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 15:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9ld-0005Gl-Ke; Wed, 22 Mar 2006 15:17:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9lb-0005Dm-Ui for dix@ietf.org; Wed, 22 Mar 2006 15:17:15 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9la-0000Eq-IB for dix@ietf.org; Wed, 22 Mar 2006 15:17:15 -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 k2MKHDrU003943 for ; Wed, 22 Mar 2006 12:17:13 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 12:17:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] DIX use cases Date: Wed, 22 Mar 2006 12:17:13 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD379E0B5C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] DIX use cases Thread-Index: AcZNPXWSdgSf4HQcR5ym132m4piyCwAr0UXA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 22 Mar 2006 20:17:13.0868 (UTC) FILETIME=[9B891CC0:01C64DED] X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1352388046==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1352388046== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01C64DBB.507B2A70" This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C64DBB.507B2A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Hmmm, I'm not sure this is right, but what is right is that > the way to use SAML in HTTP is not as easily abstracted from > the application as an authentication layer in the HTTP > protocol would, and I'm not sure that DIX is any different > from SAML in this sense. Remember that each standards venue has its own constraints. SAML was one of the very first major OASIS specs. At the time SAML 1.0 started there were no browser providers at the table. The proposals made were limited to what was possible. Much has happened since, SAML is generally considered to be a successful protocol in certain areas. It is important enough to be on the list of 'no-brainer' infrastructure that other proposals in the area have to support. The blog pain point has appeared. Phishing is rife. The browser providers have a major interest in locking down the inbound and outbound authentication processes. I think that we certainly do need to have a zero footprint solution. We should be aware that we have the opportunity to go further here and make proposals that do depend on browser changes, particularly in the area of proposals that support the concept of secure chrome. ------=_NextPart_000_0048_01C64DBB.507B2A70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjIyMDE3MTNaMCMGCSqGSIb3DQEJBDEWBBTu x3c5DfGOO6z4e5oe0XqirGelxDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYCubvAEkOXBl24+q+5kTjHakgRm LPQvNa/wz17p8aGLtN6iE9SQEVvqbIeNOtj1HrFp0KaGHpQivqmkve+dis2IUkG1GDnD1qA41t7z LnS8OpwQW4rMvd3QSeU5caoUzlXYYSd5A+7E2WiU2OwjayF6GKmtg44syb6g2YTkcPNi/wAAAAAA AA== ------=_NextPart_000_0048_01C64DBB.507B2A70-- --===============1352388046== 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 --===============1352388046==-- From dix-bounces@ietf.org Wed Mar 22 15:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9m7-0005Uc-6P; Wed, 22 Mar 2006 15:17:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9m5-0005UX-Tk for dix@ietf.org; Wed, 22 Mar 2006 15:17:45 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9m4-0000FL-Lw for dix@ietf.org; Wed, 22 Mar 2006 15:17:45 -0500 Received: from [127.0.0.1] (stdhcp-222.va.neustar.com [10.31.13.222]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2MKHdBY010718 for ; Wed, 22 Mar 2006 20:17:44 GMT Message-ID: <4421B0DD.9010505@neustar.biz> Date: Wed, 22 Mar 2006 12:17:33 -0800 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] DIX use cases References: <44205E35.8000308@gmail.com> <44209E4C.4010403@neustar.biz> <4420C034.7090300@gmail.com> In-Reply-To: <4420C034.7090300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Robert Yates wrote: > > What I'm trying to state is that SAML cannot be used with non-browser REST > based web services such as the atom publishing protocol. Not correct, in a literal sense. Abstractly, it's sorta correct in that the presently-specified set of SAMLv2 profiles may not address your particular needs. However, somewhat subtle, and very important aspect of SAML is that: "If there is not yet a SAML Profile that does what one needs, then one can craft a new profile to accomplish it." The -sip-saml-05 I-D [1] is an example of just such an exercise. JeffH [1] SIP SAML Profile and Binding http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 15:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA68-0003ZS-TK; Wed, 22 Mar 2006 15:38:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA67-0003ZN-TT for dix@ietf.org; Wed, 22 Mar 2006 15:38:27 -0500 Received: from toad.mtbrook.bozemanpass.com ([69.145.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMA66-0000zQ-J9 for dix@ietf.org; Wed, 22 Mar 2006 15:38:27 -0500 Received: from [69.145.82.218] (unknown [69.145.82.218]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id B8FD111027B for ; Wed, 22 Mar 2006 12:38:23 -0800 (PST) Message-ID: <4421B5C0.8050809@boreham.org> Date: Wed, 22 Mar 2006 13:38:24 -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] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> In-Reply-To: <4421B003.70104@it.su.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 >- - Simple doesn't necessary mean less code, text-based rather > than 'binary' protocols, etc. The fact that you can debug your > protocol by looking at tcpdump traces should not influence > your design too much. > > Of course LDAP is a purely binary protocol, and some of us have made a nice living debugging the encoding/decoding code for it ;) An available text-based variant (DSMLv2) has approximately zero deployment footprint. OTOH the text based protocol argument worked well in the case of SOAP/XML-RPC. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 15:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA79-0004EC-Bf; Wed, 22 Mar 2006 15:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA77-0004E7-T1 for dix@ietf.org; Wed, 22 Mar 2006 15:39:29 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMA76-00012J-5R for dix@ietf.org; Wed, 22 Mar 2006 15:39:29 -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 k2MKdRgv032635 for ; Wed, 22 Mar 2006 12:39:27 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 12:39:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] DIX use cases Date: Wed, 22 Mar 2006 12:39:25 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD379E0B6F@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] DIX use cases Thread-Index: AcZNXj1pCam1skGgQLWHpRZuqrMGrgAj3WLg From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 22 Mar 2006 20:39:27.0059 (UTC) FILETIME=[B62DEA30:01C64DF0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0500475671==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0500475671== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004D_01C64DBE.6A5F18E0" This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C64DBE.6A5F18E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Robert Yates [mailto:robyates70@gmail.com] > Jeff Hodges wrote: > > > Robert Yates wrote: > > > SAML can only do Web Services > > > > Incorrect -- and where did that notion come from? > > > > The web browser SSO profile of SAML [1], employing either the SAML > > HTTP Redirect Binding or the HTTP POST Binding [2], are essentially > > RESTful, AFAIU. > > agreed, but i think you may be quoting me out of context :). > What I'm trying to state is that SAML cannot be used with > non-browser REST based web services such as the atom > publishing protocol. I don't know why that would be the case. I wrote the first draft of what became the SAML assertion infrastructure before Microsoft wrote the first draft of SOAP. WS-* is certainly tied down to the Web Services framework. That is a different design decision that has advanatges and disadvantages. WS-* is architected as an active transport layer protocol, SAML is architected as static data. The advantage of the static mode is precisely that you are not tied to transport unless you want to be. REST is just a protocol architecture style. Fielding has a different architectural style to Fristyk-Neilsen or Hallam-Baker. I don't see why the idea of giving his style an acronym makes it more valid than any other or creates an incompatibility. He sees an adantage to keeping to one consistent style that he adopted in 1995 or so. Folk who care about these things can probably see quite a lot of change in my style over the years. There is a case to be made for both approaches. ------=_NextPart_000_004D_01C64DBE.6A5F18E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjIyMDM5MjVaMCMGCSqGSIb3DQEJBDEWBBR9 Lds5+sdDWC3x+EzbnZDLQLuJ2zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAqUh62Fa9vqfAETXi+nmlkvYMt q1yCvyrkwieQbHEqVEanKxc808beISsngHcFnash3HcrypZru27Kuzq8Pf9/RapCffDnOtxu9VU0 r9aCKjOG7LGErNdQ2zv9NSKRNPduWtCh01uDsFgt5dStf2AYtGR1rprNJaK4H6X8YeObCQAAAAAA AA== ------=_NextPart_000_004D_01C64DBE.6A5F18E0-- --===============0500475671== 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 --===============0500475671==-- From dix-bounces@ietf.org Wed Mar 22 15:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAEt-0001rQ-T2; Wed, 22 Mar 2006 15:47:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAEr-0001rB-Qh for dix@ietf.org; Wed, 22 Mar 2006 15:47:29 -0500 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAEq-0001OE-EQ for dix@ietf.org; Wed, 22 Mar 2006 15:47:29 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k2MKlR3W018945 for ; Wed, 22 Mar 2006 12:47:27 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2MKlQca027242 for ; Wed, 22 Mar 2006 13:47:26 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2MKlQ2b002424 for ; Wed, 22 Mar 2006 14:47:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2MKlQEI002423 for dix@ietf.org; Wed, 22 Mar 2006 14:47:26 -0600 (CST) Date: Wed, 22 Mar 2006 14:47:26 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] DIX use cases Message-ID: <20060322204725.GA1010@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> <4421A3D7.9090403@cisco.com> <20060322193359.GW1010@binky.Central.Sun.COM> <4421AA2F.6000607@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4421AA2F.6000607@cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Wed, Mar 22, 2006 at 01:49:03PM -0600, Eliot Lear wrote: > Nicolas Williams wrote: > > > I think Robert meant that your dad wants to have to remember no more > > than one username and password, not that there mustn't be others under > > the covers. > > > > This is the high order bit for him. Endless registration is also an > issue, and these are two different problems. Yes, but the endless enrolment problem hadn't been explicitly stated. I've been trying to distill, out of rather broad problem descriptions, concrete real-world problems. Very general descriptions of the problem may help us to not solve specific problems in ways that aren't so useful (replacing one problem with an equally bad, but different problem), but I don't want to keep guessing what the specific problems are either, and I do believe we need to know what specific problems we want to solve. We also need to establish what threat models apply in what circumstances. This is critical, IMO. If the IETF is going to do any work in this space then an overly broad charter, either in problem description or solution space, is likely to lead to failure. 'Twould be better to debate such matters now than two years into a WG's life. Chartering a WG should not be the only measure of success here (see Phillip's post on that topic). Cynics might also prefer that any such WG be limited to their preferred solutions to their perceived problems; an overly broad charter does not achieve that. Everyone else should still want a narrow charter to improve the chances of success. So, is it safe to say that some of the use cases posted by Robert amount to saying that - users shouldn't have more than one physical (smartcard/token/whatever) or logical (username/password) credential - non-interactive authentication/ID exchange/whatever must be supported - no more endless enrolment by creation of username/passwords - it should be easy to manage authorization - etc... ? Cheers, Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 15:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAIV-00059f-Eu; Wed, 22 Mar 2006 15:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAIT-00054Q-Jd for dix@ietf.org; Wed, 22 Mar 2006 15:51:13 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAIS-0001Yi-83 for dix@ietf.org; Wed, 22 Mar 2006 15:51:13 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2MKpBdK005570 for ; Wed, 22 Mar 2006 12:51:11 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2MKpAca028861 for ; Wed, 22 Mar 2006 13:51:11 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2MKpAMA002435 for ; Wed, 22 Mar 2006 14:51:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2MKpAOr002434 for dix@ietf.org; Wed, 22 Mar 2006 14:51:10 -0600 (CST) Date: Wed, 22 Mar 2006 14:51:10 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] DIX use cases Message-ID: <20060322205110.GB1010@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> <44209E4C.4010403@neustar.biz> <4420C034.7090300@gmail.com> <4421B0DD.9010505@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4421B0DD.9010505@neustar.biz> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Wed, Mar 22, 2006 at 12:17:33PM -0800, Jeff Hodges wrote: > Robert Yates wrote: > > > > What I'm trying to state is that SAML cannot be used with non-browser REST > > based web services such as the atom publishing protocol. > > Not correct, in a literal sense. Abstractly, it's sorta correct in that the > presently-specified set of SAMLv2 profiles may not address your particular > needs. > > However, somewhat subtle, and very important aspect of SAML is that: "If > there is not yet a SAML Profile that does what one needs, then one can > craft a new profile to accomplish it." And with less effort than starting from scratch. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 15:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAOh-0003lA-Mr; Wed, 22 Mar 2006 15:57:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAOg-0003l5-Q2 for dix@ietf.org; Wed, 22 Mar 2006 15:57:38 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAOf-00027H-Iw for dix@ietf.org; Wed, 22 Mar 2006 15:57:38 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k2MKvbtZ017197 for ; Wed, 22 Mar 2006 15:57:37 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k2MKvVZb009338 for ; Wed, 22 Mar 2006 15:57: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 k2MKvUhg029152 for ; Wed, 22 Mar 2006 15:57:30 -0500 Message-ID: <4421BA35.1070703@redhat.com> Date: Wed, 22 Mar 2006 12:57:25 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> In-Reply-To: <4421B003.70104@it.su.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0006207653==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0006207653== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000300090303030906020002" This is a cryptographically signed message in MIME format. --------------ms000300090303030906020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Leif Johansson wrote: >A couple of lessons from the LDAP/X.500 (imvho as always): > >- - Simple doesn't necessary mean less code, text-based rather > than 'binary' protocols, etc. The fact that you can debug your > protocol by looking at tcpdump traces should not influence > your design too much. > > Simple in the LDAP sense most certainly does mean less code, where it counts, in the client. >- - Non-structured as opposed to structured (ASN.1, XML, etc) data > is a non-issue. One of the major simplifications of LDAP was > the choice to only support text-based attribute values. That > is one of the major problem with LDAP today > ;binary? In any case, I think the text based attribute values helped fuel adoption and to a certain extent narrowed focus and expectations. >. >- - Don't make design choices before fully understanding other > solutions even remotely in the same space. > > > Agreed. Whether you believe LDAP was too simple or not, I think it can be agreed that whatever it did, for good or bad, it got deployed widely. In the absence of LDAP I don't think x.500 would ever have achieved the same ubiquity. DIX has similar goals, simplify where it counts, make it deployable in a larger scope than current offerings. -- Pete --------------ms000300090303030906020002 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMjIyMDU3MjVaMCMGCSqGSIb3DQEJBDEWBBQu67cDNNfWNPV5 NsRj5to7pEHwVTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAYY9HEC4+r/1UujaNh0Uph9+aws6HRbvuYe/M41x2MA3vj9urJHffyUVq+YRE SR0nKfvMt/AWejaXkQn0EpGmG0h2dSD4PcINDk16ZkuX1GQfoy/+hVBA7aO1ZIGC9Onw/Lip XxqBAiTXjvr+rRqaAa9F06BOnFcN75oNLNwpMEm8wwkYa7KDmyxRNSypO2ReUEurnjP43pz+ rxuh3nln3f9bIR+97g+mf8ZtUGl0g370wkMnELtv5WUob7kvG6dd0rZgH7gGcYVbUumN7kqm OkycdKobuHokBYwjLFK1hrpgwU8oPCko+G4VUUNPzUjH86IRVP1MGqd9EbTM+orUgwAAAAAA AA== --------------ms000300090303030906020002-- --===============0006207653== 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 --===============0006207653==-- From dix-bounces@ietf.org Wed Mar 22 15:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAP3-0004DZ-4Y; Wed, 22 Mar 2006 15:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAP1-0004DU-Vv for dix@ietf.org; Wed, 22 Mar 2006 15:57:59 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAP0-00028p-GO for dix@ietf.org; Wed, 22 Mar 2006 15:57:59 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2MKvwSD022212 for ; Wed, 22 Mar 2006 13:57:58 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2MKvvcc001931 for ; Wed, 22 Mar 2006 13:57:57 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2MKvv8O002444; Wed, 22 Mar 2006 14:57:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2MKvuog002443; Wed, 22 Mar 2006 14:57:56 -0600 (CST) Date: Wed, 22 Mar 2006 14:57:56 -0600 From: Nicolas Williams To: david_list@boreham.org, Digital Identity Exchange Subject: Re: [dix] So what went wrong? Message-ID: <20060322205756.GC1010@binky.Central.Sun.COM> References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> <4421B5C0.8050809@boreham.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4421B5C0.8050809@boreham.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Wed, Mar 22, 2006 at 01:38:24PM -0700, David Boreham wrote: > > >- - Simple doesn't necessary mean less code, text-based rather > > than 'binary' protocols, etc. The fact that you can debug your > > protocol by looking at tcpdump traces should not influence > > your design too much. > > > > > Of course LDAP is a purely binary protocol, and some of us have made a nice > living debugging the encoding/decoding code for it ;) > > An available text-based variant (DSMLv2) has approximately zero > deployment footprint. > > OTOH the text based protocol argument worked well in the case of > SOAP/XML-RPC. When I look just at specs, never mind actual protocol traces, I find that wading through a bunch of XML is almost as hard as looking at XDR encoded data (I've had fun debugging ONC/RPC protocols). Now, BER/DER are definitely less fun still, but thinking of XDR as a 4-octet aligned subset of PER I would go out on a limb and say that looking at traces of PER-encoded data wouldn't be so bad. (And then you have to encrypt the traffic...) But then, with extensible protocol decoders, such as ethereal, does this matter anymore? I'll go out on a limb and say "no." When implementing a new protocol one should also implement dissectors for traces of it too, just as one should implement test suites for new software. Oh, let's not have the encoding argument again. We have enough standard and ad-hoc encodings already, and I bet there will always be someone left who is not satisfied with existing choices. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 16:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMARq-0006u0-5k; Wed, 22 Mar 2006 16:00:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMARo-0006tv-UN for dix@ietf.org; Wed, 22 Mar 2006 16:00:52 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMARn-0002Mk-KN for dix@ietf.org; Wed, 22 Mar 2006 16:00:52 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 7A99B3BEC9; Wed, 22 Mar 2006 22:00:50 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11034-01-4; Wed, 22 Mar 2006 22:00:50 +0100 (CET) Received: from [130.129.129.217] (DHCP-Wireless-129-217.ietf65.org [130.129.129.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 936FD3BE53; Wed, 22 Mar 2006 22:00:48 +0100 (CET) Message-ID: <4421BAFE.60902@it.su.se> Date: Wed, 22 Mar 2006 22:00:46 +0100 From: Leif Johansson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: david_list@boreham.org, Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> <4421B5C0.8050809@boreham.org> In-Reply-To: <4421B5C0.8050809@boreham.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.251 tagged_above=-99 required=7 tests=[AWL=0.414, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Boreham wrote: > >> - - Simple doesn't necessary mean less code, text-based rather >> than 'binary' protocols, etc. The fact that you can debug your >> protocol by looking at tcpdump traces should not influence >> your design too much. >> >> > Of course LDAP is a purely binary protocol, and some of us have made a nice > living debugging the encoding/decoding code for it ;) > > An available text-based variant (DSMLv2) has approximately zero > deployment footprint. > > OTOH the text based protocol argument worked well in the case of > SOAP/XML-RPC. My point is that no-one (going far out on the limb here and bringing a saw) will develop serious applications using LDAP *or* DSMLv2 without the use of a library implementing the marshalling/object encoding. - From an application-implementation standpoint this means that the choice of ASN.1 vs DSML vs XML vs YAML vs FOO is all about "Sure fine whatever but where is my toolkit?!". The SAML community would (beginning to saw into the limb) probably have seen a much larger deployment of their stuff if there had been a php implementation :-) MVH leifj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIbr+8Jx8FtbMZncRAkLbAJ9dAbFejphUNMBtyft6k1sMxTS2nQCghNuH Gz4aUQtelrrNintDd9wcqNs= =shfS -----END PGP SIGNATURE----- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 16:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAWx-0000hJ-Mj; Wed, 22 Mar 2006 16:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAWw-0000hE-4N for dix@ietf.org; Wed, 22 Mar 2006 16:06:10 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAWv-0002h2-MU for dix@ietf.org; Wed, 22 Mar 2006 16:06:10 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 3DAB13BEC9 for ; Wed, 22 Mar 2006 22:06:09 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11638-01-4 for ; Wed, 22 Mar 2006 22:06:08 +0100 (CET) Received: from [130.129.129.217] (DHCP-Wireless-129-217.ietf65.org [130.129.129.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 4941F3BE53 for ; Wed, 22 Mar 2006 22:06:08 +0100 (CET) Message-ID: <4421BC3D.9030508@it.su.se> Date: Wed, 22 Mar 2006 22:06:05 +0100 From: Leif Johansson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> <4421BA35.1070703@redhat.com> In-Reply-To: <4421BA35.1070703@redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.255 tagged_above=-99 required=7 tests=[AWL=0.410, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Simple in the LDAP sense most certainly does mean less code, where it > counts, in the client. Measured how exactly? > >> - - Non-structured as opposed to structured (ASN.1, XML, etc) data >> is a non-issue. One of the major simplifications of LDAP was >> the choice to only support text-based attribute values. That >> is one of the major problem with LDAP today >> > ;binary? In any case, I think the text based attribute values helped > fuel adoption and to a certain extent narrowed focus and expectations. Not ;binary - thats details. It did lower expectations but clearly didn't narrow focus. LDAP is beeing used for much more than X.500 was ever intended to be used for and I claim that many of these applications are today feeling the lack of structured data in attribute values (to pick one simplification of LDAP). > >> . >> - - Don't make design choices before fully understanding other >> solutions even remotely in the same space. >> >> >> > Agreed. > > Whether you believe LDAP was too simple or not, I think it can be agreed > that whatever it did, for good or bad, it got deployed widely. In the > absence of LDAP I don't think x.500 would ever have achieved the same > ubiquity. DIX has similar goals, simplify where it counts, make it > deployable in a larger scope than current offerings. And I am trying to put it across to the dix community that there is value in simplification but not in over-simplification. LDAP did not represent the optimal simplification. Learning from LDAP (and similar cases) might help dix achieve wide deployment *and* long life. MVH leifj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIbw98Jx8FtbMZncRAhepAKC6C0VUHeVGjJsHAIsRqACXFgbEsACcC/gj 8/3dA3+LT8LHe22aHIfZngI= =/49J -----END PGP SIGNATURE----- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 16:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAm0-0004hQ-Pu; Wed, 22 Mar 2006 16:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAm0-0004hL-3x for dix@ietf.org; Wed, 22 Mar 2006 16:21:44 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAly-0003T9-Sv for dix@ietf.org; Wed, 22 Mar 2006 16:21:44 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k2MLLgoK027492 for ; Wed, 22 Mar 2006 16:21:42 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k2MLLfeL015767 for ; Wed, 22 Mar 2006 16:21:42 -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 k2MLLehg030509 for ; Wed, 22 Mar 2006 16:21:41 -0500 Message-ID: <4421BFE3.5030201@redhat.com> Date: Wed, 22 Mar 2006 13:21:39 -0800 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> <4421BA35.1070703@redhat.com> <4421BC3D.9030508@it.su.se> In-Reply-To: <4421BC3D.9030508@it.su.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1705106003==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1705106003== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070601090301070902020103" This is a cryptographically signed message in MIME format. --------------ms070601090301070902020103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Leif Johansson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > >>Simple in the LDAP sense most certainly does mean less code, where it >>counts, in the client. >> >> > >Measured how exactly? > > I don't want to bog down this list with this, so I'll just say that client responsibilities are much lower in LDAP than in x.500. >> >>Whether you believe LDAP was too simple or not, I think it can be agreed >>that whatever it did, for good or bad, it got deployed widely. In the >>absence of LDAP I don't think x.500 would ever have achieved the same >>ubiquity. DIX has similar goals, simplify where it counts, make it >>deployable in a larger scope than current offerings. >> >> > >And I am trying to put it across to the dix community that there is >value in simplification but not in over-simplification. LDAP did not >represent the optimal simplification. Learning from LDAP (and similar >cases) might help dix achieve wide deployment *and* long life. > > That is noted :) I was just making the point that simple but widely deployed is sometimes (usually?) better than complex and not widely deployed. Even if down the road you may need to revise some things to address new areas of interest, at least you have something to do it with. -- Pete --------------ms070601090301070902020103 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 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 CSqGSIb3DQEJBTEPFw0wNjAzMjIyMTIxMzlaMCMGCSqGSIb3DQEJBDEWBBR6hYbs6Dfci3+O O8RxMkOeUT1DyzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAuAyC0dvVNtjw+8O40DLLYzZN1VGkyTgyPb/rf4Vc6NlKHdpaSA8dtYFdpgVc LKDDrUU3VHBk6url21vjDdD3E4So9qHGSf0lnqMUipfAmqxsIqkZf78pTA5RsZcQW6My6tdF V0K0G7XXsOgPkvLQKFoX2i5K/p9KxEFHzGisrx0Y35zIvDtdqU189IcBe5T6YkWPBj1rgwZw zMhITUU5nVzb1otjCIp5DcZkne4sWFBfKL6Cb0GQRaDBGMdUIJjC5Rv80xFmgRuCyCsDyLfy p1ypCmTyk691T0asb2Q9Xa7pNHRlMb7LznN71Iwgvya+GzMiC61oeIVJvvfrN4jXpwAAAAAA AA== --------------ms070601090301070902020103-- --===============1705106003== 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 --===============1705106003==-- From dix-bounces@ietf.org Wed Mar 22 16:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMB3T-0005Nv-PN; Wed, 22 Mar 2006 16:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMB3S-0005Nq-QD for dix@ietf.org; Wed, 22 Mar 2006 16:39:46 -0500 Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMB3R-00049u-9P for dix@ietf.org; Wed, 22 Mar 2006 16:39:46 -0500 Received: by wproxy.gmail.com with SMTP id 71so30237wra for ; Wed, 22 Mar 2006 13:39:45 -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=GtSo4IsNJIT+Ij2sEFTVBk6gNpsykYb6gF6pAphzZRmVQgOwdhbYKRYeApxS0C6Thd4ePy0AGfnlb9ghfcgMs7AZZIVHS12TdMAEkZC9c/bPC5rtqzaGJW7UsQ/5SUwU9tN2NNVuEenQeuniJNpSHBqEaLYTIdxmEd1Zq27crSg= Received: by 10.54.72.8 with SMTP id u8mr649677wra; Wed, 22 Mar 2006 13:39:44 -0800 (PST) Received: from ?9.33.49.136? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 27sm178015wrl.2006.03.22.13.39.43; Wed, 22 Mar 2006 13:39:44 -0800 (PST) Message-ID: <4421C41E.1090907@gmail.com> Date: Wed, 22 Mar 2006 16:39:42 -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: SAML and REST - was Re: [dix] DIX use cases References: <198A730C2044DE4A96749D13E167AD379E0B6F@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD379E0B6F@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: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: >I don't know why that would be the case. I wrote the first draft of what >became the SAML assertion infrastructure before Microsoft wrote the first >draft of SOAP. > >WS-* is certainly tied down to the Web Services framework. That is a >different design decision that has advanatges and disadvantages. WS-* is >architected as an active transport layer protocol, SAML is architected as >static data. > >The advantage of the static mode is precisely that you are not tied to >transport unless you want to be. > >REST is just a protocol architecture style. Fielding has a different >architectural style to Fristyk-Neilsen or Hallam-Baker. I don't see why the >idea of giving his style an acronym makes it more valid than any other or >creates an incompatibility. He sees an adantage to keeping to one consistent >style that he adopted in 1995 or so. Folk who care about these things can >probably see quite a lot of change in my style over the years. There is a >case to be made for both approaches. > > > so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. Here is an ATOM post. POST /myblog/entries HTTP/1.1 Host: example.org User-Agent: Thingio/1.0 Content-Type: application/atom+xml Content-Length: nnn Atom-Powered Robots Run Amok urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 2003-12-13T18:30:02Z Some text. Where does the SAML go? I apologize for my lack of understanding here. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 18:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMD6g-0007TV-CN; Wed, 22 Mar 2006 18:51:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMD6Z-0007N7-3b for dix@ietf.org; Wed, 22 Mar 2006 18:51:07 -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 1FMD6T-0000hw-VQ for dix@ietf.org; Wed, 22 Mar 2006 18:51:06 -0500 Received: from [10.0.1.2] ([66.194.95.2]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2MNoxmL084257 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 22 Mar 2006 15:51:00 -0800 (PST) (envelope-from dick@sxip.com) In-Reply-To: <8024A864-1867-434B-98E2-FC244309280E@textuality.com> References: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> <8024A864-1867-434B-98E2-FC244309280E@textuality.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17421130-063F-4B4F-B270-D29E97EE88E7@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP Date: Wed, 22 Mar 2006 17:51:00 -0600 To: uri@w3.org, Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=2.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL autolearn=no version=3.1.0 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Tim Bray X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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-Mar-06, at 9:42 AM, Tim Bray wrote: > >> Does this make sense? Do you have a suggestion for another >> approach that provides an escape mechanism and allows >> decentralized property /capability extension? > > In general, naming things with URIs is a good and Web-friendly > thing to do; as you point out, the use of the authority field > allows distributed authority over parts of the namespace. In > particular, HTTP URIs have a lot of advantages. Thanks everyone for the feedback on the URI scheme for DIX. A likely shift in the architecture removes the requirement for the URI scheme to double as an escape sequence, so we can use HTTP. A couple examples of what we are doing are: http://sxip.net/contact/internet/email http://sxip.net/media/image/32x32 > you can put something useful there that a human being can point > their browser at and learn something about what this string means. Tim: what would you suggest that we put at that URLs above? An HTML file that describes it for people? Perhaps some metadata that is machine readable for typing? Suggestions welcome! -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 19:16:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDVF-0004sF-DJ; Wed, 22 Mar 2006 19:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDQW-0001hZ-EG for dix@ietf.org; Wed, 22 Mar 2006 19:11:44 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMDQT-0003ZM-Pt for dix@ietf.org; Wed, 22 Mar 2006 19:11:44 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2N0Bf8u019045 for ; Wed, 22 Mar 2006 17:11:41 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWJ00A01ZZSRW00@mail-amer.sun.com> (original mail from tbray@textuality.com) for dix@ietf.org; Wed, 22 Mar 2006 17:11:41 -0700 (MST) Received: from [192.168.102.100] ([154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWK00A3I0JG9WU3@mail-amer.sun.com>; Wed, 22 Mar 2006 17:11:41 -0700 (MST) Date: Wed, 22 Mar 2006 16:11:53 -0800 From: Tim Bray Subject: Re: [dix] on the dix: URI scheme for DIX/SXIP In-reply-to: <17421130-063F-4B4F-B270-D29E97EE88E7@sxip.com> To: Dick Hardt Message-id: <1E94FDD7-DC4A-40E0-B988-CF2F43614F24@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <7F546F6F-115E-4052-AA6F-58B7B65AEE94@sxip.com> <8024A864-1867-434B-98E2-FC244309280E@textuality.com> <17421130-063F-4B4F-B270-D29E97EE88E7@sxip.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Wed, 22 Mar 2006 19:16:36 -0500 Cc: Digital Identity Exchange , uri@w3.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: , Errors-To: dix-bounces@ietf.org On Mar 22, 2006, at 3:51 PM, Dick Hardt wrote: >> you can put something useful there that a human being can point >> their browser at and learn something about what this string means. > > Tim: what would you suggest that we put at that URLs above? An HTML > file that describes it for people? Perhaps some metadata that is > machine readable for typing? Suggestions welcome! Ideally, both (e.g. see http://www.rddl.org/) but there aren't any agreed-upon standards; if you want to have something there that SXIP- savvy software can read that might be useful; failing anything automated, having something human-readable to explain what's going on to the puzzled programmer is good citizenship. -Tim _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 20:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEBd-0002j4-V5; Wed, 22 Mar 2006 20:00:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEBc-0002b8-OZ for dix@ietf.org; Wed, 22 Mar 2006 20:00:24 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEBb-0005qt-EB for dix@ietf.org; Wed, 22 Mar 2006 20:00:24 -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 k2N10MgW014400 for ; Wed, 22 Mar 2006 17:00:22 -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 Mar 2006 17:00:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] So what went wrong? Date: Wed, 22 Mar 2006 17:00:22 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD379E0BF9@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dix] So what went wrong? Thread-Index: AcZN7S1tVlpf+OIJSAGx1/+cS+XKtgAEAq2w From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 23 Mar 2006 01:00:22.0598 (UTC) FILETIME=[299B9660:01C64E15] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935689858==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1935689858== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0057_01C64DCC.2E2B88F0" This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C64DCC.2E2B88F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Leif Johansson [mailto:leifj@it.su.se] > Ahem, well, more like beeing in the room trying to sell LDAP to X.500. Good analogy. I would like to emphasize the point here that regardless of whether people feel X.500 did it right or not there is no likelihood that particular protocol would ever have made it on its own. I don't think we are in that exact situation with SAML. But I think that a well defined SAML subset, possibly using a non-XML syntax but building on the existing SAML nomenclature could help catalyze deployment of a ubiquitous infrastructure. Some parts of DIX are clearly better than SAML, the use of the term 'claim' as opposed to 'statement', the distinction between assertions and statements always worried me in SAML as being entirely conventional and thus possibly confusing. Unfortunately that is probably one of the decisions it would probably be better to not revisit as introducing a new term at this time might introduce even more confusion. ------=_NextPart_000_0057_01C64DCC.2E2B88F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjIyMjE3NTZaMCMGCSqGSIb3DQEJBDEWBBTe zkQCRr0zC1fmkgrDrUg/Cy4T2zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYDPKgpSHL/yRZgyQUZeKuhljCam nnJZqvbGQ+MZOUZnDsK9rxUH/WrQ1WJsK9fUZvsgoDEZnwYhHMB4U9fSz4IQuwBafmZ6Ztf6cvKq /J9QvIPb+nP/OwpliVg4O/FP8qASEAiihFc3rVzCVoFd75jUviIsa3z8F3x3s1KMkAKOFgAAAAAA AA== ------=_NextPart_000_0057_01C64DCC.2E2B88F0-- --===============1935689858== 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 --===============1935689858==-- From dix-bounces@ietf.org Wed Mar 22 20:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEhG-0002ul-NC; Wed, 22 Mar 2006 20:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEhG-0002tj-5x for dix@ietf.org; Wed, 22 Mar 2006 20:33:06 -0500 Received: from imo-m16.mx.aol.com ([64.12.138.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMEhF-0007iU-TN for dix@ietf.org; Wed, 22 Mar 2006 20:33:06 -0500 Received: from THayes0993@aol.com by imo-m16.mx.aol.com (mail_out_v38_r7.3.) id l.1e3.4e08c503 (16112) for ; Wed, 22 Mar 2006 20:32:55 -0500 (EST) Received: from FWM-D06 (fwm-d06.webmail.aol.com [205.188.160.198]) by air-id12.mx.aol.com (vx) with ESMTP id MAILINID124-3ef04421fac7287; Wed, 22 Mar 2006 20:32:55 -0500 Date: Wed, 22 Mar 2006 20:32:55 -0500 Message-Id: <8C81C30D82722A2-C88-A785@FWM-D06.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD379E0B6F@MOU1WNEXMB04.vcorp.ad.vrsn.com> <4421C41E.1090907@gmail.com> Received: from 10.169.155.114 by FWM-D06.sysops.aol.com (205.188.160.198) with HTTP (WebMailUI); Wed, 22 Mar 2006 20:32:55 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <4421C41E.1090907@gmail.com> X-Mailer: AOL WebMail 15106 Subject: Re: SAML and REST - was Re: [dix] DIX use cases MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 205.188.160.198 X-Spam-Flag: NO X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1834881865==" Errors-To: dix-bounces@ietf.org --===============1834881865== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C81C30D82722A2_C88_A489_FWM-D06.sysops.aol.com" ----------MailBlocks_8C81C30D82722A2_C88_A489_FWM-D06.sysops.aol.com Content-Type: text/plain; charset="us-ascii" It could go in the HTTP Authorization field using a new scheme to be defined. There seem to be several people interested in enhancing HTTP to allow data like this to be provided for REST-style interactions. This has parallels with putting data in SOAP headers rather than in the content of the message. Terry -----Original Message----- From: Robert Yates To: Digital Identity Exchange Sent: Wed, 22 Mar 2006 16:39:42 -0500 Subject: SAML and REST - was Re: [dix] DIX use cases so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. Here is an ATOM post. POST /myblog/entries HTTP/1.1 Host: example.org User-Agent: Thingio/1.0 Content-Type: application/atom+xml Content-Length: nnn Atom-Powered Robots Run Amok urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 2003-12-13T18:30:02Z Some text. Where does the SAML go? I apologize for my lack of understanding here. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ----------MailBlocks_8C81C30D82722A2_C88_A489_FWM-D06.sysops.aol.com Content-Type: text/html; charset="us-ascii"
 
It could go in the HTTP Authorization field using a new scheme to be defined.
 
There seem to be several people interested in enhancing HTTP to allow data like this to be provided for REST-style interactions.  This has parallels with putting data in SOAP headers rather than in the content of the message.

Terry

-----Original Message-----
From: Robert Yates <robyates70@gmail.com>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Wed, 22 Mar 2006 16:39:42 -0500
Subject: SAML and REST - was Re: [dix] DIX use cases


so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. 
 
but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. 
 
Here is an ATOM post. 
 
POST /myblog/entries HTTP/1.1 
  Host: example.org 
  User-Agent: Thingio/1.0 
  Content-Type: application/atom+xml 
  Content-Length: nnn 
 
  <entry xmlns="http://www.w3.org/2005/Atom"> 
  <title>Atom-Powered Robots Run Amok</title> 
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> 
  <updated>2003-12-13T18:30:02Z</updated> 
  <content>Some text.</content> 
  </entry> 
 
Where does the SAML go? I apologize for my lack of understanding here. 
 
Rob 
 
_______________________________________________ 
dix mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 
----------MailBlocks_8C81C30D82722A2_C88_A489_FWM-D06.sysops.aol.com-- --===============1834881865== 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 --===============1834881865==-- From dix-bounces@ietf.org Wed Mar 22 20:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEhI-0002xZ-SR; Wed, 22 Mar 2006 20:33:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEhG-0002v0-UQ for dix@ietf.org; Wed, 22 Mar 2006 20:33:07 -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 1FMEhE-0007iQ-4X for dix@ietf.org; Wed, 22 Mar 2006 20:33:06 -0500 Received: from [10.0.1.3] ([66.194.95.2]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2N1X0vA089470 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 22 Mar 2006 17:33:01 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) 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: Wed, 22 Mar 2006 19:32:31 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=2.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL autolearn=no version=3.1.0 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 1.8 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [dix] BOF wrap up X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 still working on the notes from the meeting, but you can see the jabber log of the BOF here: http://www.ietf.org/meetings/ietf-logs/dix@rooms.jabber.ietf.org/ 2006-03-21.html Some consensus questions were asked of the audience, and there was some general agreement about some things in the debate. In summary I believe they were: - There is a real problem here and a debate around that should be held in the IETF. - Clearly more formal requirements and use cases need to be worked on. - To quote Lisa: Something is 'gelling' around user identifiers, perhaps as a URL. - We should reuse existing technology where appropriate. Next steps... - We should put effort into a clearer problem definition, some compelling use cases, and perhaps some detailed requirements. Email me if you're willing to commit effort to that. - A further investigation of existing technology. In particular Bob and Jeff's comments around SAML/Liberty/Shib was of interest to many. Is the list in rough agreement of these next steps? Are there other actions the group members think that we should take? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 20:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEk9-00073y-Te; Wed, 22 Mar 2006 20:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMEk9-00073t-CU for dix@ietf.org; Wed, 22 Mar 2006 20:36:05 -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 1FMEk6-0007q1-Fj for dix@ietf.org; Wed, 22 Mar 2006 20:36:05 -0500 Received: from [10.0.1.2] ([66.194.95.2]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2N1a06T089609 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 22 Mar 2006 17:36:01 -0800 (PST) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <0954DD74-4D99-4B55-AF44-24E32B47DC44@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: Dick Hardt Date: Wed, 22 Mar 2006 19:36:00 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=2.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL autolearn=no version=3.1.0 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [dix] User-centric SAML Profile X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Jeff Hodges was quite generous with his time yesterday after the BOF and educated John Merrells and myself on many of the design objectives of SAML 2.0. Conclusion: It seems possible that a User-centric SAML 2.0 Profile can be defined to execute on the Identity 2.0 vision. While the lists continues to discuss use cases etc. to see if a WG in IETF makes sense, John and I will confer with SAML experts (volunteers?) that are interested in driving convergence, and report back to the list. -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 22:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMGUc-00025h-9h; Wed, 22 Mar 2006 22:28:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMGUa-00025c-LX for dix@ietf.org; Wed, 22 Mar 2006 22:28:08 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMGUZ-0002t2-D4 for dix@ietf.org; Wed, 22 Mar 2006 22:28:08 -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 k2N3S5BW001871; Thu, 23 Mar 2006 03:28:06 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 22:28:05 -0500 Received: from 10.31.13.107 ([10.31.13.107]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Mar 2006 03:28:04 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 22 Mar 2006 22:28:02 -0500 Subject: Re: [dix] DIX use cases From: Peter Davis To: "Digital Identity Exchange " , Robert Yates Message-ID: Thread-Topic: [dix] DIX use cases Thread-Index: AcZOKco5CO4/y7odEdqUSAANk3jHKA== In-Reply-To: <44215697.5050805@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Mar 2006 03:28:05.0344 (UTC) FILETIME=[CC374E00:01C64E29] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 3/22/2006 8:52 AM, "Robert Yates" wrote: > Peter Davis wrote: >> The present atom-pub ID is ambiguous for UA support for 3xx class response >> codes (which would be required for the HTTP redirect binding). The POST >> binding carries no such dependencies on HTTP 3xx responses however. >> >> SAML POST only requires access to the POST and GET verbs of HTTP, and for >> convenience, support for response codes 3xx (redirect response codes), but >> those are not MTI for SAML POST to properly function. >> >> The defense RESTs ;-) >> > Not so fast ;-) The SAML POST binding requires that the HTTP UA be a > browser or at the very least it MUST be capable of rendering HTML forms > and then making posts of media type > `application/x-www-form-urlencoded'. Fair enough. (tho any self respecting webDav client should, which is what various blogging tools really are) > There is no such requirement on > atom clients, nor any HTTP UA. Google, for example, has an ATOM client > that is a plugin for word http://buzz.blogger.com/bloggerforword.html. > This certainly can't presently make use of SAML's POST binding. While > it can be argued that these clients could make use of this binding I > think the burden of being capable of parsing HTML Forms, forming a post > of media type 'application/x-www-form-urlencoded' and dealing with all > the character encoding pitfalls of html is too great when all they are > trying to do is authenticate. You are correct. As others have pointed out, however, conveying these messages as text/xml rather than application/x-www-form-urlencoded is not out of the question. > > The SAML redirect binding has more potential, as all HTTP UAs should > honor the 3xx return codes. The problem with this binding, that is also > shared with the POST binding, is how the user indicates to the SP the > location of his IdP. This (I think) is a challenge for any protocol proposal. IDP discovery has always been a challenge (esp when the user uses several IDPs for various purposes). Even with dmd1, we are faced with a requirement to have the user submit a URI to the SP to determine the IDP. > Here's the > problem. > > Elliot's dad's photostream has the following url. > http://apple.com/photostreams/elliots-dad. He e-mails the url of this > feed to Elliot and I. Now what? Again, assuming for the moment that you and Eliot use different IDPs, you would have to provide apple with some 'hint' as to where to try to route an authentication/attribute request. We have to go under the assumption that many IDPs will exist, and we'll need one (or more) mechanisms to: A] provide the relying party with at least a hint as to the set of IDPs the user and RP are willing to use for a given transaction/ B] convert that hint into something richer (metadata), which arms the RP with both the capabilities and endpoints in order to conduct the authentication > > Am not sure you can REST just yet. Your witness ;-) > Hehe. RESTful puns could get pretty bad. I'll give it a REST. =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 22 23:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHPn-0001V7-WF; Wed, 22 Mar 2006 23:27:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHPl-0001Rt-QS for dix@ietf.org; Wed, 22 Mar 2006 23:27:13 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMHPl-0005QP-5k for dix@ietf.org; Wed, 22 Mar 2006 23:27:13 -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 k2N4RCjJ026450 for ; Wed, 22 Mar 2006 20:27:12 -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 Mar 2006 20:27:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: SAML and REST - was Re: [dix] DIX use cases Date: Wed, 22 Mar 2006 20:27:06 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SAML and REST - was Re: [dix] DIX use cases Thread-Index: AcZOGcCpmPOyUmzdQB6rX4/cBI9oYQAF9Lzg From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 23 Mar 2006 04:27:12.0061 (UTC) FILETIME=[0E395ED0:01C64E32] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0252082315==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0252082315== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01C64DFF.C01D1B10" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C64DFF.C01D1B10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C64DFF.C01D1B10" ------=_NextPart_001_000B_01C64DFF.C01D1B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lets forget about REST and concentrate on the BEST place. The HTTP-Authorization field is the right place (and no I did not choose that tag name and I objected at the time, they snuck it in along with BASIC while I was suffering from food poisoning). I am responsible for the imaginative spelling of Referer though. _____ From: thayes0993@aol.com [mailto:thayes0993@aol.com] Sent: Wednesday, March 22, 2006 7:33 PM To: dix@ietf.org Subject: Re: SAML and REST - was Re: [dix] DIX use cases It could go in the HTTP Authorization field using a new scheme to be defined. There seem to be several people interested in enhancing HTTP to allow data like this to be provided for REST-style interactions. This has parallels with putting data in SOAP headers rather than in the content of the message. Terry -----Original Message----- From: Robert Yates To: Digital Identity Exchange Sent: Wed, 22 Mar 2006 16:39:42 -0500 Subject: SAML and REST - was Re: [dix] DIX use cases so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. Here is an ATOM post. POST /myblog/entries HTTP/1.1 Host: example.org User-Agent: Thingio/1.0 Content-Type: application/atom+xml Content-Length: nnn Atom-Powered Ro bots Run Amok urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 2003-12-13T18:30:02Z Some text. Where does the SAML go? I apologize for my lack of understanding here. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ------=_NextPart_001_000B_01C64DFF.C01D1B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lets forget about REST and concentrate on the = BEST=20 place.
 
The HTTP-Authorization field is the right place = (and no I=20 did not choose that tag name and I objected at the time, they snuck it = in along=20 with BASIC while I was suffering from food poisoning). I am responsible = for the=20 imaginative spelling of Referer though.

From: thayes0993@aol.com=20 [mailto:thayes0993@aol.com]
Sent: Wednesday, March 22, 2006 = 7:33=20 PM
To: dix@ietf.org
Subject: Re: SAML and REST - = was Re:=20 [dix] DIX use cases

 
It could go in the HTTP Authorization field using a new scheme to = be=20 defined.
 
There seem to be several people interested in enhancing HTTP to = allow=20 data like this to be provided for REST-style interactions.  This = has=20 parallels with putting data in SOAP headers rather than in the content = of the=20 message.

Terry

-----Original Message-----
From: Robert Yates=20 <robyates70@gmail.com>
To: Digital Identity Exchange=20 <dix@ietf.org>
Sent: Wed, 22 Mar 2006 16:39:42 = -0500
Subject: SAML=20 and REST - was Re: [dix] DIX use cases


so I admit = that I am=20 confused and probably out of my depth, and I know better than to argue = with=20 the initial spec author that it can't be done. 
 
but = I simply=20 don't understand what it means to use SAML with something like atompub = http://www.ietf.org/internet-drafts/draft-ietf-atompub-pr= otocol-08.txt=20 or any of the plethora of so-called REST based web=20 services. 
 
Here is an ATOM = post. 
 
POST=20 /myblog/entries HTTP/1.1 
  Host: = example.org 
 =20 User-Agent: Thingio/1.0 
  Content-Type:=20 application/atom+xml 
  Content-Length:=20 nnn 
 
  <entry xmlns=3D"http://www.w3.org/2005/Atom"> 
 =20 <title>Atom-Powered Ro bots Run = Amok</title> 
 =20 = <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <= BR> =20 <updated>2003-12-13T18:30:02Z</updated> 
 =20 <content>Some text.</content> 
 =20 </entry> 
 
Where does the SAML go? I apologize = for my=20 lack of understanding=20 = here. 
 
Rob 
 
_________________________= ______________________ 
dix=20 mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 
<= /DIV>
------=_NextPart_001_000B_01C64DFF.C01D1B10-- ------=_NextPart_000_000A_01C64DFF.C01D1B10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjMwNDI3MDZaMCMGCSqGSIb3DQEJBDEWBBR/ j7QW9CzRc3Bk0w6Hgdj61qg/ZTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYCnj9xh0oPOqtA/XLGXDfLb3rkC 8boRFLtElz4nlcZOPXSNBehCqUAWk/EvxV8xMd+VGh0dQ82e99cyL6wu7HzmYFtMc7BUjV264MuR eg4OwtDzKrILtrEOEO94DCj0GWKdsYI7CfLQtxhhRWqw1Zu5CDeoM54mN/QGrelC7MJpYwAAAAAA AA== ------=_NextPart_000_000A_01C64DFF.C01D1B10-- --===============0252082315== 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 --===============0252082315==-- From dix-bounces@ietf.org Wed Mar 22 23:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHY4-0007xM-68; Wed, 22 Mar 2006 23:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMHY2-0007vc-UK for dix@ietf.org; Wed, 22 Mar 2006 23:35:46 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMHY1-00062R-Ih for dix@ietf.org; Wed, 22 Mar 2006 23:35:46 -0500 Received: from [127.0.0.1] (maildrop.informatik.uni-bremen.de [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k2N4ZeSg029709; Thu, 23 Mar 2006 05:35:42 +0100 (CET) In-Reply-To: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: SAML and REST - was Re: [dix] DIX use cases Date: Wed, 22 Mar 2006 22:35:39 -0600 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 Do we really need to change HTTP for DIX? Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 02:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMKVw-0007bK-De; Thu, 23 Mar 2006 02:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMKVv-0007b8-Kl for dix@ietf.org; Thu, 23 Mar 2006 02:45:47 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMKVu-0004Up-8h for dix@ietf.org; Thu, 23 Mar 2006 02:45:47 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 08:45:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] So what went wrong? Date: Thu, 23 Mar 2006 08:45:44 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC2040A9E68@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] So what went wrong? Thread-Index: AcZN9qGikMUXoDNsTSOX5hk3CuFPyQAVq+QQ From: "BAILLEUX Benoit RD-BIZZ-CAE" To: "Digital Identity Exchange" X-OriginalArrivalTime: 23 Mar 2006 07:45:45.0101 (UTC) FILETIME=[CAF303D0:01C64E4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: Pete Rowley [mailto:prowley@redhat.com]=20 > That is noted :) I was just making the point that simple but widely=20 > deployed is sometimes (usually?) better than complex and not widely=20 > deployed. Even if down the road you may need to revise some=20 > things to=20 > address new areas of interest, at least you have something to=20 > do it with. One of the success key of LDAP is exactly based on its extensibility. So let's build something (rather) simple that can grow with its users. --=20 BB _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 04:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMLrz-0001fe-PH; Thu, 23 Mar 2006 04:12:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMLry-0001dM-P5 for dix@ietf.org; Thu, 23 Mar 2006 04:12:38 -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 1FMLrw-0008EA-40 for dix@ietf.org; Thu, 23 Mar 2006 04:12:38 -0500 Received: from [10.0.1.3] ([66.194.95.2]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k2N9CXEF002645 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 23 Mar 2006 01:12:35 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <4421BFE3.5030201@redhat.com> References: <3F864419-52EE-4745-9F9E-FC614B67C679@tzi.org> <4421B003.70104@it.su.se> <4421BA35.1070703@redhat.com> <4421BC3D.9030508@it.su.se> <4421BFE3.5030201@redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F4A5736-67BA-44D3-AFC8-FDEAF7DE47EA@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] So what went wrong? Date: Thu, 23 Mar 2006 03:12:35 -0600 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL autolearn=no version=3.1.0 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 My god... this thread has turned into an 'Alan Lloyd' experience... (*) John * You'd have to have been on the ldap lists in the late 90's to appreciate that, but there were endless endless endless threads about the wonders of ASN.1 and jet planes with wooden propellers and all manner of mangled metaphors. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 08:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQIG-0002Wh-RG; Thu, 23 Mar 2006 08:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQIG-0002Wc-3Z for dix@ietf.org; Thu, 23 Mar 2006 08:56:04 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQIA-00039a-Op for dix@ietf.org; Thu, 23 Mar 2006 08:56:04 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 62CEE14228A; Thu, 23 Mar 2006 05:55:58 -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 14377-03; Thu, 23 Mar 2006 05:55:57 -0800 (PST) Received: from [130.129.133.236] (DHCP-Wireless-133-236.ietf65.org [130.129.133.236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C1001142289; Thu, 23 Mar 2006 05:55:57 -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: <3A578967-A644-43C5-BDF7-5B450D3A1119@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] DIX use cases Date: Thu, 23 Mar 2006 07:55:47 -0600 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: 8b30eb7682a596edff707698f4a80f7d 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 Mar 22, 2006, at 9:28 PM, Peter Davis wrote: > On 3/22/2006 8:52 AM, "Robert Yates" wrote: >>> >> Not so fast ;-) The SAML POST binding requires that the HTTP UA be a >> browser or at the very least it MUST be capable of rendering HTML >> forms >> and then making posts of media type >> `application/x-www-form-urlencoded'. > > Fair enough. (tho any self respecting webDav client should, which > is what > various blogging tools really are) I can't vouch for them being "self-respecting" but here are some WebDAV clients that do not render HTML at all, so can't use HTML forms to authenticate: - Mac OS/ X "WebDAV-FS" tool in the OS, which mounts a remote WebDAV repository as a file system (very NFS-like) - Windows NT and XP and later, "Network Places" or File system "Redirector" which do the same - Xythos WebFile Client, mounts WebDAV repository as a Windows drive - cadaver, command-line WebDAV client for *nix - sitecopy, *nix utility for synchronizing local and remote file system content over WebDAV - Chandler, general sharing and calendar sharing client (CalDAV) - Mozilla "Sunbird", calendar client - Evolution calendar client - MS Outlook Express, email over WebDAV - SVN clients, doing source gets/puts/synchs over WebDAV - Adobe Acrobat, GoLive, Photoshop and others, share "workgroup" documents on WebDAV There are more listed at though it's not complete either. Lisa _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 10:38:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRt0-0003Ca-AE; Thu, 23 Mar 2006 10:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRsy-0003C1-SS for dix@ietf.org; Thu, 23 Mar 2006 10:38:05 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRsx-0000AV-J0 for dix@ietf.org; Thu, 23 Mar 2006 10:38:04 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 9669D740D5 for ; Thu, 23 Mar 2006 16:38:02 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31587-01-47 for ; Thu, 23 Mar 2006 16:38:02 +0100 (CET) Received: from [130.129.129.217] (DHCP-Wireless-129-217.ietf65.org [130.129.129.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id B2CDF74060 for ; Thu, 23 Mar 2006 16:38:01 +0100 (CET) Message-ID: <4422C0D7.9040109@it.su.se> Date: Thu, 23 Mar 2006 16:37:59 +0100 From: Leif Johansson User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] So what went wrong? References: <941BA0BF46DB8F4983FF7C8AFE800BC2040A9E68@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC2040A9E68@ftrdmel3.rd.francetelecom.fr> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.018 tagged_above=-99 required=7 tests=[AWL=0.647, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > One of the success key of LDAP is exactly based on its extensibility. So > let's build something (rather) simple that can grow with its users. That was *exactly* my point. Simplification is good when it does not affect architecture. Simplification in architecture makes extensibility difficult (typically). Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIsDX8Jx8FtbMZncRAq6RAJ9oahKGiOtzXpMhy+/tpSabM1Bs1wCgkl75 bKy2TSb4TYZfqfsu5mN0wNQ= =Tq3t -----END PGP SIGNATURE----- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 12:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTvA-0004v6-Gn; Thu, 23 Mar 2006 12:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTv8-0004v1-Op for dix@ietf.org; Thu, 23 Mar 2006 12:48:26 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTv8-0005ZE-HA for dix@ietf.org; Thu, 23 Mar 2006 12:48:26 -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 k2NHmQBW014109; Thu, 23 Mar 2006 17:48:26 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 12:48:25 -0500 Received: from 10.31.30.92 ([10.31.30.92]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Mar 2006 17:48:25 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 23 Mar 2006 12:48:26 -0500 Subject: Various User Agent Support (was: Re: [dix] DIX use cases) From: Peter Davis To: "Digital Identity Exchange " , Lisa Dusseault Message-ID: Thread-Topic: Various User Agent Support (was: Re: [dix] DIX use cases) Thread-Index: AcZOofyGOt+nErqVEdqUSAANk3jHKA== In-Reply-To: <3A578967-A644-43C5-BDF7-5B450D3A1119@osafoundation.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Mar 2006 17:48:25.0967 (UTC) FILETIME=[FC8147F0:01C64EA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 3/23/2006 8:55 AM, "Lisa Dusseault" wrote: > > On Mar 22, 2006, at 9:28 PM, Peter Davis wrote: > >> On 3/22/2006 8:52 AM, "Robert Yates" wrote: >>>> >>> Not so fast ;-) The SAML POST binding requires that the HTTP UA be a >>> browser or at the very least it MUST be capable of rendering HTML >>> forms >>> and then making posts of media type >>> `application/x-www-form-urlencoded'. >> >> Fair enough. (tho any self respecting webDav client should, which >> is what >> various blogging tools really are) > > I can't vouch for them being "self-respecting" but here are some > WebDAV clients that do not render HTML at all, so can't use HTML > forms to authenticate: I think this thread has (at least for me) is teasing out a new requirement . It underscores the need to ensure support for non-HTML aware HTTP clients. While many of the DAV clients Lisa enumerated use shared HTTP engines, they may not always avail themselves of shared HTML engines. As a result, perhaps a new requirement may look like: - the protocol shall support the transfer/transport of security tokens over HTTP, but does not require implementations to support the HTML form controls
and the associated encodings (eg: Calendar Clients, FS-browsers, etc...) Maybe that requirement (or a close cousin) is already there. I cannot seem to drudge up the present requirements thread... =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 12:57:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMU3Z-0004vI-OS; Thu, 23 Mar 2006 12:57:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMU3Y-0004v7-Uc for dix@ietf.org; Thu, 23 Mar 2006 12:57:08 -0500 Received: from zproxy.gmail.com ([64.233.162.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMU3X-0005mB-DM for dix@ietf.org; Thu, 23 Mar 2006 12:57:08 -0500 Received: by zproxy.gmail.com with SMTP id 18so710331nzp for ; Thu, 23 Mar 2006 09:57:06 -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=BjUuV/pLn+fWGxR4hPgvfYpWgmkMN0C15nUt1m0ZyY0lRfFamF8V+Y9sv4vXfBOq6ZXSHx97vYLrvkqdLvL39XFxIjzL238B6zf2K9qlHfWIHLwUinhdhYM9Wy2JdqUfK/LBcD6/M5skQy+NsY0Li3ViH1c0QyfeYm/IbCmtvZI= Received: by 10.65.158.4 with SMTP id k4mr1873039qbo; Thu, 23 Mar 2006 09:57:06 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id f14sm422564qba.2006.03.23.09.57.05; Thu, 23 Mar 2006 09:57:06 -0800 (PST) Message-ID: <4422E16F.7080503@gmail.com> Date: Thu, 23 Mar 2006 12:57:03 -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 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [dix] Re: Various User Agent Support X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Peter Davis wrote: >I think this thread has (at least for me) is teasing out a new requirement . >It underscores the need to ensure support for non-HTML aware HTTP clients. >While many of the DAV clients Lisa enumerated use shared HTTP engines, they >may not always avail themselves of shared HTML engines. > >As a result, perhaps a new requirement may look like: > >- the protocol shall support the transfer/transport of security tokens over >HTTP, but does not require implementations to support the HTML form controls > and the associated encodings (eg: Calendar Clients, FS-browsers, >etc...) > > +1 >Maybe that requirement (or a close cousin) is already there. I cannot seem >to drudge up the present requirements thread... > > > In an earlier thread Dick had ruled out of scope what he refers to as "Rich Client" applications. At the BOF they were on the in/out list. I believe that they need to be firmly on the "in" list. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 14:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVi6-0007Yo-JX; Thu, 23 Mar 2006 14:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVi5-0007Yi-Hi for dix@ietf.org; Thu, 23 Mar 2006 14:43:05 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVi4-0001pO-4h for dix@ietf.org; Thu, 23 Mar 2006 14:43:05 -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 k2NJh3dV031681 for ; Thu, 23 Mar 2006 11:43:03 -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); Thu, 23 Mar 2006 11:43:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: SAML and REST - was Re: [dix] DIX use cases Date: Thu, 23 Mar 2006 11:43:01 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD379E0CD6@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SAML and REST - was Re: [dix] DIX use cases Thread-Index: AcZOM0W5P1Mh9H0uTuaNBqVMzFMZ1AAfpb2g From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 23 Mar 2006 19:43:03.0272 (UTC) FILETIME=[FFB2BE80:01C64EB1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1553595395==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============1553595395== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01C64E7F.B3D82D60" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C64E7F.B3D82D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The point is that this is precisely what the HTTP authorize header was defined for. Sending the data as payload is the change. > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Wednesday, March 22, 2006 10:36 PM > To: Digital Identity Exchange > Subject: Re: SAML and REST - was Re: [dix] DIX use cases > > Do we really need to change HTTP for DIX? > > Gruesse, Carsten > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > ------=_NextPart_000_0014_01C64E7F.B3D82D60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjMxOTQzMDFaMCMGCSqGSIb3DQEJBDEWBBTA SmQguu5qyfFwmZobmuUCmKf3NzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYB+cKPgW5/S4bTjQOxDRZQAhIO0 x50XmCi0lv6wuab19o90HJ6X4fAFla9xZoLW0IsUKUDmz4MBIiPYMOYIKCrD24JPGcbKPuNbznvr kvHwcYxJoZJF1dKC3tLYljyv4gUvw/nQdeolOMnC3AuNFmF/uW/dkjdD/B/IxuBkramPYQAAAAAA AA== ------=_NextPart_000_0014_01C64E7F.B3D82D60-- --===============1553595395== 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 --===============1553595395==-- From dix-bounces@ietf.org Thu Mar 23 14:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVp5-00048j-Ew; Thu, 23 Mar 2006 14:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVp4-00048Z-6D for dix@ietf.org; Thu, 23 Mar 2006 14:50:18 -0500 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVp2-0002B1-U1 for dix@ietf.org; Thu, 23 Mar 2006 14:50:18 -0500 Received: from THayes0993@aol.com by imo-m27.mx.aol.com (mail_out_v38_r7.3.) id l.1bd.5b3b98 (15862) for ; Thu, 23 Mar 2006 14:50:14 -0500 (EST) Received: from FWM-M28 (fwm-m28.webmail.aol.com [64.12.193.230]) by air-id06.mx.aol.com (vx) with ESMTP id MAILINID61-3df64422fbf61ad; Thu, 23 Mar 2006 14:50:14 -0500 Date: Thu, 23 Mar 2006 14:50:14 -0500 Message-Id: <8C81CCA232C2EA6-1C7C-8724@FWM-M28.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Received: from 10.169.155.114 by FWM-M28.sysops.aol.com (64.12.193.230) with HTTP (WebMailUI); Thu, 23 Mar 2006 14:50:14 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: X-Mailer: AOL WebMail 15106 Subject: Re: SAML and REST - was Re: [dix] DIX use cases MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 64.12.193.230 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0489860004==" Errors-To: dix-bounces@ietf.org --===============0489860004== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C81CCA230ACDD6_1C7C_857A_FWM-M28.sysops.aol.com" ----------MailBlocks_8C81CCA230ACDD6_1C7C_857A_FWM-M28.sysops.aol.com Content-Type: text/plain; charset="us-ascii" No! I think the intended scope of DIX is to work within the existing HTTP capabilities. In fact, DIX is intended to work in an HTML/browser environment, rather than in non-HTML applications such as WEBDAV or even browser-based AJAX schemes. I'd like to discuss changes to HTTP somewhere, but probably not on the DIX list. Terry -----Original Message----- From: Carsten Bormann To: Digital Identity Exchange Sent: Wed, 22 Mar 2006 22:35:39 -0600 Subject: Re: SAML and REST - was Re: [dix] DIX use cases Do we really need to change HTTP for DIX? Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ----------MailBlocks_8C81CCA230ACDD6_1C7C_857A_FWM-M28.sysops.aol.com Content-Type: text/html; charset="us-ascii"
No!  I think the intended scope of DIX is to work within the existing HTTP capabilities.  In fact, DIX is intended to work in an HTML/browser environment, rather than in non-HTML applications such as WEBDAV or even browser-based AJAX schemes.
 
I'd like to discuss changes to HTTP somewhere, but probably not on the DIX list.
 
Terry
 
-----Original Message-----
From: Carsten Bormann <cabo@tzi.org>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Wed, 22 Mar 2006 22:35:39 -0600
Subject: Re: SAML and REST - was Re: [dix] DIX use cases

Do we really need to change HTTP for DIX? 
 
Gruesse, Carsten 
 
_______________________________________________ 
dix mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 
----------MailBlocks_8C81CCA230ACDD6_1C7C_857A_FWM-M28.sysops.aol.com-- --===============0489860004== 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 --===============0489860004==-- From dix-bounces@ietf.org Thu Mar 23 14:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVrk-00054t-JR; Thu, 23 Mar 2006 14:53:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVrj-00054o-7G for dix@ietf.org; Thu, 23 Mar 2006 14:53:03 -0500 Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVrh-0002Ho-Rw for dix@ietf.org; Thu, 23 Mar 2006 14:53:03 -0500 Received: from THayes0993@aol.com by imo-d20.mx.aol.com (mail_out_v38_r7.3.) id l.2c6.5fc5a57 (15886) for ; Thu, 23 Mar 2006 14:52:57 -0500 (EST) Received: from FWM-M28 (fwm-m28.webmail.aol.com [64.12.193.230]) by air-id08.mx.aol.com (vx) with ESMTP id MAILINID81-3e0e4422fc99a5; Thu, 23 Mar 2006 14:52:57 -0500 Date: Thu, 23 Mar 2006 14:52:57 -0500 Message-Id: <8C81CCA840E8CAE-1C7C-8763@FWM-M28.sysops.aol.com> From: thayes0993@aol.com References: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> Received: from 10.169.155.114 by FWM-M28.sysops.aol.com (64.12.193.230) with HTTP (WebMailUI); Thu, 23 Mar 2006 14:52:57 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Mailer: AOL WebMail 15106 Subject: Re: SAML and REST - was Re: [dix] DIX use cases MIME-Version: 1.0 To: dix@ietf.org X-AOL-IP: 64.12.193.230 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============0659383977==" Errors-To: dix-bounces@ietf.org --===============0659383977== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C81CCA840E8CAE_1C7C_85BC_FWM-M28.sysops.aol.com" ----------MailBlocks_8C81CCA840E8CAE_1C7C_85BC_FWM-M28.sysops.aol.com Content-Type: text/plain; charset="us-ascii" I agree. We should probably drop the discussion of REST and HTTP-Authorization on this list and focus on the browser-based HTML requirements. (I'm not sure what Phill is hinted at as far as BEST goes!) Terry -----Original Message----- From: Hallam-Baker, Phillip To: Digital Identity Exchange Sent: Wed, 22 Mar 2006 20:27:06 -0800 Subject: RE: SAML and REST - was Re: [dix] DIX use cases Lets forget about REST and concentrate on the BEST place. The HTTP-Authorization field is the right place (and no I did not choose that tag name and I objected at the time, they snuck it in along with BASIC while I was suffering from food poisoning). I am responsible for the imaginative spelling of Referer though. From: thayes0993@aol.com [mailto:thayes0993@aol.com] Sent: Wednesday, March 22, 2006 7:33 PM To: dix@ietf.org Subject: Re: SAML and REST - was Re: [dix] DIX use cases It could go in the HTTP Authorization field using a new scheme to be defined. There seem to be several people interested in enhancing HTTP to allow data like this to be provided for REST-style interactions. This has parallels with putting data in SOAP headers rather than in the content of the message. Terry -----Original Message----- From: Robert Yates To: Digital Identity Exchange Sent: Wed, 22 Mar 2006 16:39:42 -0500 Subject: SAML and REST - was Re: [dix] DIX use cases so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. Here is an ATOM post. POST /myblog/entries HTTP/1.1 Host: example.org User-Agent: Thingio/1.0 Content-Type: application/atom+xml Content-Length: nnn Atom-Powered Ro bots Run Amok urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 2003-12-13T18:30:02Z Some text. Where does the SAML go? I apologize for my lack of understanding here. Rob _______________________________________________ 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 ----------MailBlocks_8C81CCA840E8CAE_1C7C_85BC_FWM-M28.sysops.aol.com Content-Type: text/html; charset="us-ascii"
I agree.  We should probably drop the discussion of REST and HTTP-Authorization on this list and focus on the browser-based HTML requirements.
 
(I'm not sure what Phill is hinted at as far as BEST goes!)

Terry
 
-----Original Message-----
From: Hallam-Baker, Phillip <pbaker@verisign.com>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Wed, 22 Mar 2006 20:27:06 -0800
Subject: RE: SAML and REST - was Re: [dix] DIX use cases

Lets forget about REST and concentrate on the BEST place.
 
The HTTP-Authorization field is the right place (and no I did not choose that tag name and I objected at the time, they snuck it in along with BASIC while I was suffering from food poisoning). I am responsible for the imaginative spelling of Referer though.

From: thayes0993@aol.com [mailto:thayes0993@aol.com]
Sent: Wednesday, March 22, 2006 7:33 PM
To: dix@ietf.org
Subject: Re: SAML and REST - was Re: [dix] DIX use cases

 
It could go in the HTTP Authorization field using a new scheme to be defined.
 
There seem to be several people interested in enhancing HTTP to allow data like this to be provided for REST-style interactions.  This has parallels with putting data in SOAP headers rather than in the content of the message.

Terry

-----Original Message-----
From: Robert Yates <robyates70@gmail.com>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Wed, 22 Mar 2006 16:39:42 -0500
Subject: SAML and REST - was Re: [dix] DIX use cases


so I admit that I am confused and probably out of my depth, and I know better than to argue with the initial spec author that it can't be done. 
 
but I simply don't understand what it means to use SAML with something like atompub http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt or any of the plethora of so-called REST based web services. 
 
Here is an ATOM post. 
 
POST /myblog/entries HTTP/1.1 
  Host: example.org 
  User-Agent: Thingio/1.0 
  Content-Type: application/atom+xml 
  Content-Length: nnn 
 
  <entry xmlns="http://www.w3.org/2005/Atom"> 
  <title>Atom-Powered Ro bots Run Amok</title> 
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> 
  <updated>2003-12-13T18:30:02Z</updated> 
  <content>Some text.</content> 
  </entry> 
 
Where does the SAML go? I apologize for my lack of understanding here. 
 
Rob 
 
_______________________________________________ 
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
----------MailBlocks_8C81CCA840E8CAE_1C7C_85BC_FWM-M28.sysops.aol.com-- --===============0659383977== 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 --===============0659383977==-- From dix-bounces@ietf.org Thu Mar 23 15:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW3J-0008Of-Gk; Thu, 23 Mar 2006 15:05:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW3I-0008O7-Ta for dix@ietf.org; Thu, 23 Mar 2006 15:05:00 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW3I-0003DU-GP for dix@ietf.org; Thu, 23 Mar 2006 15:05:00 -0500 Received: from sureshmobile (dsl231-036-190.sea1.dsl.speakeasy.net[216.231.36.190]) by comcast.net (rwcrmhc12) with SMTP id <20060323200458m1200ioe4oe>; Thu, 23 Mar 2006 20:04:59 +0000 From: "Suresh Venkatraman" To: "'Digital Identity Exchange'" Subject: RE: SAML and REST - was Re: [dix] DIX use cases Date: Thu, 23 Mar 2006 12:04:54 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZOswsp98u6GyIdQZ+xmS3MAY24AwAAR8ag In-Reply-To: <8C81CCA232C2EA6-1C7C-8724@FWM-M28.sysops.aol.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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="===============1368308865==" Errors-To: dix-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1368308865== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0377_01C64E71.FF332250" This is a multi-part message in MIME format. ------=_NextPart_000_0377_01C64E71.FF332250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Disagree - DIX should work with any HTTP/1.1 UA, not just a browser. Is there a dependency on processing HTML in DIX? _____ From: thayes0993@aol.com [mailto:thayes0993@aol.com] Sent: Thursday, March 23, 2006 11:50 AM To: dix@ietf.org Subject: Re: SAML and REST - was Re: [dix] DIX use cases No! I think the intended scope of DIX is to work within the existing HTTP capabilities. In fact, DIX is intended to work in an HTML/browser environment, rather than in non-HTML applications such as WEBDAV or even browser-based AJAX schemes. I'd like to discuss changes to HTTP somewhere, but probably not on the DIX list. Terry -----Original Message----- From: Carsten Bormann To: Digital Identity Exchange Sent: Wed, 22 Mar 2006 22:35:39 -0600 Subject: Re: SAML and REST - was Re: [dix] DIX use cases Do we really need to change HTTP for DIX? Gruesse, Carsten _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ------=_NextPart_000_0377_01C64E71.FF332250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Disagree - DIX should work with any HTTP/1.1 UA, not just a browser. Is there a dependency on processing = HTML in DIX?

 

From: = thayes0993@aol.com [mailto:thayes0993@aol.com]
Sent: Thursday, March 23, = 2006 11:50 AM
To: dix@ietf.org
Subject: Re: SAML and = REST - was Re: [dix] DIX use cases

 

No!  I think the intended scope of DIX is to = work within the existing HTTP capabilities.  In fact, DIX is intended to = work in an HTML/browser environment, rather than in non-HTML applications = such as WEBDAV or even browser-based AJAX schemes.

 

I'd like to discuss changes to HTTP somewhere, but probably not on the DIX list.

 

Terry

 
-----Original Message-----
From: Carsten Bormann <cabo@tzi.org>
To: Digital Identity Exchange <dix@ietf.org>
Sent: Wed, 22 Mar 2006 22:35:39 -0600
Subject: Re: SAML and REST - was Re: [dix] DIX use = cases

Do we really need to change HTTP for DIX? 
 
Gruesse, Carsten 
 
_______________________________________________ 
dix mailing list 
dix@ietf.org 
https://www1.ietf.org/mailman/listinfo/dix 

------=_NextPart_000_0377_01C64E71.FF332250-- --===============1368308865== 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 --===============1368308865==-- From dix-bounces@ietf.org Thu Mar 23 15:26:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWNe-0007Nf-M7; Thu, 23 Mar 2006 15:26:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWNd-0007LW-3E for dix@ietf.org; Thu, 23 Mar 2006 15:26:01 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWNb-0004Cg-LK for dix@ietf.org; Thu, 23 Mar 2006 15:26:01 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2NKPw4u014605 for ; Thu, 23 Mar 2006 12:25:58 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2NKPwda015058 for ; Thu, 23 Mar 2006 13:25:58 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2NKPwoq004454 for ; Thu, 23 Mar 2006 14:25:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2NKPv1e004453 for dix@ietf.org; Thu, 23 Mar 2006 14:25:57 -0600 (CST) Date: Thu, 23 Mar 2006 14:25:57 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: SAML and REST - was Re: [dix] DIX use cases Message-ID: <20060323202557.GD1010@binky.Central.Sun.COM> References: <198A730C2044DE4A96749D13E167AD379E0C1F@MOU1WNEXMB04.vcorp.ad.vrsn.com> <8C81CCA232C2EA6-1C7C-8724@FWM-M28.sysops.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C81CCA232C2EA6-1C7C-8724@FWM-M28.sysops.aol.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Thu, Mar 23, 2006 at 02:50:14PM -0500, thayes0993@aol.com wrote: Carsten> Do we really need to change HTTP for DIX? > No! I think the intended scope of DIX is to work within the existing > HTTP capabilities. In fact, DIX is intended to work in an > HTML/browser environment, rather than in non-HTML applications such as > WEBDAV or even browser-based AJAX schemes. Which, given the complaints we've seen about SAML not catering to REST applications (+ counter arguments that either it's very close or could easily be profiled to cater to them also) one wonders: why should DIX be so limited? I'm not interested in furthering the divide between browser and non-browser based applications, unless there's a very clear way forward to address that gap (including no conflicts with DIX/SAML/YADIS/...). > I'd like to discuss changes to HTTP somewhere, but probably not on the DIX list. Well, OK, there are fora for that, but whether it should be discussed here depends on what sorts of changes we'd be talking about and how closely related to DIX they would be. Though it certainly seems too soon -- the problem statement alone needs plenty of work... Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 23 17:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYkb-00015T-UJ; Thu, 23 Mar 2006 17:57:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYka-00014C-92 for dix@ietf.org; Thu, 23 Mar 2006 17:57:52 -0500 Received: from pproxy.gmail.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYkZ-0002uH-1w for dix@ietf.org; Thu, 23 Mar 2006 17:57:52 -0500 Received: by pproxy.gmail.com with SMTP id d42so521070pyd for ; Thu, 23 Mar 2006 14:57:50 -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=NEHHy5mo7BiebzlCfWYUNo/6knLEc1krIbb6+BPzH0wfuWgyKjMP0KxAO3tzITd6WjHcsZLh4B1STbyVSbeURanh6Q2ktDbT8pOeMeKUZLPHmIfwqZb849Omq4WNH681jHXkJphVM7nyBKkFwU5crdj3qTNbJWUv89Jsg6dNrVU= Received: by 10.35.49.4 with SMTP id b4mr41271pyk; Thu, 23 Mar 2006 12:23:36 -0800 (PST) Received: from ?192.168.1.2? ( [66.30.206.61]) by mx.gmail.com with ESMTP id v50sm171381pyv.2006.03.23.12.23.35; Thu, 23 Mar 2006 12:23:35 -0800 (PST) Message-ID: <442303C5.6080307@gmail.com> Date: Thu, 23 Mar 2006 15:23:33 -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: SAML and REST - was Re: [dix] DIX use cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) 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 Suresh Venkatraman wrote: > Disagree - DIX should work with any HTTP/1.1 UA, not just a browser. > Is there a dependency on processing HTML in DIX? > > > > ------------------------------------------------------------------------ > > > > No! I think the intended scope of DIX is to work within the existing > HTTP capabilities. In fact, DIX is intended to work in an > HTML/browser environment, rather than in non-HTML applications such as > WEBDAV or even browser-based AJAX schemes. > > I also disagree. DIX needs to work with non browser clients. I'll post my original use cases and restate my claim that core DIX needs to be able to handle 1-4 and that 5 needs to be a natural extension to the core. 1. Eliot's dad wants to remember one userid and password for the web. 2. Eliot's dad wants to stop retyping his credit card information and shipping address every time he wants to buy something on the web 3. Eliot's dad wants to share his online pictures with me and Eliot (and only me and Eliot) 4. I want to subscribe to Eliot's dad's photocast so that as new photos become available they are automatically downloaded to my machine. http://www.apple.com/ilife/iphoto/features/photocasting.html 5. I want to print Eliot's dad's photos using a web photo printing website. The web site that I use to print the photos is different to the one that stores the photos. Use cases 4 and 5 imply a non browser based HTTP/1.1 client. In 4 it is iPhoto, but it could be any Feedreader and in 5 it is a non-SOAP based api call from the photo printing service to photo storage service to retrieve the photos. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 24 02:04:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgLL-000603-6r; Fri, 24 Mar 2006 02:04:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMgLK-0005zy-7c for dix@ietf.org; Fri, 24 Mar 2006 02:04:18 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMgLD-0000SF-PP for dix@ietf.org; Fri, 24 Mar 2006 02:04:15 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2O74A6W022518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Mar 2006 23:04:10 -0800 X-Auth-Received: from DHCP-Wireless-129-119.ietf65.org (DHCP-Wireless-129-119.ietf65.org [130.129.129.119]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2O749DX029910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Mar 2006 23:04:10 -0800 Date: Fri, 24 Mar 2006 01:04:10 -0600 (CST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Digital Identity Exchange Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Thu, 23 Mar 2006, Peter Davis wrote: > I think this thread has (at least for me) is teasing out a new > requirement. It underscores the need to ensure support for non-HTML > aware HTTP clients. While many of the DAV clients Lisa enumerated use > shared HTTP engines, they may not always avail themselves of shared HTML > engines. > > As a result, perhaps a new requirement may look like: > > - the protocol shall support the transfer/transport of security tokens > over HTTP, but does not require implementations to support the HTML form > controls and the associated encodings (eg: Calendar Clients, > FS-browsers, etc...) There are dozens of deployed web signon schemes using a third-party authentication service (eg SXIP, the SAML browser profiles, OpenID, etc), and to my knowledge all of them make use of all the browser features (redirection, cookies, form-based username/password entry) that make them not applicable to non-browser HTTP user agents. Organizations base their authentication strategies around these schemes, all of them aware that these schemes are web-browser-only. They do this because, guess what, the apps of interest are also web-browser-only apps, and those apps are web-browser-only because they also want to work well with browsers so they use all those browser-only features. We all use these apps constantly. So it certainly would be a good thing to have an authentication system for all HTTP purposes with all the wonderful properties we're seeking (internet scale, ease of deployment, identity-info exchange, etc). This is true in the same sense that it would great to have such a system for IMAP, SMTP, LDAP, CIFS, NFS, etc etc. For my organization and my community, I think good HTTP authentication is about as important as good authentication in all those other app protocols. And none of them is nearly as important as web authentication (ie, authentication of browsers to web-browser-oriented apps). (See http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth for discussion of improving HTTP authentication, btw.) My point is that, odd as it may seem, web authentication, as deployed in zillions of instances today, has almost nothing to do with HTTP authentication. Insisting that a single scheme support them both, or a single Working Group effort make both work equally well, is adding a pretty serious amount of additional work and constraint on the solution. Maybe the emerging importance of RSS and AJAX and WebDAV and Caldav and their use in web-app scenarios changes the balance and makes us want to tie web authentication and HTTP authentication together more than we used to. Could be. But I think there is much good work to be done on developing and deploying really good web-app-only schemes while we also work on that grand convergence. - RL "Bob" _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 24 11:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpPZ-00041T-H9; Fri, 24 Mar 2006 11:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpPY-00041J-5d for dix@ietf.org; Fri, 24 Mar 2006 11:45:16 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMpPV-0008La-TQ for dix@ietf.org; Fri, 24 Mar 2006 11:45:16 -0500 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc13) with SMTP id <20060324164512m13005kfpse>; Fri, 24 Mar 2006 16:45:12 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: References: Content-Type: multipart/mixed; boundary=Apple-Mail-60--444728113 Message-Id: From: Johannes Ernst Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) Date: Fri, 24 Mar 2006 08:45:12 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 --Apple-Mail-60--444728113 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 23, 2006, at 23:04, RL 'Bob' Morgan wrote: > There are dozens of deployed web signon schemes using a third-party > authentication service (eg SXIP, the SAML browser profiles, OpenID, > etc), and to my knowledge all of them make use of all the browser > features (redirection, cookies, form-based username/password entry) > that make them not applicable to non-browser HTTP user agents. FYI: Yadis and LID were explicitly designed to be usable by software that doesn't have a GUI, and OpenID can be used that way as well. E.g. Yadis finds its capability file either through requesting a special mime type, or an additional HTTP header, and only if those fail, looks into HTML (if there is, in order to support those folks who cannot really get at the configuration of their http server). LID takes a URL, and signs it with a GPG key pair; this requires neither HTML nor a GUI. So it can definitely be done, and it's all deployed and working as you know. Johannes Ernst NetMesh Inc. --Apple-Mail-60--444728113 Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="lid.gif" Content-Disposition: inline; filename=lid.gif 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-60--444728113 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed http://netmesh.info/jernst --Apple-Mail-60--444728113 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-60--444728113-- From dix-bounces@ietf.org Fri Mar 24 15:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMsa0-00049i-Po; Fri, 24 Mar 2006 15:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMsZz-00049d-3w for dix@ietf.org; Fri, 24 Mar 2006 15:08:15 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMsZx-0000kc-Px for dix@ietf.org; Fri, 24 Mar 2006 15:08:15 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OK8Cf1005306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Mar 2006 12:08:12 -0800 X-Auth-Received: from [192.168.1.119] ([67.170.100.234]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OK8BH6023954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Mar 2006 12:08:12 -0800 Date: Fri, 24 Mar 2006 14:08:15 -0600 (CST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Digital Identity Exchange Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 > FYI: Yadis and LID were explicitly designed to be usable by software > that doesn't have a GUI, and OpenID can be used that way as well. That's a nice feature for a system to have, but it's not the same as the point I was making. There's more to the obstacles than just GUI. Can YADIS/LID/OpenID be used to authenticate a WebDAV client to a WebDAV server, for some/most/all of the current typical WebDAV clients and servers? If so, then you've met the requirement Peter set. - RL "Bob" _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 24 15:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMsru-0006DV-JM; Fri, 24 Mar 2006 15:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMsrt-0006DD-52 for dix@ietf.org; Fri, 24 Mar 2006 15:26:45 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMsrr-0001Ha-Qi for dix@ietf.org; Fri, 24 Mar 2006 15:26:45 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OKQgrm004089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Mar 2006 12:26:42 -0800 X-Auth-Received: from [192.168.1.119] ([67.170.100.234]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OKQg3G020547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Mar 2006 12:26:42 -0800 Date: Fri, 24 Mar 2006 14:26:45 -0600 (CST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Digital Identity Exchange Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Fri, 24 Mar 2006, Johannes Ernst wrote: > FYI: Yadis and LID were explicitly designed to be usable by software that > doesn't have a GUI, and OpenID can be used that way as well. > > E.g. Yadis finds its capability file either through requesting a special > mime type, or an additional HTTP header, and only if those fail, looks > into HTML (if there is, in order to support those folks who cannot > really get at the configuration of their http server). > > LID takes a URL, and signs it with a GPG key pair; this requires neither > HTML nor a GUI. > > So it can definitely be done, and it's all deployed and working as you know. And, forgive my ignorance, aren't OpenID and LID agnostic about the actual means of authentication performed between the authentication service and the user agent? So if someone deploys it using form-based authentication, or taking advantage of some existing form-based authentication, then that would require UI, and would make the system fail to work for non-UI user agents, would it not? You can say: well, then don't deploy it that way, use Basic or something; but telling people not to use stuff they like to use isn't a winning strategy usually. It could be useful to look at standard ways to accomodate GUI and non-GUI user agents each with appropriate methods with the same installations. Or perhaps YADIS does this. - RL "Bob" _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 24 15:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtM3-0004bA-2S; Fri, 24 Mar 2006 15:57:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtM1-0004ar-PG for dix@ietf.org; Fri, 24 Mar 2006 15:57:54 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtM0-0002gu-EN for dix@ietf.org; Fri, 24 Mar 2006 15:57:53 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OKvpBE024341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Mar 2006 12:57:51 -0800 X-Auth-Received: from [192.168.1.119] ([67.170.100.234]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OKvon2026840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Mar 2006 12:57:51 -0800 Date: Fri, 24 Mar 2006 12:57:54 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Digital Identity Exchange Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' 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 > FYI: Yadis and LID were explicitly designed to be usable by software > that doesn't have a GUI, and OpenID can be used that way as well. Another thing that might be said here is that there's nothing in the SAML web browser profiles that requires a UI either. Though the fact that identity-provider discovery is not covered in those profiles (except for the Common Domain Cookie approach which is not broadly applicable) does mean that in some deployments (not all by any means) a UI is used to do discovery. The YADIS discovery method could well be used to initiate a SAML web browser profile flow too (and I think some people might even be working on how to do this). But the SAML browser profiles do require browser features that tend not to be found in other HTTP user agents, or to put it in more of standards way, are not required to be in them for compliance with the HTTP-based spec they are implementing. It is my impression that these specs (eg WebDAV) aren't actually very specific about which HTTP user agent features are mandatory (though I could be wrong about that), which if true may need fixing. - RL "Bob" _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 24 16:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuIl-0002M3-W6; Fri, 24 Mar 2006 16:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuGp-0001DQ-K3 for dix@ietf.org; Fri, 24 Mar 2006 16:56:35 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMuGn-00052f-Kb for dix@ietf.org; Fri, 24 Mar 2006 16:56:35 -0500 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc13) with SMTP id <20060324215632m13005qmuke>; Fri, 24 Mar 2006 21:56:32 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: References: Content-Type: multipart/mixed; boundary=Apple-Mail-104--426050613 Message-Id: <124EF1BC-2B1C-40CA-9E13-8F30FF6C1D9B@netmesh.us> From: Johannes Ernst Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) Date: Fri, 24 Mar 2006 13:56:30 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Fri, 24 Mar 2006 16:58:34 -0500 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 --Apple-Mail-104--426050613 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 24, 2006, at 12:57, RL 'Bob' Morgan wrote: > The YADIS discovery method could well be used to initiate a SAML > web browser profile flow too (and I think some people might even be > working on how to do this). I heard the same thing ;-) By the way, I'm told by the term police (aka Joaquin Miller, of NetMesh, the Yadis editor) that I need to tell everybody to spell it Yadis, not YADIS, because it isn't an acronym any more, just Yadis. Johannes Ernst NetMesh Inc. --Apple-Mail-104--426050613 Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="lid.gif" Content-Disposition: inline; filename=lid.gif 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-104--426050613 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed http://netmesh.info/jernst --Apple-Mail-104--426050613 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-104--426050613-- From dix-bounces@ietf.org Fri Mar 24 17:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuLK-0005LE-JD; Fri, 24 Mar 2006 17:01:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuLJ-0005If-C5 for dix@ietf.org; Fri, 24 Mar 2006 17:01:13 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMuLH-0005Up-2X for dix@ietf.org; Fri, 24 Mar 2006 17:01:13 -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 <20060324220110m1100c8bppe>; Fri, 24 Mar 2006 22:01:10 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23CF9776-6059-4E03-B8D2-3A1E696CC910@netmesh.us> Content-Transfer-Encoding: 7bit From: Johannes Ernst Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) Date: Fri, 24 Mar 2006 14:01:07 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) 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 Mar 24, 2006, at 12:26, RL 'Bob' Morgan wrote: > And, forgive my ignorance, aren't OpenID and LID agnostic about the > actual means of authentication performed between the authentication > service and the user agent? Yep. > So if someone deploys it using form-based authentication, or > taking advantage of some existing form-based authentication, then > that would require UI, and would make the system fail to work for > non-UI user agents, would it not? You can say: well, then don't > deploy it that way, use Basic or something; but telling people not > to use stuff they like to use isn't a winning strategy usually. No. The question is 'which is the endpoint that you are authenticating?' If, for example, the endpoint is your/on your local PC (instead of a Yadis URL out in the cloud, accessible only through a browser), you might not need to authenticate again because you already did when you logged into your computer. Which of course brings up the issue of "identity chaining" or whatever we'd call it, which surprisingly, has been largely absent from this list so far: the use of one identity/persona/whatever to authenticate against another identity/persona/whatever and so forth, which then becomes the only thing a Relying Party sees; something the LID protocol has been able to do for a long while, and that turns out to be quite handy ... e.g. in order to log on only once at a single service, but still use a number of separate identities/identifiers/ personas/whatever hosted by a variety of service providers. I don't think anybody has implemented the same thing for OpenID so far, but I can't think of a reason it can't be done either without any protocol extensions. > It could be useful to look at standard ways to accomodate GUI and > non-GUI user agents each with appropriate methods with the same > installations. Or perhaps YADIS does this. This turned out to be a beneficial side-effect of Yadis that we did not even plan on. Funny, how technology sometimes does that: instead of using Yadis 'just" for identity URL discovery, one can also use it for Relying Party discovery, and the discovery of which authentication protocols a Relying Party supports. (Usually we rely on the user to do that discovery by looking at an HTML page where it says "you need to have a username and password to authenticate here" or "SXIP in" or whatever it says). So Yadis also gives us a "marker" for non-GUI-based User Agents for which auth methods are accepted here. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Mar 24 17:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuLl-0005rW-Pz; Fri, 24 Mar 2006 17:01:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuLk-0005rR-NZ for dix@ietf.org; Fri, 24 Mar 2006 17:01:40 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMuLj-0005Uz-FX for dix@ietf.org; Fri, 24 Mar 2006 17:01:40 -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 <20060324220138m1100c8bpqe>; Fri, 24 Mar 2006 22:01:38 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30AF0D48-BD0B-40E4-AD33-E1DB9C3D9675@netmesh.us> Content-Transfer-Encoding: 7bit From: Johannes Ernst Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) Date: Fri, 24 Mar 2006 14:01:36 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) 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 > Can YADIS/LID/OpenID be used to authenticate a WebDAV client to a > WebDAV server, for some/most/all of the current typical WebDAV > clients and servers? If so, then you've met the requirement Peter > set. Coincidentally, Brad Fitzpatrick -- the creator of OpenID (and LiveJournal) -- just posted on a very related subject just a few days ago. http://brad.livejournal.com/2206769.html While it is indeed a hack, it would probably work, and applies similarly to LID and Yadis. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Mar 25 22:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNLeB-0006Th-0W; Sat, 25 Mar 2006 22:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNLe9-0006Tc-Vk for dix@ietf.org; Sat, 25 Mar 2006 22:10:29 -0500 Received: from mx1.myoutlookonline.com ([69.25.74.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNLe8-0005gE-OA for dix@ietf.org; Sat, 25 Mar 2006 22:10:29 -0500 Received: from be022.mail.lan ([10.109.209.122]) by mX1.myOutlookonline.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Mar 2006 22:10:28 -0500 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: Various User Agent Support (was: Re: [dix] DIX use cases) Date: Sat, 25 Mar 2006 22:10:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Various User Agent Support (was: Re: [dix] DIX use cases) Thread-Index: AcZPjom8smPDSUuLTNSlXFTuGGQX6wA8Le4Q From: "David Recordon" To: "Digital Identity Exchange" X-OriginalArrivalTime: 26 Mar 2006 03:10:28.0335 (UTC) FILETIME=[D56DC7F0:01C65082] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 We're currently using OpenID to login to our installation of Request Tracker and want to extend this to our version control as well. While the idea of a proxy will certainly work, it also isn't meant to replace machine <-> machine authentication with OpenID. I know various people are working on things like this, so you can do fun things like authenticate to a WebDAV server using OpenID. Just as the Simple Registration extension (http://www.openidenabled.com/openid/simple-registration-extension/) isn't meant to be the answer to profile exchange with OpenID, this sort of proxy also isn't the OpenID answer to many of the use cases that have been brought up on this list. We do however think there are all sorts of cool things which can be done with low cost and easy to implement extensions and proxies to OpenID until there actually is convergence in this space. Until then, technologies such as Yadis allow early adopters to choose their preferred authentication, authorization, profile exchange, reputation, etc protocols and not have to worry if their choice will be supported by their favorite app. I'd much rather put the burden of supporting multiple protocols on the service providers than make users have five different identities since we all can't decide on the best way to do things. --David -----Original Message----- From: Johannes Ernst [mailto:jernst+ietf.org@netmesh.us]=20 Sent: Friday, March 24, 2006 2:02 PM To: Digital Identity Exchange Subject: Re: Various User Agent Support (was: Re: [dix] DIX use cases) > Can YADIS/LID/OpenID be used to authenticate a WebDAV client to a =20 > WebDAV server, for some/most/all of the current typical WebDAV =20 > clients and servers? If so, then you've met the requirement Peter =20 > set. Coincidentally, Brad Fitzpatrick -- the creator of OpenID (and =20 LiveJournal) -- just posted on a very related subject just a few days =20 ago. http://brad.livejournal.com/2206769.html While it is indeed a hack, it would probably work, and applies =20 similarly to LID and Yadis. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Mar 26 03:12:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNQMH-0000cX-Qd; Sun, 26 Mar 2006 03:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNQMG-0000cS-LG for dix@ietf.org; Sun, 26 Mar 2006 03:12:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNQME-0000Lk-D2 for dix@ietf.org; Sun, 26 Mar 2006 03:12:20 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2006 00:12:17 -0800 X-IronPort-AV: i="4.03,129,1141632000"; d="scan'208"; a="1788373464:sNHT29322304" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2Q8CHYg012899 for ; Sun, 26 Mar 2006 00:12:17 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp312.cisco.com [10.61.65.56]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2Q8D0p8027003 for ; Sun, 26 Mar 2006 00:13:01 -0800 Message-ID: <44264CE2.4000101@cisco.com> Date: Sun, 26 Mar 2006 02:12:18 -0600 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: SAML and REST - was Re: [dix] DIX use cases References: <442303C5.6080307@gmail.com> In-Reply-To: <442303C5.6080307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=712; t=1143360781; x=1143792981; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20SAML=20and=20REST=20-=20was=20Re=3A=20[dix]=20DIX=20use=20cases |To:Digital=20Identity=20Exchange=20; X=v=3Dmtcc.com=3B=20h=3DQy3CWCzUXbVyq8KXA0YLiB8nUtk=3D; b=P5TFJpKsakPvTh3tATlh9DiJIqqb4NoqRFjAxeXsmcZv6LCP8Xp+qjXrcEs8gwOWp+tUkP+G Q3bSvzT9So++S7jNErtRNZ7/o7CtyRx/v8BObsKrjezJr9EvX6yt7/ij7zoMs1BZGYa4IH+cYsE 0YxBqHFqTKusZRPh1HCD0ki8=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Robert Yates wrote: > 1. Eliot's dad wants to remember one userid and password for the web. He also wants to use the same mechanism for IMAP a/o POP, SMTP to his MSA, and calendaring. As a stretch goal he may want to use the same mechanism to authenticate through on 802.1x, but I would admit that this could prove challenging. Now, for those who weren't in the SAAG meeting there was a very good presentation on a registration protocol that is very close to being properly abstracted (CK-TIP?). They already have text for HTTP. Really good stuff. The callouts that are good for registration should be even more easily adopted for just normal authentication. Definitely related work. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 27 19:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1qe-0002vP-MI; Mon, 27 Mar 2006 19:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1qd-0002uY-Uq for dix@ietf.org; Mon, 27 Mar 2006 19:14:11 -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 1FO1qc-0004UB-Kv for dix@ietf.org; Mon, 27 Mar 2006 19:14:11 -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 k2S0E8wp039024 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Mar 2006 16:14:09 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060322204725.GA1010@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> <4421A3D7.9090403@cisco.com> <20060322193359.GW1010@binky.Central.Sun.COM> <4421AA2F.6000607@cisco.com> <20060322204725.GA1010@binky.Central.Sun.COM> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75F5D92B-4420-434B-86D3-31231975D8A4@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] DIX use cases Date: Mon, 27 Mar 2006 16:14:06 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 22-Mar-06, at 12:47 PM, Nicolas Williams wrote: > So, is it safe to say that some of the use cases posted by Robert > amount > to saying that > > - users shouldn't have more than one physical > (smartcard/token/whatever) or logical (username/password) > credential I don't think you can mandate 'just one', but I think you can mandate choice. Users should have as few or as many as they feel they need. As a real world example think of credit cards. You could have one but you probably have a back-up or two. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 27 19:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2EL-0001zk-Md; Mon, 27 Mar 2006 19:38:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2EK-0001zY-PR for dix@ietf.org; Mon, 27 Mar 2006 19:38:40 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO2EI-0005Bf-BC for dix@ietf.org; Mon, 27 Mar 2006 19:38:40 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2S0cWdK023486 for ; Mon, 27 Mar 2006 16:38:37 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2S0cVda006589 for ; Mon, 27 Mar 2006 17:38:31 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2S0cV1r007878 for ; Mon, 27 Mar 2006 18:38:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2S0cVds007877 for dix@ietf.org; Mon, 27 Mar 2006 18:38:31 -0600 (CST) Date: Mon, 27 Mar 2006 18:38:31 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: SAML and REST - was Re: [dix] DIX use cases Message-ID: <20060328003830.GU7525@binky.Central.Sun.COM> References: <442303C5.6080307@gmail.com> <44264CE2.4000101@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44264CE2.4000101@cisco.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Sun, Mar 26, 2006 at 02:12:18AM -0600, Eliot Lear wrote: > Robert Yates wrote: > > 1. Eliot's dad wants to remember one userid and password for the web. > > He also wants to use the same mechanism for IMAP a/o POP, SMTP to his > MSA, and calendaring. As a stretch goal he may want to use the same > mechanism to authenticate through on 802.1x, but I would admit that this > could prove challenging. There was a BoF at Paris, but insufficient bodies to do the proposed work then, for a Generally Useful Authentication Mechanism (GUAM) framework so that we could end up with a suite of mechanisms for EAP, SASL and the GSS-API. There is now an I-D (draft-salowey-guam-mech-00.txt) for GUAM. And more work will follow. This combined with some additional HTTP authentication using the GSS-API (beyond what Negotiate can do) and the new SASL/GSS-API bridge (draft-josefsson-sasl-gs2-00.txt), improvements in digest mechanisms, and applying GUAM principles to any remaining populate mechanisms should go a long way to meeting this requirement. Coroporate networks tend to use lots of these protocols and plenty of browser-based applications too. Which is why I would insist on any solutions in this problem space at the very least not preclude being extended to work in non-browser contexts. But I think such a requirement wouldn't be difficult to meet. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Mar 27 19:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2Ht-0004AQ-Ha; Mon, 27 Mar 2006 19:42:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2Hs-0004AL-5K for dix@ietf.org; Mon, 27 Mar 2006 19:42:20 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO2Hq-0005GQ-RW for dix@ietf.org; Mon, 27 Mar 2006 19:42:20 -0500 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k2S0gIQj027148 for ; Mon, 27 Mar 2006 17:42:18 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2S0gHda007781 for ; Mon, 27 Mar 2006 17:42:17 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2S0gHOG007885 for ; Mon, 27 Mar 2006 18:42:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2S0gHUe007884 for dix@ietf.org; Mon, 27 Mar 2006 18:42:17 -0600 (CST) Date: Mon, 27 Mar 2006 18:42:17 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] DIX use cases Message-ID: <20060328004217.GV7525@binky.Central.Sun.COM> References: <44205E35.8000308@gmail.com> <4421A3D7.9090403@cisco.com> <20060322193359.GW1010@binky.Central.Sun.COM> <4421AA2F.6000607@cisco.com> <20060322204725.GA1010@binky.Central.Sun.COM> <75F5D92B-4420-434B-86D3-31231975D8A4@sxip.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75F5D92B-4420-434B-86D3-31231975D8A4@sxip.com> User-Agent: Mutt/1.5.7i 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 Mon, Mar 27, 2006 at 04:14:06PM -0800, John Merrells wrote: > > On 22-Mar-06, at 12:47 PM, Nicolas Williams wrote: > > >So, is it safe to say that some of the use cases posted by Robert > >amount > >to saying that > > > > - users shouldn't have more than one physical > > (smartcard/token/whatever) or logical (username/password) > >credential > > I don't think you can mandate 'just one', but I think you can mandate > choice. Users should have as few or as many as they feel they need. > As a real world example think of credit cards. You could have one > but you probably have a back-up or two. Agreed, but users shouldn't _have_ to have more than one as a result of the ad-hoc nature of the systems they use. I think that is what Robert was trying to convey, or at least my reading of the particular requirement I was distilling. I wouldn't disagree with that... I suspect users won't mind having multiple tokens, provided that number is small, as much as having many accounts that require passwords. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 28 02:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8v4-0002VH-Qj; Tue, 28 Mar 2006 02:47:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO8v1-0002VC-6R for dix@ietf.org; Tue, 28 Mar 2006 02:47:11 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FO8uz-0004SG-Pf for dix@ietf.org; Tue, 28 Mar 2006 02:47:11 -0500 Received: (qmail invoked by alias); 28 Mar 2006 07:47:08 -0000 Received: from p549858EA.dip.t-dialin.net (EHLO [192.168.2.102]) [84.152.88.234] by mail.gmx.net (mp005) with SMTP; 28 Mar 2006 09:47:08 +0200 X-Authenticated: #29516787 Message-ID: <4428E9FB.6060904@gmx.net> Date: Tue, 28 Mar 2006 01:47:07 -0600 From: Hannes Tschofenig 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: SAML and REST - was Re: [dix] DIX use cases References: <442303C5.6080307@gmail.com> <44264CE2.4000101@cisco.com> <20060328003830.GU7525@binky.Central.Sun.COM> In-Reply-To: <20060328003830.GU7525@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Hi Nico, let me also point to the TLS Inner/Application draft here: http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-02.txt It also tries to accomplish the goals mentioned below. Ciao Hannes Nicolas Williams wrote: > On Sun, Mar 26, 2006 at 02:12:18AM -0600, Eliot Lear wrote: > >>Robert Yates wrote: >> >>>1. Eliot's dad wants to remember one userid and password for the web. >> >>He also wants to use the same mechanism for IMAP a/o POP, SMTP to his >>MSA, and calendaring. As a stretch goal he may want to use the same >>mechanism to authenticate through on 802.1x, but I would admit that this >>could prove challenging. > > > There was a BoF at Paris, but insufficient bodies to do the proposed > work then, for a Generally Useful Authentication Mechanism (GUAM) > framework so that we could end up with a suite of mechanisms for EAP, > SASL and the GSS-API. > > There is now an I-D (draft-salowey-guam-mech-00.txt) for GUAM. And more > work will follow. > > This combined with some additional HTTP authentication using the GSS-API > (beyond what Negotiate can do) and the new SASL/GSS-API bridge > (draft-josefsson-sasl-gs2-00.txt), improvements in digest mechanisms, > and applying GUAM principles to any remaining populate mechanisms should > go a long way to meeting this requirement. > > Coroporate networks tend to use lots of these protocols and plenty of > browser-based applications too. Which is why I would insist on any > solutions in this problem space at the very least not preclude being > extended to work in non-browser contexts. But I think such a > requirement wouldn't be difficult to meet. > > Nico _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 28 03:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO9Xn-000412-Uh; Tue, 28 Mar 2006 03:27:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO9Xm-00040x-MV for dix@ietf.org; Tue, 28 Mar 2006 03:27:14 -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 1FO9Xl-0005fe-Be for dix@ietf.org; Tue, 28 Mar 2006 03:27:14 -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 k2S8RAU7054902 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Mar 2006 00:27:11 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <0D04ED42-CC52-4478-86DF-D6DAFCF9E466@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Digital Identity Exchange From: John Merrells Date: Tue, 28 Mar 2006 00:27:09 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [dix] DIX BOF Meeting Materials X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 the following link you'll find: - The presentation slides, including the 2 ad hoc slides (as PDF) - The meeting notes (thanks Hans!) - History of SAML presentation (thanks Bob!)(as PDF) - draft-merrells-dix-00.txt presentation (as PDF) Unfortunately there wasn't time to present the last two slide decks. Bob's on SAML is well worth a read. And I hope that mine on the dmd draft is an easy introduction to that draft. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Mar 28 14:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKJe-0002fC-Co; Tue, 28 Mar 2006 14:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKJd-0002f7-8B for dix@ietf.org; Tue, 28 Mar 2006 14:57:21 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOKJb-00049r-Ps for dix@ietf.org; Tue, 28 Mar 2006 14:57:21 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k2SJvIdK021072 for ; Tue, 28 Mar 2006 11:57:18 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k2SJvIda026914 for ; Tue, 28 Mar 2006 12:57:18 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2SJvHwS009296 for ; Tue, 28 Mar 2006 13:57:17 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2SJvHBd009295 for dix@ietf.org; Tue, 28 Mar 2006 13:57:17 -0600 (CST) Date: Tue, 28 Mar 2006 13:57:17 -0600 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: SAML and REST - was Re: [dix] DIX use cases Message-ID: <20060328195717.GR7525@binky.Central.Sun.COM> References: <442303C5.6080307@gmail.com> <44264CE2.4000101@cisco.com> <20060328003830.GU7525@binky.Central.Sun.COM> <4428E9FB.6060904@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4428E9FB.6060904@gmx.net> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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 Tue, Mar 28, 2006 at 01:47:07AM -0600, Hannes Tschofenig wrote: > Hi Nico, > > let me also point to the TLS Inner/Application draft here: > http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-02.txt > > It also tries to accomplish the goals mentioned below. You know, I'm a fan of this approach, but as I understand it there are requirements we must meet in order to be deployable that this approach doesn't address. Specifically: support for proxies, and support for proxies that want to see application protocol plaintext. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Mar 29 02:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVVn-0007G7-6n; Wed, 29 Mar 2006 02:54:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVVl-0007FD-Qw for dix@ietf.org; Wed, 29 Mar 2006 02:54:37 -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 1FOVVh-00079j-Sj for dix@ietf.org; Wed, 29 Mar 2006 02:54:37 -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 k2T7sSM7002001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 28 Mar 2006 23:54:30 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) To: Digital Identity Exchange Message-Id: <02F5C4B9-BDCB-4DA8-BE79-8EB447D5BDE6@sxip.com> Content-Type: multipart/mixed; boundary=Apple-Mail-3--44574672 From: John Merrells Date: Tue, 28 Mar 2006 23:54:26 -0800 X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL, BAYES_00, URIBL_OB_SURBL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b Subject: [dix] draft-merrells-use-cases-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 --Apple-Mail-3--44574672 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here's a more formal write up the use cases that I posted to the list just before the BOF. They cover all the browser based 'Eliot's Dad' scenarios that have been on the list in the past week. I've also written up a set of scenarios from Dick Hardt that cover various kinds of claims usage. The focus on these is the moving around of the claims, rather than the claims themselves. I've not documented Lisa and Rob's non-browser based use cases for DIX over HTTP and other protocols, as I'm not necessarily familiar enough with each case to do them justice. I would however encourage the group to write them up though. Volunteers? There seem to be strong opinions on whether we should or should not be considering non-browser based applications. My opinion is that we have enough of a challenge agreeing on a protocol for browser based applications. I'd propose that we deal with supporting this over browsers now and reserve non-browser based applications for future consideration. Comments/Additions/Deletions for the following draft please. John --Apple-Mail-3--44574672 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0777; name="draft-merrells-use-cases-00.txt" Content-Disposition: attachment; filename=draft-merrells-use-cases-00.txt Network Working Group J. Merrells Internet-Draft Sxip Identity Expires: September 29, 2006 March 28, 2006 Digital Identity Exchange - Use Cases draft-merrells-use-cases-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the motivating use cases for DIX, the Digital Identity Exchange protocol. Merrells Expires September 29, 2006 [Page 1] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. UC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. UC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. UC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. UC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. UC5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6. UC6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.7. UC7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.8. UC8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.9. UC9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.10. UC10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.11. UC11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.12. UC12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.13. UC13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.14. UC14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.15. UC15 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.16. UC16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.17. UC17 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.18. UC18 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.19. UC19 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.20. UC20 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.21. UC21 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.22. UC22 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.23. UC23 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.24. UC24 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.25. UC25 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.26. UC26 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.27. UC27 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Merrells Expires September 29, 2006 [Page 2] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Merrells Expires September 29, 2006 [Page 3] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 2. Definitions Digital Identity - The transmission of digital representation of a set of Claims made by one Party about itself or another Digital Subject, to one or more other Parties. Identity Agent - An agent acting on behalf of the user. Identifier - An identifying attribute for a set of attributes. Identity Data / Identity Information - A set of attributes. Claim - An assertion made by a Claimant of the value or values of one or more attributes of a Digital Subject, typically an assertion which is disputed or in doubt. Definitions drawn from the lexicon of 'The Identity gang'. [identitygang]. Merrells Expires September 29, 2006 [Page 4] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 3. Use Cases The use cases below describe various scenarios for the Digital Identity Exchnage (DIX) protocol [dmd0]. Some use cases are dependant upon others, so should be perused in order. Beth is our protagonist throughout; a typical Internet user, but she's a bit of a geek. 3.1. UC1 Beth receives an email from a friend introducing her to a new website, geeknews.com, a site that publishes techie news articles. She browses the site and decides to read some articles. She sees an IN button, which she clicks. Her identity agent performs an authentication process to ensure that it is representing Beth, and not an imposter. Her identity agent displays a screen informing her that geeknews.com is requesting some data, her first name. She enters 'Beth' at the prompt, provides consent and the data is sent to the site. 3.2. UC2 Beth browses to geekdate.com, she clicks an IN button. Her identity agent displays a screen informing her that geekdate.com is requesting some data, her first name. Her agent already has this data. She provides consent and the data is sent to the site. 3.3. UC3 Beth decides to create a profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an Identifier. She instructs her identity agent to create an identifier specific to her relationship with geekdate.com. She provides consent and the data is sent to the site. 3.4. UC4 Beth decides to flesh out her profile at geekdate.com. Geekdate.com displays a registration form. One field requests a URL of a photo of her. Beside it is a SAVE button. She enters the URL and clicks the button. Her identity agent displays a screen informing her that this data item can be stored. She provides consent and the data is stored by her agent. 3.5. UC5 Geeknews.com offers Beth the option to build up a readership Merrells Expires September 29, 2006 [Page 5] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 preferences profile over time, the benefit being that the site will tailor its content to her interests. She decides to take up the offer, she sees an IN button, which she clicks. Her identity agent displays a screen informing her that geeknews.com is requesting some data, an Identifier. She selects an existing identifier that represents a subset of her identity, which is used for a subset of the sites she has a relationship with. She provides consent and the data is sent to the site. 3.6. UC6 [Assumptions: Beth has visited geeknews and geekdate before and has informed her identity agent that she consents to a relationship with them.] Beth starts her day with a strong coffee and a perusal of geeknews.com. She starts her computer and authenticates herself to the operating system. By that authentication mechanism she has also authenticated herself to her identity agent, as her vendor of that system has hooked it into the operating system's authentication system. She browses to geeknews.com and clicks the IN button and is directly shown the content, no further clicks. She then browses to geekdate.com, she clicks the IN button and is directly presented with her profile no further clicks. 3.7. UC7 Beth's identity agent prompts her to provide a 'spoken name'. Using the multimedia capabilities of her computer she records her spoken name; an mp3 of her saying 'Beth'. She later browses to voicebox.com, which runs a voicemail service, she opts to create an account and the site requests some properties, amongst which is a request for her spoken name. She provides consent and the data is sent to the site. 3.8. UC8 Beth purchases a book from an online store, as she's checking out the store makes her an offer: 10% off for completion of a demographic survey. She's tempted, but how many data fields are there? One hundred! Too many to be worth the effort. But it happens to be commonly requested data, which she has already entered during previous exchanges with other sites. So, she completes the remaining fields, saving them to her identity agent for future reuse. She provides consent and the data is sent to the site. 3.9. UC9 Beth has invested significant effort in building up a persona and reputation around a specific identifier, her 'home' identifier. But, Merrells Expires September 29, 2006 [Page 6] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 she has become dissatisfied with her identity agent and so decides to switch vendors. She establishes the new agent and migrates her identity data from the old one to the new one. She then administers her identifier so that her new identity agent is authoritative for authentication and provision of identity data. 3.10. UC10 Whilst in town Beth stops off at an Internet Cafe to check her email. She goes to her webmail account, which requires that she identity herself. Her Identity Agent prompts her for consent and provides her identifier so that she can gain access to her email. 3.11. UC11 Beth visits a website that requests some identity information. Her Identity Agent warns her that satisfying the request would contravene her established privacy policy. 3.12. UC12 Beth moves house, so she changes the home address information stored by her Identity Agent. Her Identity Agent offers to notify all relying parties to whom she has previously provided her home address. 3.13. UC13 Beth is a frequent traveler on Galactic Air, whose site offers a claim of membership for use at affiliate sites. She acquires a membership claim, which her Identity Agent stores for her. 3.14. UC14 Beth visits a Galactic Air affiliate site that provides discounted travel insurance for frequent travelers. She presents her Galactic Air membership claim and receives a discount. 3.15. UC15 Beth leaves work and goes to the bus stop. Whilst waiting for the next bus home she uses her smart phone to browse geeknews.com. Her Identity Agent provides her with the same clickless browsing that she experiences on her work and home computers. 3.16. UC16 Beth is ending her day at work. She leaves work and waits for the next bus home. Her friend calls and invites her to the movies. She Merrells Expires September 29, 2006 [Page 7] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 uses her phone to browse to the movies.com to find out what's playing. The site requests her current location, which she consents to release via her Identity Agent. 3.17. UC17 Beth signs up with a financial services site, BigPicture.com, which provides an aggregate view of her finances. She provides the site with agency rights over each of her existing bank accounts. 3.18. UC18 Beth goes to an auction side, ibay.com. Her Identity Agent shows a signed graphic of ibay.com for releasing data. Beth knows that she's dealing with ibay.com, and not an imposter. 3.19. UC19 Beth visits her online bank, which requires the use of a strong authentication mechanism. She authenticates to her Identity Agent using a two-factor device indicated by the bank to be an acceptable mechanism. 3.20. UC20 Adam uses a service to acquire a verified email claim. With it he can prove that he owns his email address, Adam@example.com, without having to go through a verification process. 3.21. UC21 Beth gives her friend, Adam@example.com, access to her photos. Adam receives an email from Beth inviting him to view her photos. He goes to the site, which requests a verified email claim. He presents his claim and gains access to the photos Beth has published for him. 3.22. UC22 Adam visits a site that requires that he prove he is over 21. He provides the site with a claim that he is over 21 from the government of his country of residence, gov.ca. The site is unable to find out who Adam is from gov.ca. 3.23. UC23 Adam returns to the same site. He must again prove that he is over 21. He provides a claim, but the site cannot tell that it is Adam that has returned again to the site. Merrells Expires September 29, 2006 [Page 8] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 3.24. UC24 Adam heavily frequents two gambling sites, goldenslots.com and luckydice.com. He uses the same identifier accross both sites, so that they know he is the same person. 3.25. UC25 Beth's employer has partnered with a local university to provide it's staff with access to online courses. She signs up for some modules at the university admissions website acquiring an enrollment claim. She then browses to the computer science school website to sign up for an advanced programming course. The site requests claims that she is an employee, that she has previously completed some basic introductory modules, and that she has been enrolled. 3.26. UC26 Beth is shopping online for a new laptop computer. She visits an online site that caters to recently graduated professionals. She selects a machine and investigates the lease options available. To work out the monthly payment the site requests some claims: A claim that she's an alumni of a university, so that the site can include an appropriately branded tote bag. A claim that she's a member of Galactic Air, so that she can be credited with airmiles for her purchase. And, a claim from a credit scoring agency that she has a 'good' credit rating. 3.27. UC27 Beth is at home checking her work email, she has an email from a colleague assigning a customer support issue to her. The company help desk system is provided by helpdesk.com, an on-demand application provider. She clicks through a link in the email to the page that describes the issue. Helpdesk.com requests a claim that Beth is an employee of 'Nano Software Inc', which she provides from her Identity Agent, and she gains access to the page. Merrells Expires September 29, 2006 [Page 9] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 4. Security Considerations None. 5. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [dmd0] Merrells, J., "draft-merrells-dix-00.txt", March 2006. [identitygang] The Identity Gang, "http://identitygang.org/Lexicon", March 2006. Merrells Expires September 29, 2006 [Page 10] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Author's Address John Merrells Sxip Identity 798 Beatty Street Vancouver, BC 94110 Canada Email: merrells@sxip.com URI: http://sxip.com/ Merrells Expires September 29, 2006 [Page 11] =0C Internet-Draft Digital Identity Exchange - Use Cases March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Merrells Expires September 29, 2006 [Page 12] =0C --Apple-Mail-3--44574672 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-3--44574672-- From dix-bounces@ietf.org Wed Mar 29 19:58:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlUh-0005uy-Ex; Wed, 29 Mar 2006 19:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlUf-0005um-54 for dix@ietf.org; Wed, 29 Mar 2006 19:58:33 -0500 Received: from wproxy.gmail.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOlUe-0003kl-Sj for dix@ietf.org; Wed, 29 Mar 2006 19:58:33 -0500 Received: by wproxy.gmail.com with SMTP id i14so627666wra for ; Wed, 29 Mar 2006 16:58:32 -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=ehG02pUftqtMR5qnL16P52pQbQKASbQb9R7UpR8RMIjBTxm6xlhTQ3/mSPHsKHL9xMF3OMNHk0iUgnNzZfnOVPz/v9e7im2DlQHqBRVQzqGfvDW9Vt9XB6Dy2/U0pHuUoVO4FLWlzZqD5Nfluhx66iwM6iDy6fwatOWr5jD4itQ= Received: by 10.54.69.4 with SMTP id r4mr1188417wra; Wed, 29 Mar 2006 09:25:50 -0800 (PST) Received: from ?9.33.49.136? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 39sm211061wrl.2006.03.29.09.25.48; Wed, 29 Mar 2006 09:25:49 -0800 (PST) Message-ID: <442AC318.5050803@gmail.com> Date: Wed, 29 Mar 2006 12:25:44 -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] draft-merrells-use-cases-00.txt References: <02F5C4B9-BDCB-4DA8-BE79-8EB447D5BDE6@sxip.com> In-Reply-To: <02F5C4B9-BDCB-4DA8-BE79-8EB447D5BDE6@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.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: > > Here's a more formal write up the use cases that I posted to the list > just before > the BOF. They cover all the browser based 'Eliot's Dad' scenarios > that have > been on the list in the past week. They look good and have clarified some points for me. I have some concerns about claims though below. > > I've also written up a set of scenarios from Dick Hardt that cover > various kinds > of claims usage. The focus on these is the moving around of the claims, > rather than the claims themselves. The usability of the claims stuff worries me. The use cases are all written with the user previously acquiring a claim. What is the user experience if the user visits a site that requires a claim and the user does not have a claim. Are they sent to the appropriate site to get the claim? Will most users understand what a claim is? or does this all need to seemlessly happen? I think a use case that outlines this scenario should be added. e.g. Beth gives her friend, Adam@example.com, access to her photos. Adam receives an email from Beth inviting him to view her photos. He goes to the site, which requests a verified email claim. His identity agent does not presently have such a claim. His identity agent retrieves the required claim from his e-mail provider. His identity agent then presents this claim and gains access to the photos Beth has published for him. There may also be some use cases around expired claims that I think need to be present if claims are going to receive appropriate coverage. > > I've not documented Lisa and Rob's non-browser based use cases for DIX > over HTTP and other protocols, as I'm not necessarily familiar enough > with > each case to do them justice. I would however encourage the group to > write them up though. Volunteers? I'll take a stab at some. Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Mar 30 09:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyRD-0008Tv-P9; Thu, 30 Mar 2006 09:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyRC-0008Tj-J6 for dix@ietf.org; Thu, 30 Mar 2006 09:47: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 1FOyRB-000885-89 for dix@ietf.org; Thu, 30 Mar 2006 09:47:50 -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 k2UElkhu052600 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 30 Mar 2006 06:47:47 -0800 (PST) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <442AC318.5050803@gmail.com> References: <02F5C4B9-BDCB-4DA8-BE79-8EB447D5BDE6@sxip.com> <442AC318.5050803@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81525747-7F15-4D6C-A4B8-A9DC0AB8674F@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-use-cases-00.txt Date: Thu, 30 Mar 2006 06:47:43 -0800 To: Digital Identity Exchange X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) 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 On 29-Mar-06, at 9:25 AM, Robert Yates wrote: > The usability of the claims stuff worries me. The use cases are > all written with the user previously acquiring a claim. What is > the user experience if the user visits a site that requires a claim > and the user does not have a claim. Are they sent to the > appropriate site to get the claim? Will most users understand what > a claim is? or does this all need to seemlessly happen? I think a > use case that outlines this scenario should be added. > > e.g. > > Beth gives her friend, Adam@example.com, access to her photos. > Adam receives an email from Beth inviting him to view her photos. > He goes to the site, which requests a verified email claim. His > identity agent does not presently have such a claim. His identity > agent retrieves the required claim from his e-mail provider. His > identity agent then presents this claim and gains access to the > photos Beth has published for him. > > There may also be some use cases around expired claims that I think > need to be present if claims are going to receive appropriate > coverage. Both good points. I'll add use cases for them. >> I've not documented Lisa and Rob's non-browser based use cases for >> DIX >> over HTTP and other protocols, as I'm not necessarily familiar >> enough with >> each case to do them justice. I would however encourage the group to >> write them up though. Volunteers? > > I'll take a stab at some. Super. I'll fold those into the draft when they're done. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix