Subject: [http-auth] WWW-Authenticate for 200 Response Codes

From: Gary Mort <[email-masked]>
Date: Mon, 12 May 2014 15:43:42 -0400

As I read the WWW-Authenticate specs, they /may/ be sent for status 
codes other then 401.

An example usage that may be useful for some applications:

WWW-Authenticate: TOTS realm="www.example.com", totosforms="formname", totsfield="fieldname"
WWW-Authenticate: COOKIE realm="www.example.com", cookie="cookiename"

Using a scheme such as this, were various authentication methods are set, it would then be possible for custom extensions in web clients to support more user friendly logon procedures.

To further the example, the use of TOTS today is disruptive for the end user, they must not only enter their userid and password to logon, but afterwards submission they will be prompted to enter a TOTS code before being allowed to log on.

If a website advertises TOTS support for all requests where the user is not logged on, then it would be possible for the client to automatically query any connected TOTS devices and automatically fill in the totsfield when a logon form is submitted.  TOTS devices which require manual intervention at the least prompt the user to retrieve that data before logging on.

By the same token, session cookie names tend to be rather opaque for end users, so users who choose not to allow cookies without their explicit permission are innundated with opaque prompts.   By specifying that authentication is via a cookie, and specifying the name of that cookie, clients could provide clearer information to end users.  IE instead of a message like "Do you wish wwww.example.com to be allowed to set the PHPSESSID cookie" they could provide clarity with a message such as "Do you wish wwww.eample.com to be allowed to set the visitor tracking cookie PHPSESSID"

In any case, I am not specifically promoting these particular extensions - I simply wish to verify that this type of usage is implicitly supported in the current standards.   The primary benefit of doing this with multiple headers is that it current browsers "support" this implementation in that for 401 responses, it is the last header which is used - so WWW-Authenticate: digest... can be placed last and the browser will default to using it - while extensions have events available so they can override the default behaviour based on the existence of additional headers.

-Gary

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 May 2014 21:50:58 +0200

> In any case, I am not specifically promoting these particular extensions - I simply wish to verify that this type of usage is implicitly supported in the current standards.   The primary benefit of…

Although this is the "http-auth" mailing list, you're in the wrong 
location. "http-auth" is about defining specific auth schemes.

What's relevant here is the authentication *framework*, and that is 
defined in the httpbis specs, in particular 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-26.html>, 
to be published as RFC really soon now.

Best regards, Julian

---

From: Gary Mort <[email-masked]>
Date: Tue, 13 May 2014 12:53:03 -0400

> to be published as RFC really soon now.

Thanks  - sorry for the confusion and I will redirect my query.

I was playing around with exploring some of the some less well know HTTP 
Auth features recently which led me to this working group - not meaning 
to tred on any toes, I just wanted to confirm my own understandings as 
well as to comment on some of the sections where I found confusion in 
various attempts to implment it via PHP since some versions of IIS and 
some other servers did expect nonce-prime but instead expected the 
current nonce to be used.

The current wording seemed fairly unambigous to me - but if it can be 
made clearer then it saves me time in the future when dealing with 
integration. :-)

-Gary