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

Issuer API Cross Trust Boundary Scoping - VC-HAPI (f.k.a. VC-HTTP-API)

From: Brian Richter <brian@aviary.tech>
Date: Sat, 24 Jul 2021 08:58:05 -0700
Message-ID: <CAPUZd8tDqcphB+7ChjeJEvJ5SjSN=N5QqjqOx1KqjemfgdrWxg@mail.gmail.com>
To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
(Subject line is an endorsement for the name VC-HAPI)

The scope of the Issuer API is an important consideration of VC-HAPI that I
don't think is entirely clear to anybody. Is it used within an issuer org /
sovereign domain? Does it allow external parties to issue credentials about
subjects they are authorized to issue claims about?

I think the important question to ask is are we designing this API with
Zero Trust Architecture in mind? If so, how granular are we reintroducing
trust through this authorization mechanism?

I think I'm starting to understand how RAR fits into this picture. This
decision can be made for us by punting the question to the authorization
process entirely. With RAR we can force the user to authorize for the
actual subject they are issuing the credential about. Is Alice authorized
to issue VCs with claims about did:example:12345? To answer that question
Alice asks for a token with the following RAR request

{
type: “vc-hapi”,
actions: [ create ],
datatypes: [ credentials ],
identifier: did:example:12345
}

If Alice has a token that fits that description then they are authorized
and the API can allow them to issue a credential regardless of if they are
within the trust boundary or outside. How can this be accomplished with
oauth2 standard scopes? Alice can have a token with the
create:credentials scope
in their token but we can't entirely authorize the user for a specific
action without additional domain business logic..

I think one of the main friction points here is that RAR brings some of the
domain logic into the authorization process which in my opinion is a worthy
endeavour. If we can fully trust our authorization process to do *ALL* of
the authorization this API can be something truly special. However if we
limit ourselves to less granular scopes, we are either implicitly creating
an internally scoped API or requiring ourselves to bake in a secondary
authz process.

I can only speak for myself and my organization but I am here to do
something special not reinvent the same wheel over again with a bit of VC
pixie dust sprinkled on top. I now entirely agree with Justin in that if we
don't include RAR as a MUST we are doing ourselves and this API a
disservice. It would be a big mistake.

Hopefully what I've outlined above does a good job explaining how powerful
granular authz might allow this API to accomplish something special. So
here is my concrete proposal to see if the group aligns with what I've said:

PROPOSAL: The VC-HAPI Issuer API MUST allow authorization on a credential
subject granularity level

Thanks,
Brian

PS Let's make VCs Happy together :)
Received on Saturday, 24 July 2021 15:58:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:18 UTC