Native App Associations
If passkeys will be registered and used through a custom native application on Android and/or iOS — rather than only through a web browser — the operating system needs proof that your app is actually allowed to act on behalf of your domain. Both Android and iOS require a small JSON file to be hosted on your domain to establish this trust:
- Android looks for a
assetlinks.jsonfile (the Digital Asset Links protocol). - iOS looks for an
apple-app-site-associationfile (Apple App Site Association, sometimes abbreviated AASA).
Without these files in place, the platform will refuse to hand passkey requests from your app to the relying party at all — regardless of how the Passkey authentication settings are configured.
Trivore ID can host both of these files for you. This page explains how to configure them.
You'll find these settings under System Preferences → Platform → Base settings → Native app associations.
This page only covers hosting the association files. It does not cover the passkey ceremony itself, which is configured on the Passkey authentication tab.
Android: Digital Asset Links
Digital Asset Links verify the relationship between your website and your Android app. Trivore ID hosts the resulting file at:
https://<your-domain>/.well-known/assetlinks.json
Enabling the file
Check Enable Digital Asset Links to have Trivore ID serve assetlinks.json at the path above. If this is left unchecked, the file is not served, even if entries have been configured below.
Digital Asset Links entries
The Digital Asset Links table lists every app/certificate combination that should be declared as associated with your domain. Each row corresponds to one entry in the generated JSON file. The table shows the Namespace, Package Name, and any Notes you've entered for that entry, along with edit and delete actions.
Click Add (or the pencil icon on an existing row) to open the entry editor, which has the following fields:
| Field | Description |
|---|---|
| Relations | One relation per line. For passkey support, this should include delegate_permission/common.get_login_creds. If your app also handles regular App Links for this domain, you can additionally add delegate_permission/common.handle_all_urls on its own line. |
| Namespace | The asset type. For Android apps this is always android_app. |
| Package Name | Your Android app's package identifier, e.g. com.example.app. |
| SHA-256 Certificate Fingerprints | One fingerprint per line, in colon-separated hex form (e.g. AB:CD:EF:...). This is the SHA-256 hash of the certificate used to sign the app. |
| Notes | Free-text field for your own reference (for example, "Play Store release" or "Debug build"). Not included in the generated JSON. |
Since each signing certificate produces a different fingerprint, you'll typically need one entry per build variant — for example, one for your local debug key and a separate one for your production release/upload key. If you're not sure which certificate your app is currently signed with, or how to compute its fingerprint, see Create a passkey – Android Developers.
Click Apply to save the entry, or Cancel to discard it. Remember to click Save on the main settings page afterward to persist your changes.
Reviewing and verifying
Use Preview assetlinks.json to see the exact JSON that will be served, based on your current entries — useful for catching typos before saving. Once the configuration is saved, Open active assetlinks.json URI opens the live, publicly served file so you can confirm it's reachable and correctly formed.
iOS: Apple App Site Association
Apple App Site Association files verify the relationship between your website and your iOS app, and are what allows the app to access passkeys tied to your domain. Trivore ID hosts the resulting file at:
https://<your-domain>/.well-known/apple-app-site-association
Enabling the file
Check Enable Apple App Site Association to have Trivore ID serve the file at the path above. If left unchecked, the file is not served.
Apple App Site Association entries
The Apple App Site Associations table lists every app declared as associated with your domain, showing its App ID, Paths, whether it's marked for Web Credentials, and any Notes.
Click Add (or the pencil icon on an existing row) to open the entry editor:
| Field | Description |
|---|---|
| App ID | Your app's identifier, formed from your Apple Developer Team ID (App ID Prefix) and bundle identifier, e.g. ABCDE12345.com.example.app. |
| Paths | One path pattern per line, e.g. /path/*. These control which URLs the app is allowed to open as Universal Links. For a passkey-only integration, this can typically be left empty or minimal, since passkey access is governed by the Web Credentials flag rather than the paths list. |
| Web Credentials | Check this box for entries that should be allowed to use passkeys tied to this domain. This adds the app to the webcredentials section of the generated file, which is what actually grants passkey access — an app ID with paths but without this checked will not be able to use your domain's passkeys. |
| Notes | Free-text field for your own reference. Not included in the generated JSON. |
Click Apply to save the entry, then Save on the main settings page to persist the change.
For example, an entry with App ID AA.com.example.app, paths /path/*, haa, and /hoo, with Web Credentials checked, would produce:
{
"applinks": {
"details": [
{
"appID": "ABCDE12345.com.example.app",
"paths": ["/path/*", "/foo", "/bar"]
}
]
},
"webcredentials": {
"apps": ["ABCDE12345.com.example.app"]
}
}
Note that the app only appears under webcredentials.apps because Web Credentials was checked — the applinks section alone would not grant passkey access.
For details on obtaining your Team ID and configuring the corresponding Associated Domains capability in your iOS app, see Supporting passkeys – Apple Developer Documentation.
Reviewing and verifying
Use Preview apple-app-site-association to check the generated JSON before saving. Once saved, Open active apple-app-site-association URI opens the live file so you can confirm it's being served correctly.
Also update the Passkey Origins field
Hosting these association files makes the platform trust your app, but it's a separate step from telling Trivore ID's relying party to accept requests coming from that app. On Android specifically, a native app's passkey requests report an origin of the form android:apk-key-hash:<fingerprint> rather than a normal web address. This value must still be added manually to the Origins field on the Passkey authentication tab — one line per SHA-256 fingerprint you've configured above, base64url-encoded (see the field's own documentation for the exact format).
On iOS, native app requests share the same origin as your website, so no separate Origins entry is normally required, as long as that web origin is already covered.
Summary
| Platform | File | Served at | Grants passkey access via |
|---|---|---|---|
| Android | assetlinks.json | /.well-known/assetlinks.json | delegate_permission/common.get_login_creds relation |
| iOS | apple-app-site-association | /.well-known/apple-app-site-association | Web Credentials checkbox on the entry |
After enabling and saving either section, always use Open active <filename> URI to confirm the file is actually reachable over HTTPS with the content you expect — the operating systems fetch and cache these files, so a broken or missing file is one of the most common causes of passkeys silently failing to work from a native app.