Difference between revisions of "Proof of Presence"

From MgmtWiki
Jump to: navigation, search
(Standards)
(Full Title)
Line 1: Line 1:
 
==Full Title==
 
==Full Title==
[[Proof of Presence]] of user and app: This is a proposed work item pending funding.
+
[[Proof of Presence]] of user and app.
  
 
==Context==
 
==Context==

Revision as of 20:31, 17 April 2021

Full Title

Proof of Presence of user and app.

Context

  • Decentralized ID presents a problem with assurance of the trustworthiness of the wallet apps.

Goal: to convert a verifiable credential into a verifiable presentation that includes online proof of presence of the subject of the Verifiable Presentation.

  • Orie Steele (Transmute) reported on some work on biometric verifiable presentations a while ago. He used BioID Face Recognition & Liveness Detection Software. BioID provides software-based biometric authentication with presentation attack detection using face recognition and liveness detection. Most likely you would make a presentation that included a short lived liveness credential and the credential of primary concert to the Verifiable Presentation, for example: {DriversLicense, BiometricLivenessCheck}.

Problems

  • By far the biggest impediment to create a proof of presence reporter is trust by the Relying Party of the code that report the claim. Wallets in Apple and Android smartphone have the advantage be being provided the the o/s vendors which are known quantities. Wallets from third parties have a huge hill to climb in getting that kind of acceptance by the other sites.

Standards

Cloud based

The IATA traveler Identification process is compliant with ICAO standards. The process that a passenger would take to securely identify themselves in the IATA Travel Pass uses government issued ePassports to create a digital travel credential as per the standards developed through ICAO. The process has six steps:

  1. Download the free IATA Travel Pass to their Smart phone and login
  2. Take a selfie with the smart phone
  3. Complete a liveness test as instructed by the phone – i.e., move their head, close their eyes in front of the camera as instructed
  4. Scan the data on the two lines at the bottom of the passport photo page with their smart phones and scan the data-chip on the passport as prompted by the phone
  5. The IATA Travel Pass then matches the photo with the passport data (which contains a digital biometric photo of the passport holder) to verify that:
    1. the passport belongs to the person in front of the phone and
    2. that the passport is genuine and has not been tampered with.
  6. The verified digital travel credential is then stored on the passenger's phone and can be used as their ‘digital passport/ ID’.

Wallet

  • Trust registries for native code applications have been proposed but not yet widely implemented.

Solutions

There are two ways to get a trusted signer on the phone or other user computing device.

  1. Register an app that is trusted. If that is the method the easiest way is to register the actual instance of the wallet itself to the user.
  2. For a high assurance credential presentation to work, there has to be an element on the phone that is a "trusted" issuer.

The most likely solution is a certified wallet that includes some "credential" that is securely stored in the Trusted Execution Environment, for example the Android KeyStore and depend on the trusted element in the phone to boot up an assurance element - the TPM code in the TEE could do that, but it depends on a trusted server in the could. All of these depend on a web of trust that is not based on any human intervention. Not sure what the rWOT guys think about that? (nb this could be accomplished with a webauthn token like that from Yubikey)

Note that more than one type of "credential" is implied here.

  1. The Private Key under the control of the user.
  2. Credentials with data bound to that Private Key.

Android

Apple

Windows

When a user sets up Windows Hello on their machine, it generates a new public–private key pair on the device. The trusted platform module (TPM) generates and protects this private key. If the device does not have a TPM chip, the private key is encrypted and protected by software. In addition TPM-enabled devices generate a block of data that can be used to attest that a key is bound to TPM. This attestation information can be used in your solution to decide if the user is granted a different authorization level for example. Windows Hello provides strong Multi-factor Authentication that is fully integrated into Windows and replaces reusable passwords with the combination of a specific device, and a biometric gesture or PIN. An application can never use the keys from another application, nor can someone ever use the keys from another user.

To enable Windows Hello on a device, the user must have either their Azure Active Directory account or Microsoft Account connected in Windows settings.

References