Hi Kosuke, As a potential implementer for a OpenID Connect Core use case, my impression is that option 1 is the best way to do it. I think it should be the responsibility of the Client Attester to define which risk signals (potentially including App Attest) they consider when determining whether to issue a Client Attestation JWT. The Authorization Server should not have to care about the exact nature of the "optional further attestations" (such as App Attest) provided to the Client Attester. Note also that some clients may use other attestation providers than Apple or Google, so adding special support for specific formats seems like a potentially never-ending task.
We have some other doubts about how the spec can be implemented, so if you are considering implementation, I would like to exchange experiences. I will also be at IIW if you or anyone else wants to discuss further there. Cheers, Frederik On Wed, 3 Sept 2025 at 19:55, Paul Bastian <[email protected]> wrote: > Hi Kosuke, > > the intention of the authors is option 1 ("Use App Attest only during > attestation generation, and rely on Keychain Services for subsequent PoP > JWT signing."). The main motivation for this is to have a common format and > mechanism across all platforms. Furthermore, the clients backend/attester > may have additional signals beyond Apple's app attest that are input for > making the decision to issue a client attestation. > > Best regards, Paul > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
