getEntries

Retrieve data entries and associated data from this IdentityCredential.

If an access control check fails for one of the requested entries or if the entry doesn't exist, the entry is simply not returned. The application can detect this by using the getStatus method on each of the requested entries.

It is permissible to call this method multiple times using the same instance. If this is done the same auth-key will be used.

The application should not make any assumptions on whether user authentication is needed. Instead, the application should request the data elements values first and then examine the returned ResultData. If STATUS_USER_AUTHENTICATION_FAILED is returned the application should call getCryptoObject and use the returned androidx.biometric.BiometricPrompt.CryptoObject with a androidx.biometric.BiometricPrompt. Upon successful authentication the application may call getEntries again.

If not null the requestMessage parameter must contain data for the request from the verifier. The content can be defined in the way appropriate for the credential, but there are three requirements that must be met to work with this API:

• The content must be a CBOR-encoded structure.
• The CBOR structure must be a map.
• The map must contain a tstr key "nameSpaces" whose value contains a map, as described in the example below.

If these requirements are not met the InvalidRequestMessageException exception is thrown.

Here's an example of CBOR which conforms to this requirement:

  ItemsRequest = {
    ? "docType" : DocType,
    "nameSpaces" : NameSpaces,
    ? "RequestInfo" : {* tstr => any} ; Additional info the reader wants to provide
  }

  DocType = tstr

  NameSpaces = {
    + NameSpace => DataElements    ; Requested data elements for each NameSpace
  }

  NameSpace = tstr

  DataElements = {
    + DataElement => IntentToRetain
  }

  DataElement = tstr
  IntentToRetain = bool

If mdoc session encryption is used (e.g. if createEphemeralKeyPair has been called) and if setSessionTranscript was called, the X and Y coordinates of the public part of the key-pair previously generated by createEphemeralKeyPair must appear somewhere in the bytes of the CBOR. Each of these coordinates must appear encoded with the most significant bits first and use the exact amount of bits indicated by the key size of the ephemeral keys. For example, if the ephemeral key is using the P-256 curve then the 32 bytes for the X coordinate encoded with the most significant bits first must appear somewhere in the CBOR and ditto for the 32 bytes for the Y coordinate.

If readerAuth is not null it must be the bytes of a COSE_Sign1 structure as defined in RFC 8152. For the payload nil shall be used and the detached payload is the ReaderAuthenticationBytes CBOR described below.

    ReaderAuthentication = [
      "ReaderAuthentication",
      SessionTranscript,
      ItemsRequestBytes
    ]

    ItemsRequestBytes = #6.24(bstr .cbor ItemsRequest)

    ReaderAuthenticationBytes = #6.24(bstr .cbor ReaderAuthentication)

where ItemsRequestBytes are the bytes in the requestMessage parameter.

The public key corresponding to the key used to make the signature, can be found in the x5chain unprotected header element of the COSE_Sign1 structure (as as described in draft-ietf-cose-x509-04). There will be at least one certificate in said element and there may be more (and if so, each certificate must be signed by its successor).

Data elements protected by reader authentication are returned if, and only if, they are mentioned in requestMessage, requestMessage is signed by the top-most certificate in the reader's certificate chain, and the data element is configured with an AccessControlProfile configured with an X.509 certificate which appears in the certificate chain.

Note that only items referenced in entriesToRequest are returned - the requestMessage parameter is used only for enforcing reader authentication.

The reason for having requestMessage and entriesToRequest as separate parameters is that the former represents a request from the remote verifier device (optionally signed) and this allows the application to filter the request to not include data elements which the user has not consented to sharing.

Parameters

Throws