Hi Kosuke & Frederik, I do believe both Paul and I will be at IIW - happy to have a session on the topic and possible challenges and feedback there! Do you have concrete points you would like to address from an implementer’s perspective that haven’t been brought up in the mailing list or on GitHub before Frederik? Getting more implementation feedback would be really helpful.
Best regards, Christian > On 4. Sep 2025, at 09:18, Frederik Krogsdal Jacobsen > <[email protected]> wrote: > > 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] > <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > 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]
