Credential Specifications

This document covers both the technical construction of credential formats and the type-specific attribute schemas for all credential types used in this project.

The system supports credentials from the EUDI Wallet ecosystem, organized by category:

Government:

• Mobile Driver’s License (mDL) — Full driving licence with optional age verification attributes
• Person Identification Data (PID/National ID) — EU digital identity (mso_mdoc and SD-JWT VC)
• Proof of Age (EU AV) — Dedicated privacy-preserving age verification attestation
• Tax Identification — Tax number attestation (mso_mdoc and SD-JWT VC)
• Pseudonym (Age Over 18) — Privacy-preserving age pseudonym (mso_mdoc and SD-JWT VC)
• Certificate of Residence — Proof of residential address

Travel:

• Photo ID — ISO 23220-2 photo identification
• Travel Reservation — Booking/reservation attestation

Finance:

• IBAN — Bank account attestation (mso_mdoc and SD-JWT VC)

Health:

• European Health Insurance Card (EHIC) — Cross-border healthcare attestation (mso_mdoc and SD-JWT VC)
• Health ID — Health insurance identification (mso_mdoc and SD-JWT VC)

Social Security:

• Portable Document A1 (PDA1) — Social security coordination (mso_mdoc and SD-JWT VC)

Retail:

• Loyalty Card — Retail loyalty programme attestation
• MSISDN — Mobile phone number attestation (mso_mdoc and SD-JWT VC)

Other:

• Power of Representation (PoR) — Legal representation attestation (mso_mdoc and SD-JWT VC)

The authoritative specifications are defined in:

1. ISO/IEC 18013-5:2021 — For mDL (paid standard from ISO)
2. ISO/IEC 23220-2 — For Photo ID
3. EU Commission Implementing Regulation (CIR) 2024/2977 — For PID attributes
4. EU Architecture and Reference Framework (ARF) — Attestation Rulebooks
5. EU Age Verification Profile — For dedicated Proof of Age attestations
6. IETF SD-JWT VC — For SD-JWT-based Verifiable Credentials

Related Documentation:

• For DCQL queries to request these credentials, see DCQL Age Verification
• For acronyms and terminology, see the Glossary

Authoritative Sources

Credential Formats

The EUDI Wallet ecosystem uses two credential formats. Many credential types are available in both.

Format Identifiers and DCQL Fields

Naming convention: mso_mdoc docType and namespace follow eu.europa.ec.eudi.<type>.1 (dot-separated). SD-JWT VC vct follows urn:eu.europa.ec.eudi:<type>:1 (colon-separated). Exception: PID uses the shorter urn:eudi:pid:1.

mso_mdoc Technical Reference

The mso_mdoc format (Mobile Security Object / mDoc) is defined in ISO/IEC 18013-5. It is binary (CBOR) and used for mDL, EU PID, EU Age Verification, and many other attestation types.

Overall Structure

An mDoc presentation consists of a DeviceResponse CBOR structure:

DeviceResponse = {
  "version": "1.0",
  "documents": [ Document+ ],          ; one or more documents
  "status": 0                          ; 0 = OK
}

Document = {
  "docType": tstr,                     ; e.g. "org.iso.18013.5.1.mDL"
  "issuerSigned": IssuerSigned,
  "deviceSigned": DeviceSigned
}

IssuerSigned and the MSO

IssuerSigned carries the issuer-authenticated data:

IssuerSigned = {
  "nameSpaces": IssuerNameSpaces,      ; disclosed claim values
  "issuerAuth": COSE_Sign1             ; the Mobile Security Object (MSO)
}

The MSO is a signed CBOR structure embedded as the payload of a COSE_Sign1. It contains digests of claim values rather than the values themselves:

MobileSecurityObject = {
  "version": "1.0",
  "digestAlgorithm": "SHA-256",
  "valueDigests": {
    "org.iso.18013.5.1": {
      0: bstr,    ; SHA-256 digest of IssuerSignedItemBytes for element 0
      1: bstr,    ; ...
      ...
    }
  },
  "deviceKeyInfo": { "deviceKey": COSE_Key },
  "docType": tstr,
  "validityInfo": { "signed": tdate, "validFrom": tdate, "validUntil": tdate }
}

