David Chadwick: We'd like to use the VC-HTTP-API, but it seems like the current version has lost features from a couple weeks ago. ✪
Kaliya Young: Coming out of IIW, we are going to host two special topic summits, probably in July, one on UX for SSI the other on the business of SSI ✪
Manu Sporny: Just a heads up. The Linked Data Signatures Working Group charter debate continues on the semantic web mailing list. ✪
Juan_Cabalero: that group is trying to describe ways to get credentials from one stack to another using existing tech. not so much developing new protocols, but rather how we can already do many of these things. ✪
... This is analysing how existing implementations are different.
... a few of the questions in that process address how the proposers are going to involve folks from different skillsets like design or anthropology and more diverse perspective.
... We, the chairs, realize that might be a heavy lift for the work proposers to find those folks on their own
... so maybe we could source that list as a group to help people find a more diverse group of people
... this work item is about bootstrapping that through the community
... to find folks interested in working on work items in a more diverse role
... might be the right time to start working on this
... Is this a good idea? Are folks interested in helping?
... Just thinking about the VC-HTTP-API for the issuer.
<heathervescent> Juan - I'm gonna wait till we have a break to take questions.
... The issuer is going to be operating some sort of web service gateway that will expose some part of the API
... That system talks to an application-specific service inside the firewall, which executes business logic.
... For example, this is where the application makes decisions about when & why to issue VCs (and the content thereof)
... The application service relies on a database.
<anil_john> @mprorock Would you mind if I set up the VC HTTP API origin story for you?
... It also relies on a verifier service and issuer service
<mprorock> @anil that would be much appreciated
... That's the issuer.
... If we look at the verifier, this is the right side of the diagram
... (Some of these we already know we need to update the diagram)
<anil_john> +q to set up the VC HTTP API Origin Story
<heathervescent> copy Anil
... The verifier website using the VC-HTTP-API with its own application service (with its own business logic) and it uses a verifier service.
... Still teasing out the language, but this is an early draft
... If a digital wallet is being used, we expect that wallet to expose APIs for requesting proofs, etc.
... we know we need to talk about encrypted storage and how one is authorized to use these endpoints
... Those are the pictures of where we're at now
... Hand it over to Anil
Anil John: A little bit of background. I'm the technical director of the Silicon Valley Innovation Program. ✪
... When we put the call out for digital credential work, including digital permanent residence card
... we made a conscious decision where we had been locked into vendors
... so the solicitation itself called out "any API facing the website must be open, royalty-free"
... When we had our first kickoff meeting, the first conversation was that we fully realize that each of these eight companies could implement an open API.
... but what we want to do is to go out under the umbrella of CCG and work out with the broader community what a standard API could be for anyone using VCs and DIDs, regardless of the underlying tech (DLT, etc.)
... If you can do this under the CCG, we can get feedback from the global community.
... Rather than telling what API vendors must use, we committed to using the open standard developed through collaboration
... You are now seeing the interim result that has come out of that
Mike Prorock: First, I want to give Markus credit for his initial issuer and verifier API, which has evolved into this work item. ✪
... The real goal was to make sure there was a good way to handle this interchange over normal REST API rather than relying on polyfills or browser features.
... A lot of us are dealing with VCs in a system-to-system paradigm.
... That's where the test harness came from.
... Which led to a standard endpoint that people can use to test an implementation
... This meant that, e.g., Digital Bazaar was able to take the existing test infrastructure with at new vocabulary and see how the existing ecosystem already supports the use case
... So how do these system-system interchanges happen? This is what brought us into this VC-HTTP-API
... This is something real, that people are using.
Manu Sporny: Five weeks ago we started off with a list of challenges, over to Juan ✪
Juan Caballero: There have been discussion about how to structure the spec itself ✪
... and a lot of workshopping use cases
... the trickiest thing to contribute is that people don't naturally think in terms of generic APIs
... people think in specific use cases
... generalizing from that is hard.
.. The question that everyone brings when they first encounter the work is "Is this an internal API or does it cross trust boundaries" ✪
... The point of the API is to imaging that each role is outsourced. The "worst" case.
... That's the hardest conceptual ah-hah for many
... Joe and Eric Schuh and I have been meeting once/week to iterate on use cases, in-between meetings to bring issues and questions back to the regular call
... Those diagrams Manu shared is something that is also iterating in parallel.
... Use cases are 1/3 of the process, Data flows are another third.
... So these flows could happen entirely on the same machine (without assumptions)
Manu Sporny: The other success is we do have a starting format ✪
... what we don't have are lead editors
... we need to find that.
... next up, Adrian
Adrian Gropper: The next steps and challenges all have to do with human rights on a self-sovereign subject ✪
... Everything about many of these diagrams are seen from the perspective of the issuers and verifiers
... To summarize: if the goal is to enable a self-sovereign subject, give them a capability that they can delegate as desired