Re: WWW-Authenticate with webauthn?

["Soni L." <[e-mail]>]

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.