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

Just to be clear - it's only the verifier -> verification service
end-point that I'm talking about here.  It seems reasonable (at least to
me) that the issuing API could use OAuth because you'd assume that the
issuer needs a way to identify the subject to whom they are issuing a
credential.  Also if your model for VPs is to ask the issuer to mint one
for you then OAuth could work for that too.  Although we cant really use
that model because the redaction of a bearer VC might be done by any
holder, including those we dont know - which is why we use the merkel
hash-tree approach to redaction.

On Sun, 13 Jun 2021 at 09:52, steve capell <steve.capell@gmail.com> wrote:

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

-- 
Steve Capell