Server retrieval: is it really that bad? Dock Labs webinar looks at mDL kerfuffle

Some of the momentum mDLs accrued through the early part of 2025 has been derailed by the issue of server retrieval models, and whether they constitute a significant privacy risk.

A webinar presented by Dock Labs takes up the discussion, exploring what server retrieval is, why it has enraged certain corners of the identity ecosystem, and how it fits into real-world implementations of mDLs.

The talk features Dock Labs’ Richard Esplin, alongside Andrew Hughes, VP of global standards for FaceTec, and Ryan Williams, program manager for digital credentialing and identity management with AAMVA. The trio dives right into the topic at hand: if the international standards for mDL, ISO/IEC 18013 parts 5 and 7, have a grave privacy flaw in allowing “phone home” server retrieval.

Hughes, who is on the standards committee, begins by delineating between server retrieval and device retrieval. “Device retrieval is where the MDOC reader or the verifier or the relying party, depending on which terminology you want to use, requests specific claims or attributes from the MDOC app, which is primarily intended to be your mobile device.” The app gives the reader whatever data the user chooses to respond with.

“Reader and app talk directly, data exchange, off you go.”

For server retrieval, however, “after an engagement session between the reader and the app, the app sends some sort of access token to the reader, which then goes back to the issuing authority infrastructure, presents the access token and retrieves data from that infrastructure.” At a very high level, he says, “it’s simply online data retrieval from an internet server, and it’s controlled by the user.”

Much of the conversation underlines the point that standards, and mDL, are works in progress. New versions will incorporate new functions, and Hughes notes that the committee is incorporating the W3C digital credential API for presentation of credentials over a browser.

No phonin’ home for the American West

Williams emphasizes the unique complexity of the U.S. ecosystem, with its patchwork of jurisdictions. “We’re working with 69 jurisdictions, and trying to come up with the best practice or or the best way to do that is taxing, especially in an ecosystem that’s perpetually evolving.”

His view of server retrieval is rooted in that system and its deep stake in personal freedoms. “The concern around server retrieval is specifically that it allows for the potential for an issuer to have visibility into a particular person, of when a credential was used, the IP address potentially and what data was shared during that transaction. If that token is passed on to a relying party and then that relying party is reaching back to an issuing authority or even a third party and getting that information, then there is a trail behind that.”

“We believe that a presentation process where the issuing authority or another third party is contacted is not necessary or acceptable,” Williams says.

“Especially in the American West,” laughs Esplin, “we don’t want any of that happening. We’re very strict about that.”

Hughes points out that severe retrieval systems are not something that can simply be switched on. Issuers “have to deliberately consciously enable it to happen and spend money to do so.”

One key point Williams raises concerns interoperability. Namely, that foreign mDLs that work through server retrieval will still work in U.S. jurisdictions that don’t allow “phoning home,” by simply defaulting to device retrieval. “They’re able to come and make a transaction, but it’s not going to call back.”

‘It does come down to the purchasers’

Hughes notes the somewhat gauzy nature of standards.

“Standards writers write a standard. There’s things that are mandatory to implement and things that are optional. None of it matters because implementers will implement what they implement. We can’t tell a programmer somewhere 10 years later to do something, and even if we did they wouldn’t. They would do it how they need to get it done.”

“Purchasers use certifications to get third party attestation that an implementation of software does certain things. And one of those things that it might do is conform to the mandatory requirements of a specification or conform to every requirement inside a specification. So it does come down to the purchasers, what they want to purchase and if there are certification bodies that will certify the parts that the purchaser needs to have certified. You can have a conforming driving license and MDL app that doesn’t actually implement every mandatory feature. You just put a disclaimer on it saying that, you know, we implement everything except for clause 7.6.2 so that the purchaser knows exactly what they’re getting.”

Standards, in short, are written to be fit for purpose, and international standards have to fit multiple purposes because rules are different around the world. The inclusion of server retrieval in an ISO standard does not mean everyone has to use it.

Besides, says Hughes, it’s the potential for misuse that’s a problem, rather than the function itself. “Retrieving data from a server in the vast majority of cases is certainly not controversial. In fact, anybody viewing this webinar is retrieving data from a server and it’s being tracked. So, it can’t be that bad.”

Article Topics

AAMVA  |  digital ID  |  Dock  |  ISO 18013  |  ISO 18013-5  |  ISO 18013-7  |  ISO standards  |  mDL (mobile driver's license)  |  No Phone Home