Wallets that hold gov’t Creds

For discussion by the OWF 2023-08-28

Taxonomy and Notes

• Wallet = User Agent that can securely store and use holder’s secrets
• Device = A mobile computing device with wireless network access
• Subject Data = Personally Identifiable Information including trackable data
• Credential = Immutable signed data given to the wallet to store and use
• Issuer = the source of credentials
• Holder = Natural human that has installed the wallet on the Device
• Subject = Natural human that holds sovereign control of data about themself
• Verifier = Entity that will ask the Holder for access to Subject Data
• This is the name that will display on the Consent screen for Holder to make trust decision
• Tracking = Any process that allows any service to aggregated subject data

Should a wallet be required to be able to ID itself?

• DHS is interested in the capabilities of a wallet rather than the provider.
• But some entity must be accountable, and that is likely to be the provider of the wallet
• Typically current wallets are identified by the app store that installs them
• The information today includes the registered name of the developer and min version of the os
• The app must declare the capabilities that it requires to run, the user must agree to this
• The app owner can check this information at install time (aka at instance instantiation)
• This allows the creation of a registered app instance number, which can be tied to the holder
• If there is a trusted execution env, a private key can be created to prove consistency of ID
• In the absence of the above hand-shake, the app can say anything it wants
• There is no known way to determine if the app is just lying about who it is
• Unless the app can use the os/app store to describe what it is to a verifying party.
• If the app has a protected key it can create credentials of its own for attestation
• In the US the FAA requires Remote Identification of Unmanned Aircraft
• It seems that remote id of installed apps should have the similar requirements

Attestation of Wallet and Device

• Kantara Mobile Authentication Assurance Statement solves many issues

Recovery

• The worst-case fall back is just credential reissuance to a new wallet
• This basically is the standard in use for paper creds
• One case is for a resident to ask that updates go to a newly acquired wallet
• For example the mDL has an mDoc which is updated from time to time

Target identifier ecosystems in any government agency

• The primary target is government agencies that need identity information.
• Excluded from this discussion are high security, defence, financial and personal health
• It is to be assumed that those agencies will add additional requirements to those in this doc
• In the case of Washington State there are close to 200 types of creds
• While the driver’s licence has been the most obvious agency for identity certs
• There is a growing tendencies for a single identifier cred to be shared by many agencies
• The additional creds would then be dependant on that identifier cred
• Some federal agencies include similar numbers of creds
• Any approved wallet must support all qualified holders of the cred
• Either on a phone that they own, or one shared in some way described in other documents
• That wallet must be usable at all sites that require verification of the cred
• US Federal agencies cannot accept mDL after Real ID start date of May 2025
• TSA will need to issue regulations that may invalidate state mDL created before issuance

Security Requirements

• All government issuers will have some requirements on the wallet’s security
• This document will focus on requirements from the EU and the 5 eyes (US UK CA AU NZ)
• Protection of data disclosure is the most common requirement
• Encryption of data in transit and in storage is the most common solution
• Measures to protect “cloning” of the credential may be required
• All dependencies must be listed in a Software Bill of Materials (SBOM)
• All dependencies must have an accountable entity for exploited vulnerabilities
• For the Issuers or Verifiers attestation of Wallet code precedes trust
• Protections of data and acquisition of informed consent are principle goals of a wallet
• Subject privacy will require selective disclosure and tracking protection
• A full threat analysis should be performed at design and prior to deploying
• Must consider subject’s as well as government’s requirements
• Smart custody is already in development and could be included

What does it take for a Wallet to be trusted by a gov’t

• Most governments, or federations of governments write regulations
• Yet most data protection requirements are based on Common Criteria
• So data at rest and intransit into and out of the wallet must be encrypted
• All components used to encrypt data need to be approved
• Typical this means the components that create and use the private and secret keys
• The Open Source Security Foundation targets a secure supply chain
• Some gov’t regulations require a Software Bill of Materials (the supply chain)
• Here are some points from an existing FirstNet app requirements list:
• Application Lifecycle Management - Like JIRA - to track development and maintenance
• List of typical vulnerabilities faced by Mobile Apps
• Mature testing processes to verify quality in functional effectiveness, usability, stability, performance, and load testing.= See the Checklist
• Software scan required for the Certified label (app can be listed as Verified without this step)

Should a phone be unlocked before creds are released?

• Yes - No information should be released from an unlocked phone
• Unlocking is biometric (or similar) proof that the holder is present
• No - too much other PII of all sorts is exposed in an unlocked phone
• Consider the need for a cred in an untrusted country or business location (ticket to a concert)
• In the US police officers are technically required to get a warrant to access a holder’s phone
• In Russia (and elsewhere) authorities ask to hold the phone to acquire the credential
• Phones already enable the release of emergency information to emergency responders
• We can use that as a paradigm for other types of release, like paying at checkout
• Other subjects beside the holder may ask to use the phone to enable their rights

Push-from-me, Pull-by-you

• Pull - the wallet responds to a request to connect and consents to send data
• Use case = the user is accessing a service where authN is required
• The user in on the street and asked to provide documentation to another mobile phone
• The wallet needs to be “on” and able to accept requests
• Some trigger starts the process - user clicks on link - wallet ble or nfc signal accessed
• Verifier sends request with purpose and/or attribute list requirements (mandatory, optional)
• Wallet displays verifier ID and purpose (perhaps optional data requested - opt in)
• Holder consents with a gesture and sends data or an access token to data (OIDC)
• Verifier confirms with a signed receipt that data was received and the purpose of use
• Push - the holder starts the wallet app and sends selected credential data
• Use case = the user is told to enter appropriate right-to-work data before applying for job
• Holder creates a data presentation with a did and sends to the verifier that they chose
• For example the presentation is a smart health card (SHC:)
• And the ICAO MACHINE READABLE TRAVEL DOCS (see below)
• When verifier receives that, they respond with a receipt showing data received and purpose

