13A/ Mobile Driving License AND Verifiable Credentials PART 2 - see notes from session 9A for ISO 18013-5 overview slides

From IIW

ISO 18013-5 Mobile Driving Licences AND Verifiable Credentials - Even Better Together

Wednesday 13A

Convener: Andrew Hughes

Notes-taker(s): David Waite

Tags for the session - technology discussed/ideas considered:

MDL, Mobile Drivers License, ISO 18013-5, MDOC

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps

Overview slides covering ISO 18013-5 mobile driving license are here - from Session 9A 5:30am PDT 2021-10-13:

https://docs.google.com/document/d/1FtWfULPqCyNqbXf3ekPlWs42LNjgWukPRaYCG5fPU10/edit?usp=sharing

Andrew reviewed the above deck, to provide an overview for those who are not familiar with the ISO standard.

Topic ideas:

  • Issuer-controlled, restricted use credentials (a.k.a. mDL)

  • Credential derivation from mDL

  • Transport protocols for ISO 18013-5 mDL credentials

Important to remember these credentials, being state-issued, are legally restricted documents (to certain uses) and the property of the State.

Questions on Derived Credentials, to create credentials which do not have the same restrictions.

Do restrictions impact use for identity proofing - depends on whether that is defined as an official use.

Restrictions on official use are unlikely but a concern, and would push toward more derived credential use.

Apple has announced mDL will be going into the wallet, but has not announced ways to get them out to present them.

TSA is particularly conservative, and wants particular guarantees from their vendors when false negatives strongly impact security.

Selective Release vs Selective Disclosure - DW summarizes it as subatomic release, e.g. date of birth being released as an “over 20” value, rather than needing an “age_over_20” claim.

The Zoom Chat Transcript Follows:

13:31:39 From Andrew Hughes1 to Everyone:

https://docs.google.com/document/d/1FtWfULPqCyNqbXf3ekPlWs42LNjgWukPRaYCG5fPU10/edit?usp=sharing

13:31:45 From Kristina Y, to Everyone:

why are you awake Naohiro?

13:31:51 From Vic Cooper to Everyone:

Will you be recording this session?

13:32:57 From Juan from Spruce to Everyone:

some of us have seen it and tried reading it quickly and still didn't understand it :D

13:33:15 From Naohiro Fujie to Everyone:

@Kristina, good morning! I awoke now.

13:34:30 From Kristina Y, to Everyone:

Juan, you need a lot of contxt, that's true

13:35:43 From Kristina Y, to Everyone:

23220 and 18013-5 and not dependant on each other in a simple statement

13:37:50 From Darrell O'Donnell to Everyone:

intended for Issuers - got it - but is it intended for Verifiers?

13:38:26 From Juan from Spruce to Everyone:

one set of verifiers (law enforcement) are discussed a lot 🚔

13:40:33 From Darrell O'Donnell to Everyone:

agree on co-existence

13:40:34 From Drummond Reed to Everyone:

that’s a pretty strong opinion, Andrew!

13:40:47 From Drummond Reed to Everyone:

-)

13:41:15 From Darrell O'Donnell to Everyone:

YES / NO / Maybe - as a strong “opinion”!

13:41:47 From David Waite to Everyone:

Do not understate how strong of a maybe it is

13:42:08 From Drummond Reed to Everyone:

Ha!

13:42:26 From Kristina Y, to Everyone:

funny how issuers cannot prevent secondary use in physical, but can in digital - by limiting access to the PKI only to the selected verifiers

13:43:11 From Juan from Spruce to Everyone:

germany is POCing left and right, not sure what's a realistic timeline for prod tho

13:43:15 From Andrew Hughes1 to Everyone:

https://docs.google.com/document/d/1FtWfULPqCyNqbXf3ekPlWs42LNjgWukPRaYCG5fPU10/edit?usp=sharing

13:43:25 From Drummond Reed to Everyone:

Yes, the same is actually true of ePassports - only verifiable by government agencies

13:45:03 From Kristina Y, to Everyone:

