- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 14 Jun 2021 09:21:42 -0400
- To: public-credentials@w3.org
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