Validation of SAD JWT:s will not work if a Proxy-IdP is used.

[swedenconnect]

Validation of SAD JWT:s will not work if a Proxy-IdP is used.

[martin-lindstrom]

Possible solutions?

The first one is obvious, but probably not acceptable. We restrict the usage of SAD:s by banning Proxy-IdP solutions from supporting SADRequest messages.

Next. Can we require that Signature Service to obtain the metadata from the "real" IdP that issued the SAD? And if so, it should be able to verify the signature. But we don't even now if they are in the same federation, so this is not probably the way to go. Furthermore, it will not aid the Signature Service is succeeding with the other checks.

What if we require Proxy-IdP:s wanting to support the SAD/SAP specification to issue a proxy-SAD?

If the Proxy-IdP promises to verify a received SAD (the 8 checks above), it should be able to wrap the original SAD into a Proxy-SAD which can be verified by the Signature Service. The original SAD would still be there for proof. We would need to add an extra field to the seElnSadext claim - proxiedSad.

[Razumain]

SAD verification is done is a tamper resistent environment. It is therefore important that the SAD itself is simple and can be validate using fairly simple process.

I suggest a small change to the specification.

1. Add a request ID to the SAD request (SRID).
2. Change the "irt" parameter of the SAD to contain the SRID instead of the Authn Request ID.

If a proxy is used, the original SAD request is also proxied to the upstream IdP, preserving the SRID.

Add a new "Proxy section" stating that:

1. A proxy IdP may also proxy data that is useful to validate a SAD from an upstream IdP, such as the certificate for the SAD issuer as well as necessary information about attribute and LoA mapping between federations.
2. Providing such proxy information described in step 1 is currently outside the scope of this specification.

With these changes, all of the validation steps will pass even if proxy is used.

[Razumain]

Update after discussion today:

• In addition to the proposal above: Add new request param in SAD request expressing the ID of the requesting signing service.
• The current SAD parameter aud will contain the id of the requesting signing service
• Also add a simple way to proxy the SAD signing certificate from upstream IdP proving the SAD.