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

>>  which is why we use the merkel hash-tree approach to redaction.

That's not right is it?  I think a holder can make a ZKP based VP from a VC
without asking the issuer.  my bad.  I probably should have just said that
we use the merkel tree approach because it's simple.

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

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

-- 
Steve Capell