Re: New VC-API architectural overview

Joe, hi -

I'm just sharing this as an anecdote, from the commercial world. It's 
not an objection - just a comment.

The Verifiable Credentials Data Model does indeed define three 
fundamental roles: the Issuer, the Holder and the Verifier.  We've 
always had trouble with the last two terms and instead use 'Recipient' 
and 'Relying Party'.  The term verifier in our context refers to a 
computational process - what the VC API document describes as an app.  
As for apps, we have an Issuer App, a Viewer App and a Verifier App.  
The Viewer and Verifier Apps are used either by the recipient or the 
relying party and occasionally by the Issuer.

I do understand that this approach glosses over important differences 
between bearer, subject and custodian.  But these usually boil down to a 
relying party's dilemma, ie- how does the bearer of a VC prove that they 
are the subject or a valid custodian? There are technical solutions such 
as ZKP or Paypal verification (the ability to spend from a wallet 
referenced in a VC), but most relying parties would conflate the 
bearer/subject/custodian term as VC Recipient and just (naively) assume 
that Verifier Apps take care of these technicalities.

One further note, our Issuer App is multi-tenanted and supports multiple 
Producers engaged by a single Issuer.  Example use cases would be 
Clinics operating under a Health Ministry, and Schools operating under a 
University.  The term 'Producer' does not exist in the VC lexicon, but 
the function does.  A Producer is simply a delegated Issuer role.  The 
Producer role also aligns with the well-understood GDPR terms: Data 
Controller and Data Processor.

We think it's important to identify both Issuer and Producer as actors 
in the VC document.

Regards, Bill Claxton (williamc@nextid.com)
LinkedIn, Facebook, Telegram, Slack, Skype, Twitter or Gmail: wmclaxton
SG Voice, Text or Whatsapp: +65-9012-4327
US Voice, Text or Voicemail: +1-415-797-7348


On 10/27/2021 3:38 AM, Joe Andrieu wrote:
> Based on the work with both CHAPI and Supply Chain use cases, we've 
> developed a new architectural overview, which you can find in PR #237
> https://github.com/w3c-ccg/vc-api/pull/237
>
> This is a proposal for shared language that teases out the 
> distinctions between various implementer's perspectives, and still 
> needs input and engagement from the larger community.
>
> I'm sure some of the language might seem strange at first, but it 
> seems to be a good starting point for resolving apparent differences 
> between different use cases by baselining shared language about how 
> the ecosystem works.
>
> Let's discuss.
>
> -j
>
> --
> Joe Andrieu, PMP joe@legreq.com
> LEGENDARY REQUIREMENTS                        +1(805)705-8651
> Do what matters. http://legreq.com <http://www.legendaryrequirements.com>
>
>