Re: VC HTTP Authorization Conversation

It's my impression that all of the 8 implementations were built on the
basis of DHS as the sole issuer and customer. In some cases, BC Gov was
another issuer / customer beyond the control of the subjects.

We are issuing VCs for use and verification by other customers outside the
DHS space fyi, primarily in use for record keeping of chemical applications
in agricultural settings, as well as to enable our customers to record
verifiable field sample and observation data, and provide chain of custody
on biological samples.  These use cases predate any of our work with DHS,
and in all cases, all transport is done over TLS with OAuth 2.

Michael Prorock
CTO, Founder
mesur.io

On Thu, Jun 10, 2021, 09:32 Adrian Gropper <agropper@healthurl.com> wrote:

> (a) +1 David's suggestion of TLS.
>
> (b) Regarding scope, Manu's personal perspective is inconsistent with my
> personal perspective. For example, I was clear that VCHTTP would be
> best-served by working on Issuance as a separate document.
>
> (c) Most important, Manu is saying:
>
>> "the entire VC Data Model is set up around being able to have a choice in
>> verifiers, so it's a bit strange that you're asking this question in the
>> first place."
>
>  while also asserting that:
>
>> "Gating the VC HTTP API on technology that hasn't been integrated into
>> any of the 8+ implementations that we have today of the VC HTTP API will
>> create anunnecessary block on the work."
>
>
> It's my impression that all of the 8 implementations were built on the
> basis of DHS as the sole issuer and customer. In some cases, BC Gov was
> another issuer / customer beyond the control of the subjects.
>
> As others have pointed out in our discussions, there's a difference
> between internal and external interoperability. OAuth2 is fine for internal
> interoperability because the resource server and authorization server are
> internal to the same trust domain. But this is **irrelevant** to the VCHTTP
> spec as I understand it. If there's no choice of issuer, then the issuer
> can control the holder and their wallet and probably will. For example,
> Apple announced support for state drivers licenses in their iPhone wallet
> on Monday. As with the GAEN COVID exposure notification work, it's easy to
> see how state authority will license specific vendors to act as their
> agent. This is why our good work on the VC data model risks significant
> nullification if we rush protocols under the "internal" assumption.
>
> I indeed am attempting to block work on VC-related protocols until "we" as
> a community deal openly with this issue because I do seem to agree with
> Manu that ignoring it threatens the adoption and success of the VC work
> itself.
>
> - Adrian
>
> On Thu, Jun 10, 2021 at 10:24 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> Hi Manu
>>
>> one solution will be to require mutual TLS, where the authz token is the
>> caller's X.509 PKC, since this can address both authn and authz
>>
>> Kind regards
>>
>> David
>> On 09/06/2021 18:19, Manu Sporny wrote:
>>
>> On 6/8/21 3:41 PM, Manu Sporny wrote:
>>
>> Bootstrapping is completely out of scope. The VC HTTP API doesn't care how
>> you got the token, it just cares that you have a token that authorizes your
>> access to the endpoint.
>>
>> Let me try to reformulate this as a pre-proposal, based on my understanding of
>> Justin and Adrian's characterisation[1] on the call yesterday and what I
>> believe Mike Varley was getting at in his Trust Agent[2] use case...
>>
>> Background:
>>
>> There are three separable components to the VC HTTP API Authorization discussion:
>>
>> 1. Is the caller of the VC HTTP API authorized? That is,
>>    are they in possession of a valid authorization token?
>>
>> 2. How do we determine what authorizations they have
>>    based on the authorization token? That is, what
>>    are the contents or associated authorizations
>>    that are conveyed with the token?
>>
>> 3. How did they come to possess that authorization
>>    token in the first place? That is, what is the
>>    process of authenticating and then granting
>>    authorizations to be conveyed with the token?
>>
>> I'm going to suggest that:
>>
>> #1 is in scope for the VC HTTP API.
>>
>> #2 is only in scope to the degree that the group
>>    can agree to at least one token format (Simple Bearer
>>    vs. JWT vs. something else). We may not be able to
>>    agree on anything here (other than "it's opaque" and
>>    "it's up to the implementation to determine how to
>>     process the token").
>>
>> #3 is completely out of scope.
>>
>> Would there be any objections to any of the above if it were put forward as a
>> set of proposals during the next meeting?
>>
>> If you object, please provide a concrete counter-proposal that the group can
>> consider.
>>
>> -- manu
>>
>> [1]https://w3c-ccg.github.io/meetings/2021-06-08-vchttpapi/#topic-2
>>
>> [2]https://w3c-ccg.github.io/meetings/2021-06-08-vchttpapi/#topic-3
>>
>>