solid
Update to DPoP specification v08
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.
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.
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.
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.