Re: VC HTTP Authorization Conversation

Hi Adrian,

Thank-you for bringing this subject to the list to see if we can make progress outside of a tight 1hr call – I had similar intentions so now I will piggy back on your initiative :)

First, SecureKey is a strong supporter and proponent of GNAP, seeing potential in that protocol/pattern in this space since the day it was introduced as an idea at IIW, and we implemented the first NodeJS “XYZ” spec to help prove its viability.

That being said, I think it is still too early to hitch the VC-HTTP-API to GNAP – GNAP is still very much in drafting stages at IETF, and there is a lot to unpack in that spec.

Second,  I do not believe authorization _mechanisms_ are in scope for the VC-HTTP-API. As mentioned on the call, the VC-HTTP-API is a Resource – and in order to protect its Endpoints, Client’s (may) require authorization to execute a function on that Resource. But in a pure separation of concerns, this resource is not managing authorizations, policy decisions, or permissions – but it is (should be?) enforcing these decisions made by a decisioning entity (like an AuthZ server, or maybe a Trust Agent as per the use case I entered in the google doc).

There are  2 types of authorization I have heard on the call that I think apply to the VC-HTTP-API server endpoints:

  1.  A system-to-system authorization/authentication (as an application, am I permitted to call this endpoint?) – for example, the /issue/credential is a utility function that mints a Verifiable Credential for a upstream system, and this call may need authorization for an application to call, and
  2.  A session or context based authorization - other interactions with a person/holder/entity have taken place, and now a client may call the VC-HTTP-API endpoint in the context of that interaction (for example, issuing a credential to a specific DID/Holder).

(my assumptions)

In order to stipulate a workable model for the spec in this early stage, OAuth 2.0 supports both of the above cases. An OAuth 2.0 model will also support UMA and OpenID Connect scenarios. Other, better authorization mechanisms may be specified and applied as required for certain use cases, but I believe (correct me if I am wrong) that an OAuth 2.0 based authorization model sufficiently meets the authorization requirements, without cutting out future methods.

One warning I would have against REQUIRINF OAuth 2.0 is that it may impact existing enterprise systems which rely on mTLS for (1) above, where tokenization is not yet supported.

Also, I think it makes sense to look at the endpoints specifically to see where authZ is required, recommended, or not required given cases (1) and (2) above.

SecureKey will definitely be working on integrating GNAP like flows with this space moving forward, and I look forward to collaborating on that effort.

Thanks, I am looking forward to feedback on my above assumptions because I’m not sure where the group sits :)

MV


From: Adrian Gropper <agropper@healthurl.com>
Date: Wednesday, June 2, 2021 at 5:10 PM
To: W3C Credentials Community Group <public-credentials@w3.org>
Subject: VC HTTP Authorization Conversation
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The diversity of our community is a plus. To begin a conversation on VC access controls, I suggest this short intro to the differences between OAuth 2.0 and GNAP:

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-compared-to-oauth-20

My goal is to arrive at a shared understanding of what would be minimum needed to support both OAuth2 and GNAP for securing access to a VC.

- Adrian

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.