From bergi@axolotlfarm.org Thu Nov 3 15:35:09 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 A6F331F0C9F for ; Thu, 3 Nov 2011 15:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 RiWR1gIuVbEd for ; Thu, 3 Nov 2011 15:35:08 -0700 (PDT) Received: from axolotlfarm.org (essen062.server4you.de [217.172.182.62]) by ietfa.amsl.com (Postfix) with ESMTP id 718C61F0C59 for ; Thu, 3 Nov 2011 15:35:04 -0700 (PDT) Received: from p4fedba83.dip.t-dialin.net ([79.237.186.131] helo=[192.168.1.1]) by axolotlfarm.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1RM5rj-0006Gq-A4; Thu, 03 Nov 2011 23:34:31 +0100 Message-ID: <4EB316F9.405@axolotlfarm.org> Date: Thu, 03 Nov 2011 23:34:33 +0100 From: bergi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <4EADC3F3.5000602@axolotlfarm.org> <4EAE6A0D.5040802@wp.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Nov 2011 16:34:11 -0700 Cc: julian.reschke@greenbytes.de, http-auth@ietf.org, foaf-protocols@lists.foaf-project.org, public-xg-webid@w3.org, ietf-http-wg@w3.org, public-rww@w3.org, Dominik Tomaszuk Subject: Re: [http-auth] HTTP request header field for acceptable authentication methods 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: Thu, 03 Nov 2011 22:42:31 -0000 Am 02.11.2011 01:59, schrieb Mark Nottingham: > > On 31/10/2011, at 8:27 PM, Dominik Tomaszuk wrote: > >> On 30.10.2011 22:38, bergi wrote: >>> Currently my and maybe most other web applications with WebID support >>> have the following flow for user authentication: >>> >>> - The user sees your web page with reduced content >>> - The user follows the login link >>> - The login resource asks for a client certificate >>> - The WebID gets bound to the session cookie >>> - The server sends a redirect to the original page >>> - Finally the user sees page with the content for that WebID >>> >>> For example the Java address book application or most robots want to >>> access the resource in a RESTful way and will not use the described >>> flow. I haven't found a way to force the use of a client certificate if >>> the server doesn't ask for one. I propose to use a HTTP header field to >>> tell the server that the client is able to authenticate with a WebID. As >>> such a field could be also useful for other authentication methods I >>> would chose a generic name. There are already some Accept-* fields I >>> would follow that pattern. As it's currently not a standard field I >>> would prefix that field with X-. > > Please, please don't do this. See: > http://tools.ietf.org/html/draft-ietf-appsawg-xdash > > >>> Multiple values must have the same >>> format as defined for the Accept field. Also the quality parameter must >>> be handled by the server. >>> >>> Example only with WebID authentication: >>> X-Accept-Authentication: WebID >>> >>> Example with WebID and Basic authentication: >>> X-Accept-Authentication: WebID, Basic;q=0.9 >>> >>> What do you think about my proposal? >> It might be interesting to HTTPBis, part 7: Authentication [1] and HTTPBis Authentication Scheme Registrations [2] >> >> [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16 >> [2] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02 > > > It's not appropriate in the HTTPbis documents, as they're specifically NOT introducing new mechanisms. > > Optional authentication has been widely discussed in the past; you might want to try the http-auth list . > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > Thanks! Maybe we should split this a little bit. Authentication Scheme I was thinking about this a little bit more and now I'm not sure if we should use WebID or WebID-TLS or even something else. From the terminology point of view WebID-TLS would fit better. HTTPBis, part 7, section 2.3 [1] points to a link on the IANA web site which is dead [2]. I haven't found a new URL. Somebody knows if this page has moved somewhere else? On the other hand HTTPBis, part 7, section 2.3.1 [3] says: "..thus an authentication scheme can not bind information to the TCP session over which the message was received...". But even if this is true for our case, the proposed field could and should be used by WebID and existing HTTP authentication schemes. A registered scheme could avoid name conflicts. Acceptable authentication schemes request field Just a summarization: The field Accept-Authentication tells the server which authentication scheme the clients supports. Valid values are one or multiple HTTP authentication schemes. Each value can have a quality factor which must be handled like the one for the Accept field (described in RFC2616, section 14.1 or HTTPBis, part 3 section 6.1 [4]). [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3 [2] http://www.iana.org/assignments/http-authschemes [3] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1 [4] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-17#section-6.1 the bergi From y.oiwa@aist.go.jp Thu Nov 3 16:55:15 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 9411211E80CA for ; Thu, 3 Nov 2011 16:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=-2.477, BAYES_00=-2.599, 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 a5Jm+DVfSW8E for ; Thu, 3 Nov 2011 16:55:14 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9961011E80AD for ; Thu, 3 Nov 2011 16:55:14 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id pA3Nsx97013688; Fri, 4 Nov 2011 08:54:59 +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=1320364500; bh=I50R0yXXEiSjLnSbxrVvDF/oK+nKRTPMlYHXpZWM8qA=; h=Message-ID:Date:From; b=jJAFFbqEClORGO10Jut1+TpDSqHpkiIIYE9rPvUif8IZkExSTi1EvwHKKh+toA5zC S3Hv9+jd1CrvtcHO2JlIQjxBDP62HWs9+LvIkzXGGn0b1AICS5tk9zizeiTYT5OyYX 6szR1D8h60+J9b2fPVDGEky2C4V+6ZHRTRPPinfM= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id pA3Nsxj4029508; Fri, 4 Nov 2011 08:54:59 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id pA3Nssn2013786; Fri, 4 Nov 2011 08:54:55 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4EB329CE.5000507@aist.go.jp> Date: Fri, 04 Nov 2011 08:54:54 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Dominik Tomaszuk References: <4EADC3F3.5000602@axolotlfarm.org> <4EAE6A0D.5040802@wp.pl> In-Reply-To: <4EAE6A0D.5040802@wp.pl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: julian.reschke@greenbytes.de, "http-auth@ietf.org" , foaf-protocols@lists.foaf-project.org, public-xg-webid@w3.org, ietf-http-wg@w3.org, public-rww@w3.org Subject: Re: [http-auth] HTTP request header field for acceptable authentication methods X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "http-auth@ietf.org" List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 23:55:15 -0000 Dear Dominik, # Reply-to set to http-auth mailing list, be careful. I am actually interested about the idea, as I was considering similar one for another purpose (footnote *1). As Mark Nottingham has suggested in another reply in HTTPBIS, it should not be X- prefixed, and it seems not to be the area of HTTPBIS working group. HTTP-AUTH list seems to be appropriate for a moment, and if it goes rapidly than HTTP-Auth activity, it may possibly be rerouted to the APPSAWG. Currently I am submitting an individual draft called "HTTP Authentication Extensions for Interactive Clients" , and if you allow me I would like either to include it to the next version of this draft, or to write a separate draft for that header. However, there seems to be a few things to be solved before specifying: 0) the name: HTTP does not have the corresponding *-Authentication header. Should it be either Accept-Authentication, Accept-Authorization, or Accept-WWW-Authenticate? 1) The header will naturally take tokens for HTTP authentication schemes, which will have registration entries in "HTTPBis Authentication Scheme Registrations" you have mentioned, as all other "Accept-*" headers do somewhat similar. You have included "Basic" in an example, I guessed from that. However, as far as I know, WebID will not use HTTP Authentication layer, and thus it will (at least naturally) not have an entry in the registry. We will have to find the way to include non-HTTP authentication names in the headers unambiguously, by a) find some distinguishable syntax for holding two separate name-spaces, b) find a way to have registration system for non-HTTP authentication, either unified or non-conflicting to HTTP-Auth scheme tokens, or c) find an (unlikely?) way to reserve a token in the HTTP-Auth registry. 2) Do we really need qvalue here? Or what q=0 suggests? Do you have some opinion about these? (*1) As far as several HTTP-Auth schemes are involved, the HTTP auth framework allows servers to provide several possible schemes at once, and clients to choose the most strong one. However, I want to allow servers to check whether clients accepts my Mutual authentication scheme, otherwise divert to Form authentication possibly for transition purpose. On 2011/10/31 18:27, Dominik Tomaszuk wrote: > On 30.10.2011 22:38, bergi wrote: (skipped) >> I propose to use a HTTP header field to >> tell the server that the client is able to authenticate with a WebID. As >> such a field could be also useful for other authentication methods I >> would chose a generic name. There are already some Accept-* fields I >> would follow that pattern. As it's currently not a standard field I >> would prefix that field with X-. Multiple values must have the same >> format as defined for the Accept field. Also the quality parameter must >> be handled by the server. >> >> Example only with WebID authentication: >> X-Accept-Authentication: WebID >> >> Example with WebID and Basic authentication: >> X-Accept-Authentication: WebID, Basic;q=0.9 >> >> What do you think about my proposal? > It might be interesting to HTTPBis, part 7: Authentication [1] and HTTPBis > Authentication Scheme Registrations [2] > > [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16 > [2] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02 > > Best, > Dominik 'domel' Tomaszuk > -- 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[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From mnot@mnot.net Thu Nov 3 22:03: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 607C81F0C45 for ; Thu, 3 Nov 2011 22:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.438 X-Spam-Level: X-Spam-Status: No, score=-105.438 tagged_above=-999 required=5 tests=[AWL=-2.839, 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 EQnryKRVZ0YA for ; Thu, 3 Nov 2011 22:03:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 368691F0C41 for ; Thu, 3 Nov 2011 22:03:43 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.71.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 13E5C22E253; Fri, 4 Nov 2011 01:03:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4EB316F9.405@axolotlfarm.org> Date: Fri, 4 Nov 2011 16:03:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <255520C6-B4D2-41CF-8805-A6BC8CEA480F@mnot.net> References: <4EADC3F3.5000602@axolotlfarm.org> <4EAE6A0D.5040802@wp.pl> <4EB316F9.405@axolotlfarm.org> To: bergi X-Mailer: Apple Mail (2.1251.1) Cc: julian.reschke@greenbytes.de, http-auth@ietf.org, foaf-protocols@lists.foaf-project.org, public-xg-webid@w3.org, ietf-http-wg@w3.org, public-rww@w3.org, Dominik Tomaszuk Subject: Re: [http-auth] HTTP request header field for acceptable authentication methods 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: Fri, 04 Nov 2011 05:03:45 -0000 On 04/11/2011, at 9:34 AM, bergi wrote: >=20 > Authentication Scheme >=20 > I was thinking about this a little bit more and now I'm not sure if we > should use WebID or WebID-TLS or even something else. =46rom the > terminology point of view WebID-TLS would fit better. >=20 > HTTPBis, part 7, section 2.3 [1] points to a link on the IANA web site > which is dead [2]. I haven't found a new URL. Somebody knows if this > page has moved somewhere else? That link is dead because HTTPbis hasn't been through the entire process = yet; the IANA registries will be established later on. Cheers, -- Mark Nottingham http://www.mnot.net/ From henry.story@bblfish.net Fri Nov 4 04:09: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 9693F21F8C1C for ; Fri, 4 Nov 2011 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 QaY7v8YCG3Z7 for ; Fri, 4 Nov 2011 04:09:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4CB21F8C3F for ; Fri, 4 Nov 2011 04:09:27 -0700 (PDT) Received: by wyg30 with SMTP id 30so2555764wyg.31 for ; Fri, 04 Nov 2011 04:09:26 -0700 (PDT) Received: by 10.227.209.21 with SMTP id ge21mr17704516wbb.6.1320404965322; Fri, 04 Nov 2011 04:09:25 -0700 (PDT) Received: from reclhc195180.univ-st-etienne.fr (reclhc195180.univ-st-etienne.fr. [161.3.195.180]) by mx.google.com with ESMTPS id em4sm6540636wbb.20.2011.11.04.04.09.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 04:09:24 -0700 (PDT) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2011 12:09:23 +0100 Message-Id: <610CA253-E9FA-4B15-9DB5-BA19C2F2C697@bblfish.net> To: http-auth@ietf.org, WebID XG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: Re: [http-auth] Fwd: [TLS] HTTPS client-certificate-authentication in browsers, 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: Fri, 04 Nov 2011 11:09:30 -0000 Hello, ( I just subscribed to this list so I was not able to reply-to the = original post, and so the threading might be a bit askew. ) Let me first present myself quickly. I am currently chairing the W3C = WebID XG group which has a nice little introductory video on = http://webid.info/ , and a spec that is slowly developing at = http://webid.info/spec/ . It is worth looking a bit longer that way, = because there is a lot of hidden power in TLS that we have been = discovering, which makes all kinds of very interesting things possible.=20= On Novermber 4th 2011, Yoav Nir > I'm pretty sure that if client certificates worked for HTTPS, we would = not have an HTTP-AUTH initiative. So I hope we don't have to open this discussion in such a polarising = way. There is nothing to say that WebID/TLS cannot be compatible with = client auth, indeed it never occurred to me that it should not be. The above statement also assumes that nothing new can come to light from = well known quarters. Yet for hundreds of thousands of years the earth = man walked on was round and yet few people took much notice [1] : the = earth being round for example was not hidden in any way to humanity. And = here I hurry to add that I am not saying that HTTP Auth is in the flat = earth camp! But if we start off by assuming that we can't discover = something new from unexpected quarters, and we justify that by the fear = that this new thing may put too much in question, then though this is = quite a well trodden path in the history of humanity, it is certainly = not the attitude that let to the discovery of the Americas and so the = foundation of the IETF :-) > But the biggest thing working against certificates is that they = identify a device, not a user. A certificate identifies a person in possession of the private key of a = given public key. That this is best done via devices is another thing. = On this reasoning someone's signature does not identify the person, but = the pencil they used to sign.=20 > If I have several devices then I either have to have multiple copies = of my cert and private key, or several different certificates, one for = each device, or an n+1-th device (such as a USB token) that contains the = private key and can be connected to any browser, and there's no = technology now that would work with all browsers. It is true that if a certificate can only be used on one web site, then = this is a problem because the advantage they provide is so infinitely = small. But this is no longer the case once WebID enters the scene. A = WebID certificate can be used on every web site: so the benefit had by = putting the certificate on different devices then becomes justifies. = When that is taken into account, and the ease of certificate creation is = understood, then you can see how both your position and the WebID = procedure can be right. It is also worth seeing that certificate creation is not that difficult. = In addition to the video mentioned above, here is a video that shows how = one can create a certificate in one click in a number of browsers easily http://www.youtube.com/watch?v=3DS4dlMTZhUDc It does rely on the use of a temporary key, to help switch between = devices. One time keys can be sent via cell phones or other means.=20 > It's little wonder that all the big services prefer to use passwords. The reason service providers prefer to use passwords is, as mentioned = above, quite other. It is that client certificates are not of much use = in addition to passwords if the certificate can only be used on one web = site. Your point about the complexity of getting certificates onto = different devices you explained above is well taken. But when the ease = of creating a certificate is then combined with the value gained from = using it, then those issues disappear in practical importance. I wrote this up as a FAQ here = http://www.w3.org/wiki/Foaf%2Bssl/FAQ#Why_have_most_sites_preferred_to_use= _passwords_over_client_certificates.3F So hopefully I have been able to phrase these rebuttals in such a way as = to make in both understandable why these misunderstandings exist and why = one can in fact solve the problems of client certificates with hardly = any changes. >=20 > Yoav >=20 > On Jul 25, 2011, at 9:36 AM, Peter Saint-Andre wrote: >=20 > > Might be of interest here... > >=20 > > -------- Original Message -------- > > Subject: [TLS] HTTPS client-certificate-authentication in browsers > > Date: Mon, 25 Jul 2011 14:06:59 +0200 > > From: Anders Rundgren > > To: tls at ietf.org > >=20 > > Hi Guys, > > I don't really know who "owns" this question but presumably you = do... > >=20 > > HTTPS client-certificate-authentication in browsers > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > I don't believe that TLS CCA (Client Certificate Authentication) in = the > > form of HTTPS as implemented in current browsers has much of a = future. > >=20 > > In fact, quite a bunch of the entities in the EU working with = consumer PKI > > have replaced HTTPS CCA with an application level scheme which = wasn't such > > a big deal since they anyway were forced writing a browser PKI = client more > > or less from scratch since the ones shipped with browsers doesn't = support > > PKI as defined by banks and government (like mandatory PIN codes = also > > for on-line enrolled keys). > >=20 > > That the TLS CCA protocol doesn't even support "Logout" haven't made > > it a logical choice for web developers either. Well, there are some > > workarounds but they are by no means straightforward, supported > > out-of-the-box by server authentication schemes, and are (of course) > > entirely undocumented. The logout code that works in IE and Firefox is function logout(elem) { if (document.all =3D=3D null) { if (window.crypto) { try{ window.crypto.logout(); return false; //firefox ok -- no need to follow the link } catch (err) {//Safari, Opera, Chrome -- try with tis session = breaking } } else { //also try with session breaking } } else { // MSIE 6+ document.execCommand('ClearAuthenticationCache'); return false; }; return true } see: http://www.w3.org/wiki/Foaf%2Bssl/HOWTO > >=20 > > The button "Clear SSL state" in MSIE is an indication how horribly = bad it > > can go when security experts design systems for "people". > >=20 > > There's no way you can hide the fact that TLS CCA is only truly = useful > > securing tunnels between "boxes". > >=20 > > Anders [1] http://bblfish.net/blog/page7.html#2005/06/24/12-54-28-860 Social Web Architect http://bblfish.net/ From mnot@mnot.net Fri Nov 4 18:55:46 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 2EC7211E80A2 for ; Fri, 4 Nov 2011 18:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 6uDaS-zsHiJv for ; Fri, 4 Nov 2011 18:55:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 81E6011E8091 for ; Fri, 4 Nov 2011 18:55:45 -0700 (PDT) Received: from [10.90.38.255] (unknown [123.98.136.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 611C922E1FB; Fri, 4 Nov 2011 21:55:37 -0400 (EDT) References: <4EADC3F3.5000602@axolotlfarm.org> <4EAE6A0D.5040802@wp.pl> <4EB316F9.405@axolotlfarm.org> <255520C6-B4D2-41CF-8805-A6BC8CEA480F@mnot.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <07E090D5-B167-44C2-BE53-017AA13CB532@mnot.net> X-Mailer: iPhone Mail (9A334) From: Mark Nottingham Date: Sat, 5 Nov 2011 12:55:26 +1100 To: Peter Williams Cc: "julian.reschke@greenbytes.de" , "http-auth@ietf.org" , "foaf-protocols@lists.foaf-project.org" , "public-xg-webid@w3.org" , "ietf-http-wg@w3.org" , "public-rww@w3.org" Subject: Re: [http-auth] [foaf-protocols] HTTP request header field for acceptable authentication methods 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: Sat, 05 Nov 2011 01:55:46 -0000 Not sure why you're asking me; perhaps the cc list needs to be trimmed?=20 On 05/11/2011, at 12:45 PM, Peter Williams wrote: > So what is webid vs webid-tls? >=20 > Does webid tls exclude ssl v3? >=20 > I ask as only very specific agendas call for the elimination of ssl v3. On= ly .001% of the users know the difference, and less than half of those can a= ccurately state it. >=20 >=20 > On Nov 4, 2011, at 2:28 AM, "Mark Nottingham" wrote: >=20 >>=20 >> On 04/11/2011, at 9:34 AM, bergi wrote: >>>=20 >>> Authentication Scheme >>>=20 >>> I was thinking about this a little bit more and now I'm not sure if we >>> should use WebID or WebID-TLS or even something else. =46rom the >>> terminology point of view WebID-TLS would fit better. >>>=20 >>> HTTPBis, part 7, section 2.3 [1] points to a link on the IANA web site >>> which is dead [2]. I haven't found a new URL. Somebody knows if this >>> page has moved somewhere else? >>=20 >> That link is dead because HTTPbis hasn't been through the entire process y= et; the IANA registries will be established later on. >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >> _______________________________________________ >> foaf-protocols mailing list >> foaf-protocols@lists.foaf-project.org >> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols From henry.story@bblfish.net Sat Nov 5 14:46:06 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 A436611E8083 for ; Sat, 5 Nov 2011 14:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Q9Mzycd8bllv for ; Sat, 5 Nov 2011 14:46:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7078411E807F for ; Sat, 5 Nov 2011 14:46:04 -0700 (PDT) Received: by wyg30 with SMTP id 30so3950256wyg.31 for ; Sat, 05 Nov 2011 14:46:01 -0700 (PDT) Received: by 10.180.0.100 with SMTP id 4mr3643492wid.48.1320529560475; Sat, 05 Nov 2011 14:46:00 -0700 (PDT) Received: from bblfish.home (LCaen-156-55-35-161.w80-15.abo.wanadoo.fr. [80.15.5.161]) by mx.google.com with ESMTPS id en7sm2237595wib.0.2011.11.05.14.45.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 14:45:59 -0700 (PDT) From: Henry Story Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_F965823A-D684-4D52-8A97-DC6BDE9034AF" Date: Sat, 5 Nov 2011 22:45:58 +0100 In-Reply-To: To: julian.reschke@greenbytes.de, http-auth@ietf.org, "Roy T. Fielding" , foaf-protocols@lists.foaf-project.org, WebID XG , HTTP Working Group , Read-Write-Web References: <4EADC3F3.5000602@axolotlfarm.org> <4EAE6A0D.5040802@wp.pl> <4EB316F9.405@axolotlfarm.org> <255520C6-B4D2-41CF-8805-A6BC8CEA480F@mnot.net> , <07E090D5-B167-44C2-BE53-017AA13CB532@mnot.net> Message-Id: <974BD2BB-165D-49F2-8D2B-2FEECB142C7F@bblfish.net> X-Mailer: Apple Mail (2.1251.1) Subject: Re: [http-auth] [foaf-protocols] HTTP request header field for acceptable authentication methods 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: Sat, 05 Nov 2011 21:46:06 -0000 --Apple-Mail=_F965823A-D684-4D52-8A97-DC6BDE9034AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Perter Williams is our Paranoid Android, please take what he says with a = pinch of salt.=20 WebID currently specialises on TLS, just because that is what works in = current browsers, and because we are an incubator group, and don't have = infinite resources to work on a logic to tie these all together. These = things can be tied together, we will have some demos soon. The IETF = knows very well that multiple specifications can interact together = fluidly. One does not have to write the one spec to finish all specs. Henry On 5 Nov 2011, at 19:36, Peter Williams wrote: > The issue of webid, browserid (and the 5 other latest schemes doing = the same thing) has become religious, at the cultish level. One sees the = cc: trick, as folks seek to make their case. To be fair, browserid = community is a bit more disciplined than others, on keeping a lid on = broadcast-based prosletizing. > =20 > All I see is 5 new unverified schemes with about a max of 1000 users = each (mostly developers), vying for attention in the usual vendor space. = Each denies the legitimacy of the other, including such as gmail or = yahoo or openid or SAML or ws-fedp, or OAUTH, or OAUTH v2, or anything = else. AS a consumer of such assertions, I reject any scheme proposal = IF IT HAS THAT POSTURE. The posture means its too immature for adoption = by the likes of us (mainstream). We are really not interested in another = Google Wave. > =20 > There seems nothing to be done to stop the endless pursuit of = assertion protocols. Any scheme that half-works simply induces a = counter-scheme to become designed, as folks seek to impose some or other = twist on what MUST now be trusted. This seems to be lobbyist-based, as = some new infrastrcuture business sees $$ in controlling user logon. For = browserid, someone believes that only email providers enable scalable = verification. For our users , half of them use gmail and gmail already = does the equivalent of a browserid assertion and validation. Its called = openid v2. For me, its was trivial to integrate openid (i.e. Google), as = Microsoft's ACS ideneity gateway did 100% of the work for us. = Integrating microsoft gateway was pretty trivial, too. It want hard to = pursuade the security auditor that our work was "reasonable." > =20 > If it helps, perhaps note that we are service provider. We are = logically an adoptee of schemes such as browser, assuming they deliver a = 100 million users to our door - since we need the problem solved "at a = national level". its just the nature of real estate. We have even = decided to get out of the login and authentication business (after 40 = years). Nothing helped make anyone happy - despite having delivered = password management, securid tokencodes, phone-based SMS, passmark = anti-fraud neural networks, and even biometrics. We are even designed = our own secure USB key, for a while. No user community was/is happy. = Every subgroup wants some twist, to suit their personal hot button = issue. The user community is almost as fragmented as the vendor = community. Of course, noone will pay anything, as its someones else = responsibility. Whats more (in our unusual space), no ads are allowed - = so even that funding trick is unavailable. Folks cannot even trade off = their privacy for free security technology. > =20 > If anyone cares (and I rarely find folks in the religious phase of a = movement could give a damn, wanting only to preach to those likely to be = "converted") we have stopped accepting any of the third-party schemes, = unless its gatewayed to us by the Microsoft Azure ACS service. Fpr the = next year or two, they are the gatekeeper on the n schemes, rewriting = the n assertion blob formats into one. Its not that there is anything = special about the Microsoft Azure service to us, other than its scheme = agnostic. What it does is make identity verification less of a = "miserable affair", removing the posturing and the carping that is = getting in the way of delivering service values. > =20 > Hope the feedback on the list's tone helps. > =20 > > CC: bergi@axolotlfarm.org; julian.reschke@greenbytes.de; = http-auth@ietf.org; fielding@gbiv.com; = foaf-protocols@lists.foaf-project.org; public-xg-webid@w3.org; = ietf-http-wg@w3.org; public-rww@w3.org > > From: mnot@mnot.net > > Subject: Re: [foaf-protocols] HTTP request header field for = acceptable authentication methods > > Date: Sat, 5 Nov 2011 12:55:26 +1100 > > To: home_pw@msn.com > >=20 > > Not sure why you're asking me; perhaps the cc list needs to be = trimmed?=20 > >=20 > > On 05/11/2011, at 12:45 PM, Peter Williams wrote: > >=20 > > > So what is webid vs webid-tls? > > >=20 > > > Does webid tls exclude ssl v3? > > >=20 > > > I ask as only very specific agendas call for the elimination of = ssl v3. Only .001% of the users know the difference, and less than half = of those can accurately state it. > > >=20 > > >=20 > > > On Nov 4, 2011, at 2:28 AM, "Mark Nottingham" = wrote: > > >=20 > > >>=20 > > >> On 04/11/2011, at 9:34 AM, bergi wrote: > > >>>=20 > > >>> Authentication Scheme > > >>>=20 > > >>> I was thinking about this a little bit more and now I'm not sure = if we > > >>> should use WebID or WebID-TLS or even something else. =46rom the > > >>> terminology point of view WebID-TLS would fit better. > > >>>=20 > > >>> HTTPBis, part 7, section 2.3 [1] points to a link on the IANA = web site > > >>> which is dead [2]. I haven't found a new URL. Somebody knows if = this > > >>> page has moved somewhere else? > > >>=20 > > >> That link is dead because HTTPbis hasn't been through the entire = process yet; the IANA registries will be established later on. > > >>=20 > > >> Cheers, > > >>=20 > > >> -- > > >> Mark Nottingham http://www.mnot.net/ > > >>=20 > > >>=20 > > >>=20 > > >> _______________________________________________ > > >> foaf-protocols mailing list > > >> foaf-protocols@lists.foaf-project.org > > >> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols Social Web Architect http://bblfish.net/ --Apple-Mail=_F965823A-D684-4D52-8A97-DC6BDE9034AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
The issue of webid, browserid (and the 5 other latest = schemes doing the same thing) has become religious, at the cultish = level. One sees the cc: trick, as folks seek to make their case. To be = fair, browserid community is a bit more disciplined than others, on = keeping a lid on broadcast-based prosletizing.
 
