Allowing JWT as tamper evident containers from PEP to PDP

[identitymonk]

Subject data will be more than often extracted from OAuth2 JSON Web Token but by passing just the payload of it we are stripping the digital signature and the chain of custody on this information.

Supporting JWT can allow a longer term feature that would see Transaction Tokens [txn-tokens - https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/ ] to be passe as structure of context.

[davidjbrossard]

This should be part of a BCP

id can contain a full-blown JWT. Should the request indicate the datatype of id? Should we instead use the properties object to convey that information?

If using the spec as it stands, we should use:

• subject type for things like user, NHI, customer, employee...
• subject id for an identifier of the given type. That id depends on what the PDP expects. It could be an email, a UUID, a JWT...

In that approach, we don't need to change the spec AND the it is up to the PDP to figure out the actual content and type of id

[ogazitt]

We have discussed a profile in which a base64-encoded JWT can be used as a subject: https://hackmd.io/6rB2M7e3QuWUo2MBEKZ8nw

[gffletch]

A few thoughts...

1. What are the requirements on the PDP to validate the JWT object (assuming it's signed)? Does the PDP have the necessary data to even be able to validate the signature or other data? if the JWT object is NOT signed, then what is the trust model that the PDP should trust the information?
2. If the JWT is a DPoP bound access_token, the PDP will not be able to validate the JWT?
3. Is there a danger of leaking information to the PDP that should NOT be visible to the PDP?
4. As a PDP the number of JWTs it will need to handle and process is infinite. If the expectation is just that the PDP will "JSON Path" to the identified claims that might help though that can put a decent amount of complexity on the PEP to know what "JSON Path" is associated with the particular JWT that is presented.

[baboulebou]

mmm... doesn't seem to me that this extra complexity is necessary here. A Tx context can always be passed as part of the context of the AuthZen request, and indeed we can't necessarily expect a PDP to have all the right configs to validate a JWT signature. Besides, the trust should be between the PEP and the PDP, not between a subject and the PDP (which is what a JWT access token would be here).

[identitymonk]

1- I assumed JWT validated by JWS. Whatever this is an OAuth2 Access Token or other. Rules will be ones defined by the RFC associated with the typ of JWT. Not signed JWT will be best effort, falling back to current state of passing a Context JSON structure in the AuthZEN request. If signed JWT is expected then RFC9700 applies.
2- That is a good question, but this will fall under the tmb draft works.
3- PEP and PDP are in the same trust boundary, so whatever leaked to the PEP is consider safe up to the PDP in terms of privacy.
4- that PDP implementation therefore outside this spec if I am following the Chairs mental model

[gffletch]

1 - To validate the signature, you need the correct key. With JWTs this can sometimes be found via discovery and JWKS documents. However, that is a lot for the PDP to handle to follow those every time a new JWT shows up signed with a key the PDP doesn't have.
3 - I don't think that always holds. I know of deployments effectively using selective disclosure inside the perimeter to ensure that only the correct service "sees" that information.
4 - I'm not sure I understand the "chairs mental model". Is that documented somewhere? What I see happening here (and not supported by the proposal) is that string the PEP wants the PDP to use for the subject is inside a multiply nested JSON object in the JWT. That adds a fair amount of complexity when it comes to parsing.

I'm just wondering if we are really saving the PEP implementer that much work compared to the added complexity we are pushing onto the PDP. The PEP already has to validate the JWT signature unless the expectation is that the PDP is going to do both token validation AND authorization policy. From a pure performance perspective, having the PEP do the token validation makes a lot of sense rather than taking the latency to call the PDP to do that job. If the token is not valid, then don't invoke the PDP. If the client identified in the token is not authorized to call that API (this can be a static check in the PDP) then fail fast.

[baboulebou]

I agree with George here, let's avoid this on the PDP. This is overkill imho. The PDP should trust the PEP, that's the basic premise of the whole system and of Zero trust too (see NIST SP 800-207 for example). As long as the PEP can authenticate with the PDP, then the PDP should trust the AuthZen payload without having to check additional signatures or other.

[identitymonk]

he PDP should trust the PEP, that's the basic premise of the whole system and of Zero trust

the premise of Zero Trust is to have... Zero implicit Trust, therefore the name @baboulebou or another to spin it is the Trust but Verify. Signature helps the "but Verify".

I am surprised by how the AuthZEN approaches features. There was a lot of comments like "Let's not put that in the Spec cause me as a PDP I don't knoiw how to implement that" here we have PDP that can implement this proposal, are we barring those to port that on AuthZEN requests?

[identitymonk]

@gffletch following on your comments

1 - Validation and JWKS

This WG has been very adamant to not enter the realm of implementation guidance at the PEP nor the PDP. Your points, while very legit, is a PDP implementation problem and can be easily resolvable by following the RFC that govern JWT/JWS/JWKS

3 - SD-JWT

This is a two fold argument:
A. If like @baboulebou says, PEP or PDP -> no difference on scope of visibility and therefore inherent trust. If here something the PDP should not see, then the PEP should not see it either...

B. As pointed in (1), this a PDP implementation detail. If a SD-JWT is passed through an AuthZEN request, the PDP in its implementation will have to abide by the RFC that govern JWT/JWS/JWKS and also SD-JWT. In any way, the SD-JWT, if the PDP cannot handle it, will appear as a gribberish JWT for sensitive information that won't match policy conditions. Therefore it will be secure by default.

4 - as pointed in (1) and (3) the WG Chair decided to not guide on the implementation details at the PEP and PDP on how to evaluate an Authorization request in order to respect the multitude of PDP that exists: Firewall-ruled model (Axiomnatics and OPA), ReBAC (Indykite), etc. The chairs set the guidelines at defining only the exchange format and defining the rules to ensure validation of well formatted requests and responses. Not the payload request and response. Therefore the ask here is just to allow a format to provide information as a JWT (which can be an OAuth2 JWT profiled Access Token, a Trasaction Token, a SD-JWT, in fact whatever would follow a JWT format). How this is processed by the backend PDP is up to it and outside this spec.

[baboulebou]

Gee, SD-JWT now... this is definitively getting out of hand. We did support W3C Verifiable Creds with 3Edges, but this is definitively implementation specific imho. Some vendors may not even want to enter that space, we can't dictate vendor strategy here. I don't think it should be in the base spec, nor the JWT payload. If you want to profile AuthZen with these, fine with me as separate specs.
I also stand my ground, the PEP-PDP interaction must be trusted. A PEP could just authenticate with an API key for example (we use pki for this for example), but that is also out of scope for the spec here: any usual API authN method would be valid here.

My take, of course others feel free to chip in...

[identitymonk]

Just to be clear, the ask to pass a JWT in the Payload IS NOT for AuthN mechanism of the PEP to PDP. The ask is to pass data about the subject, the resource, or the conditions in a tamper evident container (aka a JWT).

I am surprised you are not liking it might be a SD-JWT. Cause you should not care what I passing as typed JWT in the format I am asking to support in the AuthZEN Request. This is a PDP and PEP implementation to agree on the right type of JWT.

Would you bar the request to have a normalized optional Key in the AuthZEN request to transport JWT cause you might not like implementers to pass a SD-JWT typed JWT?

[HenkVanMaanen]

We have a use case where we can't trust the PEP. The PEP in our case is a frontend SPA. The frontend disables certain buttons and hides certain links based on the authzen response (we also authz on the backend). We want to directly call the PDP in the SPA, but the user object can then be spoofed. The current workaround is: we create a wrapper api that verifies that the user in the user object in the authz request to the PDP corresponds with the user in the JWT send via the Authorization header, and then pass the request to the real PDP.

We could skip the wrapper api if it's possible to use a jwt in the user object directly to the PDP. But I agree, I think it's an implementation detail and maybe suppliers shouldn't be forced to implement it.

[identitymonk]

Agreed that the ask is for an optional but standardized field to ensure that any PDP expecting it will find the information at the same place.

[baboulebou]

@HenkVanMaanen , the PEP, once authenticated, must be trusted by the PDP, else I don't know how we'd be able to authorize anything. It's also part of the basics in Zero Trust (see NIST SP 800-207).
So you must implement a system where your PDP trusts a PEP at least (authentication issue?).

Anyway, the PEP only does the enforcement, passing a signed JWT to the PDP doesn't change that. The "thing" issuing the PDP request (with JWT) is, de-facto, the PEP: it will receive a response from the PDP and will have to deal with it.