13A/ Mobile Driving License AND Verifiable Credentials PART 2 - see notes from session 9A for ISO 18013-5 overview slides
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 :-)
