- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 9 Jun 2021 13:19:37 -0400
- To: public-credentials@w3.org
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
--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches
Received on Wednesday, 9 June 2021 17:20:10 UTC