but nothing in 18013=5 prevents DPKI, just saying

13:45:35 From Kristina Y, to Everyone:

very shocking

13:45:35 From Drummond Reed to Everyone:

Doesn’t it assume X.509 certs?

13:46:24 From @PrivacyCDN to Everyone:

Scope is essentially in person presentation, not a web transaction

13:46:34 From Drummond Reed to Everyone:

It sounds very much like the ICAO PKD. Which is pretty much the antithesis of DPKI.

13:46:55 From Drummond Reed to Everyone:

Just sayin’ ;-)

13:47:26 From JEFF NIGRINY to Everyone:

lol- we submitted a response to AAMVA's RFP suggesting an ICAO trust model approach was a mistake, didn't go anywhere

13:48:42 From Drummond Reed to Everyone:

Yes, the same happened with WHO for their COVID-19 credential recommendations

13:49:32 From JEFF NIGRINY to Everyone:

you'll have to mention that unfortunate outcome in rev1 of your book ;)

13:49:58 From Drummond Reed to Everyone:

True…OR…we can tell the story of how we came together and made it all work!

13:50:13 From Drummond Reed to Everyone:

(have a happy ending ;-)

13:50:34 From Kristina Y, to Everyone:

can I give a quick pitch on 23220-2 than?

13:50:56 From Margo Johnson1 to Everyone:

I would like that Kristina!

13:51:31 From Darrell O'Donnell to Everyone:

+1 Kristina - provide a new view/perspective

13:51:37 From Drummond Reed to Everyone:

Can you explain what 23220-2 is?

13:51:58 From Andrew Hughes1 to Everyone:

23220-2 is the data model and structure

13:52:13 From Christian Paquin to Everyone:

You said that, today, the only ID proofing of the mDL is your face (i.e., the photo embedded in the credential). Are there other mechanisms considered by the WG?

13:54:28 From Andrew Hughes1 to Everyone:

@Christian - for in-person modes, the person’s face and portrait photo is the commonly-available biometric

13:54:38 From Andrew Hughes1 to Everyone:

Fully-online modes cannot do that well right now

13:55:04 From @PrivacyCDN to Everyone:

Is one of the issues that mDLs are explicitly Identification and Authorization as opposed to VC’s?

13:55:30 From Christian Paquin to Everyone:

@Andrew, ok, just wanted to see if there were other mechanisms being investigated...

13:55:33 From Juan from Spruce to Everyone:

lol

13:56:24 From Kristina Y, to Everyone:

@Christian, 23220-5 is the spec considering that

13:56:37 From Kristina Y, to Everyone:

for online it becomes biometrics

13:57:31 From Drummond Reed to Everyone:

I’m curious, given that Andrew and Kristina are deep into this work at ISO and also understand VCs and DIDs pretty well: what are each of your thoughts about how we should best work together? What would be your recommended roadmap of concrete steps forward?

13:57:50 From Kristina Y, to Everyone:

If SSI is about direct presentation of my digital ID to the verifier, mDL is a perfectly valid SSI solution

13:58:45 From JEFF NIGRINY to Everyone:

I would be very interested to hear what their specific reason or citation was for not relying on blockchain. I did a project with Anil John (as did almost everyone - I know ;) for CBP at DHS specifically for their use of multiple blockchains. There is no prohibition I'm aware of whatsoever.

13:59:07 From Kristina Y, to Everyone:

Jeff, blockchain for what?

13:59:14 From Christian Paquin to Everyone:

Thanks @Kristina for the pointer

13:59:32 From Margo Johnson1 to Everyone:

@Kristina curious for the biometrics piece how far in is 23220-5 going / what does the data model or structure describe?

13:59:42 From Kristina Y, to Everyone:

23220-2 does give a stab at using DIDs too btw, because it does not have a dependency to use device bound keys like in 18013-5

14:00:15 From Darrell O'Donnell to Everyone:

@Kristina - you should consider giving a session

14:00:22 From Juan from Spruce to Everyone:

