W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 14 Jun 2021 09:21:42 -0400
To: public-credentials@w3.org
Message-ID: <079f01d6-2039-ba48-4b7b-c4e00bd4275e@digitalbazaar.com>
On 6/14/21 12:40 AM, Steve Capell wrote:
> 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.

Yes, that's valid... more below.

> If we host a QR accessible anonymous verification UI then we’d also provide
> an API.

Yes, the key word here is "anonymous" -- because of that word, OAuth doesn't
apply.

> Our general principle is that everything you can do by UI you should also
> be able to do via API.

Yes, valid and I expect is how most modern Web-based interfaces and APIs are
built today.

> The sole trader might want to allow his financial system to hit the API
> rather than use the UI.

Ehhh, I thought you said that the sole trader doesn't have the resources to do
integrations like that... :)

... but I'm fine pretending that you didn't say that. I know sole traders that
have built their entire software system from scratch... besides, you need to
offer the API for the large customs organizations and trade finance orgs.

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

Yes. I will note that your authorization mechanism, unless all you need to do
is post the VC, is entirely bespoke. No one else knows how to do exactly what
you're doing today because it's not documented... and that's why we care so
much about authz. No one can interoperate at a global scale with the mechanism
you're describing until you write it down in a specification and offer it on a
patent-and-royalty-free basis.

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

Yes, although I would suggest what you're really doing is exposing an
industry-specific API to verify trade finance documents. I would imagine that
your verification API does more than just check digital signatures and
revocation information. It probably does some degree of data validation as
well, and thus, is not the VC HTTP API verify functions.

Take a look at this diagram:

https://docs.google.com/drawings/d/19wJSXTVabVpYJIv1b2hXPPpJ2mPlDkhyYnHylQFwE0Q/edit

What you're really talking about is authz on the "Web Service" box, not the
"Verifier Service" box.

> 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

... and that you for engaging -- it's vitally important that this stuff
doesn't happen in a vacuum; conversations like these are formative for the work.

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

Like all standards work, it was a team effort -- Dave Longley and Gregg
Kellogg are the real heroes there, with a very large supporting cast of
characters:

https://www.w3.org/TR/2014/REC-json-ld-20140116/#acknowledgements
https://www.w3.org/TR/json-ld/#ack

Glad JSON-LD is of use to you... :)

-- 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/
Received on Monday, 14 June 2021 13:22:09 UTC

This archive was generated by hypermail 2.4.0 : Monday, 14 June 2021 13:22:16 UTC