From stpeter@stpeter.im Mon Oct 3 09:34:45 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96921F8BAC for ; Mon, 3 Oct 2011 09:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC-J6CLMhb0j for ; Mon, 3 Oct 2011 09:34:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6921F8BAA for ; Mon, 3 Oct 2011 09:34:44 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 402DAE84C9; Mon, 3 Oct 2011 10:41:57 -0600 (MDT) Message-ID: <4E89E4DD.3020200@stpeter.im> Date: Mon, 03 Oct 2011 10:37:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "HAYASHI, Tatsuya" References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> <4E2CA293.70603@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: [http-auth] side meeting in Taipei (was: Re: HTTP-Auth BoF in Quebec City Postponed) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:34:45 -0000 On 9/30/11 11:43 PM, HAYASHI, Tatsuya wrote: > > Hi! Peter. > > The cut-off date of BOF proposal requests in IETF Taipei is coming soon. > Taking account of the recent status of this list, I don't think we > have a BOF in Taipei. However, I want to improve the authentication in > the web too, so is there any intention to have a side meeting to > clarify the scope and the problem? > > As a co-author of the problem statement draft by Yutaka Oiwa, I want > the draft enhanced by other guys familiar with authentication. > (We are updating a draft!) Yes, I think it would be good to have a side meeting in Taipei. At IETF 81, we talked about a few action items, such as: 1. Provide reviews of the Browser ID technology that Mozilla has been working on at https://browserid.org/ (this would provide some positive cross-pollination between IETF / security and W3C / browser folks). 2. Start some wiki pages at trac.tools.ietf.org to list existing technologies in this space (e.g., one page per solution), explore the differences between browsers and native applications (especially mobile apps), clarify the user experience factors involved here, etc. 3. Get more people to review the problem statement draft you have been working on with Yutaka Oiwa. 4. Reach out to service providers and developers (banks, payment systems, mobile app developers, people who work on account manager software, etc.). It would be nice to make progress on some of those before we hold a side meeting. I admit that I haven't done enough here, but I would like to help as time permits. Peter -- Peter Saint-Andre https://stpeter.im/ From y.oiwa@aist.go.jp Tue Oct 4 01:59:30 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EB521F8D08 for ; Tue, 4 Oct 2011 01:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=-3.372, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNyOZmBj1IgB for ; Tue, 4 Oct 2011 01:59:29 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E821F8D03 for ; Tue, 4 Oct 2011 01:59:28 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p9492ST2016753; Tue, 4 Oct 2011 18:02:28 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1317718949; bh=n+xoTzm6FfrosUnJF2yBUCgWVFQ0WXlnl2+VT54nlCw=; h=Message-ID:Date:From; b=YJhwXnfFOkQ3pnS6W7jld0U2JSF2mFJ3ytUFJz8LRCkcAMfwjfYrPoP5Zup5+VzSg t3ruGBsytPby6rrq7YIsgGJzBEj7fiMEX+UwLzXgE6LzijHJ166TjxfTn3oL6UvVta NTqbEM7wsF2MUQR0+Ps1dI+J1lnhLA9dOz2htfCg= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p9492SPA014877; Tue, 4 Oct 2011 18:02:28 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p9492RTA019381; Tue, 4 Oct 2011 18:02:27 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4E8ACBA3.3030302@aist.go.jp> Date: Tue, 04 Oct 2011 18:02:27 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: ietf-http-wg@w3.org References: <4E76C29A.60908@qbik.com> <68D65286-0397-4DD2-B99C-CF74CB331453@opera.com> <4E77B3F7.8020406@qbik.com> In-Reply-To: <4E77B3F7.8020406@qbik.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] OT re HTTP auth disassocation of credentials X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 08:59:30 -0000 Dear all, (added http-auth mailing list, responses preferred to this list) recently some browser vendors are trying incorporating authentication control with the browser's identity management mechanisms, and they propose some HTML/JavaScript level extensions for it. If you just need log-out feature, and if you can assume JavaScript support, it may just work for you. I think this trend may allow us a small icon for authentication control, hopefully. I am working from a bit different viewpoint, making HTTP authentication support more features which is currently only available via Form-based authentications, not limited to log-out control. My proposal is currently in a part of my new HTTP authentication scheme draft (draft-oiwa-http-mutualauth-09), and I am planning to make it a separate draft in the next revision. I put "pre-draft" on our Web page at (or < https://bit.ly/o3MDq4 > if line wrapping is nasty), and I will submit -00 draft possibly before the Taiwan meeting. Again, it may be over-engineered for log-out only, but please have a look, and if you're going to or wish to extend HTTP, it may serve for your needs. On 09/20/11 06:28, Adrien de Croy wrote: > > I think it would me more useful if it could be controlled from the server. > Hence a status or header. > > However, for browser vendors, since finding screen real-estate is such a > problem, an approach could be taken similar to the one used to show that a > sight is using TLS and to see certificate information. E.g. a small icon > showing that the request is authenticated, which could then give details of the > method, and an option to log out. > > Adrien > > > On 20/09/2011 12:43 a.m., Karl Dubost wrote: >> Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit : >>> FWIW I'd rather see browsers put a logout-button right in the browser GUI. >>> The button could simply cause the browser to stop sending the credentials. >> >> As much as I could see the benefit for it. I do not think this will fly for >> browser vendors. They are all currently trying to simplify the UI and >> minimize it. There is also the balance in between introducing a new UI >> feature with the number of times this (HTTP Auth) will be used. For example, >> Firefox removed the RSS icon (by default). >> >> PS: not advocating for any sides of the issue. >> > From y.oiwa@aist.go.jp Tue Oct 4 02:31:55 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF37321F8906 for ; Tue, 4 Oct 2011 02:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-2.803, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc0j8IeihsGk for ; Tue, 4 Oct 2011 02:31:54 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 46EF621F8AFA for ; Tue, 4 Oct 2011 02:31:54 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p949YrvH027321; Tue, 4 Oct 2011 18:34:54 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1317720894; bh=dKBi8p1esNWeis4IqJE7TPUbU7QsirXt/cN+5NoomuI=; h=Message-ID:Date:From; b=WTWsFa09Juj6Pzqr73Is0nydWW03qh16Q35j9YHTHTWttc5ypBOFXi4wxDBcnX0Uy V0nqXjt2HHJNoX1+369H6JiNjhagEbC1pTkFwM348dXGT7z5qU04f24ajvlPIsX6WJ ADI1kFOOWdFrAUZJ9A/BIqF8E5WF2+c/hVpL67R4= Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p949YrTT021681; Tue, 4 Oct 2011 18:34:53 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp1.aist.go.jp with ESMTP id p949Yq0f002645; Tue, 4 Oct 2011 18:34:52 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4E8AD33C.3070102@aist.go.jp> Date: Tue, 04 Oct 2011 18:34:52 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [http-auth] (request) some terminologies on authentication credentials X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 09:31:55 -0000 Dear http-auth list members, I am currently working on revising http-auth-problem-statement draft, and I have a favor to ask for possible terminology suggestions. In authentication protocols (especially those implemented on multi-layer protocol stacks), there is several kinds of manipulated passwords going on wire. I have no clearly indicating terms for the following 2 cases. In this text, I use the term "raw passwords" for the passwords that users type in, for example "ThisIsAPassword". It is often called "plain", "cleartext", "unencrypted", or "plaintext" passwords. (1) In usual Basic authentication on plain HTTP or SASL PLAIN authentication, the raw password is sent as "cleartext" on-wire (forget about BASE64 now). In this case, the term "cleartext password" gives no confusion. However, if we use Basic on HTTPS, the "raw password" is delivered as is to the peer server, on an encrypted channel. The raw password is not available to any eavesdroppers, but the receiving peer has direct access to it, and can be reused if it is malicious. I always feel yuck on "encrypted plaintext (or cleartext) password", but "a plaintext password on an encrypted channel" is still long and complex and confusing. Any ideas? (2) In APOP, a raw password is used in the following way. Let H be some kind of hash function. 1) S->C: challenge 2) C->S: H(challenge | password) The server computes the same H(challenge | password) using the copy of raw password stored in the server-side user database to authenticate. In this way, the server has to have a copy of raw passwords. Without having it the server cannot perform the password checking. In HTTP Digest auth., a raw password is used in a slightly different way. After greatly simplified, it is equivalent to the following: 1) S->C: challenge 2) C->S: H(challenge | H(password)) In this case, the server-side database has to have H(password) for authentication. This is not a "raw password", obviously. However, carefully observing the protocol, you will find that, if an attacker knows H(password), it can perform an authentication trial as a client without knowing the raw password itself. By comparing the above two protocol flows, H(password) in the latter case serves the role of "raw password" in the former one. This is very different from the nature of "hashed password" used in server-side for Basic/plaintext authentication. The problem I hit is how to describe the nature of this "H(password)" in a compact form. In the -00 draft I used the term "raw credential" and tried to describe the nature different from the usual "hashed password", but it is still very non-intuitive unclear. If you have a good idea or previous knowledge, please let me know. -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1] From marsh@extendedsubset.com Tue Oct 4 09:09:17 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33821F8DA3 for ; Tue, 4 Oct 2011 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH2iguNW1vZi for ; Tue, 4 Oct 2011 09:09:15 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id BEDBA21F8D63 for ; Tue, 4 Oct 2011 09:09:14 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RB7bQ-000AMs-1Q; Tue, 04 Oct 2011 16:12:20 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D2A5863BF; Tue, 4 Oct 2011 16:12:17 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Kp+Uuxn/zFhGWzUx5doy2htfs+mo+xIo= Message-ID: <4E8B3061.2030409@extendedsubset.com> Date: Tue, 04 Oct 2011 11:12:17 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Yutaka OIWA References: <4E8AD33C.3070102@aist.go.jp> In-Reply-To: <4E8AD33C.3070102@aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] (request) some terminologies on authentication credentials X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:09:17 -0000 On 10/04/2011 04:34 AM, Yutaka OIWA wrote: > > In this text, I use the term "raw passwords" for the passwords that users type > in, for example "ThisIsAPassword". It is often called "plain", "cleartext", > "unencrypted", or "plaintext" passwords. > > (1) > In usual Basic authentication on plain HTTP or SASL PLAIN authentication, the > raw password is sent as "cleartext" on-wire (forget about BASE64 now). In this > case, the term "cleartext password" gives no confusion. > > However, if we use Basic on HTTPS, the "raw password" is delivered as is > to the peer server, on an encrypted channel. The raw password is not available > to any eavesdroppers, but the receiving peer has direct access to it, and can > be reused if it is malicious. I always feel yuck on "encrypted plaintext (or > cleartext) password", but "a plaintext password on an encrypted channel" is > still long and complex and confusing. Any ideas? "Plaintext password over an encrypted channel" is the best way I have found to describe this. I think it feels a bit yucky because it *is* a bit yucky. :-) Since the password credential is not bound to the channel, it's not the same as actual strong mutual authentication. Having a nicer term for this scheme might make it seem nicer than it really is! > (2) > However, carefully observing the protocol, you will find that, if an attacker > knows H(password), it can perform an authentication trial as a client without > knowing the raw password itself. >[...] > The problem I hit is how to describe the nature of this "H(password)" in a > compact form. In the -00 draft I used the term "raw credential" and tried to > describe the nature different from the usual "hashed password", but it is still > very non-intuitive unclear. If you have a good idea or previous knowledge, > please let me know. I like the term "password equivalent" for that type of thing. Perhaps you could call it a "password equivalent hash value" or something like that. - Marsh From nico@cryptonector.com Tue Oct 4 11:52:37 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5FC21F8CB9; Tue, 4 Oct 2011 11:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiXKVshrdcIE; Tue, 4 Oct 2011 11:52:36 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D86C621F8D6A; Tue, 4 Oct 2011 11:52:36 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 948CD67C073; Tue, 4 Oct 2011 11:55:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=vWwed0Cs8DXJSjRvHxtuz 8emWJGGrqRFf0cFCJOD//sLn1+S3URU1uh/GnMwKu1pKaec7FsOoao2D+3JPEyig VNHyrff0J3oDgsiBzOkOeUbmkuzQckZodouPE+65FWp5pJLN2mwl6bY8fLhLMosg a6bKSJzf1gbI0haIBKk0sc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VWxjz5emYibkZSyh8prU fnNEhAg=; b=po3WOOM8oL8+c1QG5x3EzRrifmQPbFx0LR/ZPk3p9pNKqOGFJgix ejHOI6iT1UP9HxM7YaPgTPUR5RssCCt6FzyQZLzSmAD1vgL4Fgxeuu6VPJrHCK9Z sd6ZuL5Hcrv0tddxTeBIb1JEowgEPTP/jIjChAZ3G1PceEzKMmM3c/0= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 46BBE67C072; Tue, 4 Oct 2011 11:55:39 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so856924vcb.31 for ; Tue, 04 Oct 2011 11:55:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.93.139 with SMTP id cu11mr1658081vdb.77.1317754538605; Tue, 04 Oct 2011 11:55:38 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Tue, 4 Oct 2011 11:55:38 -0700 (PDT) In-Reply-To: References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> <4E2CA293.70603@stpeter.im> Date: Tue, 4 Oct 2011 13:55:38 -0500 Message-ID: From: Nico Williams To: "HAYASHI, Tatsuya" Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" , "apps-discuss@ietf.org Discuss" Subject: Re: [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:52:37 -0000 On Sat, Oct 1, 2011 at 12:43 AM, HAYASHI, Tatsuya wrote: > The cut-off date of BOF proposal requests in IETF Taipei is coming soon. > Taking account of the recent status of this list, I don't think we > have a BOF in Taipei. However, I want to improve the authentication in > the web too, so is there any intention to have a side meeting to > clarify the scope and the problem? > > As a co-author of the problem statement draft by Yutaka Oiwa, I want > the draft enhanced by other guys familiar with authentication. > (We are updating a draft!) We agreed at Quebec not to have a meeting at Taipei. I thought we all agreed that it would be counter-productive to have such a meeting with a significant constituency absent. What's changed since Quebec? Nico -- From stpeter@stpeter.im Tue Oct 4 12:34:47 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F9421F8F7A; Tue, 4 Oct 2011 12:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFyO-J52jodM; Tue, 4 Oct 2011 12:34:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9DF321F8F74; Tue, 4 Oct 2011 12:34:46 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 67178E84C9; Tue, 4 Oct 2011 13:42:05 -0600 (MDT) Message-ID: <4E8B608E.3030400@stpeter.im> Date: Tue, 04 Oct 2011 13:37:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nico Williams References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> <4E2CA293.70603@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , "apps-discuss@ietf.org Discuss" Subject: Re: [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:34:47 -0000 On 10/4/11 12:55 PM, Nico Williams wrote: > On Sat, Oct 1, 2011 at 12:43 AM, HAYASHI, Tatsuya > wrote: >> The cut-off date of BOF proposal requests in IETF Taipei is coming soon. >> Taking account of the recent status of this list, I don't think we >> have a BOF in Taipei. However, I want to improve the authentication in >> the web too, so is there any intention to have a side meeting to >> clarify the scope and the problem? >> >> As a co-author of the problem statement draft by Yutaka Oiwa, I want >> the draft enhanced by other guys familiar with authentication. >> (We are updating a draft!) > > We agreed at Quebec not to have a meeting at Taipei. I thought we all > agreed that it would be counter-productive to have such a meeting with > a significant constituency absent. > > What's changed since Quebec? We agreed not to hold a BoF. I see no particular harm in a little side meeting if folks are interested. Peter -- Peter Saint-Andre https://stpeter.im/