- From: Joe Andrieu <joe@legreq.com>
- Date: Wed, 22 Sep 2021 09:18:11 -0700
- To: "Credentials Community Group" <public-credentials@w3.org>
- Message-Id: <42755752-8e23-449a-b93e-1ab68d748ba7@www.fastmail.com>
On Wed, Sep 22, 2021 at 1:10 AM Markus Sabadello <markus@danubetech.com> wrote: >> Also, since it mentions WebKMS, I was wondering what's the current state of that, and is anyone actually using it in conjunction with the VC API. >> Good catch. The WebKMS there really should just be *KMS. It is meant as a generic Key Management Service, not necessarily the WebKMS variant of that. (I'll let implementers speak on their use, but yes, I do know of active use of the WebKMS spec.) One of the things we've found vital to teasing out the roles in these kinds of flows is figuring out exactly where the crypto needs to happen and how that is authorized. The nice thing about a WebKMS or a *KMS is that you use an authorization architecture to get key services performed. In the WebKMS flow, that means you have to create a zCap Invocation, which itself must be signed. That means that the invoker has to be able to perform at least some crypto on its own, with its own app-specific keys (or at least it tends to be app-specific keys). The *KMS enables a lot of nice use cases where you can delegate key usage without sharing the private key, hence its place in the diagrams. That point alone has shifted some of the messaging (and some more that needs to be updated) to clarify who has to be capable of signing an invocation (or satisfying some other authorization regime which we will eventually need to outline). As I mentioned on one of the calls for these diagrams, anyone could "Martha Stewart all the way down" and build, e.g., the Issuer App, the Issuer Service, the Issuer *KMS, and the Issuer Storage Service all in a single monolithic Issuer app. But thinking about it as monolithic obscures the important discussions about how to handle substitutability. We had a fun time debating whether or not these diagrams need to break everything out like this, but so far, I've found it illuminates more than it confuses. In particular, when we break out the different components at this level of granularity, we can convince ourselves that the API supports a firm notion of substitutability as well as interoperability between those substitutes. In fact, I'd posit a principle embodied here, that every component MUST be substitutable without loss of API functionality. If I want to use the Veres Wallet front end with a Ledger-based KMS, I should be able to do so as long as both support the VC-API. To me, THAT is perhaps the primary goal from a holder application perspective (aka wallet): a complete separation of key and custody management from the apps that rely on them. How I choose to back up my keys or apply business rules like multi-sig is my business, not the apps. I can't do that when providers like Coinbase have a monolithic app and hold my keys in their system. Sometimes that's appropriate (unless >> I agree with the App/Service terminology, it helps to illustrate where the VC API comes into play and where it doesn't. >> Indeed. It also was a huge breakthough for me bridging the gap with the supply chain perspective (relative to the human-mediated green card flow). Mike & Orie have been arguing that the Verifier App needs some clear API endpoints for holders and many of us were hearing that as the Verifier Service needs those endpoints, which seemed crazy since the Verifier Service is a back-end support for the Verifier App and is never directly involved with the holder... at least in the architecture developed for the DHS interop plugfest. At first, I thought they were crazy, but then I realized they just had a different starting point (and that we were conflating components with misaligned language). If we want the kind of interoperability and substitutability I mentioned above, yes, absolutely API endpoints for the Apps should be a part of the discussion. What those are, of course, are up for debate, but the current API (as represented by the swagger files as I understand it) already has some of these, and we've just been talking past ourselves on the topic. -j On Wed, Sep 22, 2021, at 5:36 AM, Mike Prorock wrote: > Data Ready Package in the context of the diagram is sent by the Verifier App with any needed data for the Holder App to make the signed VP > > I'll let Orie or others discuss WebKMS > > Mike Prorock > CTO, Founder > https://mesur.io/ > > > > On Wed, Sep 22, 2021 at 1:10 AM Markus Sabadello <markus@danubetech.com> wrote: >> >> I had some minor questions about a few details, e.g. what's a "Data Ready Package"? >> Also, since it mentions WebKMS, I was wondering what's the current state of that, and is anyone actually using it in conjunction with the VC API. >> >> >> But in general, I think this digram is very useful, nice job! >> I agree with the App/Service terminology, it helps to illustrate where the VC API comes into play and where it doesn't. >> >> Markus >> >> On 21.09.21 21:59, Joe Andrieu wrote: >>> Here's a rendering of the work flow from the supply chain folks (Erich Schuh and I sat down with Orie and Mike to tease this out). It advances the conversation from a non-chapi use case. >>> >>> Notably, some additional definitions >>> >>> XXX App = The server that instantiates the business rules that drive XXX behavior >>> XXX Service = The service/software that provides the XXX specific functionality, driven by the XXX App. >>> >>> For example, in the USCIS Digital Green Card case >>> *Issuer App* = the website run by USCIS that interfaces with beneficiaries and knows who gets a green card. It drives the Issuer Service. >>> *Issuer Service *= the SaaS run by, e.g., Digital Bazaar, which provides VC issuance capability to clients >>> >>> We've started using this pattern across all three roles and are working through updating the CHAPI flow. >>> >>> -j >>> >>> -- >>> Joe Andrieu, PMP joe@legreq.com >>> LEGENDARY REQUIREMENTS +1(805)705-8651 >>> Do what matters. http://legreq.com <http://www.legendaryrequirements.com/> >>> >>> -- Joe Andrieu, PMP joe@legreq.com LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com <http://www.legendaryrequirements.com/>
Received on Wednesday, 22 September 2021 16:18:46 UTC