ISO 18013-5 feature support
A feature-by-feature reference for how MATTR VII supports ISO/IEC 18013-5 when issuing mDocs, covering the Mobile Security Object, device key binding, revocation, mDL data elements and the issuing authority certificate profiles.
Overview
This page is a feature-by-feature reference for how MATTR VII supports ISO/IEC 18013-5 when acting as an mdoc issuer.
ISO/IEC 18013-5 defines the mdoc data model, the Mobile Security Object (MSO) that an issuer signs, and the certificate profiles an issuing authority uses. MATTR VII applies the same behavior whichever way the mDoc is issued, through OID4VCI or through direct issuance.
It complements ISO-compliant credentials, which shows how to configure a compliant mDoc, and the certificates overview, which explains the IACA and document signer certificates. Use this page when you need to know whether a specific clause is implemented before you design an issuance solution.
If you are building a wallet or a verifier, see ISO 18013-5 feature support (Holder) or ISO 18013-5 feature support (Verifier) instead.
How to read this page
Each feature is given one of the following support statuses:
- Supported: Implemented and available for use.
- Partial: Implemented with a specific limitation, described in the notes.
- Not supported: Not currently implemented.
- Not applicable: Not relevant to the issuer role.
The Spec column cites the relevant clause of ISO/IEC 18013-5 second edition, as published in its
Draft International Standard (DIS) form. This is a draft, so clause numbers can still change before
publication. The second edition also reorders the document, so its clause numbers differ from the
2021 edition. Clause numbers beginning with a letter refer to an annex, for example B.1.4.
Features introduced by the second edition, such as MSO revocation, are labeled in the notes.
If you need clarification on any feature, contact us.
Mobile Security Object
| Feature | Spec | Status | Notes |
|---|---|---|---|
IssuerSigned structure | 12.3.4 | Supported | Each mDoc carries issuerAuth and nameSpaces, with every data element encoded as a tag 24 IssuerSignedItemBytes. |
| MSO version | 12.3.4 | Supported | Always 1.0. |
MSO signature (issuerAuth) | 12.3.4 | Supported | An untagged COSE_Sign1, with alg in the protected header and the document signer certificate in the unprotected x5chain header. |
| Signature algorithm | 12.3.4, 12.7.2 | Partial | ES256 on P-256 only. ES384, ES512 and EdDSA are not used. |
x5t certificate thumbprint header | 12.3.4 | Not supported | This optional header is not included. Readers find the signer certificate in x5chain. |
| Digest algorithm | 12.3.5 | Partial | SHA-256 only. |
| Random value per data element | 12.3.5 | Supported | Each IssuerSignedItem carries a fresh 16 byte random value, the minimum the specification requires. |
digestID assignment | 12.3.4 | Supported | Digest identifiers are shuffled within each namespace, so they do not correlate with the order of data elements or across credentials. |
validityInfo (signed, validFrom, validUntil) | 12.3.4 | Supported | Encoded as tag 0 UTC date-time strings in whole seconds. validFrom defaults to the signing time and cannot be earlier than it. |
validUntil within the document signer certificate validity | 12.3.4 | Supported | Issuance is rejected if the mDoc would remain valid after its document signer certificate expires. |
expectedUpdate | 12.3.4 | Partial | Can be set through direct issuance. It is not set on mDocs issued through OID4VCI. |
Coarsened signed timestamp | 12.3.4 | Not supported | signed records the actual signing time rather than a rounded value. |
| Additional MSO members | 12.3.4 | Supported | When branding is configured, the MSO carries a MATTR-specific member that conformant readers ignore. |
Device key binding
| Feature | Spec | Status | Notes |
|---|---|---|---|
deviceKeyInfo with an untagged COSE_Key | 12.3.4 | Supported | The holder's public key from the issuance request or proof is embedded in the MSO. |
| Device key curves | 12.7.2 | Partial | P-256 only. Direct issuance requires a P-256 key, and OID4VCI proofs must use ES256. |
| Device key usable for MAC authentication | 12.4.5 | Supported | A P-256 device key supports key agreement, so a wallet can use either MAC or signature device authentication. MATTR VII does not restrict the choice. |
keyAuthorizations | 12.3.4 | Not supported | An issuer cannot restrict which namespaces or data elements the device key may sign. |
keyInfo | 12.3.4 | Not supported |
MSO revocation
MSO revocation is a second edition feature. MATTR VII supports both mechanisms the specification defines, status lists and identifier lists. For the full detail of status lists, see Token Status List feature support (Issuer).
| Feature | Spec | Status | Notes |
|---|---|---|---|
status element in the MSO | 12.3.6.2 | Supported | Present when the credential is issued with revocation enabled. |
Status list (status_list) | 12.3.6.3, 12.3.6.5 | Supported | The default mechanism. The MSO references a list URI and index. Lists are signed CWTs that use one bit per entry, signed by a status list signer certificate issued under your IACA. |
Identifier list (identifier_list) | 12.3.6.4 | Supported | Selected per credential through direct issuance. The MSO references a list URI and a unique 16 byte identifier, and revoking the credential adds that identifier to the list. |
certificate element in the status reference | 12.3.6.2 | Partial | Included for identifier lists, carrying the IACA certificate. Omitted for status lists, where the status list signer certificate chains to the IACA, which the specification allows. |
Data model and mDL data elements
MATTR VII issues any mdoc document type, including the mDL. It encodes the data elements you supply but does not enforce the mDL data element set, so your credential configuration is responsible for mDL content. See ISO-compliant credentials.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Any document type and namespace | 8.1, 13.4.1 | Supported | mDL document types (org.iso.18013.5.1.mDL) are recognized so that the stricter document signer validity limit applies. |
| Domestic namespaces | 13.4.9 | Supported | Add elements under your own namespace, for example org.iso.18013.5.1.US. |
full-date (tag 1004) | 8.3, 13.4.2 | Supported | date claims in YYYY-MM-DD form are encoded as tag 1004. |
tdate (tag 0) | 8.3, 13.4.2 | Supported | dateTime claims are normalized to UTC in whole seconds. |
driving_privileges | 13.4.2 | Supported | A dedicated claim type encodes vehicle_category_code, issue_date and expiry_date, with both dates as full-date, plus codes. |
| Tagged dates inside other nested structures | 13.4.2 | Partial | Object and array claims can hold strings, numbers and booleans. driving_privileges is the only structure with embedded dates. |
portrait and other binary elements | 13.4.3 | Partial | Encoded as a byte string. Image format and size are not validated. |
age_over_NN attestations | 13.4.6 | Partial | Issue them as boolean claims. MATTR VII does not derive them from birth_date or check their names. |
| mDL schema validation | 13.4.1, 13.4.2 | Not supported | Mandatory mDL data elements and identifiers are not enforced. |
Certificates and CRLs
MATTR VII can generate and manage your IACA, or you can register an unmanaged (external) IACA that you manage yourself. See the certificates overview.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| IACA root certificate generated by MATTR VII | B.1.2 | Supported | Self-signed X.509 v3 on P-256, signed with ECDSA SHA-256. It includes critical basicConstraints (CA, path length 0), keyUsage (keyCertSign, cRLSign), a subject key identifier, an issuer alternative name and an ISO 3166-1 country code. Validity defaults to 10 years and cannot exceed 20. |
| CRL distribution point on the IACA | B.1.2 | Supported | Included on IACAs generated by MATTR VII. |
| Unmanaged (external) IACA root certificate | B.1.2 | Supported | Unmanaged IACAs can use P-256, P-384, P-521 or brainpool curves. The MSO is still signed by a P-256 document signer with ES256. |
| IACA link certificate | B.1.3 | Not supported | No link certificate is created when you replace an IACA. |
| Document signer certificate | B.1.4 | Supported | Issued under your IACA on P-256, with digitalSignature as the only key usage, the mdlDS extended key usage (1.0.18013.5.1.2), authority and subject key identifiers, a CRL distribution point and alternative names. |
| Document signer validity of 457 days or less | B.1.4 | Partial | Enforced for mDL document types. Document signers for other document types can be valid for longer. |
| Document signer generation and rotation | B.1.4 | Supported | For an IACA managed by MATTR VII, MATTR VII creates or reuses a document signer whose validity covers the requested credential validity. For an unmanaged (external) IACA, you supply document signer certificates signed by your certificate authority, and issuance fails if no suitable signer is available. |
| Certificate serial numbers | B.1.2, B.1.4 | Supported | Random positive integers of 80 bits. |
| CRL for an IACA managed by MATTR VII | B.2 | Supported | A v2 CRL signed with ECDSA SHA-256, carrying an authority key identifier and CRL number. It is reissued immediately when you revoke a document signer. |
| CRL for an unmanaged (external) IACA | B.2 | Not applicable | Your own certificate authority publishes the CRL. |
| VICAL | Annex C | Not applicable | Not part of issuance. MATTR VII publishes VICALs as a separate capability. See the VICAL overview. |
Not currently supported
At a glance, the following features are not currently supported by MATTR VII when issuing mDocs:
- MSO signature algorithms other than
ES256(12.3.4) - Digest algorithms other than
SHA-256(12.3.5) - The
x5tcertificate thumbprint header (12.3.4) - Coarsened
signedtimestamps (12.3.4) - Device key curves other than P-256 (12.7.2)
- Issuer-defined
keyAuthorizationsandkeyInfo(12.3.4) - mDL schema validation (13.4)
- IACA link certificates (B.1.3)
Related
How would you rate this page?
Last updated on