the problem with blockchain and NIST is that they certify one algorithm/library at a time-- if you limit yourself to what's allowlisted today, it's pretty hard to build something conformant. but one by one they're approving lots of the bits and bops... secp is street legal now (but not keccak :/)

14:00:28 From JEFF NIGRINY to Everyone:

My project was a data aggregator across multiple DLTs so you could see things like food as it went from producer to transport to retailer. Bascially it let you act as a participating node in several different DLTs - it's in GitHub - DLT Gateway.

14:00:41 From Kristina Y, to Everyone:

Margo, I think 23220-5 has been focusing on the transmission and APIs

14:00:59 From Judith Fleenor1 to Everyone:

I would also love to hear “I’m curious, given that Andrew and Kristina are deep into this work at ISO and also understand VCs and DIDs pretty well: what are each of your thoughts about how we should best work together? What would be your recommended roadmap of concrete steps forward?”

14:01:03 From Juan from Spruce to Everyone:

what about DERIVED credentials

14:01:18 From Darrell O'Donnell to Everyone:

For clarity the Issuer may NOT be the government - but the actual Vendor?

14:01:24 From Juan from Spruce to Everyone:

can a notary or intermediary issue to a holder a more self-sovereign "snapshot" of that issuer-controlled credential, at least partially?

14:01:48 From Kristina Y, to Everyone:

Android API will give you a Boolean whether a person in front a phone is the same person who was in front of the phone when the mID was issued

14:01:57 From Dan Robertson (he/him) to Everyone:

+1 Juan: good question

14:02:37 From Nader Helmy to Everyone:

@Juan wonder if it would be theoretically possible to issue a verifiable credential version of an MDL

14:02:55 From Kristina Y, to Everyone:

@Darrell, if you mean a vendor contracted by the gov. yes, from the user perspective, the issuer is always the gov, I guess

14:02:57 From Juan from Spruce to Everyone:

hypothetically ;)

14:03:01 From Michael Shea to Everyone:

lagging indicators?

14:03:17 From Kristina Y, to Everyone:

@Nader, yes, it is being defined

14:03:38 From Darrell O'Donnell to Everyone:

@Kristina - but is the Issuer the vendor or does Govt retain its control to revoke, issue, etc.?

14:03:40 From Kristina Y, to Everyone:

Juan, what is the use-case for the derived creds?

14:04:00 From Juan from Spruce to Everyone:

oh, idunno, most of them

14:04:18 From Kristina Y, to Everyone:

@darrell, I think that question is out of scope of the technical spec, and btw revocation is not defined in 18013-5

14:04:19 From Juan from Spruce to Everyone:

everything you don't want the issuer in the loop for :D

14:04:28 From nembal to Everyone:

P

14:04:42 From Kristina Y, to Everyone:

Juan, in mDL offline presentation there is NO ISSUER INVOLVED

14:05:14 From Juan from Spruce to Everyone:

🚔

14:05:26 From Kristina Y, to Everyone:

mDL offline presentation has session encryption, authentication of the app and optionally authentication of the verifier

14:05:32 From Juan from Spruce to Everyone:

the only thing funner than "show me your papers" is "hand over your phone"

14:05:53 From Drummond Reed to Everyone:

that’s a very real danger, Juan

14:06:03 From Kristina Y, to Everyone:

the offline mDL presentation is **contactless**

14:06:18 From Juan from Spruce to Everyone:

"hold your phone against this magnet", then

14:06:22 From Kristina Y, to Everyone:

no need to hand over your phone, just scan the QR code that police shows on their device

14:06:39 From Juan from Spruce to Everyone:

iisn't that the online mode?

14:06:41 From Kristina Y, to Everyone:

you are holding your device over the magnet everyday when you pay contactlessly

14:06:42 From Drummond Reed to Everyone:

@Kristina: “Juan, in mDL offline presentation there is NO ISSUER INVOLVED”. Are you saying the mDL is not even signed by the issuer?

14:06:58 From Kristina Y, to Everyone:

