test-suite
test-suite copied to clipboard
solid-contrib
DPoP `ath` claim check
As described in #150, there is a new version of the DPoP spec, so we need to update how our test suites make requests to storage servers.
In the jest-based tests (solid-crud-tests, web-access-control-tests, webid-provider-tests) this probably means we'll have to switch away from solid-auth-fetcher. I'll try to find time to look into that.
@edwardsph which version of the DPoP spec does the harness follow, and/or is that configurable?
We mainly ran into this one (@ylebre told me): https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-11#section-4.3
- if presented to a protected resource in conjunction with an access token,
- ensure that the value of the ath claim equals the hash of that access token,
- confirm that the public key to which the access token is bound matches the public key from the DPoP proof.
We updated to require the presence of the ath claim in the dpop proof, after which the tests started failing. it seems that the solid-auth-fetcher code does not add the ath claim to the proof, which was valid for dpop 01 but no longer the case with 04 and 11.
Ah ok sorry, I missed this point in 04:
- when presented to a protected resource in conjunction with an access token, ensure that the value of the ath claim equals the hash of the access token that has been presented alongside the DPoP proof.
So it was already required in 0.9.0. I'll fix it!
I'm working on the following labelling of spec versions:
roughly-0.8("deprecated", was never really pinned unambiguously)Dec-2019("old", pinned on 17 December 2019)v0.9.0("current", pinned on 17 December 2021)vNext("latest")
This ticket is for switching from solid-auth-fetcher to a new client lib that send the right ath claim, and then also adding tests (I think they would belong in solid-crud-tests) that check how a server reacts to incorrect or missing ath claims.