Decide on header/mechanism for reporting auth metadata for a Solid pod (RS) about authentication-panel HOT 7 OPEN

The consensus from the 2019-10-21 Authentication panel meeting was:

1. Yes, we should use the WWW-Authenticate response header as the designated mechanism for a Resource Server to communicate which authentication method that server is using.
2. The registry of supported methods should live in the top-level Solid spec. (With the understanding that the initial 1.0 spec version will support just one mechanism.)

from authentication-panel.

I think the question still remains (which I forgot to bring up in the meeting):

Which attribute of the WWW-Authenticate header do we use to communicate the authentication mechanism a server is using?

Currently, Node Solid Server is using the scope attribute, where scope="openid webid" means "WebID-OIDC".

Are folks ok continuing to use that attribute?

from authentication-panel.

Well according to the Mozilla document on WWW-Authenticate,

WWW-Authenticate: <type> realm=<realm>

you use the type to specify the types of authentication methods allowed. They list an IANA registry of those.

My guess is that if the server wants to offer a number of different methods, it should send a number of WWW-Authenticate headers. I am not sure where the scope keyword comes from.

from authentication-panel.

WWW-Authenticate: Bearer scope="tls webid", realm="whatever"

is improper, because it has nothing to do with OAuth2-style bearer tokens. a different auth-scheme should have been used for this case, like

WWW-Authenticate: WebID-TLS realm="whatever"

if we're going to document deprecated legacy behavior that was deployed, putting the Bearer scope="tls webid" in a registry somewhere is fine and all, but if we wanted to be serious about WebID-TLS again, transitioning to a different auth-scheme would be more appropriate.

while we're at it, i've always had a problem with using the Bearer auth-scheme for the current POPToken scheme, since POPTokens, being manufactured by the client instead of being issued to the client by the RS's authorization server (#1, #12), aren't in the spirit of OAuth2 bearer tokens (that is, they're as much a "bearer token" as the Base64(username ":" password) of HTTP Basic Auth). in an ideal world, a different auth-scheme would have been used for this too, like

WWW-Authenticate: Solid-POPToken realm="whatever"

from authentication-panel.

@zenomt All good points. The scope="tls webid" was just a historical solid-auth-client implementation note; not intending to carry it forward.

from authentication-panel.

i've always had a problem with using the Bearer auth-scheme for the current POPToken scheme

DPoP draft intends to register DPoP token type for Bearer authentication scheme
https://github.com/danielfett/draft-dpop/blob/master/mainmatter.md#oauth-access-token-type-registration

OAuth Access Token Type Registration

This specification registers the following access token type in the
OAuth Access Token Types registry defined in [RFC6749].

• Type name: "DPoP"
• Additional Token Endpoint Response Parameters: (none)
• HTTP Authentication Scheme(s): Bearer
• Change controller: IETF

• Specification document(s): [[ this specification ]]

Also in Justin's book I've noticed use of PoP
https://livebook.manning.com/book/oauth-2-in-action/chapter-15/36

HTTP POST /foo
Host: example.org
Authorization: PoP eyJhbGciOiJSUzI1NiJ9.eyJhdCI6ICI4dXloZ3Q2Nzg5MDQ5...

Not sure how those two registries supposed to work together

• https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml
• https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types

If we use authentication scheme in WWW-Authenticate header, we can't really communicate token type. Possibly related to mentioned tendency to conflate authentication and authorization.

from authentication-panel.

@elf-pavlik Ahhh yeah, ok, you're right, the DPoP draft spec does specify using 'DPoP' as the Authentication scheme.

So then we'll use as a response header:

WWW-Authenticate: DPoP realm="<optional realm>" scope="openid webid"

to indicate that the RS supports the DPoP presentation mechanism.

from authentication-panel.