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

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

We use the royalty free open source library from Singapore government for this. See:

https://www.openattestation.com/

However it’s quite true that it’s not written as a formal standards specification.  I don’t believe that there is any license or IP issue to prevent it - just nobody has done it yet 

I’m not sure whether the w3c http api spec is the right place for it but I do strongly believe that there is a need for an anonymous verification http  method - and that a secret key with VC kind of thing adds value to help prevent ddos etc.  

Is this something that might be put in scope for this work? If so then how can we help?

Steven Capell
Mob: 0410 437854

> On 14 Jun 2021, at 11:26 pm, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> 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/
> 
>