Mobile Driver's License Presentation

Full Title or Meme

Mobile Driver's License Presentation maps ISO 18013-5 wallet presentation to DIF Presentation Exchange.

Context

• This is a specific use case of both Presentation and the Presentation from a Wallet wiki pages.
• The DIF Presentation Exchange is looking for test cases. This is such a test case (ie a use case with teeth).
• This use case looks at the wallet as the source of Presentation Statements, which is not necessarily the full scope of the DIF WG.
• See wiki page Consent for Mobile Credentials to understand the conditions that must be met for consent to be meaningful.

Actors

• Holder = The entity that submits proofs to a Verifier to satisfy the requirements described in a Presentation Definition (may or may not be the subject)
• mDL holder = individual to whom an mDL is issued = legitimate holder of the driving privileges reflected on an mDL = subject of the mDL
• Device = smartphone or similar with a trusted wallet (in the ISO docs this is conflated with the doc that resides on the device (aka mdoc)
• Verifier = The entity that defines what proofs they require from a Holder (via a Presentation Definition) in order to proceed with an interaction.
• mDL verifier = entity using an mDL reader to verify an mDL
• Issuing Authority = trusted signer of data elements
• Trust Authority = TBD source of certs

Transaction

1. The holder and verifier establish a session
2. The verifier asks for mDL data
3. mDL send data by value or by reference
4. The verifier may or may not request other data

• Transport can be by various NFC or QR code.
• Format is CBOR - represented here as json.

Security

data	mDL	DIF	Comments
Encryption	Encrypting with authentication of the mdoc requests and mdoc responses protects mdoc data from eavesdropping and alteration.	out-of-scope	it is not clear how mDL protection of alteration is meant to work
session keys	standard ephemeral key ECDH to establish session keys	out-of-scope	etc...
Reader <-> Trust authority	TLS	out-of-scope	etc..
Reader <-> Holder	exchange engagement information (see below)	assurances as to the provenance, identity, or status of a Presentation Definition from digital signatures may be required	DIF seems to be voluntary with no way for holder to make requirements known.
channel	off-line from device or on-line (OIDC or WebAPI) mDL reader receives the token and URL from the mDL accesses data from issuing authority	on-line only -- channel left open	It may be that DIF treats device-device flows as on-line
privacy	supports selective release -- device always stays in user possession	not addressed	etc..

Device Engagement

data	mDL	DIF	Comments
Version	tstr	unkown	etc...
Device and protocol information	Device, server and protocol information	not defined	This is key to trusting data from the device
Security	cipher suite and key info	open	neither checks identity or security of the device or software

Request

data	mDL	DIF	Comments
Device request	The point of this piece is the assurance that the device is trustworthy	Presentation Request	etc...
version	tstr	unknown	see below
Security	encrypted path	current draft is not clear	etc..

DIF Example

{
  "id": "drivers_license_information",
  "name": "Fred's Bar and Grill",
  "purpose": "Proof of age",
  "metadata": {
    "client_id": "4fb540be-3a7f-0b47-bb37-3821bd766ed4",
    "redirect_uri": "https://yourwatchful.gov/verify"
  },
  "schema": [
    {
      "uri": "https://yourwatchful.gov/drivers-license-schema.json",
      "required": true
    }
  ],
  "constraints": {
    "fields": [
      {
        "path": ["$.expirationDate"],
        "filter": {
          "type": "string",
          "format": "date-time",
          "min": "2020-12-31T23:59:59.000Z"
        }
      }
    ]
  }
}

Privacy

hack-a-thons are not designed to share negative information. The information i have was directly from participants (that are known and trusted by me) who explained that the CA mDL is not designed to limit data sharing in any way and tests that were run could ask for, and receive, any data on the mDL. This is easily tested if you have access to an mDL card and a verifier. I have not been able to acquire an mDL because of my state. Note that ISO specs put all of the enforcement on the issuer who theoretically controls the wallet design.

I fully expect the same from the OIDF interop tests of OID4VP in the EUDIW. User privacy will never be tested except by real-world failures, just as it is today. Wayne Chang may have some insights (he is not my source of information but did design the original CA mDL wallet.)

Alexis Hancock Director of Engineering Perhaps we could create a site somewhere to collect feedback?

Response

• Zero Knowledge Proofs Alone Are Not a Digital ID Solution to Protecting User Privacy

By Alexis Hancock and Paige CollingsJuly 25, 2025

Reference

• A comparison Verifiable Credentials vs mdocs: A Comparative Analysis by Heather Flanigan 2024-01
• This wiki is one example of a Verifiable Presentation wiki.
• GitHub issues of the Presentation Exchange.