Difference between revisions of "Apps on User Devices"

From MgmtWiki
Jump to: navigation, search
(Created page with "==Full Title or Meme== This design pattern focuses on ways to get computing power and security into the devices that are in the user's hands. ==Context== * A world where the c...")
 
(Test & Validation)
 
(26 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
==Context==
 
==Context==
 
* A world where the computing device in the user's hand is more powerful than supercomputers of the past generation.
 
* A world where the computing device in the user's hand is more powerful than supercomputers of the past generation.
==Use Case==
+
* This wiki page focuses on getting some assurance from the [[Apps on User Devices]] that the data presented meets an appropriate level of assurance.
 +
 
 +
==Problems==
 +
* [https://medcitynews.com/2021/04/some-proposed-hipaa-changes-could-inadvertently-expose-the-data-its-supposed-to-protect/?rf=1 Problems in Healthcare] is HIPAA a solution or is it the problem?
 +
* [https://gizmodo.com/60-of-school-apps-are-sharing-your-kids-data-with-thir-1846819024 Problems in K12 schools] 60% of School Apps Are Sharing Your Kids' Data With Third Parties
 +
 
 +
===Use Case===
 
* Preconditions: The user is given the legal right to acquire their own health records with the 21st Center Cures Act and regulations.
 
* Preconditions: The user is given the legal right to acquire their own health records with the 21st Center Cures Act and regulations.
 
* Regulation: Requires that Electronic Health Records (EHR) for the user may (subject to limitations) be downloaded into user apps from certified developers.
 
* Regulation: Requires that Electronic Health Records (EHR) for the user may (subject to limitations) be downloaded into user apps from certified developers.
Line 10: Line 16:
 
* Service Assessment Criteria: Proposed work item pending funding.
 
* Service Assessment Criteria: Proposed work item pending funding.
 
* Certification document for Apps: Draft now available at https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations
 
* Certification document for Apps: Draft now available at https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations
* Proof of Presence of user and app: Proposed work item pending funding.
+
* [[Proof of Presence]] of user and app: Proposed work item pending funding.
 
* Trust Registry that can verify app certification and presence: Proposed work item pending funding.
 
* Trust Registry that can verify app certification and presence: Proposed work item pending funding.
 +
 
==App Categories==
 
==App Categories==
As of 2020-10 there are two categories of app that are proposed for user by users:
+
As of 2020-10 there are two categories of app that are proposed for use by users:
 
===Native Apps===
 
===Native Apps===
* These have been available at the dawn of the smart phone.
+
* 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 [https://kantarainitiative.org/download/kantara-mobile-assurance-statement/ MAAS] and an [[Assurance]] signed by the app that Authentication was successful and the user secrets were securely stored.
 +
 
 
===Web Apps===
 
===Web Apps===
 
* Also known as Progressive Web Apps, these are being aggressively advance by the browser vendors in the blink (chromium + webkit) environment.
 
* 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:
 +
<pre>
 +
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.</pre>
 +
===Hybrid Apps===
 +
This is not a distinct type, but a combination of a native app with a web site that performs some critical function. For example the [https://solidproject.org Solid Project] at MIT or its [https://inrupt.com/solid/ commercial manifestation].
 +
 +
==Solutions==
 +
===Design===
 +
* [[Human-centered Design]]
 +
* Design for Test
 +
* Design for Reliability
 +
 +
===Build===
 +
* Track all bugs and changes
 +
* Supply Chain verification
 +
===Test & Validation===
 +
* [[App Assessor]]
 +
 
==References==
 
==References==
 +
* Details are in the wiki [[Proof of Presence]].
 +
* See the Wiki page on [https://wiki.idesg.org/wiki/index.php/Patient_Choice Patient Choice]
  
 
[[Category: Health]]
 
[[Category: Health]]

Latest revision as of 17:25, 12 May 2021

Full Title or Meme

This design pattern focuses on ways to get computing power and security into the devices that are in the user's hands.

Context

  • 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 getting some assurance from the Apps on User Devices that the data presented meets an appropriate level of assurance.

Problems

Use Case

  • Preconditions: The user is given the legal right to acquire their own health records with the 21st Center Cures Act and regulations.
  • Regulation: Requires that Electronic Health Records (EHR) for the user may (subject to limitations) be downloaded into user apps from certified developers.
  • Use Case: This is one approach to meeting this regulation.
  • Specifications: The current state is that the CARIN alliance has published a Code of Conduct for user apps.
  • Service Assessment Criteria: Proposed work item pending funding.
  • Certification document for Apps: Draft now available at https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations
  • Proof of Presence of user and app: Proposed work item pending funding.
  • Trust Registry that can verify app certification and presence: Proposed work item pending funding.

App Categories

As of 2020-10 there are two categories of app that are proposed for use by users:

Native Apps

  • 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.

Web Apps

  • 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.

Hybrid Apps

This is not a distinct type, but a combination of a native app with a web site that performs some critical function. For example the Solid Project at MIT or its commercial manifestation.

Solutions

Design

Build

  • Track all bugs and changes
  • Supply Chain verification

Test & Validation

References