App Attestation (v1)

[cvarjao]

Description / User Story

As an Issuer
I want to know if the wallet app being used is trusted
so that I can trust the wallet to hold a high assurance credential

As an verifier
I want to know if the wallet app being used is trusted
so that I can trust the credential being used

Acceptance Criteria

• There's a way to attest for the app integrity
• App attestation manifests as a verifiable credential and it is validated via a proof request
• UX does not impede on the user's happy path

---

• Cache Nonce The nonce should be cached for app attestation #1638

The nonce sent by the Controller to Apple should be cached so that it can be looked up and confirmed it was the one sent to a device. It should probably expire, it should not be sent back from the device.

• Complete Apple Verification Complete iOS app attestation #1602

To verify an Apple attestation there are 9 steps. Steps 1-5 are complete, while 6-9 are outstanding. These steps need to be completed to finalize the work for iOS.

• Google Play API App Attestation (v1) - Android | development #1419

The Google Play API should be implemented so that google integrity can be verified. This needs to be implemented in the npm package as well as the controller.

• Protocol via RFC Determine a method to use for Wallet to Attestation Controller communicaiton #1603

As per Stephen's comment ACA-py on Discord the protocol used should be formalized in its own RFC and become a separate entity to Basic Message. This would require designing the protocol, writing an RFC, and pushing ahead with the adoption of the the RFC.

• Finalize VC Schema - Register App Attestation Schema #1714

The draft schema for the PoC has the following attributes:

• Assurance Level
• Issue Date

Which are fictitious and may or may not be in the final schema. For BC, we should come up with a proper schema and implement all the necessities like publishing, documenting it, and providing OCA branding for it. We should also consider what it means to be "Hight Assurance" for example, if an alternative method is used on iOS < 14 do we note it's a "medium" assurance credential.

• Support for < iOS 14.

The current functionality is only supported on iOS 14 and devices with a secure-enclave. We may want to implement app-store receipt checking devices lower than 14.

• Correctly populate credential values The attestation controller should correctly populate VC fields #1767

Now that the credential schema is decided on we need the controller to correctly set the new values.

• Decide on and set credential and connection name Decide on and set both VC and Issuer name on attestation credential #1768

Even though this credential is mostly opaque to the user we should still set the name of it and connection name correctly. We should also decide if branding is required and create any related tickets.

• Update Helm chart to deploy redis Add redis to app attestation controller helm chart #1712
• Redis cache invalidation for nonces Redis cache invalidation for nonces #1713
• Activation by Proof Request App Attestation (v1) | Activation by Proof Request | development #1667
• RPC protocol implementation in AFJ #1720

Technical Debt

• The Apple Attestation is done in Objective-C which is perhaps legacy now. Consider converting it to Swift before the code base gets overly large.

• Convert Controler to Plug-in

The server side controller logic should be converted to an ACA-py plug-in so that it can be better integrated into an agent.

[nodlesh]

I'm just thinking about this story some more, trying to construct Some Gherkin Acceptance Criteria. It raises questions for me. Is this scenario correct?

Scenario: Initial verification of the BC Wallet app
Given the wallet user has opened the app for the first time
And the app initialization has finished
When the app has been validated against the app store by the BC Gov issuer (triggered by the Mediator when initializing?)
Then the wallet user will receive an "attestation credential" offer from the BC Gov issuer

If this is correct, then I have so many questions...

1. What happens if there is a connection outage during this verification and/or issuing process?
2. If Lets use common phrasing #1, what triggers it to verify the app again and issue that credential?
3. If someone doesn't get that attestation credential can they still use the app? Why would we let them use the app?
4. If we decided that the app cannot be used without this attestation credential, then there would be no need for proof requests to even ask for it. If the wallet works then that means they have the attestation cred.
5. What happens if they accidentally delete the attestation credential?
6. What if they rejected the attestation credential offer? How do they get the process going again? Reinstall the app?