Re: [http-auth] WGLC on the MutualAuth drafts
Julian Reschke <julian.reschke@gmx.de> Sat, 18 June 2016 10:00 UTC
Return-Path: <julian.reschke@gmx.de>
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 56E0212D0BC for <http-auth@ietfa.amsl.com>; Sat, 18 Jun 2016 03:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA2xOwcIYW6n for <http-auth@ietfa.amsl.com>; Sat, 18 Jun 2016 03:00:06 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5069712B063 for <http-auth@ietf.org>; Sat, 18 Jun 2016 03:00:05 -0700 (PDT)
Received: from [192.168.178.20] ([93.217.113.121]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MCfcc-1b5zZD1kQc-009PUo; Sat, 18 Jun 2016 12:00:01 +0200
To: Yoav Nir <ynir.ietf@gmail.com>, httpauth mailing list <http-auth@ietf.org>
References: <2DBE893A-434D-4B67-BF12-AEFBDE7A23B7@gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <32b9df1f-b61d-405e-d935-5d964d9acbb6@gmx.de>
Date: Sat, 18 Jun 2016 11:59:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <2DBE893A-434D-4B67-BF12-AEFBDE7A23B7@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:zyvhzkEHhXwFdUezgIbsIBoxRk0JyGSqg52nNXRbPN762Ni7rDp nXvDTnq9Oh6SUMVdPUqYl2QhZQ+wrtHtFQN305MBei4/jMElsnbXZgYaJ8/wKqyAX6nq32i gOK/qPcflefU548EGaiaOsR+11Q1cCpXCf8EnKwjVBw6gaC2AGUHz6zdO5unRXTliZuTjPz GZi+5OggUyXpWMtcW2aYw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:sRYPb7zX9NI=:GSy7pW5MOwG+H36NowSODe pUj6qVAkFx7ss1BQVUWL/o56Uq4t5JUdIiRaHiO4CZOqqkw5ZX5qGN7Tg48uV0R1ri+G7WNMH /agMaU6LWeaBRzQXZYnfu0aZYjST4/nCGASKFgQdiSuDtE1VSXe9XdvifhgXzgv7VMg0JyqGE hDsEPEtcEyxxboj6Zi7eM9iTUnAkNMWrn7jHeoc1NOAfZUHyo6RlXSNyDGh82NM+Ha4T8Quxb 8Yazb6NifIbK9/oeuqloNwLFBstkA8Gf9LUJNcvK7HqJePNUkRnPGLkptB/hRofCTCMSfyduy ZEyTaqIqnd44Y5m+GwvEgiBzMbcX7LCt9/7EkDlrvoWbLLaKiefr5UsngCaxdIJ37unr9/tH7 8HXn7r7WQ8aEHLRlBms7XVH+y1aNJaV9YsVnuaLZNsjyZllvMx9T32vGrAxpOA/EFLPhYYopE m2yDqPbxtX3ymCz+GnFOnyP6MXjaNZpDA0qRxjiGzXJ2vcHxxNr62Fs3wsqOiu7dUCFlQZ5hz Jj4lLVUwinKxq4vOLmNUOAJg9GwZGmLMMY/d6CrBy/g6yTcIJCUljcJyk+bsEexFwHsVztdOE xsIZIggF1rDWfWFlxgDzmok9EWW85d9DK2Ji24VK0GWNWTs/nT00jeC1M6dqeVTtL+g+QRzCH b4xaJq05wqfabL8b6J0XgpsLbOj42ReKwxwlMAh68qdtdhe3OTmyWTAG1BgMN5f3BXG2IY/n5 kOI926orFtwvbNWs89ba/68NXrlgq+PCS/tKuXTPj15erXEa9+iH+6S5+j8K83BlPE69IoT90 22gSsjv
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/3IrGsN_0BAkDrCZWM020O_x4Bnc>
Subject: Re: [http-auth] WGLC on the MutualAuth drafts
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2016 10:00:10 -0000
Hi there, find below some unstructured (sorry for that) feedback on the extension draft. I believe this contains lots of interesting ideas, but it'll need more work on the details; in particular how to deploy it in practice (such as: do we need a way for clients to signal that they implement this spec?). Abstract This document specifies extensions of HTTP authentication framework s/of/for the/ for interactive clients. Recently, fundamental features of HTTP- Maybe: "currently"? level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing "by means like HTML forms" secure authentication mechanisms handled jointly by servers and user- agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility against existing Web and non-Web uses of HTTP authentications. s/against/with/ 1. Introduction The document proposes several extensions to the current HTTP "This document defines..." authentication framework, to provide functionality comparable with current widely-used form-based Web authentication. A majority of the recent websites on the Internet use custom application-layer authentication implementations using Web forms. The reasons for these may vary, but many people believe that the current HTTP Basic and Digest authentication methods do not have enough functionality (including good user interfaces) to support most realistic Web-based applications. However, this method is very weak against phishing and clarify "this method"... other attacks, because all behavior of the authentication is "...against attacks like phishing...." 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms "encouraged" and "advised" are used for suggestions that do not constitute "SHOULD"-level requirements. People MAY freely choose not to include the suggested items regarding [RFC2119], but complying with those suggestions would be a best practice; it will improve the security, interoperability, and/or operational performance. Not sure what the "regarding [RFC2119]" is about... 2. Definitions 2.1. Terms for describing authentication protocol flow HTTP Authentication defined in [RFC7235] may involve several pairs of HTTP requests/responses. Throughout this document, the following terms are used to categorize those messages: for requests, 1) A non-authenticating request is a request not attempting any authentication: a request without any Authorization header. s/header/header field/ (throughout) 3) A successfully-authenticated response is a response for an authenticating request meaning that the authentication attempt was granted. (Note: if the authentication scheme used does not use an Authentication-Info header, it may be indistinguishable from a non-authenticated response.) ...avoid lowercase BCP14 keywords (throughout). Here maybe s/may/can/. 5) A negatively-authenticated response is a response for an authenticating request which means that the authentication attempt was declined and can not continue without a different set of authentication credentials. Clients typically erase memory of the active credentials and ask the user for other ones. Usually the format of these responses are as same as the one for authentication-initializing responses. Client can distinguish s/Client/Clients/ negatively-authenticated responses from authentication- initializing responses by comparing the protection spaces contained in the request and in the response. Figure 1 shows a state diagram of generic HTTP authentication with the above message categorization. Note that many authentication schemes use only a subset of the transitions described on the diagram. Labels in the figure show the abbreviated names of response types. 2.2. Syntax Notation This specification uses an extended BNF syntax defined in [RFC7230]. s/BNF/ABNF/ Also, 7230 only defines extensions to 5234, so that should be referenced here as well. Additionally, this specification uses the following syntax definitions as a refinement for token and the right-hand-side of auth-param in [RFC7235]. (Note: these definitions are consistent with those in [I-D.ietf-httpauth-mutual].) bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") extension-token = "-" bare-token 1*("." bare-token) extensive-token = bare-token / extension-token integer = "0" / (%x31-39 *%x30-39) ; no leading zeros Figure 2: the BNF syntax for common notations Extensive-tokens are used in this protocol where the set of acceptable tokens may include private extensions. Any private extensions of this protocol MUST use extension-tokens with the format "-<token>.<domain-name>", where <domain-name> is a valid (sub-)domain name on the Internet owned by the party who defines the extension. a) it would be good to state how bare-token is different from token, and why it is needed. b) this introduces a syntax for private extensions that is awfully similar to the "x-" convention that we just deprecated a few years ago... 3. Optional Authentication The Optional-WWW-Authenticate header enables a non-mandatory authentication, which is not possible under the current HTTP authentication mechanism. In several Web applications, users can Insert paragraph break here. access the same contents as both a guest user and an authenticated user. In most Web applications, This functionality is implemented s/THis/this/ using HTTP cookies [RFC6265] and custom form-based authentication. The new authentication method using this message will provide a replacement for these authentication systems. Servers MAY send HTTP non-interim responses containing the Optional-WWW-Authenticate header as a replacement of a 401 response when it the response is authentication-initializing. The Optional-WWW-Authenticate header MUST NOT sent on 401 responses (i.e. a usual WWW-Authenticate header MUST be used on 401 responses.) HTTP/1.1 200 OK Optional-WWW-Authenticate: Basic realm="xxxx" Optional-WWW-Authenticate = 1#challenge Figure 3: BNF syntax for Optional-WWW-Authenticate header I'm not totally convinced that a new header field is needed here? Is there a reason why sending "WWW-Authenticate" with a 2xx response wouldn't work? (And yes, we probably discussed this several times already, but it would be good to summarize the outcome over here) The challenges contained in the Optional-WWW-Authenticate header are the same as those for a 401 responses corresponding to the same request. For authentication-related matters, an optional authentication request will have the same meaning as a 401 message with a corresponding WWW-Authenticate header (as an authentication- initializing response). (The behavior for other matters, such as caching, MAY be different between the optional authentication and 401 messages.) This "MAY" is really vague; the behavior needs to be spelled out completely, I think. Support of this header is OPTIONAL; Clients MAY also choose any set of authentication schemes for which optional authentication is supported (in other words, its support MAY be scheme-dependent). Hard to understand. Does this mean: "clients are free to implement this only for selected schemes"? However, some authentication schemes MAY require mandatory/ recommended support for this header, so that server-side applications MAY assume that clients supporting such schemes are likely to support the extension as well. "New authentication schemes though can make support of optional auth mandatory" ? 4. Authentication-Control header Authentication-Control = 1#Auth-Control-Entry Auth-Control-Entry = auth-scheme 1*SP 1#auth-control-param auth-control-param = extensive-token BWS "=" BWS token / extensive-token "*" BWS "=" BWS ext-value ext-value = <see RFC 5987, Section 3.2> Figure 4: the BNF syntax for the Authentication-Control header FYI: I'm in the process of revising RFC 5987, and that ABNF production is going to be removed. Seems we need to coordinate here. Among the multiple entries in the header, the meaningful entries in the header are those corresponding to an auth-scheme and a realm (if any), for which "the authentication process is being performed, or going to be performed". In more detail, (1) If the response is either an authentication-initializing response or a negatively-authenticated response, there may be multiple challenges in the WWW-Authenticate header (or the Optional-WWW-Authenticate header defined in this extension), each of which corresponds to a different scheme and realm. In this case, the client has a choice on the scheme and realm they will use to authenticate. Only the entry in the &Authentication-Control; header corresponding to that scheme and realm are meaningful. &Authentication-Control;? Also, maybe use "relevant" instead of "meaningful"? Each entry contains one or more parameters, each of which is a name- value pair. The name of each parameter MUST be an extensive-token. Clients MUST ignore any unknown parameters contained in this header. The entries for the same auth-scheme and the realm MUST NOT contain duplicated parameters for the same name. ...otherwise? Do we want to state what to do with invalid values? The type of parameter value depends on the parameter name as defined in the following subsections. Regardless of the type, however, the recipients SHOULD accept both quoted and unquoted representations of MUST... values as defined in HTTP. If the parameter is defined to have a string value, implementations SHOULD send the parameter in a quoted form or an ext-value form (see Section 4.1). If the parameter is Why, it it doesn't require quoting? defined as a token (or similar) or an integer, the value SHOULD follow the corresponding ABNF syntax after possible unquoting of the quoted-string value (as defined in HTTP), and SHOULD be sent in a unquoted form. Again, why? ...don't make requirements that do not help on the wire, and which make it harder to use generic libraries. Server-side applications SHOULD be aware that any parameters contained in this header MAY be ignored by clients. Also, even when What does it mean to "be aware" of it? Don't need a SHOULD here... a client accepts this header, users may always be able to circumvent s/may always be/are/ the semantics of this header. Therefore, if this header is used for security purposes, its use MUST be limited to providing some non- fundamental additional security measures valuable for end-users (such as client-side log-out for protecting against console takeover). Server-side applications MUST NOT rely on the use of this header for protecting server-side resources. +1. Note: The header syntax allows servers to specify Authentication- Control for multiple authentication schemes, either as multiple occurrences of this header or as a combined single header (see Section 3.2.2 of [RFC7230] for rationale). The same care as for parsing multiple authentication challenges SHALL be taken. s/SHALL/needs to/ 4.1. Non-ASCII extended header parameters Parameters contained in the Authentication-Control header MAY be extended to ISO 10646-1 values using the framework described in s/ISO 16046-1/non-ASCII/ [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded in [RFC5987] syntax. If a value to be sent contains only ASCII characters, the field MUST be sent using plain RFC 7235 syntax. The syntax as extended by RFC 5987 MUST NOT be used in this case. IMHO it would be better to use the ABNF terms instead of the RFC numbers here. If a value (except the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the ext-value syntax defined in Section 3.2 of [RFC5987]. Such a parameter MUST have a charset value of "UTF-8", and the language value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the used syntax. The "realm" parameter exception needs a rational. For example, a parameter "username" with value "Renee of France" SHOULD be sent as < username="Renee of France" >. If the value is "Ren<e acute>e of France", it SHOULD be sent as < username*=UTF- 8''Ren%C3%89e%20of%20France > instead. Unfortunate line breaking; I'd move the examples into <artwork> elements. 4.2. Auth-style parameter Authentication-Control: Digest realm="protected space", auth-style=modal (The above is an example, right? Maybe say so...). The default behavior for clients is implementation-dependent, and clients MAY choose different defaults for different authentication schemes. The proposed default behavior is "modal" for all authentication schemes, but specifications for authentication schemes MAY propose a different default. Do we really need to allow all this variation? The above two different methods of authentication may introduce a observable difference of semantics when the response contains state- changing side effects; for example, it may change whether Cookie s/may change whether/can affect how/ headers [RFC6265] in 401 responses are processed or not. However, the server applications SHOULD NOT depend on both existence and non- existence of such side effects. remove "and non-existence" 4.3. Location-when-unauthenticated parameter Authentication-Control: Mutual realm="auth-space-1", location-when-unauthenticated="http://www.example.com/login.html" (see above) The parameter "location-when-unauthenticated" specifies a location where any unauthenticated clients should be redirected to. This header may be used, for example, when there is a central login page for the entire Web application. The value of this parameter is a string that contains an absolute URL location. Senders MUST always send an absolute URL location. If a received URL is not absolute, the clients SHOULD either ignore it or consider it a relative URL from the current location. Too much variation. There's no reason to require an absolute URL here, in particular if we have a SHOULD-level requirement to accept relative references as well. This parameter MAY be used with a 401 response for an authentication- initializing response. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully-authenticated or intermediately-authenticated. The clients SHOULD ignore this parameter when a response is a negatively-authenticated one (the case is unlikely to happen, though). Is this really a SHOULD? When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication s/if/and if/ credentials, the client will treat the entire response as if it were a 303 "See Other" response with a Location header that contains the value of this parameter (i.e., client will be redirected to the specified location with a GET request). Unlike a normal 303 response, if the client can process authentication without the user's interaction, this parameter MUST be ignored. 4.4. No-auth parameter Authentication-Control: Basic realm="entrance", no-auth=true (see above) The parameter "no-auth" is a variant of the location-when-unauthenticated parameter; it specifies that new authentication attempts are not to be performed on this location in order to improve the user experience, without specifying the redirection on the HTTP level. This header may be used, for example, s/may/can/ when there is a central login page for the entire Web application, and when an explicit user interaction with the Web content is desired before authentications. The value of this parameter MUST be a token "true". If the value is incorrect, client MAY ignore this parameter. This parameter MAY be used with authentication-initiating responses. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully-authenticated or intermediately-authenticated. The clients SHOULD ignore this parameter when a response is a negatively- authenticated one (the case is unlikely to happen, though). (see above) When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication credentials, the client will ignore the WWW-Authenticate header contained in the response and treat the whole response as a normal negative 4xx-class response instead of giving the user an opportunity to start authentication. If the client can process authentication without the user's interaction, this parameter MUST be ignored. This parameter SHOULD NOT be used along with the location-when-unauthenticated parameter. If both were supplied, clients MAY choose which one is to be honored. This parameter SHOULD NOT be used as a security measure to prevent authentication attempts, as it is easily circumvented by users. This parameter SHOULD be used solely for improving user experience of Web applications. 4.5. Location-when-logout parameter Authentication-Control: Digest realm="protected space", location-when-logout="http://www.example.com/byebye.html" (see above) The parameter "location-when-logout" specifies a location where the client is to be redirected when the user explicitly requests a logout. The value of this parameter MUST be a string that contains an absolute URL location. If a given URL is not absolute, the clients MAY consider it a relative URL from the current location. (see above) This parameter MAY be used with successfully-authenticated responses. If this parameter is contained in other kinds of responses, the clients MUST ignore this parameter. When the user requests termination of an authentication period, and if the client currently displays a page supplied by a response with this parameter, the client will be redirected to the specified location by a new GET request (as if it received a 303 response). The log-out operation (e.g. erasing memories of user name, authentication credential and all related one-time credentials such as nonce or keys) SHOULD occur before processing a redirection. When the user requests termination of an authentication period, if s/if/and if/ the client supports this parameter but the server response does not contain this parameter, the client's RECOMMENDED behavior is as follows: if the request corresponding to the current content was safe (e.g. GET), reload the page without the authentication credential. If the request was non-idempotent (e.g. POST), keep the current content as-is and simply forget the authentication status. The Is it intentional that the alternatives are "safe" and "non-idempotent"? What about, for instance, about DELETE? client SHOULD NOT replay a non-idempotent request without the user's explicit approval. Web applications are encouraged to send this parameter with an appropriate value for any responses (except those with redirection (3XX) statuses) for non-GET requests. General comment: it makes me a bit uneasy that we define response header fields that essentially change the semantics t a redirect, without the status code saying so. There's a long history of redirect-related issues in browsers (such as what to change the method to, how to repeat them, what header fields to include etc), so adding a new way to redirect that doesn't look like a redirect might be a concern. 4.6. Logout-timeout parameter Authentication-Control: Basic realm="entrance", logout-timeout=300 (see above) 4.7. Username parameter Authentication-Control: Basic realm="configuration", username="admin" (see above) If the used authentication scheme requires a specific style of text preparation for the user name (e.g., PRECIS string preparation or Unicode normalization), the specified user name SHOULD follow such requirements. Needs references. Also: if the auth scheme has a "MUST" requirement wrt names, why would we only say "SHOULD" here? 5. Usage examples (informative) Drop "(informative)". That's implied by "examples". This section shows some examples for applying this extension to typical websites which are using Forms and cookies for managing authentication and authorization. The content of this section is not normative and for illustrative purposes only. We assume that all features described in the previous sections are implemented in clients (Web browsers). We also assume that browsers That's a bold assumption :-) will have a user interface which allows users to deactivate (log-out from) current authentication sessions. If this assumption is not value, the text below provides another approach with de- /not value/not valid/ I assume? authentication pages used instead of such a UI. 5.4. Parallel deployment with Form/Cookie authentications In some transition periods, sites may need to support both HTTP-layer and form-based authentication. The following example shows one way to achieve that. o If Cookies are used even for HTTP-authenticated users, each session determined by Cookies should identify which authentication has been used for the session. SHOULD? o First, set up any of the above settings for enabling HTTP-layer authentication. o For unauthenticated users, add the following things to the Web pages, unless the client supports this extension and HTTP-level authentication. * For non-mandatory authenticated pages, put a link to Form-based authenticated pages. * For mandatory authenticated pages, either put a link to Form- based authenticated pages, or put a HTML-level redirection (using META element) to such pages. http-equiv=refresh? If so, please say so. o In Form-based authenticated pages, if users are not authenticated, the page may have a diversion for HTTP-level authentication by "location-when-unauthenticated" setting. Diversion? o Users are identified to authorization and content customization by the following logic. * First, check the result of the HTTP-level authentication. If there is a Cookie session tied to a specific user, both should match. * If the user is not authenticated on the HTTP-level, use the conventional Form-based method to determine the user. * If there is a Cookie tied to HTTP authentication, but there is no corresponding HTTP authentication result, that session will be discarded (because it means that authentication is deactivated by the corresponding user). 7. IANA Considerations This document defines two new entries for the "Permanent Message Header Field Names" registry. +---------------------------+----------+----------------------------+ | Header Field Name | Protocol | Specification | +---------------------------+----------+----------------------------+ | Optional-WWW-Authenticate | http | Section 3 of this document | | Authentication-Control | http | Section 4 of this document | +---------------------------+----------+----------------------------+ This document also establishes a registry for HTTP authentication control parameters. The registry manages a case-insensitive ASCII strings. The string MUST follow the extensive-token syntax defined in Section 2.2. /manages a/manages/ To acquire registered tokens, a specification for the use of such tokens MUST be available as a publicly-accessible documents, as outlined as "Specification Required" level in [RFC5226]. Registrations for authentication algorithms are required to include a description of the control extension. New registrations are advised to provide the following information: Hmmm... Why are these code "algorithms"? That's very confusing. o Token: a token used in HTTP headers for identifying the algorithm. o Specification: A reference for a specification defining the algorithm. 8. Security Considerations All parameters in Authentication-Control header SHOULD NOT be used s/All parameters in/Parameters in the/ for any security-enforcement purposes. Server-side applications MUST always consider that the header may be either ignored by clients or even bypassed by users. Then it' a MUST NOT, no? Authors' Addresses ... Nit: an author should supply at least sufficient information so he/she can be contacted. Why no email addresses here? Best regards, Julian
- Re: [http-auth] RFC5987bis, was: WGLC on the Mutu… Yoav Nir
- [http-auth] RFC5987bis, was: WGLC on the MutualAu… Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts 大岩寛
- Re: [http-auth] WGLC on the MutualAuth drafts 大岩寛
- Re: [http-auth] WGLC on the MutualAuth drafts Yoav Nir
- Re: [http-auth] WGLC on the MutualAuth drafts Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts 大岩寛
- Re: [http-auth] WGLC on the MutualAuth drafts Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts 大岩寛
- Re: [http-auth] WGLC on the MutualAuth drafts Yoav Nir
- Re: [http-auth] WGLC on the MutualAuth drafts Yoav Nir
- Re: [http-auth] WGLC on the MutualAuth drafts Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts Yoav Nir
- Re: [http-auth] WGLC on the MutualAuth drafts Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts 大岩寛
- Re: [http-auth] WGLC on the MutualAuth drafts Julian Reschke
- Re: [http-auth] WGLC on the MutualAuth drafts 大岩寛
- [http-auth] WGLC on the MutualAuth drafts Yoav Nir
- Re: [http-auth] RFC5987bis, was: WGLC on the Mutu… 大岩寛