Decide on header/mechanism for reporting auth metadata for a Solid pod (RS)

[dmitrizagidulin]

As both the authentication and authorization/acl systems for Solid evolve, it would be helpful to standardize on (and document) some way to inform clients as to which system (and spec version) a particular storage pod (Resource Server, in oauth2 terms) is running.

For example, currently, we use the scope param of the WWW-Authenticate response header, to help solid-auth-client figure out which auth mode a Solid server is running in (WebID-TLS-only, or WebID-OIDC).

So, for node-solid-servers running in WebID-OIDC mode, on a 401 Unauthorized response, the server returns the following header:

WWW-Authenticate: Bearer realm="<pod serverUrl>", scope="openid webid"

The scope maps to, roughly:

• openid webid === WebID-OIDC mode
• tls webid === legacy WebID-TLS-only mode

(This was included to help solid-auth-client decide on how to interface with the server).

So, we have several questions before us:

• Should we have a mechanism that denotes which authentication / authorization system and version a Solid server is running?
• What should that mechanism be? (Typically, this is done via the WWW-Authenticate response header, so if we continue going with that, what should the parameter be?)
• The WWW-Authenticate header spec tends to conflate authentication and authorization mechanisms into one -- how do we separate the two? (The authorization mechanism does not need to be communicated.)
• Where should we keep a registry of the various supported systems / spec versions?

[dmitrizagidulin]

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.)

[dmitrizagidulin]

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?

[bblfish]

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.

[zenomt]

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"

[dmitrizagidulin]

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

[elf-pavlik]

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.

[dmitrizagidulin]

@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.