Passkey setup

​

Configure your platform

• Android
• iOS

OwnID uses Android Credential Manager for passkey creation and authentication.

1

Add Credential Manager

Use the current AndroidX Credentials version for both artifacts:Latest stable AndroidX Credentials version

build.gradle.kts

dependencies {
    implementation("androidx.credentials:credentials:<latest-version>")
    implementation("androidx.credentials:credentials-play-services-auth:<latest-version>")
}

See the AndroidX Credentials release notes for version-specific changes.

2

Publish Digital Asset Links

Host assetlinks.json at this exact URL:

https://<relying-party-domain>/.well-known/assetlinks.json

The endpoint must be public over HTTPS, return HTTP 200 with a JSON content type, and must not redirect. Allow automated retrieval of /.well-known/assetlinks.json; if the domain uses robots.txt, make sure it does not block /.well-known/.

assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "<android_application_id>",
      "sha256_cert_fingerprints": [
        "<sha256_signing_certificate_fingerprint>"
      ]
    }
  }
]

3

Cover every signed app variant

Add an entry for every application ID and SHA-256 signing certificate that should use passkeys, including relevant debug, release, and product-flavor builds.You can inspect a keystore certificate with:

keytool -list -v -keystore <path-to-keystore>

See Android’s Credential Manager prerequisites and Digital Asset Links guidance for validation requirements.

OwnID uses Apple’s AuthenticationServices framework for passkey creation and authentication.

1

Add the Associated Domains capability

In Xcode, open your app target, select Signing & Capabilities, and add Associated Domains. Add the relying party domain without a protocol or path:

webcredentials:<relying-party-domain>

Enable Associated Domains for the matching App ID in Apple Developer as well. If the app uses manual signing, regenerate and install its provisioning profiles after enabling the capability.

2

Publish the Apple App Site Association file

Host the extensionless file at this exact URL:

https://<relying-party-domain>/.well-known/apple-app-site-association

The endpoint must be public over HTTPS, return HTTP 200 with a JSON content type, must not redirect, and its uncompressed content must stay at or below 128 KB.

apple-app-site-association

{
  "webcredentials": {
    "apps": [
      "<APP_ID_PREFIX>.<BUNDLE_ID>"
    ]
  }
}

3

Verify the signed application identifier

Add every app target that should use passkeys. Each <APP_ID_PREFIX>.<BUNDLE_ID> value must match the signed app’s application-identifier entitlement.The App ID prefix is often your Apple Team ID, but it can differ. Use the prefix from the signed app or provisioning profile.

See Apple’s Supporting associated domains and Associated Domains entitlement references for signing and validation requirements.

​

Configure the OwnID Console

1

Open the native app settings

Sign in to the OwnID Console, open your application, and go to Integration > Native Apps.

2

Add platform identifiers

• Android
• iOS

Enter the Android application ID and SHA-256 signing certificate fingerprint. They must match an entry in assetlinks.json.

Enter the iOS bundle identifier. It must match the bundle ID used in the Apple App Site Association file and the signed app.

3

Save the configuration

Save your changes before testing passkey creation or authentication.

​

Verify the association

https://<relying-party-domain>/.well-known/assetlinks.json

https://<relying-party-domain>/.well-known/apple-app-site-association

​

Allow time for updates

curl -sS -D - -o /dev/null \
  https://<relying-party-domain>/.well-known/<association-file>

• Google Digital Asset Links determines statement validity from the underlying data TTL, subject to implementation limits. The Digital Asset Links API returns maxAge, which indicates how much longer its result should be considered valid.
• Apple’s CDN normally requests the apple-app-site-association file within 24 hours. Devices check for updates approximately once per week after installation. Apple does not provide manual cache invalidation. See Supporting associated domains.