Difference between revisions of "App Assessor"
|Line 6:||Line 6:|
* . the to 1the
* [are data
Revision as of 18:33, 12 May 2021
Full Title or Meme
An App Assessor or Auditor has been accepted by a Trust Authority to evaluate apps that are to be accepted as Trustworthy by that Trust Authority.
- A world where the computing device in the user's hand is more powerful than supercomputers of the past generation.
- This wiki page focuses on defining the App Assessment process and the companies that are in the App Assessment business.
- User Applications are increasingly given authority by users to act as the user's agent. How is the user to determine that the app will (1) fairly represent the user's intentions, and (2) maintain the security of the user's private data.
- If a Relying Party is required to get user consent and to protect the users private information, how can that RP assure that they are not liable for reliance on faulty or even fraudulent data.
As of 2020-10 there are two categories of app that are proposed for use by users:
- These have been available early in the life of the smart phone. The apps are constructed in an interpreted language (like java or .NET) on the "native" (really interpreted) environment of the device.
- Typically the code is downloaded from an App Store run by the o/s vendor.
- To meet the use case the app would need to be certified and given a certification, like the Mobile Authentication Assurance Statement" link above.
- The app would authenticate the user in a native method like a pin or biometric.
- Any trust Assertion from the user/app would include the MAAS and an Assurance signed by the app that Authentication was successful and the user secrets were securely stored.
- Also known as Progressive Web Apps, these are being aggressively advance by the browser vendors in the blink (chromium + webkit) environment.
Android example courtesy of James Manger:
In the use case, itsyourweb.org provides wallet software as a progressive web app (PWA). Presumably the PWA asks the user's browser to generate a key-pair; hopefully hardware-backed; perhaps requiring the user's device-unlock gesture for each operation with the private key; and maybe with an attestation (chaining back to the O/S vendor and/or device vendor) that the key has these protections. The PWA will use the private key to sign SIOP responses. A user with such a wallet can only use it at RP that explicitly supports this specific wallet vendor; ie an RP that lists itsyourweb.org alongside, say, Facebook & Google as supported OPs in a NASCAR-style list of logos. In the example, Air Canada (the RP) shows a QR code specific to itsyourweb.org (not any other SIOP). An RP doesn't get any assurance that a user is running the true itsyourweb.org wallet. The user could have installed their own root CA and their own DNS settings pointing itsyourweb.org to their own site. But, under the assumption that a user is running a "normal" browser on a "normal" O/S, the RP can assume the itsyourweb.org wallet is running, with all the protections and consent screens that itsyourweb.org is trusted to implement. That may be sufficient for an RP to show a duty-of-care towards users by only supporting quality wallets. Perhaps in future attestations from the O/S vendor about the state & identity of a PWA will be possible, much like an Android SafetyNet attestation from Google gives some assurance about a mobile app.
- Human-centered Design
- Design for Test
- Design for Reliability
- Track all bugs and changes
- Supply Chain verification
Test & Validation
- App Assessor