- From: Adrian Gropper <agropper@healthurl.com>
- Date: Wed, 22 Sep 2021 10:02:46 -0400
- To: Mike Prorock <mprorock@mesur.io>
- Cc: Markus Sabadello <markus@danubetech.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CANYRo8hPfj-vWSM_wLZ-Jcs=NKKsG6yZu=Wd58_gqigpEk78gQ@mail.gmail.com>
from a privacy perspective: Across Verifier-side trust domain: - Steps 1 and 2 - no impact because no identifying info is shared with verifier trust domain - Step 3 - A decision is made to share an identifier that - resolves to a service endpoint controlled by the holder role - provides a public key to be used for the challenge - Step 13 - more information flows to the verifier Across Issuer-side trust domain: - Step 7 - Request VC - Step 8 - Get Issuer-signed private information as VC - VC Subject is identified by - Long-lived (rotatable) key tied to reputation and to VC subject - Biometric tied to notary or other non-repudiation mechanism (reputation is irrelevant) - Step 11 - If the non-repudiation mechanism is based on - chain-of-custody, use private key to sign the challenge in a more or less non-repudiable way - biometrics, challenge is irrelevant but subject authentication must be out-of-band An alternate flow might be: - Step 3 - A decision is made to share an identifier that - resolves to a service endpoint controlled by the holder role as an agent / authorization server (AS) - Step 6 - Verifier makes a request to the AS. The request may - assume a biometric will adequately identify the subject - include a challenge - The AS controller _alone_ decides if "calling home" or "client credentials" are a privacy problem - Step 6B - The Verifier validates the VC - Step 16 - Depending on business rules, if the VC alone does not include an adequate biometric or equivalent, then an authentication step may be added: - Authentication may apply to the subject or their agent and the private key used to sign the challenge will reflect one or the other - The alternate flow MAY involve client credentials. - Adrian On Wed, Sep 22, 2021 at 8:38 AM Mike Prorock <mprorock@mesur.io> 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> >> >> >>
Received on Wednesday, 22 September 2021 14:03:13 UTC