Re: VC HTTP Authorization Conversation

Hi Mike,

Firstly, I want to thank SecureKey for the early and major support of GNAP.
If not for you, I might still be stuck trying to profile UMA for another
decade. (As a founder of the OpenID HEART workgroup, I am not kidding.)

Second, I appreciate that institutional clients can use OAuth at the
VC-HTTP endpoint but my concern is on how self-sovereign clients (compiled
from source by me, as for example, would happen with a typical microservice
or app platform) will get the VC.

Third, I’m hoping that someone much more knowledgeable than myself in the
ways of OAuth and GNAP draft 5 will share with our workgroup the specific
implications of doing both OAuth and GNAP draft 5 simultaneously.

Thanks,
Adrian

On Thu, Jun 3, 2021 at 9:24 AM Mike Varley <mike.varley@securekey.com>
wrote:

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