Re: [MINUTES] CCG Incubation and Promotion 2025-04-16

Thank you Manu 

Yes you are right that the privacy concern are a little less significant in trade use cases 

The way we handle this now is without wallets.  Basically 
1- the issuer of a vc encrypts the vc and hosts it publically - anywhere such as an aws s3 bucket 
2- the issuer chooses any hosted vc verifier and then with the vc location url and the verifier url, constructs a composite url as follows and sends the url (also as a qr) to their trading partner - eg by email 

Https://{verifierServiceURL}?{VCStorageURL}&{decryotionKey}

The act of sharing the URL - is also the act of granting access to the vc.  Not unlike I send you and invoice so obviously I intend for you to see it. Can be exchanged any old way eg as an email or even printed on a paper /PDF version or even printed on the inside or outside of the box (depending on they of vc and desired public visibility) 

Moving to the recipient 
- if they don’t have any vc infrastructure then they just scan the QR and get taken to the hosted verifier and can see / download / print the  rendered vc. 
- if they are a machine that is vc aware then they ignore the hosted verifier url and just get the vc , decrypt it, and verify it themselves 

I know that this “solutiion” has a number of security concerns.  But the overwhelming advantage is that the issuer can go digital without any dependency on verifier technical maturity. This is especially critical in trade processes because there are so many different actors that look at one document and if they all needed vc capability then we could just never start.  

For example a preferential certificate of origin (very apt example given current tariff mayhem) - is issued by an authorised entity, typically a chamber of commerce, to an exporter.  Exporter sends it yo importer with other docs. Imported hands it to customs broker who, in turn, lodges it with importing customs.  And on top of that, if the trade is financed with documentary letter of credit (which is 80% of global trade by value) then two banks look at it as well, and maybe a finance broker.  In short that one VC is viewed and handled by 6 to 8 different parties.  If they all needed a wallet you’d just never get off the ground 

Steven Capell
Mob: 0410 437854

> On 19 Apr 2025, at 11:43 pm, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On Thu, Apr 17, 2025 at 9:12 PM Steve Capell <steve.capell@gmail.com> wrote:
>> One requirement I’d like to add to this excellent tender template discussion is about handling credentials with lots of optional data and with repeating structures - so require dynamic template
> 
> Ah! Yes, we have discussed that lightly. The current thinking seems to
> be that we'd have a simple static templating system and language
> (Mustache) for most use cases... and we might have to just depend on a
> full blown headless HTML+JS rendering engine for dynamic templates.
> 
> The good news here is that with the selective disclosure schemes, we
> can do minimized, dynamic, and fully programmable rendering on the
> client-side. The bad news is that doing so brings in some (debatably)
> heavy requirements -- it's "just" running Javascript + HTML to produce
> a dynamic PDF that's printed out via pdf.js.
> 
> So, yes, we hear you and we're getting those sorts of requirements
> from others. The big concerns here are 1) the runtime demands, and 2)
> the correlation and privacy risks. Those sorts of renderings will
> probably come with guidance that: "You are almost certainly going to
> be tracked if you hand over this VC with this rendering method" <--
> not usually an issue for supply chain, but certainly an issue for
> personal identity.
> 
>> Take a trade invoice as a VC for example. Might include payment details and might not - do you tender payment properties with no data or just leave out that block ?
> 
> Yes, definitely possible w/ ECDSA-SD and BBS cryptographic mechanisms
> to selectively disclose that information, which would then be used by
> the HTML rendering engine to generate a minimized PDF. Note: You can
> also selectively NOT disclose the render templates to prevent
> verifiers from using them.
> 
>> Still on the invoice, it might have one line item or a hundred line items so rendering would need to show as many line items as there are in the instance.
> 
> Yep, definitely do-able.
> 
>> We are coping with these needs well enough with html rendering.  Not sure whether an svg or pdf template can be dynamic like that ?
> 
> You can write an HTML+JS-based rendering engine to generate an SVG or
> PDF, certainly, but really you're just in browser-land at that point,
> so you might as well do the entire rendering in HTML and you can
> export that to PDF (via something like pdf.js) or SVG, if you really
> need to... or you can just "Print" at that point to generate something
> that could go to a bog standard printer.
> 
> The thing we're struggling the most with right now is the litany of
> privacy warnings we're going to need to put on any HTML-based
> rendering approach.
> 
> -- manu
> 
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/

Received on Saturday, 19 April 2025 22:34:04 UTC