Re: VC-HTTP-API new sequence diagram

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>
>>
>>
>>