Re: VC HTTP API Endpoint Authz Needs (was: Re: Attempting to block work)

Treading carefully here to avoid tilting at any windmills - but this bit
seems odd to me:

--------------












*> Veronica>> * To be honest.. I verify anything you throw at me. I get
upset when I> can't verify something. Do I really need to authz?Yes, authz
is needed here. If you don't have authz, you have a denial ofservice attack
vector.Yes, you will try to verify anything that is thrown at you, but you
need toestablish if the caller is in your trust boundary, and to do that
OAuth2suffices for now... and in the future, if we want delegation, we can
addsupport for delegation-aware authorization protocols. The switch is as
simpleas this:*
--------------

We have two distinct verification use cases, one when the verifier is
outside the trust boundary of the verification HTTP API and one when it
is.  Imagine the scenario where an issuing authority in AU ssues a
Certificate of Origin (CoO) VC as a bearer token style VC to an AU exporter
(who is identified in the VC but isn't a DID subject).  It travels along
the supply chain from exporter -> importer -> broker -> importing customs
authority (lets say it's china, CN) and along the way is presented to a
bank (in signapore) as part of a bundle of evidence to support a letter of
credit.  There are 3 verifiers in this story. And two different
verifiication HTTP end points.

   - The broker in CN who has a legal obligation to assure the validity of
   the import documents prior to presenting them to the importing authority.
   He's a sole trader without any significant technical maturity. He scans a
   QR code on the human readable version of this CoO VC and is taken to the AU
   issuers SaaS verification service / API. This case has verifier outside the
   trust domain of the verification service (hosted by the issuer).  Can't use
   OAuth for this.
   - The importing authority (china customs) has no shortage of technical
   capability and, in any case wants it's own assurance and, of course, it's
   own language. CN customs systems receive the VC and call their own
   verfication API.  Any UI presented to a china customs official is talking
   to the HTTP API inside the same trust domain.  OAuth is fine for this -
   although so is SAML or whatever else this enterprise wants to use - not
   sure why we care how they do authz.
   - The bank in Singapore will issue a letter of credit to guarantee
   payment to the seller.  typically the bank will want to see the commercial
   invoice, the certificate of origin and other stuff.  The bank has three
   options for verification.  they could just can the CoO QR and use the AU
   issuers hosted verification service, or they could be big and bad enough to
   have their own internal verification service like CN customs, or they could
   use the SG Government's hosted verification service because they prefer to
   trust their local authority.  So this one could be inside or outside of
   trust domains.

In the cases where the verifier is outside the trust domain, there is no
shared IDP and no relationship at all between verifier and verification
service - so I don't know how OAuth can work.  For this case we use a
secret key that is sent with the bearer VC to authorise the verification -
basically, if you have the VC in your hands then you are authorised to
verify it even if we've no clue who you are. The verifier has to choose to
trust the verification service domain (eg something.gov.au). DDOS attacks
are prevented in the normal way for any anonymous service.  An outer layer
works at infrastructure level, a middle layer uses that bearer secret key.

In the cases where the verifier is inside the trust domain of the
verification API (eg china customs or that singapore bank) then, at least
from our perspective, we don't care how they do authz. nd if we dont care
then we probably don't need a standard for it.

So, my (perhaps misguided and uninformed) summary is - if you are inside a
trust domain then by all means use OAuth but I'm not sure why anyone
cares.  If you are working across trust domains (which is in my
understanding the fundamental value proposition of VCs in the first place)
then you *might* care about authz and if you do then OAuth probably wont
work.

kidn regards,
steve




On Sun, 13 Jun 2021 at 03:09, Alan Karp <alanhkarp@gmail.com> wrote:

> On Sat, Jun 12, 2021 at 8:51 AM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Brian's initiative and Manu's analysis suggests that we could benefit
>> from separating internal vs. external endpoints. Internal endpoints, for
>> example, are unlikely targets for DoS attacks and benefit from delegation
>> only to the extent it promotes a Zero Trust Architecture.
>>
>
> I don't see an important distinction between internal and external
> endpoints.  Attenuated delegation is at least as important internally as it
> is externally if you want to enforce the Principle of Least Privilege (Zero
> Trust).
>
> --------------
> Alan Karp
>
>
> On Sat, Jun 12, 2021 at 8:51 AM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Brian's initiative and Manu's analysis suggests that we could benefit
>> from separating internal vs. external endpoints. Internal endpoints, for
>> example, are unlikely targets for DoS attacks and benefit from delegation
>> only to the extent it promotes a Zero Trust Architecture.
>>
>> - Adrian
>>
>> On Sat, Jun 12, 2021 at 11:23 AM Adrian Gropper <agropper@healthurl.com>
>> wrote:
>>
>>> Manu,
>>>
>>> I also appreciate the clarity of this thread.
>>>
>>> Can we try not to respond to a privacy argument (delegation) with a
>>> business argument (speed) because it just emboldens critics.
>>>
>>> As Justin phrased it in another thread, making delegation a SHOULD,
>>> would satisfy the privacy concern.
>>>
>>> Adrian
>>>
>>> On Sat, Jun 12, 2021 at 10:15 AM Manu Sporny <msporny@digitalbazaar.com>
>>> wrote:
>>>
>>>> On 6/12/21 6:03 AM, Brian Richter wrote:
>>>> > I know but there are implementations out in the real world so I am
>>>> asking
>>>> > those implementers directly.
>>>>
>>>> YES!
>>>>
>>>> These are exactly the right set of questions to be asking, Brian. Thank
>>>> you!
>>>>
>>>> For those that don't know where Brian got the endpoints from, they came
>>>> from
>>>> these documents:
>>>>
>>>> https://w3c-ccg.github.io/vc-http-api/issuer.html
>>>> https://w3c-ccg.github.io/vc-http-api/verifier.html
>>>> https://w3c-ccg.github.io/vc-http-api/holder.html
>>>>
>>>> Asking and answering these *focused* questions will help us understand
>>>> the use
>>>> cases for each endpoint in far more detail than having a
>>>> meta-conversation
>>>> about authz, GNAP, and UMA.
>>>>
>>>> > To address David's questions about the endpoints. *Issuer*
>>>> >
>>>> > * It appears you are going for a short lived credential and the API
>>>> is
>>>> > currently setup for long lived credentials (I forgot to mention the
>>>> update
>>>> > endpoint only updates status)
>>>>
>>>> This is not a correct assumption. The endpoints are set up for both
>>>> short
>>>> lived and long lived credentials and presentations.
>>>>
>>>> > *Holder*
>>>> >
>>>> > * Yes*/presentations/prove *takes in a presentation and this prove a
>>>> > presentation returns the presentation along with a proof
>>>>
>>>> Yes, although we haven't gotten to the point where at least one
>>>> organization
>>>> is going to object to the current construction of almost every Holder
>>>> API
>>>> endpoint. :)
>>>>
>>>> To be clear, the Holder endpoints are in there as a proposal; people
>>>> need
>>>> them, but they are not in their final form and everyone should expect
>>>> these
>>>> endpoints to churn once we get around to discussing them.
>>>>
>>>> > * /credentials/issue o I am an endpoint internal to my organization
>>>> so the
>>>> > authz shouldn't matter to you
>>>>
>>>> There are internal and external use cases for this:
>>>>
>>>> * internal (behind a corporate firewall)
>>>> * external (exposed as a SaaS endpoint)
>>>>
>>>> In both cases, one could say that the authorization happens within the
>>>> same
>>>> trust boundary, and that's probably the determining factor here.
>>>>
>>>> Every use case we have right now for that endpoint has the client in
>>>> the same
>>>> trust boundary as the server. That endpoint is YOUR endpoint in all use
>>>> cases
>>>> because it is using YOUR keys to sign the VC.
>>>>
>>>> It is true that in the future we might allow you to delegate access to
>>>> that
>>>> endpoint, and it is true that Digital Bazaar uses ZCAPs to do this with
>>>> our
>>>> issuer software today... but we absolutely do not want to expose the
>>>> group to
>>>> that at present because... we don't want to hold up the work to do the
>>>> simplest thing first, which is OAuth2 and simple bearer tokens and
>>>> scopes.
>>>> Doing that in no way blocks ZCAPs or GNAP from working in the future.
>>>>
>>>> > * /credentials/update o I use the internal org authz as well
>>>>
>>>> Same things above apply here as well. Authorization is same trust
>>>> boundary. If
>>>> we need to delegate, we can do that in the future.
>>>>
>>>> > Veronica
>>>> >
>>>> > * To be honest.. I verify anything you throw at me. I get upset when I
>>>> > can't verify something. Do I really need to authz?
>>>>
>>>> Yes, authz is needed here. If you don't have authz, you have a denial of
>>>> service attack vector.
>>>>
>>>> Yes, you will try to verify anything that is thrown at you, but you
>>>> need to
>>>> establish if the caller is in your trust boundary, and to do that OAuth2
>>>> suffices for now... and in the future, if we want delegation, we can add
>>>> support for delegation-aware authorization protocols. The switch is as
>>>> simple
>>>> as this:
>>>>
>>>> OAuth2 HTTP Header example:
>>>>
>>>> Authorization: Bearer mF_9.B5f-4.1JqM
>>>>
>>>> ZCAP HTTP Header example:
>>>>
>>>> Authorization: zcap capability=u3jf8Kf....pKq
>>>>
>>>> ^^ That seems to be what all of the fuss is about, and it seems to be a
>>>> tempest in a tea pot.
>>>>
>>>> > Holder
>>>> >
>>>> > * /credentials/derive o All I do is remove information. Do I need
>>>> authz?
>>>>
>>>> Yes, you need authz to provide denial of service attack prevention. The
>>>> server
>>>> also needs authz to determine which cryptographic keys to use when
>>>> performing
>>>> a derivation.
>>>>
>>>> > * /presentations/prove o I'm pretty proud of my credentials, I will
>>>> prove
>>>> > anything you want me to. Do I need authz?
>>>>
>>>> Same answer as above.
>>>>
>>>> > * /presentations/available o I don't need authz since I'm just a
>>>> notify me
>>>> > button to poke.
>>>>
>>>> This endpoint might be misguided and needs to be debated. If it stays,
>>>> it
>>>> doesn't need authz for the reason mentioned above.
>>>>
>>>> > * /presentation/submissions o I only take in credentials from you. I
>>>> can
>>>> > find other ways to throw away garbage. Do I need authz?
>>>>
>>>> Exactly -- this endpoint doesn't need authz to call it because you want
>>>> just
>>>> about anyone to be able to call it.
>>>>
>>>> Any endpoint that doesn't have authz will need to be protected using
>>>> industry
>>>> standard mechanisms (rate limiting by IP, DDoS detection and
>>>> prevention, etc.)
>>>>
>>>> The server is almost certainly going to provide other mechanisms to
>>>> throw away
>>>> garbage/attacks that are layered on top of an effectively open endpoint.
>>>>
>>>> ------------
>>>>
>>>> The fundamental take away here is: OAuth2 bearer tokens are just fine
>>>> for now,
>>>> and it's easy to see how delegation works for ZCAPs (or any other
>>>> delegation
>>>> mechanism that can be triggered through the 'Authorization' header in
>>>> the future).
>>>>
>>>> Hope this helps... and I hope folks in the community, Adrian included,
>>>> start
>>>> focusing on the endpoints themselves and the *focused* ramifications of
>>>> authz
>>>> on each endpoint.
>>>>
>>>> -- 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