Re: VC HTTP Authorization Conversation

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