- From: Brian Richter <brian@aviary.tech>
- Date: Sat, 24 Jul 2021 08:58:05 -0700
- To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAPUZd8tDqcphB+7ChjeJEvJ5SjSN=N5QqjqOx1KqjemfgdrWxg@mail.gmail.com>
(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