IssuerSignedItem and Salted Hashing

Each claim is wrapped as an IssuerSignedItemBytes:

IssuerSignedItemBytes = #6.24(bstr .cbor IssuerSignedItem)

IssuerSignedItem = {
  "digestID": uint,          ; matches the index in MSO valueDigests
  "random": bstr,            ; random salt (min 16 bytes)
  "elementIdentifier": tstr, ; claim name, e.g. "given_name"
  "elementValue": any        ; the claim value
}

The digest stored in the MSO is:

digest = SHA-256( cbor(IssuerSignedItemBytes) )
       = SHA-256( cbor(Tag(24, bstr(cbor(IssuerSignedItem)))) )

Important: the hash is computed over the full Tag(24, bstr(...)) encoding, not just the inner CBOR bytes.

Issuer Signing (issuerAuth)

The MSO is signed as a COSE_Sign1:

COSE_Sign1 = [
  protected: bstr .cbor { 1: alg },   ; e.g. alg = -7 (ES256)
  unprotected: { 33: [x5chain certs] },
  payload: bstr .cbor MobileSecurityObject,
  signature: bstr
]

The issuer certificate chain is carried in the x5chain (header label 33) unprotected header.

DeviceSigned and Device Authentication

DeviceSigned proves holder binding — that the presenting device controls the key registered with the credential:

DeviceSigned = {
  "nameSpaces": DeviceNameSpacesBytes,  ; Tag(24, bstr .cbor DeviceNameSpaces)
  "deviceAuth": DeviceAuth
}

DeviceAuth = {
  "deviceSignature": COSE_Sign1         ; or "deviceMac": COSE_Mac0
}

DeviceAuthentication Payload

The device COSE_Sign1 uses a detached payload called DeviceAuthenticationBytes:

DeviceAuthentication = [
  "DeviceAuthentication",
  SessionTranscript,          ; binds the presentation to the specific session
  DocType,                    ; e.g. "org.iso.18013.5.1.mDL"
  DeviceNameSpacesBytes       ; Tag(24, bstr .cbor DeviceNameSpaces)
]

DeviceAuthenticationBytes = #6.24(bstr .cbor DeviceAuthentication)

The wallet signs over DeviceAuthenticationBytes — the outer Tag(24, bstr(...)) wrapper must be included. The verifier must reconstruct identical bytes and use them as the COSE detached payload.

SessionTranscript and OpenID4VP Handover

For OpenID4VP presentations, SessionTranscript is:

SessionTranscript = [
  null,            ; DeviceEngagementBytes (absent for OID4VP)
  null,            ; EReaderKeyBytes (absent for OID4VP)
  OID4VPHandover
]

OID4VPHandover = [
  "OpenID4VPHandover",
  SHA-256( cbor(OID4VPHandoverInfo) )
]

OID4VPHandoverInfo = [
  clientId,             ; the RP's client_id (e.g. "redirect_uri:https://..." or "x509_san_dns:...")
  nonce,                ; from the Authorization Request
  jwkThumbprint,        ; bstr | null — SHA-256 JWK thumbprint of verifier's encryption key
  responseUri           ; the response_uri from the Authorization Request
]

The jwkThumbprint is present only when response_mode=direct_post.jwt (JARM encryption). For plain direct_post, it is CBOR null.

COSE Algorithms

mso_mdoc Encoding Rules

1. String encoding: tstr SHALL be UTF-8, max 150 characters
2. Date encoding:
   • full-date = #6.1004(tstr) per RFC 8943 (YYYY-MM-DD)
   • tdate = RFC 3339 datetime string
3. Timestamps: No fractional seconds; offset SHALL be "Z" (UTC)
4. CBOR canonical rules:
   • Integers as small as possible
   • Length expressions as short as possible
   • Definite-length items only

SD-JWT VC Technical Reference

