Technical Objections and Concerns with Proposed DPoP + VC Scheme

While a new authentication scheme using DPoP and Verifiable Credentials may technically still be a proposal, it has the outward appearance of a foregone conclusion. I have serious reservations and technical objections regarding the use of DPoP in a Solid authentication scheme, as well as concerns about proposed changes to OpenID Connect. I believe a different approach (for example, #12) is a better fit for Solid.

Problems with DPoP

draft-fett-oauth-dpop is not a "draft recommendation released by IETF"; in fact it has no formal status. It is an independent submission by its authors, is not a Working Group item (especially not the OAuth Working Group), and is not currently on a track to (eventually) represent a consensus of the IETF. An Internet-Draft is especially NOT a means of "publishing a specification" -- see Section 2.2 of RFC 2026 (BCP 9) for more specific information regarding the disposition of Internet-Drafts.
The syntax of DPoP inflates HTTP request headers with at least one extra JWT comprising at least hundreds of bytes. Because each request must have a fresh and unique proof-of-possession, this header is not compressible with HTTP/2 header compression. Transporting this extra data wastes natural resources (time and energy) and money. This waste will add up if Solid becomes widely used. Alternatively, OAuth2 bearer tokens can be compact (as an implementation detail of the Authorization Server), and can be compressed in HTTP/2 when reused for multiple requests.
DPoP requires expensive public-key cryptographic operations on every request by the client (signing) and server (verifying) even for multiple requests between the same client and server. This wastes natural resources and money. This requirement may be burdensome for resource-constrained clients (such as low-power or very slow devices). Alternative proposals employing proof-of-possession constructions can amortize the cost of signing and verifying over multiple requests between the same client and server.
Requiring a unique jti for every request (as a cornerstone of DPoP's security model) places an unreasonable burden on servers that must keep track of them, and complicates horizontal scaling of servers.
The unique jti chosen by the client, while it protects against replay, doesn't address the "happens-after guarantee of current possession" reason why you want to challenge a party to sign a nonce chosen by you (to exclude precomputation by an adversary).
DPoP is designed to address a very specific, non-Solid threat/usage model, where an AS issues an opaque-to-client access token to the client, for use with a confederation of Resource Servers that trust the AS but not each other (that is, where a Resource Server can be an adversary to another Resource Server in the confederation). As such, many of the semantics of DPoP are unnecessary for Solid, and its syntax and operational requirements are needlessly expensive.

Problems with OpenID Connect Provider Requirements

To encourage adoption of Solid authentication, ad hoc changes to OIDC (and especially compatibility-breaking changes and changes that will require more than trivial modifications to existing servers) should be minimized.

Optional Client Registration

I don't think optimizing or eliminating Dynamic Client Registration is a problem that needs to be solved for (and especially by) Solid. If there is a belief that this is really a problem, it should be taken up in OIDC, to be debated and resolved by competent experts there.

Concerns over OIDC Implicit Flow

If there are concerns with using the OIDC Implicit Flow, they should be taken up in the processes of OIDC, to be debated and resolved by competent experts there. For the greatest compatibility with OIDC Providers, Solid specs should instead recommend following the latest guidance from OIDC regarding login flow security, perhaps recommending (but not requiring) not using the Implicit Flow with sufficient and compelling justification.

Verifiable Credential in ID Token

The Verifiable Identity Credential is substantially just an ID token with a confirmation key. Unless divulging the client's client_id to a 3rd party Resource Server is a major problem, I think that merely requesting inclusion of a cnfirmation key in the id_token is a simpler ask for OpenID Connect Providers to implement, and in combination with the sub being the WebID and the App ID being in the aud, is sufficient. That being said, computation and delivery of a distinct (if substantially the same) VC is probably not insurmountably burdensome.

If there is to be a distinct Verifiable Identity Credential, then since it must be independently verifiable anyway, it should be in a separate OP response attribute, rather than be embedded as a claim in the id_token. This is congruent with the current syntax of OIDC responses. Additionally, having it separate is more compact to transmit to the client (especially as an attribute of a URL fragment identifier) since making it a claim in the id_token will incur an additional Base64 encoding with corresponding expansion.

Additionally, having it separate is more compact to transmit to the client (especially as an attribute of a URL fragment identifier) since making it a claim in the id_token will incur an additional Base64 encoding with corresponding expansion.

Does it only apply to Implicit Flow?

Does it only apply to Implicit Flow?

no matter how the tokens are transmitted to the client, having the VC token outside the id_token is more compact, since an extra base64 expansion is avoided.

update: as of april 1 2020, DPoP was adopted as a Working Group document in the IETF OAuth Working Group: https://mailarchive.ietf.org/arch/msg/oauth/opBHFtVkYSo1gJwyXWfpYZMDKjg/ . the draft is now draft-ietf-oauth-dpop.

i note in the OAuth WG mailing list there is concern and discussion along very similar lines to some concerns i raised in this issue, including "signing and checking every request, and tracking JTIs, might be too expensive" and "what exactly is the threat model anyway?" and "what is this for exactly?". participants in the WG, including the authors, note that there is still much work to do on this.

Below are some remarks from @acoburn on this issue. I've edited it a bit to keep up with the conversation:

draft-fett-oauth-dpop is not a "draft recommendation released by IETF"; in fact it has no formal status. It is an independent submission by its authors, is not a Working Group item (especially not the OAuth Working Group), and is not currently on a track to (eventually) represent a consensus of the IETF. An Internet-Draft is especially NOT a means of "publishing a specification" -- see Section 2.2 of RFC 2026 (BCP 9) for more specific information regarding the disposition of Internet-Drafts.

Given the adoption on April 1st, I'd say we can focus on the other issues. Thanks for updating us on that.

The syntax of DPoP inflates HTTP request headers with at least one extra JWT comprising at least hundreds of bytes. Because each request must have a fresh and unique proof-of-possession, this header is not compressible with HTTP/2 header compression. Transporting this extra data wastes natural resources (time and energy) and money. This waste will add up if Solid becomes widely used. Alternatively, OAuth2 bearer tokens can be compact (as an implementation detail of the Authorization Server), and can be compressed in HTTP/2 when reused for multiple requests.

In the grand scheme of things, the extra header size is quite small when compared to the mass amounts of data that come across the wire in Solid as RDF ecosystems are very network intensive. Additionally, there are more ways to keep headers compact. HTTP2 offers header compression or if you use elliptic curves, you can compress the token size even more.

DPoP requires expensive public-key cryptographic operations on every request by the client (signing) and server (verifying) even for multiple requests between the same client and server. This wastes natural resources and money. This requirement may be burdensome for resource-constrained clients (such as low-power or very slow devices). Alternative proposals employing proof-of-possession constructions can amortize the cost of signing and verifying over multiple requests between the same client and server.

Signing is a very lightweight process. Could you link the alternate proposal for employing proof-of-possession?

Requiring a unique jti for every request (as a cornerstone of DPoP's security model) places an unreasonable burden on servers that must keep track of them, and complicates horizontal scaling of servers.

It is optional per the DPoP spec (See section 9.1). Yes, it complicates the horizontal scaling of servers, though it's also not terribly difficult to implement.

The unique jti chosen by the client, while it protects against replay, doesn't address the "happens-after guarantee of current possession" reason why you want to challenge a party to sign a nonce chosen by you (to exclude precomputation by an adversary).

Could you provide more details? Are you proposing adding a nonce to the flow?

DPoP is designed to address a very specific, non-Solid threat/usage model, where an AS issues an opaque-to-client access token to the client, for use with a confederation of Resource Servers that trust the AS but not each other (that is, where a Resource Server can be an adversary to another Resource Server in the confederation). As such, many of the semantics of DPoP are unnecessary for Solid, and its syntax and operational requirements are needlessly expensive.

While it's true that DPoP was not designed for Solid's exact use case, there is a lot of value gained by evolving DPoP. If Solid creates its own sui generis authentication mechanism, then Solid simultaneously isolates itself from the rest of the world. Instead, we should be making use of existing mechanisms and standards so that we can interoperate with the existing identity ecosystem.

Problems with OpenID Connect Provider Requirements To encourage adoption of Solid authentication, ad hoc changes to OIDC (and especially compatibility-breaking changes and changes that will require more than trivial modifications to existing servers) should be minimized.

The only compatibility-breaking change is adding the webid claim to the token (or making the subject claim a URL). Everything else is layered on top in a non-breaking way.

Optional Client Registration I don't think optimizing or eliminating Dynamic Client Registration is a problem that needs to be solved for (and especially by) Solid. If there is a belief that this is really a problem, it should be taken up in OIDC, to be debated and resolved by competent experts there.

It's very possible that this sentiment will make it into the final version of our spec. So, no objections here.

Concerns over OIDC Implicit Flow If there are concerns with using the OIDC Implicit Flow, they should be taken up in the processes of OIDC, to be debated and resolved by competent experts there. For the greatest compatibility with OIDC Providers, Solid specs should instead recommend following the latest guidance from OIDC regarding login flow security, perhaps recommending (but not requiring) not using the Implicit Flow with sufficient and compelling justification.

The OIDC Implicit flow has been taken up by the OIDC community. It is generally recommended that people avoid this.

Verifiable Credential in ID Token The Verifiable Identity Credential is substantially just an ID token with a confirmation key. Unless divulging the client's client_id to a 3rd party Resource Server is a major problem, I think that merely requesting inclusion of a cnfirmation key in the id_token is a simpler ask for OpenID Connect Providers to implement, and in combination with the sub being the WebID and the App ID being in the aud, is sufficient. That being said, computation and delivery of a distinct (if substantially the same) VC is probably not insurmountably burdensome.

The ID token is not meant to be sent to a resource server. The use of VC allows a client to use part of the ID token. Alternatively, a client could use the auth token, but that has a different set of spec-level challenges. Using the vc_id claim is a reasonable compromise

HTTP2 offers header compression or if you use elliptic curves, you can compress the token size even more.

HTTP/2 header compression (HPACK) can only "compress" a header that's identical to one from a previous request. a JWT DPoP token with an elliptic curve signature will be on the order of 500 bytes at minimum , which is 1/3 of the "MTU of the Internet" (1500 bytes, also over 1/3 of the TCP MSS). when talking about making multiple simple requests from the client to the server, where the requests vary only in the path being GET-ed, you're talking dozens of bytes with a repeated bearer token vs hundreds of bytes with DPoP, per request.

Could you link the alternate proposal for employing proof-of-possession?

see #12 which links to my concrete proposal.

It is optional per the DPoP spec (See section 9.1). Yes, it complicates the horizontal scaling of servers, though it's also not terribly difficult to implement.

the link provided is to the pre-adoption individual draft. the current link is Section 9.1. note that attending to the jti on the server is not "optional"; it is a normative "SHOULD", and has security implications for treating it as "optional". that being said, the real world threat addressed by jti in a DPoP token isn't actually a practical concern (that is, intercepting a DPoP token and replaying it to the same audience). what DPoP's iat and jti don't do at all is actually demonstrate a current proof of possession of the POP key. a DPoP token could have been manufactured arbitrarily far in the past and held in stock for use at a particular time. only signing a value supplied by the server (specifically, a true nonce) can prove current possession.

Could you provide more details? Are you proposing adding a nonce to the flow?

among other things, yes. splitting hairs: note that a "nonce" can only be used once; to avoid rechallenging every request, for DPoP there would need to be a "challenge" from the server that could be used more than once, rather than a "nonce" that could only be used once. the important thing is that it's chosen by the server.

Instead, we should be making use of existing mechanisms and standards so that we can interoperate with the existing identity ecosystem.

notwithstanding DPoP is not presently a standard, the only thing substantially being taken from it for Solid is its syntax. semantically its use in Solid is equivalent to today's Solid "POPToken", only with a bigger representation and more expensive processing requirements. DPoP's semantics includes that the "sender-constrained access token" came from an authorization server with standing to issue such a token for the resource server.

see #12 which links to my concrete proposal

my "concrete proposal" is a webid/webid-oidc/webid-tls specific application of draft-thornburgh-fwk-dc-token-iss-00 (datatracker)

The objections here have been noted, but Solid-OIDC specification is built centrally around DPoP.

solid / authentication-panel