Dear OAuth Working Group, I’m seeking feedback from the WG regarding implementation of Attestation-Based Client Authentication (ABCA) on Apple devices, particularly in relation to how PoP JWTs are generated in conjunction with device integrity mechanisms.
Apple devices offer two distinct mechanisms for managing private keys: * Keychain Services – allows applications to generate and use arbitrary signatures using device-managed keys. * App Attest API – provides attestation of device and application integrity, but its signature format is WebAuthn-like CBOR, incompatible with JWS. In the context of ABCA, if the goal is to preserve device and app integrity in the PoP JWT itself, it seems appropriate to use generateAssertion() from App Attest to produce the signature. However, App Attest cannot produce a JWS-compatible signature, which implies that the JWT format itself must be extended or adapted to accommodate it. Given this situation, I’d like to understand how potential implementers currently envision ABCA working on iOS. Specifically, which of the following approaches do you consider most viable or preferable? 1. Use App Attest only during attestation generation, and rely on Keychain Services for subsequent PoP JWT signing. 2. Extend the JWT format to support WebAuthn-like signatures, allowing App Attest to directly sign the PoP JWT. 3. Use Keychain Services for PoP JWT signing, but include the App Attest generateAssertion() output as a claim within the JWT to preserve integrity context. Each approach has trade-offs in terms of interoperability, security guarantees, and implementation complexity. I’d appreciate hearing from others in the WG about their current thinking. While I don't currently plan to attend the upcoming IETF Meeting, I will be participating in IIW (Day 1–2). If any members of this group are also attending, I would be happy to discuss this in person. Best regards, Kosuke _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