Selective Disclosure Credentials

• Enabled whenever the credentials provide selective disclosure
• At a minimum the wallet will respond to requests from the Verifier
• The verifier must present purpose or a detailed attribute request
• The wallet will need to map that to what credentials and other data it holds
• The wallet will create a consent screen where the user will accept or reject the request
• The transaction will be logged by the Wallet (Q: is this after acceptance by verifier?)
• ETSI TR 119 476 v1.1.1 (2023-08) Electronic signatures and infrastructure
• Exhaustive - exhausting 82 pages - will need to wait to the market picks the winners
• The simplest form is to create subject attributes of limited scope
• ISO 18013-5 adds the “older than x” attribute, primarily to purchase age-limited goods
• It is expected that some sort of presentation logic will be in the Wallet
• The wallet will select data from one or more creds to create a “Presentation”

Policy

• Policy here means digital representations of policies that apply to wallet
• The wallet provider can create a default policy that the holder can modify
• The holder can set conditions for what to display during consent process
• This may be enabled by app settings or by a separate policy file controlled by the app
• The issuer can set policy that is a part of the credential
• In that case the issuer can limit the wallets it provision with credentials to honor policy
• Eg The Issuer might require that the wallet disable screen capture for data protection
• Or the issuer might require that a lock screen must be enabled with a strong pin for AuthN
• The contract between the user and the verifier with request and consent
• Could be considered to be a statement of policy that the verifier will honor

NIST & DHS attempting to accelerate ID on mobile

• NCCoE project focused on accelerating the adoption of digital identity on mobile devices, specifically Mobile Driver’s Licenses (mDL and mdoc)
• ​

OECD Privacy Principles for cross border data flows

• Collection Limitation Principle (from Selective Disclosure Credentials)
• Data Quality Principle (focused here on the data in the Credential)
• Purpose Specification Principle (focused here on the Verifier’s request)
• Use Limitation Principle (should follow from the stated purpose)
• Security Safeguards Principle (each Entity needs to be Accountable)
• Openness Principle (aka Transparency with Accountability)
• Individual Participation Principle (or User in Control)
• Accountability Principle (requires strong identification of each Entity)

ISO/IEC 29100 Privacy Framework - cost CHF 134

• Consent and choice.
• Purpose legitimacy and specification.
• Collection limitation.
• Data minimization.
• Use, retention and disclosure limitation.
• Accuracy and quality.
• Openness, transparency and notice.
• Individual participation and access.
• Accountability.
• Information security.
• Privacy compliance.

Use Case - ICAO MACHINE READABLE TRAVEL DOCS

• The US Department of State issues digital credentials in the form of ICAO Doc 9303 (ISO/IEC SC17 WG3) compliant eMRTDs. The ICAO DTC specification defines an ASN.1 file that has the same cryptographic security as the eMRTD in terms of determining the authenticity and integrity of the corresponding identity data. ICAO does not define how the ASN.1 file is stored or shared it defines the logical data structure and security objects – that’s it.
• Currently travelers are still required to have the eMRTD on their person as the “Physical Component” as the virtual component [obviously] has no anticloning capability and no Active Authentication capability but, some would argue, those are not necessary for most cross border travel cases where the photo is used to bind the identity of the presenter to the identity claims.

Other activities

• The UK Governments Digital Identity and Attributes Trust Framework (UKDIATF) is going down a certification route the covers components including Holder Provider Services ie. Personal Data Stores and Wallets.
• OIX has a dedicated sub group working on Wallets and PDS's certification.
• Government-Issued Digital Credentials and the Privacy Landscape (OIDF)
• EU Lawmakers Vote to Regulate Digital Wallets (2022-04-06)
• Wallet-wallet interchange from a holder to a gov’t agency
• A family at the border trying to get an appoint gov’t agent
• Migrant farmworker with a special document that may be from the state

Interchange flow for pull model

• The Verifier sends a purpose, data requirement, transparency
• The Wallet creates a consent screen
• Wallet creates a presentation based on that request
• If request is acceptable the holder accepts the request with a gesture
• The verifier receives and validates the response
• The verifier creates a response to the holder which might be:
• Just a receipt of the data with purpose and other data
• Rejection, perhaps with reasons that the wallet might be able to rectify

Interchange flow for push model

• There is a requirement in the real world for credentials
• For example the subject must supply evidence of their right-to-work for an employer
• The employer may have a list of the creds that are acceptable posted somewhere
• The user determines which credential they have that will suffice
• The user opens a wallet on their model device that contains that credential

Interchange Protocol requirements based on DHS request

• MUST have SD-JSON data integrity Proof. (not my favorite)
• MUST use FIPS crypto for covered issues, signing and key agreement - not necessarily other uses (like selective disclosure)
• MUST allow wallets other than Apple & Google.
• OSS libraries MUST be approved (he has no idea what that might mean.) - perhaps by OSS foundation?
• API & specs must be open and available for use by all.
• does ISO meets that requirement.
• ID's will look like DID:WEB:websiteaddr (other possibilities exist)