All I see = is 5 new unverified schemes with about a max of 1000 users = each (mostly developers), vying for attention in the usual vendor space. = Each denies the legitimacy of the other, including such as gmail or = yahoo or openid or SAML or ws-fedp, or OAUTH, or OAUTH v2,  or = anything else. AS a consumer of such assertions, I reject any =  scheme  proposal IF IT HAS THAT POSTURE. The = posture means its too immature for adoption by the likes of us = (mainstream). We are really not interested in another Google = Wave.
 
There seems nothing to be done to stop the endless = pursuit of assertion protocols. Any scheme that half-works simply = induces a counter-scheme to become designed, as folks seek to impose = some or other twist on what MUST now be trusted. This seems to be = lobbyist-based, as some new infrastrcuture business sees $$ in = controlling user logon. For browserid, someone believes that only email = providers enable scalable verification. For our users , half of them use = gmail and gmail already does the equivalent of a browserid assertion and = validation. Its called openid v2. For me, its was trivial to integrate = openid (i.e. Google), as Microsoft's ACS ideneity gateway did 100% of = the work for us. Integrating microsoft gateway was pretty trivial, too. = It want hard to pursuade the security auditor that our work was = "reasonable."
 
If it helps, perhaps note that we are service = provider. We are logically an adoptee of schemes such as browser, = assuming they deliver a 100 million users to our door - since we need = the problem solved "at a national level". its just the nature of real = estate. We have even decided to get out of the login and = authentication business (after 40 years). Nothing helped make = anyone happy - despite having delivered password management, securid = tokencodes, phone-based SMS, passmark anti-fraud neural networks, and = even biometrics. We are even designed our own secure USB key, for a = while. No user community was/is happy. Every subgroup wants some = twist, to suit their personal hot button issue. The user community is = almost as fragmented as the vendor community. Of course, noone will pay = anything, as its someones else responsibility. Whats more (in our = unusual space), no ads are allowed - so even that funding trick is = unavailable. Folks cannot even trade off their privacy for free security = technology.
 
