Limiting Proof of Possession Scope

[PieterKas]

Commenting as identity enthusiast as opposed to WIMSE co-chair:

Do we need additional mechanism defined in the Workload Proof Token for additional scoping (e.g. specific API on a target workload)?

[yaronf]

This is related to the bigger question of whether the token is reusable or associated with a single HTTP request.

[bc-pi]

The aud is basically meant to do that https://www.ietf.org/archive/id/draft-sheffer-wimse-s2s-protocol-00.html#section-4.2-2.2.2.2.1

But also what @yaronf said

[bc-pi]

and the @method and @request-target and Content-Type and Content-Digest in the https://www.ietf.org/archive/id/draft-sheffer-wimse-s2s-protocol-00.html#name-option-2-authentication-bas approach

[arndt-s]

From what I can see we have the following options for the Workload Proof Token (DPoP approach). The order is random and the options are not pre-filtered.

• Option A: Specify some selected claims for various request attributes. This could be an Access Token and/or Transaction token hash, the audience to specify endpoint and potentially method, maybe body hash, etc.

• Option B: Don't specify anything and only limit it by the audience. If customers need specific attributes bound they can include it into the audience

• Option C: Build something more flexible that allows to specify similar to HTTP Message Signatures what is bound. This would require the draft to include rules on how the digest is calculated.

• Option D: Allow customers to specify their own claims and rules (in addition to audience). We could only specify the claim for the digest. While this allows the most flexibility the interoperability would be a challenge.

• Option E: Use RFC9449 claims (htm & htu) to start with and profile more if necessity arises. OAuth could profit from this too then which could boost adoption.

I'm sure there's more options that don't come into my mind at the moment.

[yaronf]

B and D are clearly a no go because they leave to much to the user and/or do not promote interoperability.

Personally I think we'll be forced into C, I think the complexity is justified and people will be writing new code for WIMSE anyway.

I don't understand the comment about OAuth in option E. To me this is not OAuth DPoP, this is an entirely new think inspired by that DPoP. And yes, features we add here may be "back ported" into OAuth DPoP.

[arndt-s]

@yaronf yes, this is what I was trying to say, if WIMSE would define claims for messaging queue possession, OAuth could profit from that too.

Anyway, nothing we should put a lot of weight on IMO.

[arndt-s]

Closing this in favour of #39.

Overall, the authors believe that including the user context to the WPT scope makes sense. The current draft includes audience, ath, tth in the DPoP approach and allows signature over url, header & body in the Http Message Signature approach.

#39 is focusing on accustom deployments that may use over approaches with the WPT token.