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

Thanks Manu, 

I agree with most of what you say.  Except the “no access to verification API by sole traders” bit.

I / we / government services really don’t see any difference between UI and API access.  It’s the same service for the same anonymous or identified party.  If we host a QR accessible anonymous verification UI then we’d also provide an API.  Our general principle is that everything you can do by UI you should also be able to do via API.  The sole trader might want to allow his financial system to hit the API rather than use the UI.  So we provide both UI and API for verification and it uses the same “anonymous user holding a secret key” auth method.  And the same DDOS concerns (and solutions) apply to both UI and API.

So we most certainly do have a case for verification API that does not (cannot) use OAuth.

Other than that I agree with all your comments.  Thank you for taking the time to respond. I can see that you put huge effort into your standards participation - to the benefit of all of us 

While I’m at it - thanks for JSON-LD too!

Steven Capell
Mob: 0410 437854

> On 14 Jun 2021, at 1:20 pm, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 6/12/21 7:52 PM, steve capell wrote:
>> Treading carefully here to avoid tilting at any windmills
> 
> :)
> 
>> 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.
> 
> Hmm, you might be conflating what the the presentation API does from the
> verification API?
> 
>> 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).
> 
> Ah, in this case we don't have to imagine it since something very
> similar was implemented for one of the DHS/CBP proof of concept programs
> (the Intellectual Property Rights PoC).
> 
>> * 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.
> 
> This is not what the Verification VC HTTP API is for; it's not exposed
> to just anyone. What could happen is that they'd either use an app to
> scan the QR Code, which would then use some sort of session token to hit
> the app site, which would then use OAuth to hit the verifier VC HTTP
> API. No direct access to the VC HTTP API to sole traders.
> 
>> * 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.
> 
> We care how they do authz because companies want to sell verifiers into
> CN customs systems and CN customs systems doesn't want to get locked
> into one vendor API. They want to install the software, get an OAuth
> token, and then use the API without having to re-learn and integrate
> with a bunch of proprietary vendor APIs.
> 
>> * 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.
> 
> Again, if they're outside the trust domain of the verifier VC HTTP API
> instance, they don't have access, full stop. They need to use another
> service that provides access to them.
> 
>> 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.
> 
> It won't work, you either need a proxy or delegation. Given that there
> are other things going on here -- industry-specific processes and VCs,
> scanning of QR Codes that probably need to be processed in a certain way
> -- it's almost certainly an argument for a specialized app/webapp that
> just also happens to be tied to a verifier VC HTTP API.
> 
>> 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.
> 
> That is one authorization model that could work. You'd need other
> protections on it -- like you can only do that up to 100 times from your
> IP. There are DDoS attacks that I'd be concerned about if you did that,
> but overall, probably not a terrible thing to mitigate against via
> aggressive caching and other mechanisms to ensure that an asymmetric
> attack can't be performed.
> 
>> 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.
> 
> Well, you'll care if you're an integrator and every VC HTTP API has some
> sort of bespoke way of doing authz... especially the home-grown authz
> mechanisms.
> 
>> 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.
> 
> Hopefully I've explained above why all 8 vendors implementing the VC
> HTTP API care -- it's because their customers care and the vendors want
> to make their customer's lives easier.
> 
>> 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.
> 
> Yes, correct. When you're working across trust domains you can rely on
> the VCs and presentations themselves to determine authorization (to a
> certain degree), OR you can depend on other things like GNAP or ZCAPs...
> but as the analysis of all the endpoints we have right now showed, the
> issuer/verifier VC HTTP API endpoints don't need to work across trust
> domains. The presentation endpoints do, but you're using VCs/VPs there,
> which are fundamentally designed to work across trust domains.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>

Received on Monday, 14 June 2021 04:41:05 UTC