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

Michael and all,

I am _not_ trying to raise the question of CCG or W3C "higher level goals"
in this thread any more than ISO mDL or any other tech collaboration
depends on motives or ethics.

What I'm calling for are one or more explicit and testable measures, such
as interoperability or decentralization or scope limits that will be the
result of protocol choices built on mDL and SSI.

An example might help. Let's stipulate that Apple Wallet is or will be mDL
compatible:
https://www.apple.com/newsroom/2021/09/apple-announces-first-states-to-adopt-drivers-licenses-and-state-ids-in-wallet/
without any intentional protocol linkage to W3C / DIF / Trust OverIP or
CCG. What use-cases do we consider in-scope as we strive to influence or
align with the ISO mDL group?

The question of what CCG or W3C "stands for" may be interesting but also
distracting and I hope to avoid it in the context of this particular thread.

- Adrian



On Fri, Dec 10, 2021 at 12:24 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> ...and how do these link to CCG's higher level goals, principles, and
> metrics?
>
> What do we collectively stand for?
>
> Michael Herman
> Founder
> Trusted Digital Web
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* Adrian Gropper <agropper@healthurl.com>
> *Sent:* Thursday, December 9, 2021 12:44:40 PM
> *To:* Andrew Hughes <andrewhughes3000@gmail.com>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG (Public
> List) <public-credentials@w3.org>
> *Subject:* Re: Verifiable Driver's Licenses and ISO-18013-5 (mDL)
>
> What is to be our measure of success?
>
> A (digital) driver's license is government issued, biometrically bound,
> deduplicated and non-repudiable by design, and very long-lasting. It is
> then linked without obvious regulations to an immense range of applications
> that includes notarized civil contracts, travel, banking, proof-of-age, and
> presentation along with a vaccination card.
>
> Broadly speaking, the W3C VC and DID data models do not constrain or
> introduce regulatory concerns into any of the aforementioned aspects but
> any protocol and advocacy work we choose to do will be prime real
> estate for platform economics, regulatory capture, and social engineering.
>
> Kranzberg’s First Law of Technology is "Technology is neither good nor
> bad; nor is it neutral." A government-dominated closed process, ISO can
> pretend to serve the narrow intent of a mDL. What is our intent and measure
> of success?
>
> - Adrian
>
>
>
> On Thu, Dec 9, 2021 at 12:10 PM Andrew Hughes <andrewhughes3000@gmail.com>
> wrote:
>
> Thanks Manu
>
> The proposals made a couple years ago regarding VCs etc were too early for
> the ISO WG to absorb. Also, the ISO WG was at the time by necessity
> inwards-focused.
> Now that 18013-5 is published, it's actually a better time to talk about
> data structures and proof mechanisms - because we have one approach that is
> proven to work. Now we can make moves towards efficiency, newer approaches,
> technologies that have different properties/capabilities, and so on.
> ————————
> *Andrew Hughes *CISM CISSP
> m +1 250.888.9474
> AndrewHughes3000@gmail.com
>
>
>
> On Thu, Dec 9, 2021 at 9:38 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> On 12/7/21 1:07 PM, Andrew Hughes wrote:
> > 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).
>
> Yes, at least one large W3C Member insisted (and continues to insist) that
> protocol be placed out of scope in the VCWG. They are, interestingly
> enough,
> also involved in the ISO 18013-5 work, but I'm sure there is no connection
> between those two data points and it's just a coincidence. :P
>
> You are right to note that there is a problem there that needs a
> standardized
> solution.
>
> > 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... 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?
>
> Yes, and ONE solution to this could be embedding the MSO as a "proof" in
> the
> Verifiable Credential and passing that on verbatim. The downside, here,
> however is that it's yet another Verifiable Credential data integrity
> algorithm that we'd need to spec -- though, the spec could largely point to
> the ISO-18013-5 specification.
>
> It's not elegant, but I see no reason why it wouldn't work (yet).
>
> > 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)
>
> Here's what it could look like for a selectively disclosed driver's license
> (sharing only document number, birth date, and expiration date):
>
> https://gist.github.com/msporny/6292b3b6f77e2040fbc0e534d0a30ff2
>
> IIRC, this was already proposed to the ISO-18013-5 group several years ago.
> I'll note that BBS+ is probably a far better, more generalized, solution to
> the problem the MSO is attempting to solve. The problem w/ BBS+, of
> course, is
> the lack of finalized standards that could be leveraged today.
>
> Hope that helps, happy to answer further questions.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>