Re: VC HTTP Authorization Conversation

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


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

-- manu



Manu Sporny -
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches

Received on Wednesday, 9 June 2021 17:20:10 UTC