CAEP interop profile - Access token related queries from certification team

[jogu]

From a recent discussion with @thomasdarimont we had some about the text around https://github.com/openid/sharedsignals/blob/main/openid-caep-interoperability-profile-1_0.md#authorization-server

Questions:

1. Does the profile mandate the user of bearer access tokens (I think it can be read that way), or are DPoP or MTLS sender constrained tokens permitted to be used?
2. I believe the profile does at least allow the user of bearer access tokens, are we comfortable with that given e.g. https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewOfTheSummer2023MEOIntrusion508.pdf is recommending the use of bound tokens?
3. Have we actually seen the use of the authorization code flow to obtain an access token for SSF usage? It's not something supported by the conformance tests and as far as I know no one has raised it as an issue so maybe that mode could be removed? If it can't be removed maybe we could at least declare it out of scope for certification for now?

[depending on the answers to these questions I think it would be good to include some clarifications into the spec to make it clearer.]

[tulshi]

Thoughts:

• I think using a short-lived token without DPoP is OK. The spec recommends using a short-lived token. The conformance test need not worry about token lifetime though.
• Using short-lived token is probably not as good as using DPoP or MTLS, but it is a practical limitation of implementations today, and still keeps the security properties reasonable.
• We can remove language around the authorization code flow. As far as I can see, it is only mentioned as an example in section 2.7.1 of short-lived tokens in the FAPI draft, not something we should expect in SSF.