11.1. Digital Credential Data Model¶

A Digital Credential data model has the following structure:

Metadata attributes:
- Format-Agnostic: These are high-level metadata attributes that describe the Digital Credential independently of its encoding format. They represent the semantic information about the Credential (e.g., credential_type_identifier, issuing_authority, expiry_date) and remain conceptually consistent across different formats. When a Credential is encoded, these common metadata attributes are mapped to format-specific technical parameters according to the encoding rules of each format (SD-JWT-VC or mdoc-CBOR).
- Format-Specific: These are format-specific metadata parameters that support the security model and protocol requirements.
User attributes: Information about the User, such as identity or qualifications.

The (Q)EAAs are issued by (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT VC or mdoc-CBOR data format. The (Q)EAA data model is use-case driven and may include different User attributes according to its specific purpose. The (Q)EAA metadata attributes are specific for each data format, as described in the following sections.

11.1.1. Format-Agnostic Credential Metadata Attributes¶

The following table defines the common metadata attributes that are applicable to Digital Credentials regardless of their encoding format. These attributes represent the semantic information about the Credential.

Data Identifier	Description
credential_type_identifier	REQUIRED. A unique and collision-resistant identifier that specifies the type and schema of the Digital Credential. It defines the set of claims/attributes that the Digital Credential contains and their structure.
issuing_authority	REQUIRED. Name of the administrative authority that issued the Digital Credential.
issuing_country	REQUIRED. Alpha-2 country code, as specified in ISO 3166-1, of the country or territory of the Credential Issuer.
issuance_date	OPTIONAL. Date (and if possible time) when the Digital Credential was issued and/or the administrative validity period of the Digital Credential began.
expiry_date	OPTIONAL. Date (and if possible time) when the Digital Credential will expire.
location_status	OPTIONAL. The location of validity status information on the Digital Credential where the Credential Issuer revoke Digital Credential.
cryptographic_binding	OPTIONAL. Object containing the proof-of-possession key materials.
verification	OPTIONAL. Object containing Identity proofing and User data verification information.

The following sections provide format-specific attributes and a mapping of the above metadata attributes to format-specific technical parameters when the credential is encoded in SD-JWT VC or mdoc-CBOR format.

11.1.2. SD-JWT-VC Credential Format¶

When Digital Credentials are issued in the SD-JWT VC format, they MUST be compliant to SD-JWT and SD-JWT-VC specifications.

SD-JWT-VC Digital Credentials MUST be signed using the Issuer's private key. SD-JWT VC Digital Credentials MAY be provided along with a Type Metadata Document related to the issued Credential according to Sections 6 and 6.3 of [SD-JWT-VC]. The payload of Digital Credentials MUST contain the _sd_alg claim described in Section 4.1.1 SD-JWT and other claims specified in this section.

The claim _sd_alg indicates the hash algorithm used by the Issuer to generate the digests as described in Section 4.1.1 of SD-JWT. _sd_alg MUST be set to one of the specified algorithms in Section Cryptographic Algorithms.

Claims that are not selectively disclosable MUST be included in the SD-JWT as they are. The digests of the disclosures, along with any decoy if present, MUST be contained in the _sd array, as specified in Section 4.2.4.1 of SD-JWT.

The Disclosures are provided to the Holder together with the SD-JWT in the Combined Format for Issuance that is an ordered series of base64url-encoded values, each separated from the next by a single tilde ('~') character as follows:

<Issuer-Signed-JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>

See SD-JWT-VC and SD-JWT for additional details.

11.1.2.1. Digital Credential SD-JWT Metadata Attributes¶

The JOSE header contains the following mandatory parameters:

Claim	Description	Reference
typ	REQUIRED. It MUST be set to `dc+sd-jwt` as defined in SD-JWT-VC.	RFC 7515 Section 4.1.9.
alg	REQUIRED. Signature Algorithm.	RFC 7515 Section 4.1.1.
kid	REQUIRED. Unique identifier of the public key.	RFC 7515 Section 4.1.8.
trust_chain	OPTIONAL. JSON array containing the trust chain that proves the reliability of the issuer of the JWT.	[OID-FED] Section 4.3.
x5c	REQUIRED. Contains the X.509 public key certificate or certificate chain [RFC 5280] corresponding to the key used to digitally sign the JWT.	RFC 7515 Section 4.1.8 and [SD-JWT-VC] Section 3.5.

The JWT payload contains the following claims. Unless otherwise specifed, the following claims MUST NOT be selectively disclosable.

Claim	Description	Reference
iss	REQUIRED. String. URL string representing the Credential Issuer unique identifier.	[RFC7519, Section 4.1.1].
sub	OPTIONAL. String. The identifier of the subject of the Digital Credential, the User, MUST be opaque and MUST NOT correspond to any anagraphic data or be derived from the User's anagraphic data via pseudonymization. Additionally, it is required that two different Credentials issued MUST NOT use the same `sub` value.	[RFC7519, Section 4.1.2].
iat	OPTIONAL. UNIX Timestamp with the time of JWT issuance, coded as NumericDate as indicated in RFC 7519.	[RFC7519, Section 4.1.6].
exp	REQUIRED. UNIX Timestamp with the expiry time of the JWT, coded as NumericDate as indicated in RFC 7519.	[RFC7519, Section 4.1.4].
nbf	OPTIONAL. UNIX Timestamp with the start time of validity of the JWT, coded as NumericDate as indicated in RFC 7519.	[RFC7519, Section 4.1.4].
issuing_authority	REQUIRED. String. Format-encoded data identifier issuing_authority as defined in Section Format-Agnostic Credential Metadata Attributes.	Commission Implementing Regulation EU_2024/2977.
issuing_country	REQUIRED. String. Format-encoded data identifier issuing_country as defined in Section Format-Agnostic Credential Metadata Attributes.	Commission Implementing Regulation EU_2024/2977.
issuance_date	OPTIONAL. String. Format-encoded data identifier issuance_date as defined in Section Format-Agnostic Credential Metadata Attributes. This attribute pertains to the administrative issuance date, which is typically different from the technical issuance date expressed by the JWT `iat` claim.	Section 2.6 of the ARF PID Rulebook v1.3 [EIDAS-ARF].
date_of_expiry	OPTIONAL. String. Format-encoded data identifier expiry_date as defined in Section Format-Agnostic Credential Metadata Attributes. This attribute pertains to the administrative validity period of the Digital Credential, which is typically different from the technical validity period expressed by the JWT `exp` claim.	Commission Implementing Regulation EU_2024/2977.
status	OPTIONAL. REQUIRED only if the Digital Credential is long-lived. JSON object. Format-encoded data identifier location_status as defined in Section Format-Agnostic Credential Metadata Attributes. It MUST contain either the JSON member status_list.	Section 3.2.2.2 SD-JWT-VC.
cnf	OPTIONAL. JSON object. Format-encoded data identifier cryptographic_binding as defined in Section Format-Agnostic Credential Metadata Attributes, containing the proof-of-possession key materials. By including a cnf (confirmation) claim in a JWT, the Issuer of the JWT declares that the Holder is in control of the private key related to the public one defined in the cnf parameter. The recipient MUST cryptographically verify that the Holder is in control of that key.	[RFC7800, Section 3.1] and Section 3.2.2.2 SD-JWT-VC.
vct	REQUIRED. String. Format-encoded data identifier credential_type_identifier as defined in Section Format-Agnostic Credential Metadata Attributes. Credential type value MUST be a URN and it MUST be set using one of the values obtained from the Credential Issuer metadata, matching of the literals included in this URN MUST be performed in a case-sensitive manner. It is the identifier of the SD-JWT VC type and it MUST be set with a collision-resistant value as defined in Section 2 of RFC 7515. It MUST contain also the number of version of the Credential type. Unless otherwhise specified by EIDAS-ARF and EUDI Rulebooks, the vct SHOULD follow a structure like urn:it-wallet:{credential_type}:{credential_type_version}.	Section 3.2.2.2 SD-JWT-VC.
vct#integrity	OPTIONAL. String. The value MUST be an "integrity metadata" string as defined in Section 3 of [W3C-SRI]. SHA-256, SHA-384 and SHA-512 MUST be supported as cryptographic hash functions. MD5 and SHA-1 MUST NOT be used. This claim MUST be verified according to Section 3.3.5 of [W3C-SRI].	Section 6.1 SD-JWT-VC, [W3C-SRI]
verification	OPTIONAL. JSON object. Format-encoded data identifier verification as defined in Section Format-Agnostic Credential Metadata Attributes. It includes the following sub-value: `trust_framework`: REQUIRED. String identifying the trust framework used for User authentication. It MUST be set using one of the values described in the trust_frameworks_supported map provided within the Credential Issuer Metadata. `assurance_level`: REQUIRED. String identifying the level of identity assurance guaranteed during the User authentication process.	Domestic extension.
_sd	REQUIRED. Array of strings, where each string represents a digest of a Disclosure.	4.2.4.1 SD-JWT
_sd_alg	REQUIRED. String. Hash algorithm used by the Issuer to generate the digests.	4.1.1 SD-JWT

Note

The standard JWT claims nbf and exp are used to express the technical validity period of a SD-JWT VC-compliant Digital Credential.

The status parameter status_list, it MUST be a JSON object compliant with Section 6.2 of TOKEN-STATUS-LIST.

11.1.2.2. (Q)EAA non-normative Examples¶

Below is a non-normative example of (Q)EAA in JSON.

{
    "iss": "https://issuer.example.org",
    "sub": "NzbLsXh8uDCcd7noWXFZAfHkxZsRGC9Xs",
    "iat": 1683000000,
    "exp": 1883000000,
    "issuing_authority": "Credential Issuer Organization",
    "issuing_country": "IT",
    "date_of_expiry": "2033-03-19",
    "status": {
        "status_list": {
            "idx": 5678,
            "uri": "https://issuer.example.org/status"
        }
    },
    "vct": "urn:it-wallet:disabilitycard:1",
    "vct#integrity": "2e40bcd6799008085ffb1a1f3517efee335298fd976b3e655bfb3f4eaa11d171",
    "verification": {
        "trust_framework": "it_wallet",
        "assurance_level": "high"
    },
    "document_number": "XXXXXXXXXX",
    "given_name": "Mario",
    "family_name": "Rossi",
    "birth_date": "1980-01-10",
    "expiry_date": "2024-01-01",
    "tax_id_code": "TINIT-XXXXXXXXXXXXXXXX",
    "constant_attendance_allowance": true
}

The corresponding SD-JWT for the previous data is represented as follow, as decoded JSON for both header and payload.

{
    "alg": "ES256",
    "typ": "dc+sd-jwt",
    "kid": "dB67gL7ck3TFiIAf7N6_7SHvqk0MDYMEQcoGGlkUAAw",
    "x5c": [
        "<Issuer X.509 Certificate>"
    ]
}

{
    "_sd": [
        "D4VkWjnA0WON7HdCGFtU869MSvORHPf8p5fQRD5gNj0",
        "JOQk0kuBSVk80rFlv9VGY-yiIzsfzEJKk3d4RROfzkM",
        "Q7TX7kL8CNUp3BFBKP5xxIuPu5gRgkO6HplM3E1iMIc",
        "Wq3gFfmC0I9Lefw1mh-Bk5XPRtoSCg9aE23uOhxakas",
        "_ckhwGvTwFceg8jAFrQwqbw978ZHsaLJE_hs-rqV9lQ",
        "oF2qeWAbKO_qWGQ5z-HGKeifl2PMIEMbJe8L-PJ-wko",
        "qbRtUHp9Oax9dm5GeKnw_W12Yu1E2DoU6wrFPee7aBo"
    ],
    "exp": 1883000000,
    "iss": "https://issuer.example.org",
    "sub": "NzbLsXh8uDCcd7noWXFZAfHkxZsRGC9Xs",
    "iat": 1683000000,
    "issuing_authority": "Credential Issuer Organization",
    "issuing_country": "IT",
    "date_of_expiry": "2033-03-19",
    "status": {
        "status_list": {
            "idx": 5678,
            "uri": "https://issuer.example.org/status"
        }
    },
    "vct": "urn:it-wallet:disabilitycard:1",
    "vct#integrity": "2e40bcd6799008085ffb1a1f3517efee335298fd976b3e655bfb3f4eaa11d171",
    "verification": {
        "trust_framework": "it_wallet",
        "assurance_level": "high"
    },
    "_sd_alg": "sha-256",
    "cnf": {
        "jwk": {
            "kty": "EC",
            "crv": "P-256",
            "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
            "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
        }
    }
}

In the following the disclosure list is given:

Claim document_number:

SHA-256 Hash: D4VkWjnA0WON7HdCGFtU869MSvORHPf8p5fQRD5gNj0

Disclosure: WyJrZ2h0ZTVNRE5IYlFmZEpIcDg4cENBIiwgImRvY3VtZW50X251bWJlciIs ICJYWFhYWFhYWFhYIl0

Contents: ["kghte5MDNHbQfdJHp88pCA", "document_number", "XXXXXXXXXX"]

Claim given_name:

SHA-256 Hash: qbRtUHp9Oax9dm5GeKnw_W12Yu1E2DoU6wrFPee7aBo

Disclosure: WyJoWDFURXpfejg3N19YQXRyM0NPYVdnIiwgImdpdmVuX25hbWUiLCAiTWFy aW8iXQ

Contents: ["hX1TEz_z877_XAtr3COaWg", "given_name", "Mario"]

Claim family_name:

SHA-256 Hash: Q7TX7kL8CNUp3BFBKP5xxIuPu5gRgkO6HplM3E1iMIc

Disclosure: WyJZV3RJMDZ4RGRDeXZUYWxjSW5URTNBIiwgImZhbWlseV9uYW1lIiwgIlJv c3NpIl0

Contents: ["YWtI06xDdCyvTalcInTE3A", "family_name", "Rossi"]

Claim birth_date:

SHA-256 Hash: oF2qeWAbKO_qWGQ5z-HGKeifl2PMIEMbJe8L-PJ-wko

Disclosure: WyItejM0Y0oxZ0M1VUJQQ0l4OE9oTmlRIiwgImJpcnRoX2RhdGUiLCAiMTk4 MC0wMS0xMCJd

Contents: ["-z34cJ1gC5UBPCIx8OhNiQ", "birth_date", "1980-01-10"]

Claim expiry_date:

SHA-256 Hash: _ckhwGvTwFceg8jAFrQwqbw978ZHsaLJE_hs-rqV9lQ

Disclosure: WyJYY1hsUFZDcWpITnZlQkNubFZQWWdBIiwgImV4cGlyeV9kYXRlIiwgIjIw MjQtMDEtMDEiXQ

Contents: ["XcXlPVCqjHNveBCnlVPYgA", "expiry_date", "2024-01-01"]

Claim tax_id_code:

SHA-256 Hash: Wq3gFfmC0I9Lefw1mh-Bk5XPRtoSCg9aE23uOhxakas

Disclosure: WyJLTmM1LUdrOUNRaF9UZEdicUJLSTdBIiwgInRheF9pZF9jb2RlIiwgIlRJ TklULVhYWFhYWFhYWFhYWFhYWFgiXQ

Contents: ["KNc5-Gk9CQh_TdGbqBKI7A", "tax_id_code", "TINIT-XXXXXXXXXXXXXXXX"]

Claim constant_attendance_allowance:

SHA-256 Hash: JOQk0kuBSVk80rFlv9VGY-yiIzsfzEJKk3d4RROfzkM

Disclosure: WyIyaFFtWXBIeVgtbVpKaHoyeHNVWWNRIiwgImNvbnN0YW50X2F0dGVuZGFu Y2VfYWxsb3dhbmNlIiwgdHJ1ZV0

Contents: ["2hQmYpHyX-mZJhz2xsUYcQ", "constant_attendance_allowance", true]

The combined format for the (Q)EAA issuance is represented below:

eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCIsICJraWQiOiAiZEI2N2dM
N2NrM1RGaUlBZjdONl83U0h2cWswTURZTUVRY29HR2xrVUFBdyIsICJ4NWMiOiBbIjxJ
c3N1ZXIgWC41MDkgQ2VydGlmaWNhdGU-Il19.eyJfc2QiOiBbIkQ0VmtXam5BMFdPTjd
IZENHRnRVODY5TVN2T1JIUGY4cDVmUVJENWdOajAiLCAiSk9RazBrdUJTVms4MHJGbHY
5VkdZLXlpSXpzZnpFSktrM2Q0UlJPZnprTSIsICJRN1RYN2tMOENOVXAzQkZCS1A1eHh
JdVB1NWdSZ2tPNkhwbE0zRTFpTUljIiwgIldxM2dGZm1DMEk5TGVmdzFtaC1CazVYUFJ
0b1NDZzlhRTIzdU9oeGFrYXMiLCAiX2NraHdHdlR3RmNlZzhqQUZyUXdxYnc5NzhaSHN
hTEpFX2hzLXJxVjlsUSIsICJvRjJxZVdBYktPX3FXR1E1ei1IR0tlaWZsMlBNSUVNYkp
lOEwtUEotd2tvIiwgInFiUnRVSHA5T2F4OWRtNUdlS253X1cxMll1MUUyRG9VNndyRlB
lZTdhQm8iXSwgImV4cCI6IDE4ODMwMDAwMDAsICJpc3MiOiAiaHR0cHM6Ly9pc3N1ZXI
uZXhhbXBsZS5vcmciLCAic3ViIjogIk56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1J
HQzlYcyIsICJpYXQiOiAxNjgzMDAwMDAwLCAiaXNzdWluZ19hdXRob3JpdHkiOiAiQ3J
lZGVudGlhbCBJc3N1ZXIgT3JnYW5pemF0aW9uIiwgImlzc3VpbmdfY291bnRyeSI6ICJ
JVCIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDMzLTAzLTE5IiwgInN0YXR1cyI6IHsic3R
hdHVzX2xpc3QiOiB7ImlkeCI6IDU2NzgsICJ1cmkiOiAiaHR0cHM6Ly9pc3N1ZXIuZXh
hbXBsZS5vcmcvc3RhdHVzIn19LCAidmN0IjogInVybjppdC13YWxsZXQ6ZGlzYWJpbGl
0eWNhcmQ6MSIsICJ2Y3QjaW50ZWdyaXR5IjogIjJlNDBiY2Q2Nzk5MDA4MDg1ZmZiMWE
xZjM1MTdlZmVlMzM1Mjk4ZmQ5NzZiM2U2NTViZmIzZjRlYWExMWQxNzEiLCAidmVyaWZ
pY2F0aW9uIjogeyJ0cnVzdF9mcmFtZXdvcmsiOiAiaXRfd2FsbGV0IiwgImFzc3VyYW5
jZV9sZXZlbCI6ICJoaWdoIn0sICJfc2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJ
qd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ
1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlp
NUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.rU0-nlNtkaqNS1h
8h23YMs1mBUIgJQDY6Ouq__Ih0gBEqviTrtkHZu_MgfLWRbAwnu59ubHo0PKkuy3c6D1
9SA~WyJrZ2h0ZTVNRE5IYlFmZEpIcDg4cENBIiwgImRvY3VtZW50X251bWJlciIsICJY
WFhYWFhYWFhYIl0~WyJoWDFURXpfejg3N19YQXRyM0NPYVdnIiwgImdpdmVuX25hbWUi
LCAiTWFyaW8iXQ~WyJZV3RJMDZ4RGRDeXZUYWxjSW5URTNBIiwgImZhbWlseV9uYW1lI
iwgIlJvc3NpIl0~WyItejM0Y0oxZ0M1VUJQQ0l4OE9oTmlRIiwgImJpcnRoX2RhdGUiL
CAiMTk4MC0wMS0xMCJd~WyJYY1hsUFZDcWpITnZlQkNubFZQWWdBIiwgImV4cGlyeV9k
YXRlIiwgIjIwMjQtMDEtMDEiXQ~WyJLTmM1LUdrOUNRaF9UZEdicUJLSTdBIiwgInRhe
F9pZF9jb2RlIiwgIlRJTklULVhYWFhYWFhYWFhYWFhYWFgiXQ~WyIyaFFtWXBIeVgtbV
pKaHoyeHNVWWNRIiwgImNvbnN0YW50X2F0dGVuZGFuY2VfYWxsb3dhbmNlIiwgdHJ1ZV
0~

11.1.2.3. Digital Credential Type Metadata Document¶

When provided, the Type Metadata Document MUST be a JSON object compliant with Section 6.2 of [SD-JWT-VC].

The Credential Type Metadata JSON Document MAY be retrieved through a well-known endpoint. See Section 6.3.3 of SD-JWT-VC. This endpoint, provided by the Credential Issuer, MUST have the following format: https://{Credential Issuer Domain}/.well-known/vct/{vct}. The Endpoint returns a 200 OK status code and supports application/json and application/jwt as content type.

Below a non-normative example is given.

GET /.well-known/vct/urn:eudi:pid:it:1 HTTP/1.1
Host: pidprovider.example.it
Accept: application/jwt

HTTP/1.1 200 OK
Content-Type: application/jwt

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

GET /.well-known/vct/urn:eudi:pid:it:1 HTTP/1.1
Host: pidprovider.example.it
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "name": "Person Identification Data",
  "description": "Digital version of Person Identification Data",
  ...
}