If anyone cares (and I rarely find folks in the = religious phase of a movement could give a damn, wanting only to preach = to those likely to be "converted") we have stopped accepting any of the = third-party schemes, unless its gatewayed to us by the Microsoft Azure = ACS service. Fpr the next year or two, they are the gatekeeper on the n = schemes, rewriting the n assertion blob formats into one. Its not that = there is anything special about the Microsoft Azure service to us, = other than its scheme agnostic. What it does is make identity = verification less of a "miserable affair", removing the posturing and = the carping that is getting in the way of delivering service = values.
 
Hope the feedback on the list's tone = helps.
 
> CC: bergi@axolotlfarm.org; julian.reschke@greenbytes.de<= /a>; http-auth@ietf.org; fielding@gbiv.com; foaf-protocols@lists= .foaf-project.org; public-xg-webid@w3.org; ietf-http-wg@w3.org; public-rww@w3.org
> = From: mnot@mnot.net
> Subject: Re: = [foaf-protocols] HTTP request header field for acceptable = authentication methods
> Date: Sat, 5 Nov 2011 12:55:26 = +1100
> To: home_pw@msn.com
> 
> Not sure why = you're asking me; perhaps the cc list needs to be trimmed? 
> 
> On 05/11/2011, at = 12:45 PM, Peter Williams <home_pw@msn.com> = wrote:
> 
> = > So what is webid vs webid-tls?
> > 
> > Does webid = tls exclude ssl v3?
> > 
> > I ask as only = very specific agendas call for the elimination of ssl v3. Only .001% of = the users know the difference, and less than half of those can = accurately state it.
> > 
> > 
> > On Nov 4, = 2011, at 2:28 AM, "Mark Nottingham" <mnot@mnot.net> wrote:
> = > 
> = >> 
> = >> On 04/11/2011, at 9:34 AM, bergi wrote:
> = >>> 
> = >>> Authentication Scheme
> >>> 
> >>> I was = thinking about this a little bit more and now I'm not sure if we
> = >>> should use WebID or WebID-TLS or even something else. =46rom = the
> >>> terminology point of view WebID-TLS would fit = better.
> >>> 
> >>> = HTTPBis, part 7, section 2.3 [1] points to a link on the IANA web = site
> >>> which is dead [2]. I haven't found a new URL. = Somebody knows if this
> >>> page has moved somewhere = else?
> >> 
> >> That link = is dead because HTTPbis hasn't been through the entire process yet; the = IANA registries will be established later on.
> >> 
> >> = Cheers,
> >> 
> >> = --
> >> Mark Nottingham http://www.mnot.net/
> = >> 
> = >> 
> = >> 
> = >> _______________________________________________
> = >> foaf-protocols mailing list
> >> foaf-protocols@lists= .foaf-project.org
> >> htt= p://lists.foaf-project.org/mailman/listinfo/foaf-protocols
_______________________________________________
foaf-protocols = mailing list
foaf-protocols@lists= .foaf-project.org
htt= p://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social = Web Architect
http://bblfish.net/

