@algorandfoundation/react-native-passkey-autofill 1.0.0-canary.28 → 1.0.0-canary.29
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/ARCHITECTURE.md +1 -1
- package/CHANGELOG.md +6 -0
- package/android/src/main/AndroidManifest.xml +8 -4
- package/package.json +1 -1
package/ARCHITECTURE.md
CHANGED
|
@@ -45,7 +45,7 @@ The "Chain of Trust" ensures that passkeys are only used by the legitimate owner
|
|
|
45
45
|
1. **Digital Asset Links**: For a passkey to be used across a website and an Android app, the website must host a `/.well-known/assetlinks.json` file that explicitly authorizes the Android app (via its package name and certificate fingerprint). This establishes a cryptographically verified link between the web origin and the mobile application.
|
|
46
46
|
2. **Relying Party ID (rpId) Validation**: When the service receives a `BeginGetCredentialRequest` or `BeginCreateCredentialRequest`, it includes information about the `rpId` (e.g., `example.com`). The system verifies that the requesting app is authorized for that `rpId`; the provider then enforces credential scope itself (`credentials/RelyingParty.kt`): a get request is resolved to an effective RP ID (the request's `rpId`, else the calling app's `android:apk-key-hash:` origin), only credentials stored for that RP are offered as entries, and `GetPasskeyActivity` re-checks the selected credential against the request before any private material is loaded. A request that names no relying party gets no entries. Related Origin Requests are not supported.
|
|
47
47
|
3. **App Signature Verification**: The Android system verifies the signature of the app requesting the credential. It will only offer credentials to apps that can prove their identity through the Digital Asset Link chain.
|
|
48
|
-
4. **User Consent**: The `CredentialProviderService` does not directly return the credential. Instead, it returns a list of "Entries" (like `PublicKeyCredentialEntry`). When a user selects an entry, a `PendingIntent` is triggered, which typically launches an activity (like `GetPasskeyActivity`) to perform user verification (e.g., biometric check) before the actual passkey is released to the requesting app.
|
|
48
|
+
4. **User Consent**: The `CredentialProviderService` does not directly return the credential. Instead, it returns a list of "Entries" (like `PublicKeyCredentialEntry`). When a user selects an entry, a `PendingIntent` is triggered, which typically launches an activity (like `GetPasskeyActivity`) to perform user verification (e.g., biometric check) before the actual passkey is released to the requesting app. `GetPasskeyActivity` and `CreatePasskeyActivity` are not exported: they trust the extras they are started with (credential id, request JSON, calling-app info, the biometric result), so only the service's own `PendingIntent` may start them. `ManifestExportPolicyTest` keeps it that way.
|
|
49
49
|
|
|
50
50
|
### iOS Implementation (`ios/`) [WIP]
|
|
51
51
|
|
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,9 @@
|
|
|
1
|
+
# [1.0.0-canary.29](https://github.com/algorandfoundation/react-native-passkey-autofill/compare/v1.0.0-canary.28...v1.0.0-canary.29) (2026-09-30)
|
|
2
|
+
|
|
3
|
+
### Bug Fixes
|
|
4
|
+
|
|
5
|
+
- **android:** stop exporting the passkey activities ([dfb376e](https://github.com/algorandfoundation/react-native-passkey-autofill/commit/dfb376e84aeef3fea36d742fa338dcefde153b3e))
|
|
6
|
+
|
|
1
7
|
# [1.0.0-canary.28](https://github.com/algorandfoundation/react-native-passkey-autofill/compare/v1.0.0-canary.27...v1.0.0-canary.28) (2026-09-29)
|
|
2
8
|
|
|
3
9
|
### Bug Fixes
|
|
@@ -18,8 +18,12 @@
|
|
|
18
18
|
android:name="android.credentials.provider"
|
|
19
19
|
android:resource="@xml/provider" />
|
|
20
20
|
</service>
|
|
21
|
-
|
|
22
|
-
|
|
21
|
+
<!--
|
|
22
|
+
Not exported: both activities trust the extras they are started with, so only the
|
|
23
|
+
provider service's own PendingIntent (explicit component, this app's UID) may start them.
|
|
24
|
+
-->
|
|
25
|
+
<activity android:name="co.algorand.passkeyautofill.GetPasskeyActivity"
|
|
26
|
+
android:exported="false"
|
|
23
27
|
android:launchMode="singleTop"
|
|
24
28
|
android:theme="@style/Theme.PasskeyAutofill.Dialog">
|
|
25
29
|
<intent-filter>
|
|
@@ -27,8 +31,8 @@
|
|
|
27
31
|
<category android:name="android.intent.category.DEFAULT"/>
|
|
28
32
|
</intent-filter>
|
|
29
33
|
</activity>
|
|
30
|
-
<activity android:name="co.algorand.passkeyautofill.CreatePasskeyActivity"
|
|
31
|
-
android:exported="
|
|
34
|
+
<activity android:name="co.algorand.passkeyautofill.CreatePasskeyActivity"
|
|
35
|
+
android:exported="false"
|
|
32
36
|
android:launchMode="singleTop"
|
|
33
37
|
android:theme="@style/Theme.PasskeyAutofill.Dialog">
|
|
34
38
|
<intent-filter>
|
package/package.json
CHANGED