Sign access decision?

[eazerad]

Should the access decision be signed by the PDP private key to ensure that the payload has not been tampered with?

[tr33]

In which cases should the PEP not trust its designated PDP?

Some level of "trust" could be provided by the transport layer, e.g. via TLS.
Mutual "Trust" could also be assumed by the parties configuring PDP+PEP?

Signing + validation implies notable efforts for both parties, whilst the whole process should be as fast as possible.
It would also increase complexity on the spec and implementation.

As long as "Authorization Federation" isn't a clear concept (like with SAML-Federation) I would offload this to the transport layer and clearly assume mutual trust by the parties setting up both components.

[eazerad]

For Mutual TLS, I agree that it is a transport layer responsibility but we probably need to discuss in terms of patterns we want to support and if the API we provide can accommodate future use cases. Digitally signing can increase the trust in the authorization decision furthermore if mutual trust doesn't exist before the API call is made. I wouldn't see it as a mandatory API feature but something that is optional. Are all authorization decisions required to be fast? It is ideal but it depends on use cases we want to support. Also there is a spectrum of what is fast and near real time and what can take seconds, hours or could be tied to a workflow with manual interactions so I hope we can clarify that in the use cases.

[tulshi]

We can add a note in the draft "Security Considerations" section that reliable mechanisms must be used to ensure PDP - PEP communication integrity, privacy and authenticity (e.g. MTLS)

[ogazitt]

@davidjbrossard did we include this in our Security Considerations?

[davidjbrossard]

See https://openid.net/specs/oauth-v2-jarm.html

[davidjbrossard]

@davidjbrossard did we include this in our Security Considerations?

@ogazitt not directly. On the 6/20 call @ggebel @identitymonk and I agreed to put a proposal similar to JARM for AuthZEN that would allow for this.

The current spec states in 13.1 and 13.2 how integrity can be achieved (largely through TLS). We should keep it as is for the core spec and add the profile for JARM

[davidjbrossard]

See also #248 (comment)

[davidjbrossard]

@eazerad can you create a PR and add a section in the Security Considerations to define signing of the response as an option?

[eazerad]

@davidjbrossard - I created a pull request. I explained the "why" but not the "how". I have not mentioned adding a profile similar to JARM.