SD-JWT VC (Selective Disclosure JWT for Verifiable Credentials) is defined in IETF SD-JWT VC. It uses JSON/JWS and is used for PID, cross-device credentials, and other EUDI attestation types.

Overall Structure

An SD-JWT VC presentation is a tilde-separated string:

<Issuer-signed JWT>~<Disclosure_1>~<Disclosure_2>~...~<KB-JWT>

• Issuer-signed JWT: standard JWS containing _sd arrays of digests
• Disclosures: base64url-encoded JSON arrays [salt, claim_name, claim_value]
• KB-JWT (Key Binding JWT): proves holder control (required for wallet presentations)

Issuer-Signed JWT

{
  "alg": "ES256",
  "typ": "vc+sd-jwt"
}
.
{
  "iss": "https://issuer.example.com",
  "iat": 1700000000,
  "exp": 1800000000,
  "vct": "https://credentials.example.com/identity_credential",
  "cnf": { "jwk": { ... } },      // holder's public key (holder binding)
  "_sd_alg": "sha-256",
  "_sd": [
    "X9yH0Ajf...",   // SHA-256 digest of Disclosure for "given_name"
    "aB3kLm9n...",   // SHA-256 digest of Disclosure for "family_name"
    ...
  ],
  "age_equal_or_over": {
    "_sd": [ "qR7sT2uV..." ]   // nested selective disclosure
  }
}
.
<signature>

Disclosures

Each selectively-disclosed claim is represented as a Disclosure:

Disclosure = BASE64URL( JSON([ salt, claim_name, claim_value ]) )

Example (decoded):
[ "dX23abc_SALT_VALUE", "given_name", "Elton" ]

The digest embedded in the JWT is:

digest = BASE64URL( SHA-256( ASCII(Disclosure) ) )

To reveal a claim, the holder includes the corresponding Disclosure in the presentation. The verifier recomputes the digest and checks it against the _sd array.

Key Binding JWT (KB-JWT)

The KB-JWT proves that the holder controls the private key corresponding to cnf.jwk in the issuer JWT, and binds the presentation to a specific transaction:

{
  "alg": "ES256",
  "typ": "kb+jwt"
}
.
{
  "iat": 1700000100,
  "aud": "https://verifier.example.com",   // client_id of the RP
  "nonce": "abc123",                        // nonce from Authorization Request
  "sd_hash": "BASE64URL(SHA-256(issuer_jwt~disc1~disc2~))"  // commitment
}
.
<holder_signature>

sd_hash is SHA-256 of the SD-JWT string up to and including the last ~ before the KB-JWT. This prevents replaying the KB-JWT with a different set of disclosures.

See OpenID4VP §5.3 for Holder Binding Proof requirements.

SD-JWT VC Signing Algorithms

SD-JWT VC Encoding Rules

1. Type claim: vct SHALL be urn:eudi:pid:1 (or domestic extension)
2. Date encoding: ISO 8601-1 YYYY-MM-DD format
3. Technical validity: Use standard JWT claims nbf and exp
4. Hierarchical claims: Use dot notation (e.g. address.country)

Format Comparison

Verification Steps

mso_mdoc Verification

1. Decode the DeviceResponse from base64url → CBOR
2. For each Document:
   • Decode the issuerAuth COSE_Sign1
   • Verify the issuer certificate chain (x5chain header) up to a trusted root
   • Verify the COSE_Sign1 signature over the MSO payload
   • Check MSO expiry, validFrom, docType
   • For each disclosed IssuerSignedItem:
     • Re-encode as IssuerSignedItemBytes = Tag(24, bstr(cbor(IssuerSignedItem)))
     • Compute SHA-256(cbor(IssuerSignedItemBytes))
     • Verify it matches MSO valueDigests[namespace][digestID]
   • Reconstruct SessionTranscript from the Authorization Request parameters
   • Build DeviceAuthentication → DeviceAuthenticationBytes = Tag(24, bstr(cbor(DeviceAuthentication)))
   • Verify the deviceSignature COSE_Sign1 with the MSO deviceKey over DeviceAuthenticationBytes

SD-JWT VC Verification

