DPoP Validation

[elf-pavlik]

Current draft states:

The encoded HTTP response and resource URL of the DPoP token MUST be dereferenced and matched against the original request in the Access Token.

I fail to understand what exact steps it requires. Does resource URL of the DPoP token refer to htu claim in DPoP Proof? What does original request in the Access Token mean?

Possibly strictly using terminology

• DPoP Proof
• DPoP-bound Access Token

And specific JWT claims could help to eliminate any confusion arising.

[EndlessTrax]

You are correct, this should say DPoP proof. I will rewrite this to make it clearer, and include a little more detail around the htu claim to remove any confusion. Thanks.

[EndlessTrax]

The changes we are making as per Issue #57 supersede this. This sentence has now been removed entirely.

[elf-pavlik]

Thank you. I see that current version includes following sentence:

If either the DPoP token has expired, or either the URL and the HTTP method does not match that of the resource requested in the Access Token, then the RS MUST deny the resource request.

A DPoP-bound Access Token does not include htm and htu claims, which are defined for DPoP Proof. I would suggest removing that sentence all together or updating it to following version:

If either the DPoP-bound Access Token has expired, or either the URL and the HTTP method in DPoP Proof does not match that of the HTTP request made by the client, then the RS MUST deny the resource request.

[EndlessTrax]

Sorry, that should read DPoP Proof, not DPoP Token. I said I would fix that in the update but looks like I overlooked it. Apologies.

[EndlessTrax]

It also occurs to me we don't have DPoP Proof in the terminology section. This should be added.

[elf-pavlik]

👍 to remove the sentence

otherwise we should clarify that it doesn't add anything beyond what DPoP already mandates.

[elf-pavlik]

@acoburn suggested to specify that if cfn claim is present RS should perform DPoP Validation. I think this may also affect Resource Access section currently only stating:

Ephemeral clients MUST use DPoP-bound Access Tokens, however, the RS MAY allow registered clients to access resources using a traditional Bearer tokens.

It may help to mandate that: If IdP included cnf claim in Access Token, client MUST use DPoP for request where this token is used.

[EndlessTrax]

Latest commit on this section -- https://github.com/solid/authentication-panel/commit/493440ed41a3e423c06b3d9e8fb624ec2933aa8a

[elf-pavlik]

Latest draft fully delegates to DPoP spec