Add Apple as a supported OIDC provider

AIP-90: Add Apple as a supported OIDC provider

Summary

We are proposing adding Apple as a supported OIDC provider for Aptos Keyless accounts. This would allow users to “Sign in with Apple” inside dapps and/or wallets. This change requires Aptos validators to periodically refresh their views of Apple’s JWKs¹ via JWK consensus². It is worth emphasizing Apple’s OIDC implementation is privacy-preserving, and, as a result, prevents the mechanism for recovering Apple-based keyless accounts associated with disappeared dapps and/or wallets³ (see “Impact”).

Impact and risks

Apple’s OIDC implementation is more privacy-preserving than Google’s. Specifically, when the same Apple user signs in into two different applications, each application sees a different, application-specific sub identifier for the user. As a result, colluding applications cannot tell if they are authenticating the same user or not. In the OIDC standard, this privacy-preserving technique is referred to as pairwise-pseudonymous identifiers (PPID)⁴.

Note: Even if the application asks for the email field to be included, the Apple user can enable the “Hide my email” option when signing in, which results in an application-specific email field as well.

As a result of this, the approach for dealing with disappearing dapps for Apple keyless users described in AIP-61³ does not apply, since it assumes different applications see the same sub for the same Apple user. This puts onus on either users or applications to guarantee recovery via some other mechanism (e.g., t-out-of-n accounts, passkeys⁵).

Alternative solutions

There are no alternatives beyond continuing to rely on Google as the only supported OIDC provider.

The decision is binary: Do we (not) want to support keyless accounts backed by Apple accounts?

Specification and Implementation Details

This AIP’s implementation is very simple: we submit a governance proposal to enable Apple support, described below.

If the proposal is accepted, the validators will start JWK consensus to maintain a fresh view of Apple’s JWKs. As a result, keyless accounts which are backed by Apple can now transact on chain.

Reference Implementation

The governance proposal that will be submitted is:

script {
    use aptos_framework::aptos_governance;
    use aptos_framework::jwks;

    fun main(core_resources: &signer) {
        let core_signer = aptos_governance::get_signer_testnet_only(core_resources, @0x1);
        let framework_signer = &core_signer;

        jwks::upsert_oidc_provider(
            framework_signer,
            b"https://appleid.apple.com",
            b"https://appleid.apple.com/.well-known/openid-configuration"
        );

        aptos_governance::reconfigure(framework_signer);
    }
}

Testing (Optional)

What is the testing plan? (other than load testing, all tests should be part of the implementation details and won’t need to be called out)

When can we expect the results?

What are the test results and are they what we expected? If not, explain the gap.

To be discussed more. For now:

Make sure JWK consensus correctly handles Apple via smoke tests.
Do a manual end-to-end test in devnet for an Apple keyless account.

Security Considerations

There should be no code changes, beyond some tests.

Nonetheless, as is the case for any keyless account, the security of that account = the security of its OIDC provider. Currently, all keyless accounts rely on Google, so this AIP would give users the option to rely on Apple for their account’s security.

An argument could be made that this strengthens the liveness/durability of keyless accounts if they are set up as a 1-out-of-2 account with Google and Apple.

Future Potential

This will allow onboarding more users into the Aptos blockchain via keyless accounts⁶.

Timeline

Suggested implementation timeline

N/A, as this is an on-chain configuration change.

Suggested developer platform support timeline

N/A, as this is an on-chain configuration change.

The SDK already handles additional OIDC providers.

Suggested deployment timeline

As soon as possible. To be discussed and agreed upon.

Open Questions (Optional)

Key question: What would be a user-friendly recovery mechanism³ for OIDC providers like Apple that have PPIDs?

Appendix

JWT header and payload example

JWT header (40 bytes $\Rightarrow$ 54 bytes base64url encoding):

{
  "kid": "dMlERBaFdK",
  "alg": "RS256"
}

JWT payload (448 bytes $\Rightarrow$ 598 bytes base64url encoding):

{
  "iss": "https://appleid.apple.com",
  "aud": "app.aptosconnect.web",
  "exp": 1736540489,
  "iat": 1736454089,
  "sub": "001903.87e576838a114932b409b7bb34417904.1924",
  "nonce": "15919628789903246873379427733051374218372906955101515791742506401291192372556",
  "at_hash": "u_tp8X3aQKnxVnzUk3vECw",
  "email": "k9rqh2nkm9@privaterelay.appleid.com",
  "email_verified": true,
  "is_private_email": true,
  "auth_time": 1736454088,
  "nonce_supported": true
}