1. Split the SD-JWT on ~ into: issuer JWT, disclosures, KB-JWT
2. Verify the issuer JWT signature using the issuer’s public key (from iss metadata or x5c header)
3. Check standard JWT claims (exp, nbf, iss, vct)
4. For each presented Disclosure:
   • Compute BASE64URL(SHA-256(disclosure_string))
   • Verify the digest appears in the issuer JWT’s _sd array (recursively for nested claims)
5. Verify the KB-JWT signature using cnf.jwk from the issuer JWT
6. Check KB-JWT aud matches client_id, nonce matches the request nonce
7. Check sd_hash = BASE64URL(SHA-256(issuer_jwt~disc1~disc2~...))

Credential Types Summary

Webapp UI Credential Selection

The Relying Party Demo Webapp offers four credential types for selection:

Implementation

The configuration in js-lib/ewqwe-digital-identity/src/config.ts defines all credential types with their format, identifiers, and claims. The DCQL query builder in js-lib/ewqwe-digital-identity/src/dcql.ts handles both formats:

// mso_mdoc: namespace-based claim paths
{ id: "age_over_18", path: ["org.iso.18013.5.1", "age_over_18"] }

// dc+sd-jwt: flat JSON claim paths
{ id: "family_name", path: ["family_name"] }

1. Mobile Driver’s License (mDL)

Document Type

org.iso.18013.5.1.mDL

Namespace

org.iso.18013.5.1

Specification

The mDL data model is fully specified in ISO/IEC 18013-5:2021. Within the EUDI Wallet ecosystem:

• mDLs SHALL comply with ISO/IEC 18013-5
• mDLs SHALL NOT be implemented as SD-JWT VC-compliant attestations (per the 4th Driving Licence Regulation)
• Encoding uses CBOR per RFC 8949

mDL Attributes (namespace org.iso.18013.5.1)

Driving Privileges Structure

driving_privileges = [* DrivingPrivilege]

DrivingPrivilege = {
  "vehicle_category_code": tstr,
  ? "issue_date": full-date,
  ? "expiry_date": full-date,
  ? "codes": [* Code]
}

Code = {
  "code": tstr,
  ? "sign": tstr,
  ? "value": tstr
}

2. Person Identification Data (PID) / National ID

Document Type (mso_mdoc)

eu.europa.ec.eudi.pid.1

Namespace (mso_mdoc)

eu.europa.ec.eudi.pid.1

Verifiable Credential Type (dc+sd-jwt)

urn:eudi:pid:1

PID Specification

PID attributes are defined in CIR 2024/2977 and the EU ARF PID Rulebook. PIDs:

• SHALL be issued in both ISO/IEC 18013-5 format AND SD-JWT VC format
• Use namespace eu.europa.ec.eudi.pid.1 for ISO format
• Use vct claim urn:eudi:pid:1 for SD-JWT VC format

Mandatory Attributes (CIR 2024/2977)

Optional Attributes (CIR 2024/2977)

Mandatory Metadata (CIR 2024/2977)

Optional Metadata (CIR 2024/2977)

Complex Type Definitions

place_of_birth (ISO format)

place_of_birth = {
  ? "country": tstr,   ; ISO 3166-1 alpha-2 country code
  ? "region": tstr,    ; state, province, district
  ? "locality": tstr   ; municipality, city, town, village
}
; At least one of country, region, or locality SHALL be present

nationalities (ISO format)

nationalities = [+ CountryCode]
CountryCode = tstr  ; ISO 3166-1 alpha-2 country code

Authoritative Requirements (EU ARF Annex 2.02 Topic 3)

Important Note on Age Verification

Per the EU ARF PID Rulebook changelog (v1.1): “Age verification attributes removed, following CIR 2024/2977”

age_over_18 and age_over_21 are NOT valid PID attributes under EU regulations. For age verification, use:

1. mDL (org.iso.18013.5.1.mDL) — Contains age_over_18, age_over_21 as optional attributes
2. Proof of Age (eu.europa.ec.av.1) — Dedicated privacy-preserving attestation with only age_over_18

3. Proof of Age Attestation (EU Age Verification)

