Clarification on attestKey API in Platform SSO

Could you clarify whether the attestKey flow involves sending attestation data to an Apple server

What’s the background to this question? I mean, why does this matter to you?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the reply.

I’m currently working on threat modeling for my PSSO extension and trying to understand the different attack scenarios.

For example, what if an attacker creates a separate SSO extension to generate a valid attestation, and then somehow replaces or injects a malformed payload from their own device into the registration request of another device, potentially updating the keys?

In such cases, what protections does the attestation mechanism provide?

Also, is it sufficient to send the attestation payload directly in the request body, or should I add an extra layer of security—such as wrapping the payload in a JWT and signing it using Secure Enclave–backed keys generated during registration—to ensure the payload hasn’t been tampered with?

At the same time, I want to avoid overengineering the solution. I’m trying to determine whether these additional measures are necessary or just redundant.

Thanks for the clarification. I kicked off some research about this but I probably won’t have any updates soon. I hope to have more info around the end of next week.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the update.

I did some investigation on my end using Charles to inspect the traffic and verify whether any Apple attestation APIs are being called. I can confirm that an attestation API is indeed triggered, but I’m not entirely sure what happens behind the scenes.

Any progress on the research at your end ?

If Apple were to rotate or replace the attestation certificate chain (for example, in the event of a compromised root attestation CA), would this automatically trigger a repair / re-enrollment flow on all previously enrolled devices?

Or is the repair flow initiated only based on server-side decisions, such as attestation validation failures or explicit policy enforcement?