Re: Proposal for Authorization in VC HTTP API

thank you manu,

That table is helpful and does clarify the scope.

There is one common use case (for us) that I'm not sure is represented - or
whether it needs to be.

   - Some certifying authority (eg chamber of commerce) that is accredited
   by a national authority (eg customs) issues a bearer token style VC about a
   *thing* (eg "we attest that *consignment xyz* meets origin criteria
   abc").  The certificate is given to the exporter, who passes it to the
   freight forwarder, who sends it to the importer, who gives it to the
   customs broker, who presents it to the importing country customs.
   Meanwhile the importer (buyer) also passed the same certificate to their
   bank as part of a letter of credit application.
   - There are LOTS of parties along this chain, each of which may need to
   verify the certificate.  Some will have their own verifier service (eg the
   importing customs authority) but many will not.  Therefore the exporting
   regulator (who is motivated to facilitate exports from their economy) hosts
   a free and anonymous verifier service.  Anyone can give it a VC without any
   authentication or authorisation and the service will verify it. The service
   might be limited to certain credential type and protocols but will verify
   those credentials irrespective of who is the issuer and who is the verifier.

One day maybe everyone will have a verifier service built into their
system, but until then there is a bootstrapping problem where the issuing
economy cant go digital because somebody along that supply chain might need
to verify the certificate and, without some readily available verifier
service, might demand paper originals.

So, would this free / anonymous verifier service contradict the
verifier->verifier service row in your spreadsheet that says authorisation
is mandatory?

On Mon, 23 Aug 2021 at 00:13, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 8/21/21 7:26 PM, steve capell wrote:
> > * I'm unclear about which VC-API interactions should require
> authorisation
> > and which should not.
>
> There is clarity on most, but not all, of the endpoints we have defined so
> far
> wrt. authorization. There is a column here marked "Authorization
> Required?":
>
>
> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit#gid=0
>
> To be clear, we're talking exclusively about authorization (not
> authentication, e.g., DIDAuth -- that's out of scope).
>
> > * I can imagine that an issuer will certainly want to authorise a
> subject
> > that is requesting a VC.  "yes, that's the john smith we know, here's
> your
> > digital drivers license"
>
> The term I believe you meant to use was "authenticate", because
> "authorization" is subtly orthogonal. So, let's make sure we're talking
> about
> the same thing first:
>
> https://stackoverflow.com/a/6556548
>
> "yes, that's the john smith we know" is authentication
>
> "and given that it's the john smith we know, he is authorized to receive a
> digital driver's license" is authorization.
>
> "here's your digital drivers license" presumes some sort of authorization
> took
> place. Providing the digital drivers license happens AFTER authorization
> was
> successful.
>
> > * But I cant imagine why or how a verifier will want to authorise John
> > when he presents his license as proof of age in a bottle shop because
> > there's very unlikely to have been any a-priori registration of either
> john
> > or his chosen system to the bottle shop system. Instead I'd expect an
> > anonymous access "yes, that's a valid drivers license and, yes, the photo
> > on it looks like you sir, here's your vodka".
>
> Again, "yes, that's a valid drivers license and, yes, the photo on it looks
> like you sir" is authentication.
>
> "and given that you're above the age of ??, you are allowed to purchase
> alcohol" is authorization.
>
> "here's your vodka" presumes some sort of authorization took place.
>
> You're not far off, but we do need to make sure we're very clear about what
> we're talking about "authorization", and what's not necessarily the focus
> of
> the current discussion "authentication".
>
> > would it be possible to see a diagram of VC-API interactions with some
> > indication of which require auth and which dont?
>
> Column G here:
>
>
> https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit#gid=0
>
> The Use Cases team is working on some more detailed data flow diagrams to
> elaborate upon the matter further. I expect we're several weeks of from
> those
> being done.
>
> Did that help, Steve?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>

-- 
Steve Capell