Document Type

eu.europa.ec.av.1

Namespace

eu.europa.ec.av.1

Specification

The Proof of Age attestation is defined in the EU Age Verification Profile. Key characteristics:

• Format: ISO mDoc only — NOT SD-JWT VC
• Purpose: Privacy-preserving age verification with minimal data disclosure
• Single attribute: Contains only age_over_18 boolean
• No personal data: Does not store any identity information

Attributes

Protocol Stack

DCQL Query Example

{
  "credentials": [{
    "id": "proof_of_age",
    "format": "mso_mdoc",
    "meta": { "doctype_value": "eu.europa.ec.av.1" },
    "claims": [{"path": ["eu.europa.ec.av.1", "age_over_18"]}]
  }]
}

4. Tax Identification

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.tax.1

Claims

5. Pseudonym (Age Over 18)

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.pseudonym.age_over_18.1

Claims

Provides a privacy-preserving pseudonymous age attestation, disclosing only age_over_18 without any identity information.

6. Certificate of Residence

Document Type

eu.europa.ec.eudi.cor.1

Namespace

eu.europa.ec.eudi.cor.1

Format

mso_mdoc only.

Claims

7. Photo ID

Document Type

org.iso.23220.2.photoid.1

Namespace

org.iso.23220.photoid.1

Specification

Photo ID is defined in ISO/IEC 23220-2 and provides a general-purpose photo identification credential.

Format

mso_mdoc only.

Claims

8. Travel Reservation

Document Type

org.iso.18013.5.1.reservation

Namespace

org.iso.18013.5.1.reservation

Format

mso_mdoc only.

Claims

9. IBAN

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.iban.1

Claims

10. European Health Insurance Card (EHIC)

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.ehic.1

Claims

11. Health ID

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.hiid.1

Claims

12. Portable Document A1 (PDA1)

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.pda1.1

Specification

The Portable Document A1 (PDA1) is a social security coordination document certifying the applicable social security legislation to the holder, typically when working in another EU member state.

Claims

13. Loyalty Card

Document Type

eu.europa.ec.eudi.loyalty.1

Namespace

eu.europa.ec.eudi.loyalty.1

Format

mso_mdoc only.

Claims

14. Mobile Phone Number (MSISDN)

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.msisdn.1

Claims

15. Power of Representation (PoR)

Document Types

Namespace (mso_mdoc)

eu.europa.ec.eudi.por.1

Claims

References

1. ISO/IEC 18013-5:2021 — Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application

   • https://www.iso.org/standard/69084.html

2. Commission Implementing Regulation (EU) 2024/2977 — Rules on PID and EAA

   • https://data.europa.eu/eli/reg_impl/2024/2977/oj

3. EU Architecture and Reference Framework (ARF)

   • Main: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework
   • Annex 2.02 Topic 3 (PID Rulebook HLRs): https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md#a232-topic-3---pid-rulebook
   • PID Rulebook: https://github.com/eu-digital-identity-wallet/eudi-doc-attestation-rulebooks-catalog/blob/main/rulebooks/pid/pid-rulebook.md
   • mDL Rulebook: https://github.com/eu-digital-identity-wallet/eudi-doc-attestation-rulebooks-catalog/blob/main/rulebooks/mdl/mdl-rulebook.md

4. RFC 8949 — Concise Binary Object Representation (CBOR)

5. RFC 8943 — CBOR Tags for Date

6. RFC 8610 — Concise Data Definition Language (CDDL)

7. RFC 7515 — JSON Web Signature (JWS)

8. RFC 8152 — CBOR Object Signing and Encryption (COSE)

9. SD-JWT VC — SD-JWT-based Verifiable Credentials (IETF draft)

   • https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

10. OpenID4VP 1.0 — OpenID for Verifiable Presentations

    • https://openid.net/specs/openid-4-verifiable-presentations-1_0.html

11. OpenID Connect Core 1.0 — Standard Claims

    • https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

12. OpenID Connect for Identity Assurance — Extended claims

    • https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html

See the centralized reference list for all authoritative sources used throughout this documentation.