Update to DPoP specification v08

[dteleguin]

Recent DPoP spec updates introduce some changes that could be relevant for Solid-OIDC. I'd suggest that we update the DPoP-related parts of the spec and the primer in order to reflect those changes (most importantly server-supplied nonces); the links should be updated to -08 as well.

dpop_jkt request parameter

This parameter could be used to enforce end-to-end binding (from authorization code to the resulting tokens). See 10. Authorization Code Binding to DPoP Key

Use of this parameter is OPTIONAL.

Server-provided nonces

The concept of server-provided nonces is introduced as an alternate (and potentially more efficient) mechanism to limit the lifetime of DPoP proofs. See 8. Authorization Server-Provided Nonce

It's up to the authorization server implementation whether to support nonces, but the client support is MANDATORY; otherwise the client simply won't be able to talk to the server that employs nonces. The same is valid for the resource server supplied nonces (Section 9).

dpop_bound_access_tokens client registration parameter

As we're relying on DPoP-bound ID tokens (rather than access tokens) and we're using scope="... webid" to indicate this (see #168), the use of dpop_bound_access_tokens client registration parameter is not necessary.

[acoburn]

the links should be updated to -08 as well

The Solid-OIDC specification does not refer to a particular DPoP draft version. Unless the section numbering has changed (it as not IIRC), there is no change needed.

dpop_jkt request parameter

This is an optional parameter under DPoP. Unless this is required under Solid-OIDC (it is not), there is no need to refer to it.

Server-provided nonces

Any requirements from DPoP are also requirements from Solid-OIDC. There is no need to restate what is already present in the DPoP draft specification.

the use of dpop_bound_access_tokens client registration parameter is not necessary.

I disagree. This is how a client can indicate that DPoP is required rather than opt-in on the part of a client.

[dteleguin]

I disagree. This is how a client can indicate that DPoP is required rather than opt-in on the part of a client.

It is correct that we need to somehow indicate DPoP requirement. The issue is that, as per recent Solid-OIDC, we do not require DPoP-bound access tokens anymore. Instead, we require DPoP-bound ID tokens, which is something purely specific to Solid-OIDC and has no equivalent of dpop_bound_access_tokens. Thus, it was suggested that we use scope="... webid" for the same.

[acoburn]

It is correct that we need to somehow indicate DPoP requirement

The DPoP requirement is a requirement on the Server. It is indicated via the .well-known/openid-configuration metadata. A client opts into that requirement by presenting a valid DPoP header at the token endpoint (or by initiating the authorization code flow with a dpop_jkt at the authorization endpoint).

The client registration (whether via DCR or Client Identifier) indicates a requirement on DPoP with the dpop_bound_access_tokens property.