- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 25 Jun 2021 09:50:11 -0400
- To: W3C Credentials CG <public-credentials@w3.org>
Hi all, In an attempt to move the conversation related to authorization as it relates to the VC HTTP API forward, there are a few things that we can attempt to put out of scope that will reduce the complexity of the problem we're trying to tackle. The first one is: Is the way a client gets an access token out of scope for the VC HTTP API? As long as the client has an opaque access token, do we care how they got it? Are all interactions with an Authorization Server out of scope for the VC HTTP API? If the answer to the questions above are "yes" and "yes", that greatly reduces the scope of the authorization discussion we need to have around the VC HTTP API. The proposal form of the questions above are: PROPOSAL: Interactions between a Client and an Authorization Server, such as authorization grant, token refresh, and token lifecycle management, are out of scope for the VC HTTP API specification. COUNTER PROPOSAL: Interactions between a Client and an Authorization Server, such as authorization grant, token refresh, and token lifecycle management, MUST be fully specified in the VC HTTP API specification. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Friday, 25 June 2021 13:50:34 UTC