[Openid-specs-risc] openid/sharedsignals: Comment created on issue 308

[github at oidf.org]

openid/sharedsignals event

Issue Comment created on issue 308
Issue Title: CAEP interop profile - Access token related queries from certification team
https://github.com/openid/sharedsignals/issues/308

Comment: We discussed this today. ## Access Token Lifetime We agreed to generate a `warning` in the conformance tests if we detect an access token that is NOT "short-lived" (expires_in > now + 60mins). I'll update the conformance tests to include such a check. ## Autorization-Code Flow A few big vendors use the authorization code flow at the moment. However, most implementations that have used the conformance tests so far provided a client configuration to obtain an access token via the client_credentials grant, which seems more suitable for mostly machine-to-machine interaction. This is also reflected in https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html#section-7.1.1 `...In this case, the Receiver may obtain an access token using the Client Credentials Grant (Section 4.4 of [RFC6749]), or any other method suitable for the Receiver and the Transmitter...` The authorization code flow is mentioned as an additional way to obtain access tokens in https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html#section-2.7.1, which matches the language in the SSF spec `... or any other method suitable for the Receiver and the Transmitter...`. Since the auth code flow is usually an interactive flow that requires user presence (or at least user credentials), it is challenging to support it in conformance testing for things that interact via machine-to-machine communication. We are still undecided whether to keep supporting authorization code grant flow or limit the option to just client credentials grant flow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260113/208e16f9/attachment.htm>