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

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 03:14:49 UTC