nodlesh
commented
1 year ago 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 issuerIf this is correct, then I have so many questions...
- What happens if there is a connection outage during this verification and/or issuing process?
- If #1, what triggers it to verify the app again and issue that credential?
- If someone doesn't get that attestation credential can they still use the app? Why would we let them use the app?
- 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.
- What happens if they accidentally delete the attestation credential?
- What if they rejected the attestation credential offer? How do they get the process going again? Reinstall the app?
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
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.
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.
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.
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.
The draft schema for the PoC has the following attributes:
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.
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.
Now that the credential schema is decided on we need the controller to correctly set the new values.
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.
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.