IdentityCredentialStore
An interface to a secure store for user identity documents.
This interface is deliberately fairly general and abstract. To the extent possible, specification of the message formats and semantics of communication with credential verification devices and issuing authorities (IAs) is out of scope. It provides the interface with secure storage but a credential-specific Android application will be required to implement the presentation and verification protocols and processes appropriate for the specific credential type.
The user of these APIs is assumed to be familiar with the ISO/IEC 18013-5:2021 standard, its glossary, and the concepts it introduces.
Multiple credentials can be created. Each credential comprises:
- A document type, which is a string.
- A set of namespaces, which serve to disambiguate value names. It is recommended that namespaces be structured as reverse domain names so that IANA effectively serves as the namespace registrar.
- For each namespace, a set of name/value pairs, each with an associated set of access control profile IDs. Names are strings and values are typed and can be any value supported by CBOR.
- A set of access control profiles, each with a profile ID and a specification of the conditions which satisfy the profile's requirements.
- An asymmetric key pair which is used to authenticate the credential to the Issuing Authority, called the CredentialKey.
- A set of zero or more named reader authentication public keys, which are used to authenticate an authorized reader to the credential.
- A set of named signing keys, which are used to sign collections of values and session transcripts.
Implementing support for user identity documents in secure storage requires dedicated hardware-backed support and may not always be available. In addition to hardware-backed Identity Credential support (which is only available in Android 11 and later and only if the device has support for the Identity Credential HAL), this Jetpack has an Android Keystore backed implementation (also known as the "keystore" implementation) which works on any Android device with API level 24 or later.
The Identity Credential API is designed to be able to evolve and change over time but still provide 100% backwards compatibility. This is complicated by the fact that there may be a version skew between the API used by the application and the version implemented in secure hardware. To solve this problem, the API provides for a way for the application to query for the version of the API implemented in the store through getFeatureVersion. Known feature versions correspond to Android releases and currently include FEATURE_VERSION_202009, FEATURE_VERSION_202101, and FEATURE_VERSION_202201.
The keystore-based store is designed so it implements all capabilities that don't explicitly require hardware features so will always implement the latest feature version defined in this library. Each of the methods in that class will state whether it's implemented in the keystore-based implementation.
When provisioning a document, applications should use either getHardwareInstance or getKeystoreInstance to obtain an IdentityCredentialStore instance and prefer the former if it meets the app's feature version requirement, if any.
Apart from hardware- vs keystore-backed, two different flavors of credential stores exist - the default store and the direct access store. Most often credentials will be accessed through the default store but that requires that the Android device be powered up and fully functional. It is desirable to allow identity credential usage when the Android device's battery is too low to boot the Android operating system, so direct access to the secure hardware via NFC may allow data retrieval, if the secure hardware chooses to implement it.
Credentials provisioned to the direct access store should always use reader authentication to protect data elements. The reason for this is user authentication or user approval of data release is not possible when the device is off.
Properties
- ECKA-DH (Elliptic Curve Key Agreement Algorithm - Diffie-Hellman, see BSI TR-03111).
- HKDF-SHA-256 (see RFC 5869).
- AES-256-GCM (see NIST SP 800-38D).
- HMAC-SHA-256 (see RFC 2104).