Re: Selective Disclosure in Supply Chain Data

Thanks for your detailed response Manu, and thanks for the links.

As it happens, I've had the "painting yourself into a corner" metaphor in
front of mind a lot recently, except I've extended it with "and then
decorating the corner" :)

On Sun, 4 Jun. 2023, 1:15 am Manu Sporny, <msporny@digitalbazaar.com> wrote:

> On Tue, May 30, 2023 at 7:54 PM Richard Spellman
> <richard.spellman@gosource.com.au> wrote:
> > Steve, I think that we could simplify some of this discussion by
> thinking a bit more like a digital native about how (supply chain)
> documents are constructed.... If we start to think about documents like
> this as presentations, instead of credentials, I think things become a bit
> simpler. If the origin claim were a minimally sufficient credential in and
> of itself, then there is less need for redaction.
>
> Yes, exactly, Richard.
>
> To draw an analogy to TruAge, which is powered by Verifiable
> Credentials, and is a digital age verification system deployed for the
> 150,000 convenience retail stores in the US, we were lucky in that we
> were working with an industry that was quite forward looking wrt. how
> they wanted to prove age at the point of sale.
>
> Specifically, after analysing the way it's done today, the industry
> decided to restructure the information presented.
>
> The way it's done today is that the customer walks into the store, and
> if requested, shows their Driver's License to the clerk, which is
> often scanned by the point of sale, capturing all 20+ fields of
> personally identifiable information (PII) from the card, which then is
> used for who knows what. The industry felt like this over-collection
> of data was a liability and sought to eliminate as much PII collection
> as possible.
>
> We looked at mDL-style selective disclosure, which still enabled
> customer tracking (the digital signature on an mDL acts like a super
> cookie, if you will)... so that was out.
>
> We looked at CL Signatures and BBS-style selective disclosure with
> unlinkable digital signatures, but given the regulatory landscape
> (where a back-end system have to be able to perform quantity
> restrictions -- e.g., for the sale of cannabis)... full unlinkability
> didn't meet the regulatory needs that governments impose on retailers
> in that space. There is a parallel here to the sorts of things supply
> chains have to do. :)
>
> So, we needed something that was unlinkable by the retailers
> (customers can't be tracked by retailers), but still provided proof
> from the retailer to the regulator that the age check was performed
> and came back as valid (but in a way that the system doing the check
> couldn't even determine the individual's PII w/o a manual,
> subpoena-based regulatory process kicking in).
>
> The solution was to use one-time use tokens with a variety of
> anti-fraud checks to ensure that the tokens aren't being cloned, etc.
> The result is a system that has a very aggressive stance on protecting
> individual privacy while ensuring that the regulators have what they
> need in the case of criminal misconduct.
>
> All this to say that large industries have looked at how Verifiable
> Credentials can help their transformation into a digitally native
> solution while also enabling a path to continue processing the "old
> paper-based transactions". For example, the convenience store industry
> in the US processes around 50M age checks per day, and many of those
> are going to remain as physical driver's license checks, so it's also
> important to consider that while you want to go digital native, you
> still do need to continue supporting the old processes until everyone
> can migrate off of the old systems onto the new ones. We believe this
> is going to take upwards of a decade in the retail space in the US
> (just for age checks)... but hey, there was a time where we were
> writing physical checks in the store and thankfully, a very large
> majority of individuals don't do that anymore.
>
> I know both of you, Richard and Steve, already know all of this...
> just sharing for those that might not have the same background as both
> of you.
>
> > I realise that idea as a whole still requires redaction / selective
> disclosure, it just irks me that we aren't really taking the opportunity to
> rethink what a traditional document could actually become in the context of
> the SSI landscape.
>
> Some people are... it took two days from the time we announced Data
> Integrity Selective Disclosure to it being integrated (experimentally)
> into the European Product Passport work. This stuff isn't hard to get
> sorted into a technology stack... it's the business rules and data
> models that are a challenge (as Richard pointed out):
>
> https://github.com/european-epc-competence-center/vc-verifier/pull/31
>
> EEPC are doing some very interesting work in supply chain and product
> passports, and are working towards supporting the Data Integrity
> Selective Disclosure work, it seems:
>
> https://id.eecc.de/
>
> It might be worth pulling Christian Fries and Sebastian Schmittner
> into the discussion. I'm cc'ing both of them (unsolicited, sorry
> guys!) in the hopes that they might have some interesting stories to
> tell about their work and thoughts around selective disclosure in
> supply chain security. Or what they're working on, in general. They've
> built a compelling demo here:
>
>
> https://ssi.eecc.de/verifier/#/verify?subjectId=https%3A%2F%2Fid.eecc.de%2F253%2F040471110202262acaf727f78b7255
>
> All that to say, Richard is right -- if you don't re-think some of
> your data modelling and think ahead wrt. your toolkit, you're going to
> make this a lot harder on yourself (and might even paint yourself into
> a corner). I know, I know -- I'm singing to the choir. :)
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>

-- 


---
The content of this email and attachments are considered 
confidential. If you are not the intended recipient, please delete the 
email and any copies, and notify the sender immediately.  The information 
in this email must only be used, reproduced, copied, or disclosed for the 
purposes for which it was supplied.