= --Apple-Mail=_F965823A-D684-4D52-8A97-DC6BDE9034AF-- From henry.story@bblfish.net Sun Nov 6 01:19:27 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 546A521F84B6 for ; Sun, 6 Nov 2011 01:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 L6KwB73OZwsG for ; Sun, 6 Nov 2011 01:19:26 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2D5921F8488 for ; Sun, 6 Nov 2011 01:19:25 -0800 (PST) Received: by wwi36 with SMTP id 36so3860537wwi.13 for ; Sun, 06 Nov 2011 01:19:24 -0800 (PST) Received: by 10.227.203.200 with SMTP id fj8mr27131185wbb.14.1320571163274; Sun, 06 Nov 2011 01:19:23 -0800 (PST) Received: from bblfish.home (AAubervilliers-651-1-244-93.w83-200.abo.wanadoo.fr. [83.200.75.93]) by mx.google.com with ESMTPS id eu16sm23218456wbb.7.2011.11.06.01.19.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 01:19:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4EB5D35A.6050101@axolotlfarm.org> Date: Sun, 6 Nov 2011 10:19:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EADC3F3.5000602@axolotlfarm.org> <4EAE6A0D.5040802@wp.pl> <4EB329CE.5000507@aist.go.jp> <4EB5D35A.6050101@axolotlfarm.org> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1251.1) Cc: WebID XG , julian.reschke@greenbytes.de Subject: Re: [http-auth] HTTP request header field for acceptable authentication methods 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: Sun, 06 Nov 2011 09:19:27 -0000 On 6 Nov 2011, at 01:22, bergi wrote: >>=20 >>=20 >> 2) Do we really need qvalue here? Or what q=3D0 suggests? >=20 > Maybe in combination with Basic it doesn't make sense, but a = user/robot > could have multiple decentralized identities with different protocols. > The server may not support all of them, but with the qvalue the client > could tell what's the protocol of the primary id. >=20 > Example with WebID (primary) + OpenID: > Accept-Authentication: WebID, OpenID;q=3D0.9 >=20 > In our particular case qvalue=3D1 could also mean that the server = should > ask for a certificate in "need-mode" otherwise in "want-mode". Some > client implementations don't handle the "want-mode" in the right way = and > don't even ask for a client certificate. In "need-mode" the client = must > provide a certificate otherwise the server closes the connection with = an > error. The "need-mode" should work with all implementations. I hasten to add that the NEED mode is the least user-friendly one, when = considering Human users. Humans can mistakenly click the cancel button, = and not send a certificate, thereby automatically breaking the = connection, which usually leaves the client showing a very ugly = UserInterface. Want mode is a lot more elegant. But we may have to live = for some time with clients that require NEED. It seems Java has this issue for example https://bugs.openjdk.java.net/show_bug.cgi?id=3D100213 And some versions of Safari also I seem to remember. Henry >=20 >>=20 >> Do you have some opinion about these? >>=20 >>=20 >> (*1) As far as several HTTP-Auth schemes are involved, the HTTP auth = framework >> allows servers to provide several possible schemes at once, and >> clients to choose the most strong one. However, I want to allow >> servers to check whether clients accepts my Mutual authentication = scheme, >> otherwise divert to Form authentication possibly for transition = purpose. >>=20 >> On 2011/10/31 18:27, Dominik Tomaszuk wrote: >>> On 30.10.2011 22:38, bergi wrote: >> (skipped) >>>> I propose to use a HTTP header field to >>>> tell the server that the client is able to authenticate with a = WebID. As >>>> such a field could be also useful for other authentication methods = I >>>> would chose a generic name. There are already some Accept-* fields = I >>>> would follow that pattern. As it's currently not a standard field I >>>> would prefix that field with X-. Multiple values must have the same >>>> format as defined for the Accept field. Also the quality parameter = must >>>> be handled by the server. >>>>=20 >>>> Example only with WebID authentication: >>>> X-Accept-Authentication: WebID >>>>=20 >>>> Example with WebID and Basic authentication: >>>> X-Accept-Authentication: WebID, Basic;q=3D0.9 >>>>=20 >>>> What do you think about my proposal? >>> It might be interesting to HTTPBis, part 7: Authentication [1] and = HTTPBis >>> Authentication Scheme Registrations [2] >>>=20 >>> [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16 >>> [2] = http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02 >>>=20 >>> Best, >>> Dominik 'domel' Tomaszuk >>>=20 >=20 >=20 Social Web Architect http://bblfish.net/ From stpeter@stpeter.im Mon Nov 14 16:52:31 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 6B0B811E80DC for ; Mon, 14 Nov 2011 16:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 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 CTPAd+7hYnds for ; Mon, 14 Nov 2011 16:52:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6011E80FB for ; Mon, 14 Nov 2011 16:52:27 -0800 (PST) Received: from dhcp-15ab.meeting.ietf.org (unknown [130.129.21.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 301DC4216E for ; Mon, 14 Nov 2011 17:58:39 -0700 (MST) Message-ID: <4EC1B7C9.2070403@stpeter.im> Date: Tue, 15 Nov 2011 08:52:25 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [http-auth] wiki page(s) 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, 15 Nov 2011 00:52:31 -0000 I've created a wiki page here: http://trac.tools.ietf.org/area/sec/trac/wiki/HttpAuthentication Feel free to create sub-pages about the problem space, possible solutions, conferences of interest, etc. Peter -- Peter Saint-Andre https://stpeter.im/ From yutaka@g.oiwa.jp Mon Nov 14 17:51:06 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 B703F11E81E8 for ; Mon, 14 Nov 2011 17:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tB4-wchv3rTh for ; Mon, 14 Nov 2011 17:51:06 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17AB411E8139 for ; Mon, 14 Nov 2011 17:51:05 -0800 (PST) Received: by ggnr5 with SMTP id r5so1804273ggn.31 for ; Mon, 14 Nov 2011 17:51:05 -0800 (PST) Received: by 10.101.47.10 with SMTP id z10mr7145060anj.124.1321321865503; Mon, 14 Nov 2011 17:51:05 -0800 (PST) Received: from ?IPv6:2001:df8:0:80:d8d8:1c4d:791:a686? ([2001:df8:0:80:d8d8:1c4d:791:a686]) by mx.google.com with ESMTPS id 33sm51549590ano.1.2011.11.14.17.51.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 17:51:04 -0800 (PST) Sender: Yutaka OIWA Message-ID: <4EC1C584.5040904@aist.go.jp> Date: Tue, 15 Nov 2011 10:51:00 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Peter Saint-Andre References: <4EC1B7C9.2070403@stpeter.im> In-Reply-To: <4EC1B7C9.2070403@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] wiki page(s) 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, 15 Nov 2011 01:51:07 -0000 Thank you, Peter! As a possible starting point, I've put a break-down version of the current problem statement text in the editable pages. We need more input, especially on existing authentication mechanisms. If you have any idea beyond the current list, please add these. On 2011/11/15 9:52, Peter Saint-Andre wrote: > I've created a wiki page here: > > http://trac.tools.ietf.org/area/sec/trac/wiki/HttpAuthentication > > Feel free to create sub-pages about the problem space, possible solutions, > conferences of interest, etc. > > Peter > -- 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[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From stpeter@stpeter.im Mon Nov 14 17:55:12 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 1A6AD11E827A for ; Mon, 14 Nov 2011 17:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 S3b0xSmHm7ZW for ; Mon, 14 Nov 2011 17:55:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AA01E11E8275 for ; Mon, 14 Nov 2011 17:55:11 -0800 (PST) Received: from dhcp-15ab.meeting.ietf.org (unknown [130.129.21.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DECD942170; Mon, 14 Nov 2011 19:01:22 -0700 (MST) Message-ID: <4EC1C67D.6@stpeter.im> Date: Tue, 15 Nov 2011 09:55:09 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Yutaka OIWA References: <4EC1B7C9.2070403@stpeter.im> <4EC1C584.5040904@aist.go.jp> In-Reply-To: <4EC1C584.5040904@aist.go.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] wiki page(s) 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, 15 Nov 2011 01:55:12 -0000 I have some notes about other possible solutions from a side discussion some folks had in Quebec City, but those are at home. I'll try to add them next week. On 11/15/11 9:51 AM, Yutaka OIWA wrote: > Thank you, Peter! > > As a possible starting point, I've put a break-down version of > the current problem statement text in the editable pages. > > We need more input, especially on existing authentication mechanisms. > If you have any idea beyond the current list, please add these. > > On 2011/11/15 9:52, Peter Saint-Andre wrote: >> I've created a wiki page here: >> >> http://trac.tools.ietf.org/area/sec/trac/wiki/HttpAuthentication >> >> Feel free to create sub-pages about the problem space, possible solutions, >> conferences of interest, etc. >> >> Peter >> From yutaka@g.oiwa.jp Mon Nov 14 18:04:44 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 A4A741F0CCB for ; Mon, 14 Nov 2011 18:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yXEVMN00fpWD for ; Mon, 14 Nov 2011 18:04:44 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC41F0CBF for ; Mon, 14 Nov 2011 18:04:43 -0800 (PST) Received: by vws5 with SMTP id 5so6855531vws.31 for ; Mon, 14 Nov 2011 18:04:43 -0800 (PST) Received: by 10.224.27.147 with SMTP id i19mr3712550qac.85.1321322683501; Mon, 14 Nov 2011 18:04:43 -0800 (PST) Received: from ?IPv6:2001:df8:0:80:d8d8:1c4d:791:a686? ([2001:df8:0:80:d8d8:1c4d:791:a686]) by mx.google.com with ESMTPS id fz9sm23181991qab.13.2011.11.14.18.04.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 18:04:42 -0800 (PST) Sender: Yutaka OIWA Message-ID: <4EC1C8B5.20101@aist.go.jp> Date: Tue, 15 Nov 2011 11:04:37 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <4EC1B7C9.2070403@stpeter.im> <4EC1C584.5040904@aist.go.jp> In-Reply-To: <4EC1C584.5040904@aist.go.jp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] wiki page(s) 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, 15 Nov 2011 02:04:44 -0000 I personally feel that I am mainly thinking about the open- and widely-deploying identity managements such as portal sites, banks, commerce, etc. Do we need some more input from closed- or tightly-managed identity set such as enterprise employee authentication/authorization using Kerberos-like? I believe that, although they share some aspects, they have much different requirements sets than the other use cases. Yutaka P.S. On 2011/11/15 10:51, Yutaka OIWA wrote: > As a possible starting point, I've put a break-down version of > the current problem statement text in the editable pages. I've written "I" above, but I'd actually like to acknowledge Boku and Kazuki for Wikifying the existing plaintext. Thanks! -- 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[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From stpeter@stpeter.im Mon Nov 14 18:06: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 CF3A31F0D0B for ; Mon, 14 Nov 2011 18:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 iqAMUkz+Fy3n for ; Mon, 14 Nov 2011 18:06:17 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBB31F0CBF for ; Mon, 14 Nov 2011 18:06:17 -0800 (PST) Received: from dhcp-15ab.meeting.ietf.org (unknown [130.129.21.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9CA014216E; Mon, 14 Nov 2011 19:12:28 -0700 (MST) Message-ID: <4EC1C917.2070207@stpeter.im> Date: Tue, 15 Nov 2011 10:06:15 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Yutaka OIWA References: <4EC1B7C9.2070403@stpeter.im> <4EC1C584.5040904@aist.go.jp> <4EC1C8B5.20101@aist.go.jp> In-Reply-To: <4EC1C8B5.20101@aist.go.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] wiki page(s) 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, 15 Nov 2011 02:06:18 -0000 On 11/15/11 10:04 AM, Yutaka OIWA wrote: > I personally feel that I am mainly thinking about the open- and widely-deploying > identity managements such as portal sites, banks, commerce, etc. > Do we need some more input from closed- or tightly-managed identity set > such as enterprise employee authentication/authorization using Kerberos-like? > I believe that, although they share some aspects, they have much different > requirements sets than the other use cases. Describing key use cases on the wiki sounds like a useful activity. :)