Meeting minutes
rigo: Note that current plan for SD-JWT doesn't work cross-border in EU wallet.
phila: EU wallet standards work well in germany but not anywhere else, is that correct?
rigo: Yes, correct.
phila: Hello all, welcome -- I work for GS1 - barcode people -- also here as co-chair of VCWG
phila: I'm the neutral chair on behalf of WG, I'm not speaking as GS1
phila: No discussion of markets or marketshare, w3c code of conduct applies, as usual
phila: tomorrow morning, VCWG is meeting, discussing a number of things, we will be discussing this grid, work items -- current list of proposed standards we might be working on in future chartered group
rragent, make logs public
phila: Those will be discussed in many meetings, one on the bottom might extend in scope.
phila: We are concerned about VCs, but don't know who you are or if credential is worth anything -- need to know something else.
phila: Ivan from GLEIF proposed a sessions, I proposed a session, they got merged together -- in related space.
phila: One credential might not be enough, how do we put VCs together to figure out if set of credentials are trustworthy.
phila: Kevin Dean from Legendary requirements, but also worked at GS1 in the past.
phila: Steve Capell, works with UNECE on corss border trade.
kevindean: Hi Kevin Dean, in W3C as Legendary Requirements, formerly at GS1 and outside of Legendary am in GS1 standards groups -- not a LR presentation, this is coming rom GS1 work.
kevinddean: This diagram, going back some dyears to exploration work on VCs in early days -- this is about the power of verifiable credentials, sort of thing you can do with VCs when y ou have VCs that say multiple things --- VCs are a self-assembling ecosystem, you get to decide who the authority is on something and what those VCs issued by authorities mean to you.
kevindean: This use case, distributor in the middle, I as a manufacturer, want to distribute part in ecosystem, need to know a few things -- not as simple as finding a warehouse, we need to know more -- know that they are a legitimate business, need credential from regional business registry -- know that they are certified to manage pharmaceutical products -- background checks and in supply chain world, lot of identification is
distributed. Barcode on product, 3 components to it... GS1 prefix, GS1 company prefix, and then remaining digits are item number... that makes up global trade ID number -- GTIN, uniqely global.
kevindean: 2nd most common identifier, Global Location Number, identifies the business.
<rigo> as long as the VC will not require to understand the semantics of the number by making them explicit in RDF, we are fine :-)
kevindean: Movement through supply chain -- important thing is that this is a chain of credentials, unlike business registry, pharmaceutical registry -- single issuer identifier, we have identifier for distributor (GLN), that's not enough, they need to do so based on GS1 identifier, inturn can only do so based on GS1 Prefix -- GS1 global office is trust anchor, ony party you need to know about in order to trust GLN.
kevindean: You need all of this stuff to be trusted in pharmaceutical supply chain?
phila: Do those need to be linked, or does a pile of credentials work?
kevindean: They need to be linked
kevindean: You need to receive all of hem or receive all of them
kevindean: You have to validate entire chain to know if all of that information is complete/correct.
steve: I'm vice chair at UNCEFACT engaged in digitalization of cross border trade -- VCs can bring enormous value to this space because they can change the paradigm of data exchange.
steve: Size of this domain - global trade is $25T/year of goods, 10 billion tons of cargo, 10 million business, 2 billion consignements, 100K land/sea/air ports. There are a lot of inefficiencies and logistics issues in this space.
steve: inadequate KYC is a problem in this space as well -- the blue bubbles are benefits -- over $4 trillion in savings wih VCs / digitization
steve: This is messy, there are many parties involved -- registrar, bank, chamber, forwarder, exporter, insurer, broker, customs, carrier, and so on.
steve: All of these parties move the invoice between many parties
steve: Lots of different parties, multiple very important verifiers, many hops to get from issuer to verifier -- typical issuer/holder/verifier doesn't work in international trade. Next slide shows hat parties that ultimately get ahold of a credential care about not just invoice is valid, but who issued it -- who is exporter, who is attesting to exporter, two verifying parties, customs and a bank, high integrity threshold... bank is going
to lend money and customs authority lets good ino door, commercial invoice goit to customs bank indirectly.
steve: What bank / customs authority need to do, who issued invoice -- we needt o know australian business number, national business register, links DID of exporter to well known entity -- any authority can attest to identity of party
steve: If it's a nationa business registry, maintain list of authorized identity issuers of business identity -- you can see trust chain here -- is invoice valid, what DID, is that DID the ABN, we need a trust list of who are the authorities in the sates. A linked chain of credentials, following chain of data, basket of credentials and relationshis between them. I'll pass onto the next speaker.
ivan: I have been in dientity industry in 20 years, orgaizational identity, last 6-7 years, working for GLEIF -- non-profit founded by financial stability, global reach, working globally.
ivan: GLEIF is asking to include ACDC in W3C VC -- financial stability board, working w/ many organizations, many credential isuer, ACDC credentials are passport for legal entities for global trade. In previous slides, diagrams and workflows, how to evolve holder/issuer/verifier -- not enough to have that model, many players -- going to straight to the point, traditional credentials delegation is manual... ACDC has delegation, multi-party
chains -- native support for chains/trees, supply chian provenance, role flexibility, expressiveness, limitations with ACDC you can have support for hese things.
ivan: In terms of source of trust, GLEIF is the root of trust. vLEI has code, unique identifier, in unique way, wihin credential, LEI code, name, code, we are root of trust, we have issuers, qualified vLEI issuer -- issuers issue to legal entities -- those credentials can be can cover entire spectrum of value chain
ivan: This si credential, name, role, organizations, you can delegate -- ACDC container, you can chain, audit track, much of all functionality by local model -- that covers all use cases, all accountability, across value chain.
ivan: We have a hackathon, delivering items, include ACDC containers into VCs -- scan, see companies involved, dealing with global rade -- ESG supply chain, payments, industy sectors, shows how flexible ACDC conainers are
phila: My question to those working on VCs -- you've seen three people talking about graphs/chains/multiple VCs -- not the way that most VC work has been thought of.
Joe: VCs are modeled to be independent objects, but you can refer to one another to each other.
Ivan: What are changes that would impact VC data model to include ACDC?
ivan: you would need to create new description, but if you include ACDC, you need to create new ontology, expand VCs, new extended data model that includes ACDC data containers -- it's an evolution in that sense.
Sano: Personal credential needs unlinkability, but that presentation, I feel this credential chain is stronger than personal credentials -- that means more important linkability, zero knowledge proofs, ar they necesary?
phila: In some cases, linkability is important, these are use cases where you want to be able to link them. This is a different mindset, listening to what Joe said, it does challenge thinking of what people talk about in VCs.
<Yasushi-Sony> Manu-san, A Comment is made by our colleague, Sano-san.
kevin: Linkability can also be privacy preservng -- towards end of COVID credentials were issued from crentral authority -- provincial auhority in Canada -- government had to have complete record in order to issue a credential, but have some sort of medical record, vaccination satus, important to another party, and have chain of credentials from medical college to doctor to say this person is a physican -- put control of credentials closer
to people that hold them, further away from parties that don't have any business of knowing them, make assertions that are not necessarily suppoted by central authority, to make deeper assertions.
ivan: Yes, following workflow -- doctor providing vaccine to patient, but if you look at supply chain, there is a much deeper set of VCs, accountability for each step of the chain with ACDC credentials. It's useful to identify who is
<rigo> you could also, instead of linking, have a VC that serves as a container for all the other VCs
steve: Do we need a standard for these -- for VCs, this need exists -- someone said we already do that, of course it's feasible to get basket full of VCs and application layer problem on relationship between them -- we could hands off as W3C and say it's someone else's problem -- are there some common patterns here, where we need to give guidance here, then risk is that everyone does this differently if we don't give uguidance. Given a
credential, follow a link to anchor of trust, examples of trust anchors, reach a point where you hit something you trust -- pattern is common, should we standardize it? We shouldn't pick a way to do it, i there value in doing this? Best practice patterns around how verifiers would work.
<rigo> which means if there are other options and standardisation would be helpful
JoeAndrieu: I was mostly going to say what Steve said, you can create chains of provenance with VCs -- where we might not do magic that ACDC can do.
<phila> manu_: +1 to what Steve and Joe have said. It's worth putting together best practices. There is a clear set of use cases
<phila> manu_: yes, we can formalize these patterns. You can do this now, in lots of ways. Would be good to provide a design pattern
<phila> ... I have read the ACDC spec at depth I think we can do a lot of it already but we're not explicit about it. The WG already took a look and decided it wasn't the way we wanted to go but things have matured since then, GLEIF has an interesting set of use cases.
<phila> ... Business ID, global trade etc. We need to define something here...
<phila> ... that means we need each of you to participate in the work for anything to happen.
kevin: Yes, this breaks down into two thing -- standardizing structure -- we need to make linkage statement, we have to do it in standardized fashion, if we have a chain, we can read it in standardized manner. Discovery, getting VC, presented credential when I got to verify/validate it, I'll have to see oher credenials upon which it is based -- might not be in VC, might need discovery mechanism -- have to get credential from somewhere --
what do I need to present to get access to it? Ability to discover how to get linked credential
ivan: Going back to steve's statement -- valid point, core of this all of us -- advantages to evolved VCs to ACDC, but standardized way to do that -- we have demonstrated at GLEIF, we are in many markets already doing these credentials, good to get standardized formally -- you can do i in different flavors, we are offering here something real, use cases have been implemented in China, europe, US, other parts of the world -- standardize,
we're talking about global trade, we are global trade -- we're trying to address global interop.
steve: one question I have is that there are two ifferent ways -- you want a collection of linked credentials where I can make meaning -- i can discover them at verify time, they just exist, might be discoverable -- at verify time crawl/find -- or at issue ime, I can assemble them into ACDC container. Both patterns are valid -- some cases, where we present, classic candidate for "assemble it at invoice time", but also patterns where you
can' assemble the complete graph -- leaves forks... some combination, don't know what right combination, what right use case, just need to acknowledge these two different valid patterns.
phila: I'm hearing a number of possible ways forward -- one requires no technical work, best practice satement -- that doesn' lead to a generic pattern where one VC is presened as another credential independent of it -- BP makes sense, but verification process defined doesn't include
<rigo> hearing that chaining VCs is important for the charter IMHO, question: are those directed links?
JoeAndrieu: It's a matter of validation -- you validate against business rules, so it's not really explicitly in there, but it is a part of validation.
phila: I'm thinking test suites, implemenations, bar to get something on charter is high -- what would be the bar to add something into the spec that allows validation rules to be automated... could you put something in for hooks?
phila: A property within core VC data model, validation?
JoeAndrieu: We probably shouldn't standardize business rules, but we do want to standardize data model work -- don't want to say we should standardize validation.
kevin: Agree, we don't need to do that -- but we do need to standarize ways things ar elinked together
phila: Yes, you said discovery thought
<Kazue> +1 to JoeAndrieu
kevin: Yes, hesitant on it -- it's a possibility -- we have to present entire chain -- linking part is critical piece.
phila: When you first spoke about this -- you said "I need to link one thing to another" -- is that still true?
steve: I see common patterns; it's not to use to encode specific business rules, more about any verifier can construct graph -- conext-specific bsiness rules need to be done. There is an opportunity here to progress a bit further
ivan: We have two topics here -- foundational VC and then business logic -- if we have a good foundation, all capabilities, cross-border, delegation, chaining, are all natively supported by ACDC, on top you can have custom business logic.
ivan: this is more about solid foundation of credentials that support all of these features -- each business can do business logic -- the key point is to have solid f oundation / enable natively -- on foundational statements on auditing, delegation, linking credential, foundational layer of credential, on top you can do business logic. ACDC brings solid technical foundation, we are looking to be standardized in more places, we are an ISO
standard, and now we're looking at W3C to get to that inerop.
<phila> manu_: Trying to think what we'd need to do to include this in the charter. Current text says we're in maintenance mode. But maybe we want to be able to expand the scope. May need to constrain any new features. New charter already likely to include a lot of new work.
<rigo> note that if semantic interoperability is achieved, people will look for procedural interoperability and the VCs should support that by allowing the expression of a process. This means directing the links (first, second etc)
<phila> ... sounds like we may need to make some changes. Specify linking to other VCs? That's a change to the data model (class 4 changes)
<phila> ... For design patterns... documenting best practices. No one can stop us talking about it. Can have optional deliverables around design patterns. Byut most important thing I've heard to make sure we can support class 4 changes.
phila: I think we do need to discuss -- we need to get GLEIF in the group more directly, hope that can happen -- adopting ACDC is difficult -- very good and important ideas within ACDC, elephant in the room is methods used by vLEIs is no fully consisent with W3C which is not fully consistent with mDocs, etc... interop is already an issue in the space, we can't improve if we add news ones -- ideas are there, class 4 changes to data model
we'll disuss in the WG tomorrow -- we have to wrap up, anything else that needs to be said before we close.
JoeAndrieu: Thank you to all!
phila: Please join the work, that's how we get stuff done.