Re: VC HTTP Authorization Conversation

It helps A LOT, Mike.

This "conversation" is happening at two levels that you are helping
clarify. Let's call them authorization and bootstrapping until someone
suggests something different. One level is simply the use of an
access (authorization) token to access a VC or VP. The other level is the
bootstrapping into trust.

As you clearly describe, much of the bootstrap is out of scope for both
OAuth2 and GNAP. In the end, an access token will be presented by a client,
blindly, to the VC-HTTP resource server endpoint (RS). The access token
will be signed by either the RS itself as a capability or signed by a key
that was established as part of the bootstrap process.

As I might explain it, the difference between OAuth and GNAP is almost
entirely in the bootstrap phase. As our SSI community understands better
than anyone, the establishment of trust is not neutral in terms of
sovereign or legal authority. Different bootstrap protocols will favor
adoption by the sovereign issuers or the by the self-sovereign subjects.

If we can agree that our work should serve both masters, then maybe we can
agree to work on OAuth and GNAP simultaneously as well.

Adrian



On Fri, Jun 4, 2021 at 2:21 PM Mike Varley <mike.varley@securekey.com>
wrote:

> Hi Adrian, I will take a stab at addressing these questions.
>
>
>
> > 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.
>
>
>
> There is a challenge across the SSI space on how self-sovereign
> holders/wallets/agents “introduce” themselves to a service provider. (It is
> not unique to SSI, all open-world federated scenarios have such challenges,
> from NASCAR selectors to OpenID 2 discovery urls, to account chooser). The
> 2 most common ways I have seen to bridge this gap in SSI is 1. through the
> browser with CHAPI, or 2. through a DIDComm introduction message (that has
> a DID, and the DID Document has a published “call me here” endpoint). Once
> that introduction is made, there is (may be) an authentication step where
> the client and server establish a trusted session or link relationship;
> based on that action, the client/holder/wallet/agent can obtain an access
> token to call an HTTP endpoint to collect a Credential or deliver a
> Presentation.
>
>
>
> The point is that the VC-HTTP-API is not responsible for the bootstrapping
> of a trust relationship between and issuer/holder or holder/verifier; that
> is achieved “somewhere else” – the VC-HTTP-API simply trusts that a client
> calling an endpoint with a valid authorization token has gone through the
> necessary handshakes, and is permitted to call the function. The
> VC-HTTP-API resource trusts its Authorization Server issuing access tokens.
>
>
>
> The conversation of how this authorization handshake/dance is an important
> and interesting one; but I would argue out of scope for the VC-HTTP-API
> itself; again, this resource puts its trust in the authorization assertions
> provided to the client from a trusted source.
>
>
>
>   > 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.
>
>
>
> I dunno about the first part, but I’ll take a swing 😊 Both GNAP and
> OAuth protocols result in access tokens being delivered to clients that
> wish to access HTTP resources protected by an authorization server. As
> mentioned above, so long as the VC-HTTP-API endpoint can
> process/validate/accept an access token provided by a client, it doesn’t
> really “care” how it was obtained. OAuth 2.0 provides a mechanism for
> clients to obtain access tokens, but suffers in scenarios outlined in GNAP,
> that GNAP is aiming to address (including allowing for more dynamic client
> registration/handshaking, mobile or out-of-band agents, and other patterns
> we see in the SSI space) – however at the end of the protocol the results
> are similar; an access token for a resource is provided to a client
> (Holder/wallet/agent) to call a resource (VC-HTTP-API).
>
>
>
> The access tokens themselves are a contract between the Resource Server
> and Authorization Server; so the client does not need to process them, or
> understand that they are session tokens, JWS/E permission grants, ZCAPs
> grants, or other forms of Credentials.
>
>
>
> Finally I would like to acknowledge that there is still a floating
> question of the optimal/interoperable method for service providers,
> authorization “servers” (which could be mobile apps), and resource
> endpoints locate and trust each other “in space” and how consent is
> recorded and maintained – these are important questions in the big picture;
> but beyond the single purpose VC-HTTP-API endpoint which just wants to deal
> with Credential objects (in my understanding/opinion).
>
>
>
> Hope that helps,
>
>
>
> MV
>
>
>
> *From: *Adrian Gropper <agropper@healthurl.com>
> *Date: *Thursday, June 3, 2021 at 9:42 AM
> *To: *Mike Varley <mike.varley@securekey.com>
> *Cc: *W3C Credentials Community Group <public-credentials@w3.org>
> *Subject: *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.)
>
>
>
>
>
> 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.
>
>