ofc it is signed by the issuer

14:07:03 From Kristina Y, to Everyone:

no issuer at the presentation

14:07:04 From Juan from Spruce to Everyone:

(I think she meant realtime phone home!)

14:07:10 From Drummond Reed to Everyone:

thanks, I was confused

14:07:48 From Nader Helmy to Everyone:

@Kristina but you still have to check the issuer PKI system (which is tightly controlled) at the point of issuance right

14:07:55 From Nader Helmy to Everyone:

    • point of presentation

14:07:56 From Kristina Y, to Everyone:

so by derived creds you mean no issuer involvement at the issuer?

14:07:57 From Nader Helmy to Everyone:

Apologies

14:08:32 From Juan from Spruce to Everyone:

notarial issuer - issuer says THEY checked the signature, and resigns it with a more open-world signature

14:08:37 From Juan from Spruce to Everyone:

is one option

14:09:00 From Juan from Spruce to Everyone:

only if keccak is not involved

14:09:07 From Kristina Y, to Everyone:

@Nader, yes, but that does not equal issuer call home - AAMVA wants to run PKI in the US for all DMVs

14:09:15 From Drummond Reed to Everyone:

“keccak”?

14:09:25 From @PrivacyCDN to Everyone:

New Crypto Protocol “Rabbit in the Hat”

14:09:39 From Judith Fleenor1 to Everyone:

Magic Crypo… is that defined by muggles?

14:09:40 From Kristina Y, to Everyone:

I just still do not understand a use-case for derived creds

14:09:48 From Kristina Y, to Everyone:

this WG is very use-case driven

14:09:49 From Juan from Spruce to Everyone:

(the hash function used in all EVM contexts to create Ethereum addresses)

14:10:25 From Juan from Spruce to Everyone:

Indeed

14:11:15 From JEFF NIGRINY to Everyone:

I was trying to figure out the use case for derived as well. I support US Fed quite a bit and maybe I cannot get out of that mindset but derived there is solely about getting from smartcard form factor to smartphone. In this case, you are starting on the smartphone. Where else are we going?

14:14:04 From Kristina Y, to Everyone:

derivation is different from transforming MSO signed CBOR mDL into an JSON VC

14:14:25 From Darrell O'Donnell to Everyone:

“may not be usable in the general case” - oops

14:15:50 From Kristina Y, to Everyone:

In any case, if anyone on the call have requirements for mDL as a VC or have concrete mechanisms they want to see in mDL as a VC, please reach out - would love to reflect in 23220-2

14:19:03 From Kristina Y, to Everyone:

Andrew, I think blocking of "secondary use" will depend on jurisdiction - will be very different in the US and Europe and Japan

14:21:16 From Drummond Reed to Everyone:

Apple has also NOT announced any support for W3C VCs. Neither has Google. Or Mozilla.

14:22:26 From Ringo from Spruce to Everyone:

^^

14:22:46 From Kristina Y, to Everyone:

Apple's SMART Health Cards are VCs..

14:23:33 From Kristina Y, to Everyone:

the bottomline is, VC is only a data model, while mDL spec also defines everything else ("data representation syntax, transmission technologies, data element definitions or request and response mechanisms or messages")

14:23:43 From @PrivacyCDN to Everyone:

Vic Cooper wins the takeaway quote of the session

14:23:59 From @PrivacyCDN to Everyone:

“Organizational immune system against innovation”

14:24:16 From Kristina Y, to Everyone:

from one perspective, mDL is already a VC in CBOR signed with an external claim that is MSO

14:24:33 From Kristina Y, to Everyone:

that is how flexible VC-data-model is!

14:25:16 From Michael Shea to Everyone:

I don’t know, they implemented some pretty slowing down processes that extended time out without much consequences .

14:25:37 From Kristina Y, to Everyone:

given the current state of 18013-5, the realistic starting point would be a wallet being able to handle both - ISO-compliant mDL AND VCs

14:25:45 From Kristina Y, to Everyone:

(I am just brandumping in the cht)

