Re: Verifiable Driver's Licenses and ISO-18013-5 (mDL)

@Steve - working on it! :-)

The ISO WG is currently battling it out about 'over the internet'
presentation. And also there's work in the 23220 series for general purpose
'mobile eID' - and that's the place I am focusing on.
18013-5 is what it is, and it probably suits the stated goals pretty well.

I'm chatting with others about different technical approaches that could be
formulated into proposals for new bits. but trying to challenge my
understanding and assumptions right now.
————————
*Andrew Hughes *CISM CISSP
m +1 250.888.9474
AndrewHughes3000@gmail.com



On Tue, Dec 7, 2021 at 2:49 PM <steve.e.magennis@gmail.com> wrote:

> FWIW, my perspective on 18013-5 is that for the specific use case of
> demonstrating a right to drive as authorized by the state and demonstrating
> identification to those authorized by the state to accept a mDL as legal
> identity it is pretty good. I’m not even overly troubled by the capability
> to phone-home to the DMV when presentation alone is insufficient for a
> verifier (e.g. out of state traffic stop).
>
>
>
> The standard gets pretty thin though if you try to generalize the design
> to use mDLs as a generic, portable, holder-controlled identity. It gets
> even thinner when trying to generalize the usage pattern to include ‘mDocs’
> – essentially a VC, issued by any number of non-DMV issuers and consumed by
> any number of non-state authorized entities. My understanding is that the
> good folks in the ISO WGs do have aspirations to extend their idea into a
> generalized credential platform / ecosystem. This is where I believe W3C is
> pretty far ahead of the game and has a lot to offer in terms of both
> thinking and practice, especially when it comes to gradations across the
> spectrum of anonymity. I think within the 18013-* community, the states,
> legislation and associated industry players are running a distinct
> advantage in being able to (potentially) bootstrap digital identity
> credentials that are standardized, (semi) controlled by the holder, backed
> by strong in-person proofing and have legal standing.
>
>
>
> I would love to see a closer working relationship and sharing of ideas
> with ISO
>
>
>
> -S
>
>
>
> *From:* Andrew Hughes <andrewhughes3000@gmail.com>
> *Sent:* Tuesday, December 7, 2021 10:44 AM
> *To:* David Chadwick <d.w.chadwick@verifiablecredentials.info>
> *Cc:* W3C Credentials CG (Public List) <public-credentials@w3.org>
> *Subject:* Re: Verifiable Driver's Licenses and ISO-18013-5 (mDL)
>
>
>
> Sure - but that's not really my question even if it's the requirement that
> caused the creation of the MSO mechanism.
>
> I'm trying to guide the ISO WG (with others too) on
> good/compatible/interoperable ways to do 'over the internet' data
> transmission for 18013-5 mDL apps. Today in 18013-5 the requirement is to
> use the MSO for verification. This does indeed allow the mDL app to
> selectively *release* those data elements it or the person chooses to
> release - it's a simple 'send or don't send' selective release mechanism -
> but it works very well for the main use cases.
>
> Tomorrow's mDL data integrity mechanism? We can negotiate :-)
>
>
>
> PS We could bikeshed on whether selective release of data is the same or
> different from selective disclosure of data...(but please no)
>
> ————————
>
> *Andrew Hughes *CISM CISSP
> m +1 250.888.9474
> AndrewHughes3000@gmail.com
>
>
>
>
>
> On Tue, Dec 7, 2021 at 10:23 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
> On 07/12/2021 18:07, Andrew Hughes wrote:
>
> Hi Manu et al - thanks for this work.
>
>
>
> I'm working through the material and comparing to the ISO WG 18013-5 work.
>
> I can see very good coverage of the core mDL data model (the list of data
> elements in ISO 18013-5) in this work.
>
>
>
> The part that appears to be not covered here is the protocol-related
> clauses and the data integrity and "mdoc authentication" using the Mobile
> Security Object (MSO). While the MSO is technically not inside the data
> model in 18013-5 it is required in order for the verifier to confirm data
> integrity per-data-element.
>
> In 18013-5 there is a procedure in the Security Mechanisms clause that
> describes the steps a Verifier must perform in order to confirm data
> integrity and issuer of each data element. This is for 'server retrieval'
> mode and uses JWT/JWS for data integrity.
>
> The key issue as I see it, is how to support selective disclosure. There
> are many alternative methods that are possible, each having their pros and
> cons. There is no one best solution that everyone agrees on at the moment.
> So perhaps one approach to address this problem is to draw up a table of
> all the possible alternative solutions and to list their pros and cons in
> an objective manner. Then implementors/regulators/funders etc can choose
> the best method that fits their particular application use case.
>
> Kind regards
>
> David
>
>
>
> I realize that the VC approach in this work is not the same - but how
> should we accommodate issuers who want or need to use the 18013-5 MSO
> security approach?
>
> Verifiers following the 18013-5 verification approach will be expecting to
> get an MSO for processing.
>
> This is the biggest item that I continue to struggle to conceptualize
> (even before this work was circulated) - whether the MSO approach is
> fundamental to the concept of Mobile Driving License, or if that's just one
> approach to data integrity etc. And whether any other equivalent proof
> mechanism is acceptable for conformity to 18013-5 (which is what Issuers
> are likely to demand of any vendor/app)
>
>
>
> andrew.
>
>
> ————————
>
> *Andrew Hughes *CISM CISSP
> m +1 250.888.9474
> AndrewHughes3000@gmail.com
>
>
>
>
>
>
>
>