Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

Argh - Even though I proof read before sending, I sill missed a couple of important typos - fixed version is below 

Steven Capell
Mob: 0410 437854

> On 18 Dec 2022, at 9:03 am, Steve Capell <steve.capell@gmail.com> wrote:
> 
> Hi Manu 
> 
> Your comments in this email and the previous one deserve a longer response but just quickly 
> 
> > write up: there are 8 use cases in chapter 5 of this https://unece.org/sites/default/files/2022-09/WhitePaper_VerifiableCredentials-CBT.pdf.  All of them are linked credential use cases. I just picked 8 but there are hundreds of similar use cases.  
> 
> > why not protect sensitive lists with authz:
>   - because the verifier is unknown to the owner of the list so there no way to register, identify, and authorise them.
> - because the DID of the issuer of the leaf credential (eg did:ion:abcd or even did:web:some domain) such as a commercial invoice is NOT the identifier that is maintained in the central
> Register (such as a national register of business names and tax registration numbers) - so the only way to establish the link is through a chained credential 
> 
> > why not include the total list in a VC:  two reasons 
>  - because the total list will usually be sensitive (eg a supplier list) and
> - because the list is often so big and fast changing that the VC will be obsolete within an hour of issuing 
> 
> > these hierarchical models smack of the old centralised control models:  two counter-statements 
>  - a big central registry with authorised access is MUCH more centralised than a VC from that registrar about one of its members 
> - please don’t confuse compliance (that the issuer of a vc I’ve been given has some some registration / licensing / certification / accreditation process) with trust (that the school, even though registered is a good school, or that the business, although legally registered, is not a cover for illicit operations). 
> 
> Christopher Allen talks about a non-binary kind of trust that emerges over time.  This is completely true and is the real foundation of trust.  In supply chains this is called “evidence of market participation”. But it’s not the same as compliance.  These two kinds of confidence measures are complementary not alternatives 
> - the compliance trust chain tells me that you are legally permitted to perform the service you (or your upstream supplier) is providing 
> - the evidence of participation trust score/graph tells me that I’m likely to get a quality service 
> 
> Manu - please don’t take this the wrong way because, like almost anyone that has seen your work or had discussions with you, I have enormous respect and admiration for your skills and contributions.  But I suspect they come from a technology perspective and haven’t had enough exposure to real world business use cases, particularly in the supply chain domain.  There’s a bit of a clue in the word “chain” in supply chains isn’t there?  
> 
> Here’s one last example of why lists / registries can be bad.  Anil might like this one.  
> - cargo border security measures like the WCO “authorised economic operator (AEO)” and ICAO “known consignor (KC)” are basically audit and accreditation mechanisms to help authorities streamline genuine trade whilst protecting the community from illicit trade or worse.  Customs authorities are less likely to inspect the box if it’s from/to an AEO.  Air cargo operators will load the box (or pallet full of boxes) on a flight if it comes from a KC (this is essentially how we stop bombs on planes from a cargo perspective rather than pasenger luggage perspective)
> 
> The problem is that the verifier of the claim that ACME is an AEO or KC can be once or twice removed from the holder - so it’s not solved with a VP.  Currently sone authorities make these AEO / KC lists public because the import authority needs a way to know whether the export party in the other country is an AEO.  But making them public is also an obvious invitation to illicit traders.  “They’re a public list of traders that customs trusts - I’ll pretend to be one of them so that they are less likely to inspect my shipment of cocaine”.  This is called “piggybacking” and is the primary vector by which illicit goods get past customs. Much better not to make these lists public but to provide a way for the issuer of a cargo safety declaration (CSD) to prove that they are also a known consignor by signing the CSD with a did that is also the subject of the KC certification 
> 
> This could go on and on.  But I’ll say that I am still very firmly convinced that chains are real and important on the real world and that only practical way to represent them in the digital world is linked credentials 
> 
> I’m looking into that IETF competing specification now - not because I care very much about CBOR and compactness but because it natively supports chained credentials 
> 
> I’d really like to encourage this group to take chained credentials seriously.  If you don’t then it might be the thing that leads to the IETF competitor spec winning the uptake race 
> 
> Ok, that wasn’t such a “quick” response ;)
> 
> Kinda regards 
> 
> Steven Capell
> Mob: 0410 437854
> 
>>> On 18 Dec 2022, at 7:17 am, Manu Sporny <msporny@digitalbazaar.com> wrote:
>>> 
>> On Fri, Dec 16, 2022 at 7:52 PM Steve Capell <steve.capell@gmail.com> wrote:
>>> We simply cannot use registries or lists as they are both unmaintainable and often cannot be public because the totality of information in them is essentially commercially sensitive customer lists
>> 
>> So why not convey that information using either a protected list (via
>> standard authz mechanisms like OAuth2) or just send them as a
>> Verifiable Credential? That's the approach that the Verifiable
>> Issuer/Verifier Lists spec uses.
>> 
>>> Is there a separate work item on chained credentials and the linked semantics within them?  If not will this work item address that ? If not should I start a new work item ?
>> 
>> Need more detail on you on why you think "chained" is a requirement.
>> 
>> I believe this work item will cover "linked semantics", but will most
>> likely use JSON Schema to do the fine-grained matching.
>> 
>> Do you have a write up of your use cases, Steve? We're familiar with
>> supply chain use cases, and I see no reason why this solution wouldn't
>> work for you... but I'm probably missing something... just don't know
>> what I'm missing, yet. Enlighten me, please. :)
>> 
>> -- 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/