Manu Sporny: Agenda review, introductions, community updates, call focus on work Joe and Eric have been doing on VC API ecosystem ✪
... diagrams, naming, dataflows,
... a PR is in for this content, this is background to future discussions.
Topic: Introductions
<vasilis_k> Hello, my name is Vasileis, I'm currently an MSC student at AUEB studying computer science. I'm interested in the domain of VC and SSI. Today I wanted to attend the meeting in order to find out more. Nice to meet you all.
Topic: Relevant Community Updates
Manu Sporny: The Verifiable Creentials TPAC meetings are this week... if you are a w3c member and missed it there was charter discussion ✪
<mprorock> CCG t pac overlapped unfortunately along with WebML
Joe Andrieu: PR replaces architecture overview entirely... ✪
... defines issuer/verifier/holder and then described components, to clarify what is an "App" and what is a "service"
... there are components/services that execute business rules on behalf of the actor
... For example there is an Issuer web application that drives the VC API Issuer service.
... storage services are included, question on this needs to be standardized (like an EDV) or just leave it as "internal DB".
... There are Holder applications backed by a service, but the User Agent (browser) may still reach out to an EDV without contacting their service layer (needs to be accounted for)
... some services may communicate directly with other services without an app layer.
<mprorock> likely out of scope
... There needs to be an 'Admin' interface for services, not considered here currently.
<mprorock> at least for now
... (does admin interfacee need standardization? we have enough to do)
<david_chadwick> I cannot see the diagrams in my browsers
<mprorock> i had to go to the PR to go see the diagrams
<mprorock> not visible in link for me
Joe Andrieu: I think what most folks call wallets today is a combination of the "app" and "servoce" ✪
<by_caballero> files changes --> ... menu --> view file
... when really its a "domain/challenge" etc challenge for the desired Presentation
... if that is accurate then this is aligned with CHAPI flow.
<mprorock> yes
Joe Andrieu: In supply chain flow, the Holder defines that data that is "ready" - as opposed to personal flow, the Holder wants to use a service, and the Verifier asks for credentials it wants. ✪
... (personal == CHAPI)
Mike Prorock: Some notes on current impl - whenever a system is called there are various levels of Authorization being executed at various points. ✪
... "I have data ready" is an initiation flow that defines the data / credential that is ready for submission that gets run through a business app flow/Queue.
... eg a shipping manifest, or multiple manifests that are used in the business process.
... services/apps have very extensive audit trails; the audit trail API is out of scope from the spec but still very important for the use case.
<by_caballero> no idea
Joe Andrieu: +1 That #6 should still specify the data type request ✪
David Chadwick: Need some clarifiaction on the difference between supply chain "here is a presentation that is ready" vs. other flow where verifier is asking for specifics. ✪
<mprorock> btw - this is kindof the simple flow that lets us operate to start, there is the scaling big side of this that may go well beyond this (e.g. pub/sub, async fire and forget, streaming data between parties, etc)
Joe Andrieu: Is the question "sometimes you don't know the type of credential the verifier will accept" and (6) may be the right place for that negotiation... ✪
<by_caballero> presentation exchange?
Mike Prorock: Mostly there are pre-configured rules in place for various processes, so "negotiation" is likely already defined as a configured workflow that both sides understand. ✪
Mike Prorock: From a scaling perspective, sometimes there are 20,000 presentations "ready", which is where pre-configuratino is important. ✪
... with large scale / high volume system, sometimes even REST/HTTP gets tested and becomes more of a 'stream' of data
David Chadwick: Maybe this is a published meta-data type solution ✪
Adrian: I see calls to "an open endpoint" kicking off the flow... can we identify that call? ✪
<mprorock> none of our endpoints are open
... by open it means unprotected and subject to spam/dos attacks. Like in OAuth, the initial OAuth request is an "open endppint"
<manu_sporny> We (Digital Bazaar) does have open endpoints, fwiw
<manu_sporny> like, CHAPI starts off w/ an open endpoint.. #3 is open.
Joe Andrieu: None of these endpoints are meant to be open - but there needs to be a conversation on each of these points on how they are secured. ✪
Mike Prorock: Impl. has no open endpoints, clients are connected after contracts are signed. ✪
Joe Andrieu: Yes, the Verifier could provide a VC / consent receipt as part of (19). ✪
<by_caballero> (sweet just being explicit for the notes)
Kerri Lemoie: In terms of EDU use case, these are like "endorsement flows" where a Verified 'endorses' a credenital. ✪
<mprorock> that's what cloudflare is fore
<mprorock> *for
Manu Sporny: For some use cases, there will be open endpoints (like a process to kick off authorization). In some cases there needs to be considerations for some open endpoints. ✪
... to Kerri's point; it could be a simple ACK (200 OK) or it could be a use case that is a continuation: like a "you have passed step one, let's continue to step 2".
... for example, present driver's license, then present other qualification form and so on.
... in (19) there could be a loop step (3) for some new credential types.
<eric_schuh> Also could loop into the issuance flow (not shown here)
Mike Prorock: +1 Manu - there is definite use for that ✪
Ted Thibodeau: (20) Should be closer to (13) - because something was sent (ACK even before it is processed) ✪
... question about meaning of solid/dashed lines, and what is a response and what is a call out.
<mprorock> Ted - we are logging all inbound / outbound / etc but i am not sure that is in scope outside of non-normative best practices for security and audit controls
Joe Andrieu: This flow has "normal English" to convey intent/logic/semantics, but then in later versions we can insert actual API endpoints and params. ✪
Manu Sporny: Hopefully this was a great help to the group (this vas very valuable as concrete material) ✪
... there is a PR for this content, please review. Maybe next call cover CHAPI flow?
Joe Andrieu: Yes, let's look at CHAPI flow, but this diagram also has some controversial statements that need to be discussed; was something misunderstood or incorrect? ✪
<mprorock> as long as we don't drop years in names, cool
... there are also places where we are "not" specifying standardization; like key management. Sso how to navigate thosee issues needs discussion