14:26:09 From Darrell O'Donnell to Everyone:

@kristina 100% agreed - wallets will need to be flexible

14:27:27 From Ringo from Spruce to Everyone:

But if mDL is a huge lift and proprietary and requires OS-level access to NFC... not exactly an equal playing field

14:28:10 From Ringo from Spruce to Everyone:

"just handling both" sounds great if you already support mDL and want to support VCs, not so great if you are a tiny startup supporting VCs that wants to support mDLs :D

14:28:22 From Drummond Reed to Everyone:

+1

14:28:59 From Darrell O'Donnell to Everyone:

Agreed - add in the accreditation that will be required for ANY high assurance credentials and we’ll see a small number of wallet apps and SDKs in time

14:29:59 From Judith Fleenor1 to Everyone:

https://wiki.trustoverip.org/display/HOME/EFWG+2021-09-23+Meeting

14:30:15 From Judith Fleenor1 to Everyone:

Recording of that meeting is on the above page

14:31:12 From Vic Cooper to Everyone:

Regards of the specs and the bridging, seems like the right to drive part of a Driver’s License would best be turned into a ZKP proof while the identity proofing should move into some sort of mirco-ledger/KERI/ADP solution with biometric validation at the mobile edge device

14:32:04 From Ringo from Spruce to Everyone:

but only high-assurance vendors that can support the whole spec get access to those VCs

14:32:11 From Ringo from Spruce to Everyone:

derived credentials are a little more portable and open...

14:32:39 From Kristina Y, to Everyone:

well, the point of mDL is to be high-assurance and those are requirements

14:33:03 From Ringo from Spruce to Everyone:

so the use-case for derived VCs is every medium- and low-assurance use case

14:34:49 From Judith Fleenor1 to Everyone:

If we need to spin up a Task Force at ToIP to start the discussion… we could make a space for that… we’d just need the right people in the room.

14:34:53 From Darrell O'Donnell to Everyone:

@ringo - no, it’s just that if you want to do high-assurance there are table stakes that mean the market will converge on a smaller number of players, where we add value on top of that.

14:36:26 From @PrivacyCDN to Everyone:

mDL’s are artefacts with a number of use cases, where VC’s are more general tool

14:37:53 From Juan from Spruce to Everyone:

the question was about selective disclosure?

14:39:38 From Kristina Y, to Everyone:

oh! and this group needs to know about "intent to retain" of mDL)

14:39:44 From Judith Fleenor1 to Everyone:

selected release not selective disclosure

14:40:19 From Kristina Y, to Everyone:

which would need to be enforced by the regulations if verifiers are actually not retaining when the user set "intent to retain"= false

14:40:29 From Darrell O'Donnell to Everyone:

“intent to retain” meaning, in SSI terms the Verifier needs to tell you what they will use and/or keep?

14:41:06 From Richard Esplin to Everyone:

But the entire credential hash is always sent, even if certain data elements are not released.

14:41:14 From Richard Esplin to Everyone:

If I understood this morning's discussion correctly.

14:41:47 From David Waite to Everyone:

What is the difference between selective release and selective disclosure?

14:42:17 From Darrell O'Donnell to Everyone:

gotta roll - keep being awesome folks!

14:43:11 From Drummond Reed to Everyone:

I believe the difference is that “selective release” is limited to yes/no on claims. “selective disclosure” is more robust, including proving you do/do not have a claim. And when selective disclosure is done using ZKP, you also get correlation protection on the digital signatures.

14:43:12 From Michael Shea to Everyone:

Thank you Andrew, Kristina, great session.

14:43:29 From Juan from Spruce to Everyone:

online mode is pretty OIDC-friendly though, right?

14:43:40 From Juan from Spruce to Everyone:

correlation protection seems a major difference here :/

14:44:32 From @PrivacyCDN to Everyone:

That is why we are doing a Privacy Enhancing Mobile Credential WG in Kantara

14:44:35 From David Waite to Everyone:

Ahh so there are things being included in selective disclosure that are subatomic :-)