W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: WWW-Authenticate with webauthn?

From: Soni L. <fakedme+http@gmail.com>
Date: Mon, 17 May 2021 07:59:39 -0300
To: Rafal Pietrak <rafal@ztk-rp.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <13d0197f-3ea8-d9bf-73cf-f3dad2599b7c@gmail.com>

On 2021-05-17 4:00 a.m., Rafal Pietrak wrote:
> Hello,
> W dniu 17.05.2021 o 06:00, Soni L. pisze:
> > Are there any plans to support WWW-Authenticate with webauthn? (ideally
> > only once per session, so something like a timeout=0 flag and converting
> > the authentication into a session cookie would probably be needed.)
> > 
> Pls forgive MHO - I'm not an active participant in IETF works/groups.
> I'm just an occasional web service developer. Keeping that in mind (IMHO):
> 1. I perceive WWW-Authenticate useful only in rare cases when developer
> does not particularly care about authentication, AND does not intend to
> put any effort into it (and into future account maintenance) ... BUT
> needs to protect the content somehow. BASIC authentication (and
> variants) is then the primary choice.
> 2. (IMHO) in grand majority of other cases, web designer prefers to
> provide it's own "login page", one that have required features (like
> registration, or password reset) and one that is aesteticly coordinated
> with remaining service content. Such page comes from web-server, not
> like WWW-Authenticata, being provided by local web-browser.
> 3. www-Authenticate could possibly be useful in cases of
> proxy-authenticate. In those cases one may assume, that one server (the
> proxy server) is in administrative domain separate from the other server
> (the web-application server) administrative domain. In such cases,
> points from (2) above does not apply, so web-browser provided
> authentication panel may be useful.
> I'm no authority here, but I personally would avoid putting much effort
> into web-browser support for (browser locally generated) authentication
> "panels", which would translate authentication values into
> authentication HTTP headers being supplied transparently by the browser
> into all HTTP requests, the browser makes.
> Still, as you mentioned, www-authenticate would eventually need to be
> conveyed into cookies or something.
> IMHO, this should rather turn design efforts into cookie definition
> itself, aiming towards giving web designer the best possible tool for
> every use scenario (that web designer may need for it's implementation).
> That's why I'd like to ask you all to consider discussion (towards
> acceptance/ improvement/ ... or an EXPLICIT decline, if proved to be
> "unreperrable") of my recently updated proposal regarding additional
> attribute for cookies:
> https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/
> With best regards,
> R

This perception of WWW-Authenticate is frankly dangerous. Webforms are
vulnerable to Logger.debug(password) whereas many WWW-Authenticate
methods aren't (basic notwithstanding). There are even PAKE-based
methods like RFC 8120 which provide additional features beyond simple
authentication, but I digress.

But, please stop bringing up your proposal in replies to my posts.
Received on Monday, 17 May 2021 10:59:56 UTC

This archive was generated by hypermail 2.4.0 : Monday, 17 May 2021 10:59:59 UTC