11.1.3. mdoc-CBOR Credential Format¶

When Digital Credentials are issued in mdoc-CBOR format, they MUST be based on the ISO/IEC 18013-5 standard.

The mdoc data elements MUST be encoded in CBOR as defined in RFC 8949.

This data model structures mdoc Digital Credentials into distinct components: namespaces (nameSpaces), and cryptographic proof (issuerAuth). Namespaces categorize and structure data elements (or attributes, see Attribute Namespaces). While the cryptographic proof ensures integrity and authenticity through the Mobile Security Object (MSO).

The MSO securely stores cryptographic digests of attributes within the nameSpaces. This allows Relying Parties to validate disclosed attributes against corresponding digestID values without revealing the entire Credential. See Mobile Security Object for details.

An mdoc-CBOR Digital Credential MUST be compliant with the following structure:

Parameter	Description	Reference
nameSpaces	(map). The namespaces within which the data elements are defined. A Digital Credential MAY include multiple namespaces.	[ISO 18013-5#8.3.2.1.2]
issuerAuth	(COSE_Sign1). Contains Mobile Security Object (MSO), a COSE Sign1 Document, issued by the Credential Issuer.	[ISO 18013-5#9.1.2.4]

Note

Mandatory mDL attributes utilize the standard namespace org.iso.18013.5.1. However, it MAY have a domestic namespace, such as org.iso.18013.5.1.IT, to include additional attributes defined in this implementation profile. Each namespace within the nameSpaces MUST share the same issued document type (docType) value, which identifies the nature of the Digital Credential, as defined in the issuerAuth.

The structure of an mdoc-CBOR Credential is further elaborated in the following sections.

11.1.3.1. Mobile Security Object¶

The issuerAuth represents the Mobile Security Object which is a COSE Sign1 Document defined in RFC 9052. It has the following data structure:

protected header

unprotected header

payload

signature.

The protected header MUST contain the following parameter encoded in CBOR format:

Element	Description	Reference
1	(int). Algorithm used to verify the cryptographic signature of the mdoc Digital Credential.	RFC 9053

Note

Only the signature algorithm MUST be present in the protected header, other elements SHOULD not be present in the protected header.

The unprotected header MUST contain the following parameters, unless otherwise specified:

Element	Description	Reference
4	(tstr, OPTIONAL). Unique identifier of the Issuer JWK. Required when the Issuer of mdoc uses OpenID Federation.	The Infrastructure of Trust
33	(array). X.509 certificate chain about the Issuer. Required for X.509 certificate-based authentication.	RFC 9360

Note

The x5chain is included in the unprotected header with the aim to allow the Holder to update the X.509 certificate chain, related to the Mobile Security Object issuer, without invalidating the signature.

The payload MUST contain the MobileSecurityObject, without the content-type COSE Sign header parameter and encoded as a byte string (bstr) using the CBOR Tag 24.

The MobileSecurityObject MUST have the following attributes, unless otherwise specified:

Element	Description	Reference
docType	(tstr). Format-encoded data identifier credential_type_identifier as defined in Section Format-Agnostic Credential Metadata Attributes. When defined by an ISO standard, It MUST be a string of the form `iso.org.{iso-number}.{part}.{version}.{credential_type}` (e.g. for an mDL, the value MUST be `org.iso.18013.5.1.mDL`). When defined at the european level, it MUST be a string of the form `eu.europa.ec.{credential_type}.{version}` (e.g., `eu.europa.ec.loyaltycard.1.0`). When defined at national level, it MUST be a string of the form `{Trust Anchor reverse domain}.{credential_type}.{version}` (e.g., `it.wallet.trust-registry.pid.1`).	[ISO 18013-5#9.1.2.4]
version	(tstr). Version of the MobileSecurityObject.	[ISO 18013-5#9.1.2.4]
validityInfo	(map, REQUIRED). Contains the MobileSecurityObject issuance and expiration datetimes. It includes the following sub-values: signed (tdate, OPTIONAL). The timestamp indicating when the MobileSecurityObject was signed. validFrom (tdate, OPTIONAL). Timestamp before which the MobileSecurityObject is not considered valid. When present, it MUST be equal to or later than the signed time. validUntil (tdate, REQUIRED). Timestamp after which the MobileSecurityObject is no longer considered valid.	[ISO 18013-5#9.1.2.4]
digestAlgorithm	(tstr). Identifier of the digest algorithm, which MUST match the algorithm defined in the protected header.	[ISO 18013-5#9.1.2.4]
valueDigests	(map). Maps each namespace identifier to a set of digests, where each digest is keyed by a unique digestID and holds the digest value.	[ISO 18013-5#9.1.2.4]
deviceKeyInfo	(map). Contains metadata about the Wallet Instance's public key. It MUST include the following sub-fields, unless otherwise specified: deviceKey (COSE_Key). Contains the public key parameters. keyAuthorizations (map, OPTIONAL). Defines authorizations for either full namespaces or individual data elements. keyInfo (map, OPTIONAL). Contains additional metadata about the key.	[ISO 18013-5#9.1.2.4]
status	(map, OPTIONAL). REQUIRED only if the Digital Credential is long-lived. Format-encoded data identifier location_status as defined in Section Format-Agnostic Credential Metadata Attributes. Contains the MSO revocation information. If present, it includes a status_list based on the TOKEN-STATUS-LIST mechanism as defined in Section 6.3 of TOKEN-STATUS-LIST.	[ISO 18013-5#9.1.2.6]

Note

The private key related to the public key stored in the deviceKey map is used to sign the DeviceSignedItems and to prove the possession of the Digital Credential during the presentation phase (see the presentation phase with mdoc-CBOR).

11.1.3.2. Attribute Namespaces¶

The nameSpaces contains one or more nameSpace entries, each identified by a name. Within each nameSpace, it includes one or more IssuerSignedItemBytes, each encoded as a CBOR byte string with Tag 24 (#6.24(bstr .cbor)), which appears as 24(<<... >>) in diagnostic notation. It represents the disclosure information for each digest within the Mobile Security Object and MUST contain the following attributes:

Name	Description	Reference
digestID	(uint). Reference value to one of the `ValueDigests` provided in the Mobile Security Object.	[ISO 18013-5#9.1.2.5]
random	(bstr). Random byte value used as salt for the hash function. This value SHALL be different for each IssuerSignedItem and it SHALL have a minimum length of 16 bytes.	[ISO 18013-5#9.1.2.5]
elementIdentifier	(tstr). Data element identifier.	[ISO 18013-5#8.3.2.1.2.3]
elementValue	(any). Data element value.	[ISO 18013-5#8.3.2.1.2.3]

11.1.3.3. Digital Credential mdoc-CBOR Metadata Attributes¶

The following elementIdentifiers representing format-encoded metadata attributes are defined for Digital Credentials in mdoc-CBOR format within the respective nameSpace:

Element Identifier	Description	Reference
issuing_country	(tstr, REQUIRED). Format-encoded data identifier issuing_country as defined in Section Format-Agnostic Credential Metadata Attributes. Alpha-2 country code as defined in [ISO 3166-1].	[ISO 18013-5#7.2]
issuing_authority	(tstr, REQUIRED). Format-encoded data identifier issuing_authority as defined in Section Format-Agnostic Credential Metadata Attributes. The value MUST only use Latin1b characters and shall have a maximum length of 150 characters.	[ISO 18013-5#7.2]
issuance_date	(tdate or full-date, OPTIONAL). Format-encoded data identifier issuance_date as defined in Section Format-Agnostic Credential Metadata Attributes. This attribute pertains to the administrative issuance date, which is typically different from the technical issuance date expressed by the MobileSecurityObject parameters `signed` or `validFrom`.	Section 2.6 of the ARF PID Rulebook v1.3 [EIDAS-ARF].
expiry_date	(tdate or full-date, OPTIONAL). Format-encoded data identifier expiry_date as defined in Section Format-Agnostic Credential Metadata Attributes. It MUST be according to ISO 8601-1 YYYY-MM-DD format.	Section 3 of the ARF PID Rulebook v1.3 [EIDAS-ARF]
sub	(uuid, OPTIONAL). Identifies the subject of the mdoc Digital Credential (the User). The identifier MUST be opaque, MUST NOT correspond to any anagraphic data, and MUST NOT be derived from the User's anagraphic data through pseudonymization. Additionally, different Credentials issued to the same User or to different Users MUST NOT use the same sub value.	Domestic extension.
verification	(map, OPTIONAL). Format-encoded data identifier verification as defined in Section Format-Agnostic Credential Metadata Attributes. The CBOR map includes the following members: `trust_framework` (tstr, REQUIRED): trust framework used for User authentication. `assurance_level` (tstr, REQUIRED): level of identity assurance guaranteed during User authentication.	Domestic extension.

Note

Digital Credential User-specific attributes are defined in the Catalog of Digital Credentials. User-specific attributes for mdoc Digital Credentials such as those used in mDL or PID are also included by referencing the appropriate elementIdentifiers defined in ISO/IEC 18013-5 or the EIDAS-ARF specification.

Note

Regardless of the Digital Credential type, the sub value MUST NOT be shown to the User, as it is not a User attribute. It is used for identification purposes by the Credential Issuers.

11.1.3.4. mdoc-CBOR Examples¶

A non-normative example of an mDL encoded in CBOR is shown below in binary encoding.

a26a6e616d65537061636573a2716f72672e69736f2e31383031332e352e318cd818a100a4686469676573744944006672616e646f6d5820790401ed5d0822d1aced942e4b0c41f754eee67b89c5ee3b8fd2c97491a9640671656c656d656e744964656e7469666965726b66616d696c795f6e616d656c656c656d656e7456616c756565526f737369d818a101a4686469676573744944016672616e646f6d58201442881e24514517333019ec24aecaa70bba927d7f2d38ad7cdc3ce82d8561db71656c656d656e744964656e7469666965726a676976656e5f6e616d656c656c656d656e7456616c7565654d6172696fd818a102a4686469676573744944026672616e646f6d582051b4f3831d910861e81da746b221fd89498507476418cedc3709b5d28a7c41d071656c656d656e744964656e7469666965726a62697274685f646174656c656c656d656e7456616c7565d903ec6a313938302d30312d3130d818a103a4686469676573744944036672616e646f6d58200c8f68d1ec3aa445ef68aa10b7a5875fa18ca222a821e23890a227cdc7d25e8f71656c656d656e744964656e7469666965726a69737375655f646174656c656c656d656e7456616c7565d903ec6a323032352d30332d3237d818a104a4686469676573744944046672616e646f6d58200a9ed0d4937673152e52fb3fac0722baf4252e0d0c9869919e3339670203178e71656c656d656e744964656e7469666965726b6578706972795f646174656c656c656d656e7456616c7565d903ec6a323033302d30332d3237d818a105a4686469676573744944056672616e646f6d58204b315ff17cf3a4754a94a6cf1e9ddfdd99f6e86b177b74f173348968ca74e80b71656c656d656e744964656e7469666965726f69737375696e675f636f756e7472796c656c656d656e7456616c7565624954d818a106a4686469676573744944066672616e646f6d5820f8c82c4103f603435d0bc7762074ccc7c2c74925314a1fb5a8ab9cf2a960221f71656c656d656e744964656e7469666965727169737375696e675f617574686f726974796c656c656d656e7456616c75657828497374697475746f20506f6c696772616669636f2065205a656363612064656c6c6f20537461746fd818a107a4686469676573744944076672616e646f6d58201f7a77a353da7bfc4da12691185249c31d421afd59ddac34f9e4fb4d92b8ec5071656c656d656e744964656e7469666965726b62697274685f706c6163656c656c656d656e7456616c756564526f6d61d818a108a4686469676573744944086672616e646f6d582088e94c0365c611b523518d9a1b179ae52e242383576249f4965c40c6c97cf21471656c656d656e744964656e7469666965726f646f63756d656e745f6e756d6265726c656c656d656e7456616c756569585831323334353637d818a109a4686469676573744944096672616e646f6d5820944758b43602b01ad68911b062349845492c04c6a78129bcf8cb5fb1396af2fc71656c656d656e744964656e74696669657268706f7274726169746c656c656d656e7456616c7565590412ffd8ffe000104a46494600010101009000900000ffdb004300130d0e110e0c13110f11151413171d301f1d1a1a1d3a2a2c2330453d4947443d43414c566d5d4c51685241435f82606871757b7c7b4a5c869085778f6d787b76ffdb0043011415151d191d381f1f38764f434f7676767676767676767676767676767676767676767676767676767676767676767676767676767676767676767676767676ffc00011080018006403012200021101031101ffc4001b00000301000301000000000000000000000005060401020307ffc400321000010303030205020309000000000000010203040005110612211331141551617122410781a1163542527391b2c1f1ffc4001501010100000000000000000000000000000001ffc4001a110101010003010000000000000000000000014111213161ffda000c03010002110311003f00a5bbde22da2329c7d692bc7d0d03f52cfb0ff75e7a7ef3e7709723a1d0dae146ddfbb3c039ce07ad2bd47a7e32dbb8dd1d52d6ef4b284f64a480067dfb51f87ffb95ff00eb9ff14d215de66af089ce44b7dbde9cb6890a2838eddf18078f7add62d411ef4db9b10a65d6b95a147381ea0d495b933275fe6bba75c114104a8ba410413e983dff004f5af5d34b4b4cde632d0bf1fd1592bdd91c6411f3934c2fa6af6b54975d106dcf4a65ae56e856001ebc03c7ce29dd9eef1ef10fc447dc9da76ad2aee93537a1ba7e4f70dd8eff0057c6dffb5e1a19854a83758e54528750946ec6704850cd037bceb08b6d7d2cc76d3317fc7b5cc04fb6707269c5c6e0c5b60ae549242123b0e493f602a075559e359970d98db89525456b51c951c8afa13ea8e98e3c596836783d5c63f5a61a99fdb7290875db4be88ab384bbbbbfc7183fdeaa633e8951db7da396dc48524fb1a8bd611a5aa2a2432f30ab420a7a6d3240c718cf031fa9ef4c9ad550205aa02951df4a1d6c8421b015b769db8c9229837ea2be8b1b0d39d0eba9c51484efdb8c0efd8d258daf3c449699f2edbd4584e7af9c64e3f96b9beb28d4ac40931e6478c8e76a24a825449501d867d2b1dcdebae99b9c752ae4ecd6dde4a179c1c1e460938f9149ef655e515c03919a289cb3dca278fb7bf177f4faa829dd8ce3f2ac9a7ecde490971fafd7dce15eed9b71c018c64fa514514b24e8e4f8c5c9b75c1e82579dc1233dfec08238f6add62d391acc1c5256a79e706d52d431c7a0145140b9fd149eb3a60dc5e88cbbc2da092411e9dc71f39a7766b447b344e847dcac9dcb5abba8d145061d43a6fcf1e65cf15d0e90231d3dd9cfe62995c6dcc5ca12a2c904a15f71dd27d451453e09d1a21450961cbb3ea8a956433b781f1ce33dfed54f0e2b50a2b71d84ed6db18028a28175f74fc6bda105c529a791c25c4f3c7a11f71586268f4a66b726e33de9ea6f1b52b181c760724e47b514520a5a28a283ffd9d818a10aa46864696765737449440a6672616e646f6d5820577e4822125f55fe923117aba01fdaefcc67d4aea80018fc22efa8d48e17982f71656c656d656e744964656e7469666965727264726976696e675f70726976696c656765736c656c656d656e7456616c756581a37576656869636c655f63617465676f72795f636f646561416a69737375655f64617465d903ec4b6a323032302d30392d31376b6578706972795f64617465d903ec4b6a323033312d30362d3130d818a10ba46864696765737449440b6672616e646f6d5820fa21d3d890af5f4ea2760d08fd9a6256004cd5aa9d5e697ba5873fb0cddd555e71656c656d656e744964656e74696669657276756e5f64697374696e6775697368696e675f7369676e6c656c656d656e7456616c75656149746f72672e69736f2e31383031332e352e312e697482d818a10ca46864696765737449440c6672616e646f6d58200c3fe75be952ec3c2257031a71f2f54aeabfe7445705cec147fbb2c0f69ad56171656c656d656e744964656e746966696572637375626c656c656d656e7456616c75657820334234684b326d376641395464567a714c72477036573858794a31734e745163d818a10da46864696765737449440d6672616e646f6d5820d22c6db3dd27e066deb2ace6161e47fc6abc7a87c84a10320f14bc66d6e08d4971656c656d656e744964656e7469666965726c766572696669636174696f6e6c656c656d656e7456616c7565a36f74727573745f6672616d65776f726b6969745f77616c6c65746f6173737572616e63655f6c6576656c64686967686865766964656e636581a3647479706565766f7563686474696d656a323032352d30332d32376b6174746573746174696f6ea46474797065736469676974616c5f6174746573746174696f6e707265666572656e63655f6e756d62657273363438352d313631392d333937362d3636373170646174655f6f665f69737375616e63656a323032352d30332d323767766f7563686572a16c6f7267616e697a6174696f6e754d6f746f72697a7a617a696f6e6520436976696c656a69737375657241757468590815d284590229a30126045369707a732d6d646c2d6973737565722d6b6579182159020c30820208308201afa00302010202142eb39c647c81836bcf79fa9cd0b201ec0bf52307300a06082a8648ce3d0403023064310b30090603550406130255533113301106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e636973636f31133011060355040a0c0a4d7920436f6d70616e793113301106035504030c0a6d79736974652e636f6d301e170d3235303332373135353532305a170d3235303430363135353532305a3064310b30090603550406130255533113301106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e636973636f31133011060355040a0c0a4d7920436f6d70616e793113301106035504030c0a6d79736974652e636f6d3059301306072a8648ce3d020106082a8648ce3d03010703420004f33da72d0dd0009b62221b0e839099b12dab5e01021124ebf9060422e648f3c3ec6614a86da1e91e552b2ae35e04d3058ae82b5c65a7f1f26800cb4499652a09a33f303d303b0603551d1104343032863068747470733a2f2f63726564656e7469616c2d6973737565722e6f6964632d66656465726174696f6e2e6f6e6c696e65300a06082a8648ce3d040302034700304402204d1f0819971652b79ebe4825547de3d5554d2f41410225e6b13dab949cda125e022079ba71b823619e49719dce5daa565bf745d3d97e2b87c7f7d6a626f981e653eda1182159020c30820208308201afa00302010202142eb39c647c81836bcf79fa9cd0b201ec0bf52307300a06082a8648ce3d0403023064310b30090603550406130255533113301106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e636973636f31133011060355040a0c0a4d7920436f6d70616e793113301106035504030c0a6d79736974652e636f6d301e170d3235303332373135353532305a170d3235303430363135353532305a3064310b30090603550406130255533113301106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e636973636f31133011060355040a0c0a4d7920436f6d70616e793113301106035504030c0a6d79736974652e636f6d3059301306072a8648ce3d020106082a8648ce3d03010703420004f33da72d0dd0009b62221b0e839099b12dab5e01021124ebf9060422e648f3c3ec6614a86da1e91e552b2ae35e04d3058ae82b5c65a7f1f26800cb4499652a09a33f303d303b0603551d1104343032863068747470733a2f2f63726564656e7469616c2d6973737565722e6f6964632d66656465726174696f6e2e6f6e6c696e65300a06082a8648ce3d040302034700304402204d1f0819971652b79ebe4825547de3d5554d2f41410225e6b13dab949cda125e022079ba71b823619e49719dce5daa565bf745d3d97e2b87c7f7d6a626f981e653ed590390a76776657273696f6e63312e306f646967657374416c676f726974686d667368613235366c76616c756544696765737473a2716f72672e69736f2e31383031332e352e31ac005820f46b65d5060ad060ab9be62ff22ea8633437619ebdc7fa81f2d151159e92bffe015820e506545f6a6fd5d982670b4d62fc2b0688dc8f26754e7b0c574d63f5d72a85ac025820cfcf96fa12d100eeed5f00183d3b6a0888baa47eae85b5b95037eca7bbc0d07e0358208b0772252b0e06b611676b6b3402eb33bf866eb145e49f4d5f23215e6a04777204582014135c96693e2ab08d956876ee491357d906a6dd125557196dfb9811ba54aa8d05582086dcbd99233fbb84a9a2dce3a864a425e6e809300067a4475e3ea2a4d233dc740658202e9512d35ea225e69e7b2180ecc1678dcc3e77a16e36427e64b4f0e2861b4d3a0758204efe55c36f6249d23c473a125afc5181aa30633936494781554971b72ff13700085820cc44a4f9983c5b0b1efc0e82e2867c8d5bbdf89c34bff16a1953c923bb4e4b3e095820775eb2af0aa55f2071d62662b35c99698ae3bc0e2c4af5724ff88476cddd152f0a5820915d0ad53dd23dace34968c263d307c04701a9bb9dc9865af91dc409786fd8330b582047d89ff4fb513044e6f2394236755ac0abf3e4f4a46f40454a458a59f8b7a6fb746f72672e69736f2e31383031332e352e312e6974a20c582016d2098702e896b4614dff1859bd3b42105cac2e62ce7f87dcacc249a656db320d5820755fd7c0f9272a8589c4a661a8aa80dc916018e500884eba316899d653fcb8d16d6465766963654b6579496e666fa1696465766963654b6579a4613102622d3101622d325820f96b29873b61f05403e2963a7ecbc799c9aab28d8a6629e5848cfdef85442866622d335820a9fef033a900c63e3894d8deb805a2a1fb55ef0d2b88e3c0d3336408186485ef67646f6354797065756f72672e69736f2e31383031332e352e312e6d444c6c76616c6964697479496e666fa3667369676e656456c074323032352d30332d32375430303a30303a30305a6976616c696446726f6d56c074323032352d30332d32375430303a30303a30305a6a76616c6964556e74696c56c074323032362d30332d32375430303a30303a30305a66737461747573a16b7374617475735f6c697374a26369647819053c63757269783168747470733a2f2f73746174757370726f76696465722e6578616d706c652e6f72672f2f7374617475736c697374732f315840d09f9acdf7a6be5e4aeb405bfb3b297b1b8003bcf52558a2f39fc6e5cffed40f18f49d2cc0e72a2a56458d8aade591dee8d6540e639bca637f94bd9fa56f345c

The Diagnostic Notation of the CBOR-encoded mDL is given below.

{
"nameSpaces": {
  "org.iso.18013.5.1": [
    24(<<
        {
        "digestID": 0,
        "random": h'790401ed5d0822d1aced942e4b0c41f754eee67b89c5ee3b8fd2c97491a96406',
        "elementIdentifier": "family_name",
        "elementValue": "Rossi"
        }
      >>),
    24(<<
        {
        "digestID": 1,
        "random": h'1442881e24514517333019ec24aecaa70bba927d7f2d38ad7cdc3ce82d8561db',
        "elementIdentifier": "given_name",
        "elementValue": "Mario"
        }
      >>),
    24(<<
        {
        "digestID": 2,
        "random": h'51b4f3831d910861e81da746b221fd89498507476418cedc3709b5d28a7c41d0',
        "elementIdentifier": "birth_date",
        "elementValue": 1004(1980-01-10)
        }
      >>),
    24(<<
        {
        "digestID": 3,
        "random": h'0c8f68d1ec3aa445ef68aa10b7a5875fa18ca222a821e23890a227cdc7d25e8f',
        "elementIdentifier": "issue_date",
        "elementValue": 1004(2025-03-27)
        }
      >>),
    24(<<
        {
        "digestID": 4,
        "random": h'0a9ed0d4937673152e52fb3fac0722baf4252e0d0c9869919e3339670203178e',
        "elementIdentifier": "expiry_date",
        "elementValue": 1004(2030-03-27)
        }
      >>),
    24(<<
        {
        "digestID": 5,
        "random": h'4b315ff17cf3a4754a94a6cf1e9ddfdd99f6e86b177b74f173348968ca74e80b',
        "elementIdentifier": "issuing_country",
        "elementValue": "IT"
        }
      >>),
    24(<<
        {
        "digestID": 6,
        "random": h'f8c82c4103f603435d0bc7762074ccc7c2c74925314a1fb5a8ab9cf2a960221f',
        "elementIdentifier": "issuing_authority",
        "elementValue": "Istituto Poligrafico e Zecca dello Stato"
        }
      >>),
    24(<<
        {
        "digestID": 7,
        "random": h'1f7a77a353da7bfc4da12691185249c31d421afd59ddac34f9e4fb4d92b8ec50',
        "elementIdentifier": "birth_place",
        "elementValue": "Roma"
        }
      >>),
    24(<<
        {
        "digestID": 8,
        "random": h'88e94c0365c611b523518d9a1b179ae52e242383576249f4965c40c6c97cf214',
        "elementIdentifier": "document_number",
        "elementValue": "XX1234567"
        }
      >>),
    24(<<
        {
        "digestID": 9,
        "random": h'944758b43602b01ad68911b062349845492c04c6a78129bcf8cb5fb1396af2fc',
        "elementIdentifier": "portrait",
        "elementValue": h'ffd8ffe000104a46494600010101009000900000ffdb004300130d0e110e0c
        13110f11151413171d301f1d1a1a1d3a2a2c2330453d4947443d43414c566d5d4c51685241435f82
        606871757b7c7b4a5c869085778f6d787b76ffdb0043011415151d191d381f1f38764f434f767676
        76767676767676767676767676767676767676767676767676767676767676767676767676767676
        76767676767676ffc00011080018006403012200021101031101ffc4001b00000301000301000000
        000000000000000005060401020307ffc40032100001030303020502030900000000000001020304
        0005110612211331141551617122410781a1163542527391b2c1f1ffc40015010101000000000000
        00000000000000000001ffc4001a110101010003010000000000000000000000014111213161ffda
        000c03010002110311003f00a5bbde22da2329c7d692bc7d0d03f52cfb0ff75e7a7ef3e7709723a1
        d0dae146ddfbb3c039ce07ad2bd47a7e32dbb8dd1d52d6ef4b284f64a480067dfb51f87ffb95ff00
        eb9ff14d215de66af089ce44b7dbde9cb6890a2838eddf18078f7add62d411ef4db9b10a65d6b95a
        147381ea0d495b933275fe6bba75c114104a8ba410413e983dff004f5af5d34b4b4cde632d0bf1fd
        1592bdd91c6411f3934c2fa6af6b54975d106dcf4a65ae56e856001ebc03c7ce29dd9eef1ef10fc4
        47dc9da76ad2aee93537a1ba7e4f70dd8eff0057c6dffb5e1a19854a83758e54528750946ec67048
        50cd037bceb08b6d7d2cc76d3317fc7b5cc04fb6707269c5c6e0c5b60ae549242123b0e493f602a0
        75559e359970d98db89525456b51c951c8afa13ea8e98e3c596836783d5c63f5a61a99fdb7290875
        db4be88ab384bbbbbfc7183fdeaa633e8951db7da396dc48524fb1a8bd611a5aa2a2432f30ab420a
        7a6d3240c718cf031fa9ef4c9ad550205aa02951df4a1d6c8421b015b769db8c9229837ea2be8b1b
        0d39d0eba9c51484efdb8c0efd8d258daf3c449699f2edbd4584e7af9c64e3f96b9beb28d4ac4093
        1e6478c8e76a24a825449501d867d2b1dcdebae99b9c752ae4ecd6dde4a179c1c1e460938f9149ef
        655e515c03919a289cb3dca278fb7bf177f4faa829dd8ce3f2ac9a7ecde490971fafd7dce15eed9b
        71c018c64fa514514b24e8e4f8c5c9b75c1e82579dc1233dfec08238f6add62d391acc1c5256a79e
        706d52d431c7a0145140b9fd149eb3a60dc5e88cbbc2da092411e9dc71f39a7766b447b344e847dc
        ac9dcb5abba8d145061d43a6fcf1e65cf15d0e90231d3dd9cfe62995c6dcc5ca12a2c904a15f71dd
        27d451453e09d1a21450961cbb3ea8a956433b781f1ce33dfed54f0e2b50a2b71d84ed6db18028a2
        8175f74fc6bda105c529a791c25c4f3c7a11f71586268f4a66b726e33de9ea6f1b52b181c760724e
        47b514520a5a28a283ffd9'        
        }
      >>),
    24(<<
        {
        "digestID": 10,
        "random": h'577e4822125f55fe923117aba01fdaefcc67d4aea80018fc22efa8d48e17982f',
        "elementIdentifier": "driving_privileges",
        "elementValue": [
          {
            "vehicle_category_code": "A",
            "issue_date": 1004("2020-09-17"),
            "expiry_date": 1004("2031-06-10")
            }
          ]
        }
      >>),
    24(<<
        {
        "digestID": 11,
        "random": h'fa21d3d890af5f4ea2760d08fd9a6256004cd5aa9d5e697ba5873fb0cddd555e',
        "elementIdentifier": "un_distinguishing_sign",
        "elementValue": "I"
        }
      >>)
    ],
  "org.iso.18013.5.1.IT": [
    24(<<
        {
        "digestID": 12,
        "random": h'0c3fe75be952ec3c2257031a71f2f54aeabfe7445705cec147fbb2c0f69ad561',
        "elementIdentifier": "sub",
        "elementValue": "3B4hK2m7fA9TdVzqLrGp6W8XyJ1sNtQc"
        }
      >>),
    24(<<
        {
        "digestID": 13,
        "random": h'd22c6db3dd27e066deb2ace6161e47fc6abc7a87c84a10320f14bc66d6e08d49',
        "elementIdentifier": "verification",
        "elementValue": {
          "trust_framework": "it_wallet",
          "assurance_level": "high",
          }
        }
      >>)
    ]
  },
"issuerAuth": [
    << {1: -7} >>,                 
    {                         
        33: h'30820208308201afa00302010202142eb39c647c81836bcf79fa9cd0b201ec0bf52307300a0
        6082a8648ce3d0403023064310b30090603550406130255533113301106035504080c0a43616c6966
        6f726e69613116301406035504070c0d53616e204672616e636973636f31133011060355040a0c0a4
        d7920436f6d70616e793113301106035504030c0a6d79736974652e636f6d301e170d323530333237
        3135353532305a170d3235303430363135353532305a3064310b30090603550406130255533113301
        106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e63697363
        6f31133011060355040a0c0a4d7920436f6d70616e793113301106035504030c0a6d79736974652e6
        36f6d3059301306072a8648ce3d020106082a8648ce3d03010703420004f33da72d0dd0009b62221b
        0e839099b12dab5e01021124ebf9060422e648f3c3ec6614a86da1e91e552b2ae35e04d3058ae82b5
        c65a7f1f26800cb4499652a09a33f303d303b0603551d1104343032863068747470733a2f2f637265
        64656e7469616c2d6973737565722e6f6964632d66656465726174696f6e2e6f6e6c696e65300a060
        82a8648ce3d040302034700304402204d1f0819971652b79ebe4825547de3d5554d2f41410225e6b1
        3dab949cda125e022079ba71b823619e49719dce5daa565bf745d3d97e2b87c7f7d6a626f981e653ed'
    }, 
    << 24(<<    
        {  
            "version": "1.0",
            "digestAlgorithm": "SHA-256",
            "valueDigests": {
              "org.iso.18013.5.1": {
                  0: h'f46b65d5060ad060ab9be62ff22ea8633437619ebdc7fa81f2d151159e92bffe',
                  1: h'e506545f6a6fd5d982670b4d62fc2b0688dc8f26754e7b0c574d63f5d72a85ac',
                  2: h'cfcf96fa12d100eeed5f00183d3b6a0888baa47eae85b5b95037eca7bbc0d07e',
                  3: h'8b0772252b0e06b611676b6b3402eb33bf866eb145e49f4d5f23215e6a047772',
                  4: h'14135c96693e2ab08d956876ee491357d906a6dd125557196dfb9811ba54aa8d',
                  5: h'86dcbd99233fbb84a9a2dce3a864a425e6e809300067a4475e3ea2a4d233dc74',
                  6: h'2e9512d35ea225e69e7b2180ecc1678dcc3e77a16e36427e64b4f0e2861b4d3a',
                  7: h'4efe55c36f6249d23c473a125afc5181aa30633936494781554971b72ff13700',
                  8: h'cc44a4f9983c5b0b1efc0e82e2867c8d5bbdf89c34bff16a1953c923bb4e4b3e',
                  9: h'775eb2af0aa55f2071d62662b35c99698ae3bc0e2c4af5724ff88476cddd152f',
                 10: h'915d0ad53dd23dace34968c263d307c04701a9bb9dc9865af91dc409786fd833',
                 11: h'47d89ff4fb513044e6f2394236755ac0abf3e4f4a46f40454a458a59f8b7a6fb'
                },
              "org.iso.18013.5.1.IT": {
                 12: h'16d2098702e896b4614dff1859bd3b42105cac2e62ce7f87dcacc249a656db32',
                 13: h'755fd7c0f9272a8589c4a661a8aa80dc916018e500884eba316899d653fcb8d1'
                }
              },
            "deviceKeyInfo": {
              "deviceKey": {
                 1: 2,
                -1: 1,
                -2: h'f96b29873b61f05403e2963a7ecbc799c9aab28d8a6629e5848cfdef85442866',
                -3: h'a9fef033a900c63e3894d8deb805a2a1fb55ef0d2b88e3c0d3336408186485ef'
                  }
              },
            "docType": "org.iso.18013.5.1.mDL",
            "validityInfo": {
                "signed": 0("2025-03-27T00:00:00Z"),
                "validFrom": 0("2025-03-27T00:00:00Z"),
                "validUntil": 0("2026-03-27T00:00:00Z")
             },
           "status": {
            "status_list": {
              "idx": 1340,
              "uri": "https://statusprovider.example.org/statuslists/1"
            }
        }
        }
    >>) >>,
    h'd09f9acdf7a6be5e4aeb405bfb3b297b1b8003bcf52558a2f39fc6e5cffed40f18f49d2cc0e72a2a5645
      8d8aade591dee8d6540e639bca637f94bd9fa56f345c'
]
}

11.1.3.5. CBOR Acronyms¶

Acronym	Meaning
tstr	Text String
bstr	Byte String
int	Signed Integer
uint	Unsigned Integer
uuid	Universally Unique Identifier
bool	Boolean (true/false)
tdate	Tagged Date (for example, Tag 0 is used to indicate a date/time string in RFC 3339 format)

11.1.4. Cross-Format Credential Parameters Mapping¶

The following table provides a comparative mapping between the data structures of SD-JWT VC and mdoc-CBOR Digital Credentials. It outlines the key data elements and parameters used in each format, highlighting both commonalities and differences. In particular, it shows how core concepts - such as Credential Issuer information, validity, Cryptographic Binding, and disclosures - are represented in these Credential formats.

For SD-JWT-VC, parameters are marked with (hdr) if they are located in the JOSE header, and (pld) if they appear in the payload of the JWT. In mdoc-CBOR, these parameters are identified within the issuerAuth or nameSpaces structures.

Information Related To	SD-JWT-VC Parameters	mdoc-CBOR Parameters
Digital Credential type definition	vct (pld)	issuerAuth.doctype
Issuer	iss (pld) issuing_authority (pld) issuing_country (pld)	- nameSpaces.elementIdentifier.issuing_authority nameSpaces.elementIdentifier.issuing_country
Subject	sub (pld)	nameSpaces.elementIdentifier.sub
Validity period	iat (pld) exp (pld) nbf (pld) expiry_date (pld)	issuerAuth.validityInfo.signed issuerAuth.validityInfo.validUntil issuerAuth.validityInfo.validFrom nameSpaces.elementIdentifier.expiry_date
Status mechanism	status_list (pld)	issuerAuth.status_list
Signature	alg (hdr) kid (hdr)	issuerAuth.1 (alg) issuerAuth.4 (kid)
Trust anchors	trust_chain (OID-FED) (hdr) x5c (hdr)	- issuerAuth.33 (x5chain)
Cryptographic Binding	cnf.jwk (pld)	issuerAuth.deviceKeyInfo.deviceKey
Selective Disclosure	_sd_alg (pld) _sd (pld)	issuerAuth.digestAlgorithm issuerAuth.valueDigests
Integrity	vct#integrity (pld) Type_Metadata.extends#integrity (hdr)	-
Digital Credential format	typ (hdr)	-
Digital Credential auditability	verification (pld)	nameSpaces.elementIdentifier.verification
Disclosures	salt claim name claim value	nameSpaces