Support multiple ways to store credential PII and keys

[davidz25]

There are multiple ways how credential PII and key material is stored and also multiple ways to use this for presentment of the credential. Right now we only support a single method which is storing all the PII in the application's data directory and using a SecureArea implementation (typically Android Keystore) for both CredentialKey and a bunch of single-use DeviceKey (one for each MSO) and then using 18013-5 Device Retrieval for presentation.

Other credential storage methods include

• mdoc Direct Access: This involves storing the mdoc on a discrete Secure Element for NFC engagement / NFC data transfer w/o user interaction. This allows the holder to still present their mDL when the phone has run out of battery (but has enough battery left to still have the SE chip running).
  • We (Google) are working on this as part of Android Ready SE and we will contribute code to this project to use it.
• mdoc Device-Signed: In this setup, the IdentityCredentialStore HAL is used and because of its secure properties we can use Device-Signed for all data elements and mdoc MAC authentication. This gives different security and privacy properties than the regular SecureArea-based approach.
• mdoc Server Retrieval: In this setup, the device will convey just a server retrieval token to the reader and the reader can then get the PII / proofs from the issuer server directly. How the server retrieval token is minted is not specified and could be implement in multiple ways. This again has different security and privacy properties than our current approach and it would be worthwhile to support it.
• SD-JWT: this is a lot like what we already support with 18013-5 except that the data structures are JSON based and a little different. The main idea is the same, you use a SecureArea for the key-binding aspect and use those keys at presentment time to prove the binding.

The "Add self-signed document" screen is the first place to start. Today it says "Document type" with options "mDL", "mVR", "micov", "euPID" which are all mdoc specific. Instead it should use words like "Driving License" and for each selected document type we'd also have a list of checkboxes

 Credential Storage formats
  [X] ISO mdoc
  [ ] ISO mdoc Direct Access
  [ ] ISO mdoc w/ Server Retrieval
  [ ] ISO mdoc using Identity Credential API
  [ ] SD-JWT

Notes:

• The ISO mdoc Direct Access option is contingent on the right SE applet being installed so might not be available (grayed out)
• Similarly the ISO mdoc using Identity Credential API requires the Android device to implement the Identity Credential HAL so it might also not be available.
• For non-mdoc formats, we likely need to extend the proposed DocumentType in Issue Document type repository #401 to also include the W3C VC vocabularies from e.g. https://w3c-ccg.github.io/vdl-vocab/.

The current design (CredentialStore with one Credential instance per document) is indeed designed with this in mind and the code for each credential storage method can likely be put behind some kind of CredentialStorageAdapter interface. Will follow up with some more thoughts on this.

[davidz25]

As discussed in today's meeting

// For each Credential Format, an instance of an implementation of this interface exist:
//   MdocDeviceRetrievalAdapter
//   MdocServerRetrievalAdapter
//   MdocDirectAccessAdapter
//
// The application will instantiate these at startup.
//.   
interface CredentialAdapter {

  // At provisioning time
  fun provisionData(credential: Credential, pii: NameSpacedData)

  // At periodic intervals, this is called to e.g. refresh MSO
  fun periodicRefresh()

  // At presentation time, application can query whether a [CredentialStorageAdapter]
  // supports the given [Credential]
  fun isSupportedByCredential(credential: Credential): Boolean

}

// Each [CredentialAdapter] implementation contains specific methods to
// perform the presentation and show format-specific information
// on credential info screen
//
class XXXAdapter : CredentialAdapter {
}