Skip to content

Check how Transaction Data have been incorporated in MSO MDoc profile #399

@dzarras

Description

@dzarras

MSO MDoc profile for Transaction Data contains the following:

It is RECOMMENDED that each transaction data type defines a data element (NameSpace, DataElementIdentifier, DataElementValue) to be used to return the processed transaction data. Additionally, it is RECOMMENDED that it specifies the processing rules, potentially including any hash function to be applied, and the expected resulting structure.

Some document types support some transaction data (Section 8.4) to be protected using mdoc authentication, as part of the DeviceSigned data structure [ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the KeyAuthorizations. If a Wallet receives a request with a transaction_data type whose data element is unauthorized, the Wallet MUST reject the request due to an unsupported transaction data type.

Checking ISO.18013-5, KeyAuthorizations is part of DeviceKeyInfo and is defined as follows:

DeviceKeyInfo = {
    "deviceKey" : DeviceKey
    ? "keyAuthorizations" : KeyAuthorizations,
    ? "keyInfo" : KeyInfo
}

DeviceKey = COSE_Key

KeyAuthorizations = {
    ? "nameSpaces" : AuthorizedNameSpaces
    ? "dataElements" : AuthorizedDataElements
}

AuthorizedNameSpaces = [+ NameSpace]

AuthorizedDataElements = {+ NameSpace => DataElementsArray}

DataElementsArray = [+ DataElementIdentifier]

KeyInfo = { * int => any } ; Positive integers are RFU, negativeintegers may be used for proprietary use

Given the above in MSO MDoc profile for Transaction Data the following are true:

  1. An Issuer must authorize a specific Device to be able to authorize specific Transaction Data
  2. An Issuer can authorize a specific Device to be able to authorize either all Transaction Data in a specific NameSpace or specific Transaction Data in a specific NameSpace
  3. When the Holder authorizes specific Transaction Data, the Device includes the authorized Transaction Data data element (NameSpace, DataElementIdentifier, DataElementValue) in DeviceSigned

Checking ISO.18013-5, DeviceSigned is defined as follows:

DeviceSigned = {
    "nameSpaces" : DeviceNameSpacesBytes, ; Returned data elements
     "deviceAuth" : DeviceAuth ; Contains the device authentication ; for mdoc authentication
}

DeviceNameSpacesBytes = #6.24(bstr .cbor DeviceNameSpaces)

DeviceNameSpaces = {
    * NameSpace => DeviceSignedItems ; Returned data elements for each namespace
}

DeviceSignedItems = {
    + DataElementIdentifier => DataElementValue ; Returned data element identifier and value
}

DeviceAuth = { ; Either signature or MAC for mdoc authentication
    "deviceSignature" : DeviceSignature // ; "//" means or
    "deviceMac" : DeviceMac
}

It seems that supported MSO MDoc Transaction Data could be modeled as:

data class MsoMDoc(
    override val type: TransactionDataType,
    val nameSpace: MsoMDocNameSpace,
    val identifier: MsoMDocDataElementIdentifier,
    val value: MsoMDocDataElement,
) : SupportedTransactionDataType

With the main problem being how to represent MsoMDocDataElement.

Additionally, OpenId4VP currently misses concrete examples of MSO MDoc Transaction Data. Are they still represented as JsonObject? If so, do they only contain type, and credential_ids, meaning Wallet has prior knowledge of NameSpace, DataElementIdentifier, and DataElementValue based on type?

References:

  1. https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-transaction-data-2
  2. https://github.com/ISOWG10/ISO-18013/blob/main/Working%20Documents/Working%20Draft%20WG%2010_N2549_ISO-IEC%2018013-5-%20Personal%20identification%20%E2%80%94%20ISO-compliant%20driving%20licence%20%E2%80%94%20Part%205-%20Mobile%20driving%20lic.pdf

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions