RE: VC HTTP Authorization Conversation

Having the ability to exert self-sovereign control over one’s digital identity is one thing but it doesn’t automatically extend beyond that to each of us being able to choose which Issuers and Verifiers are allowed to traffic our digital identity information.

Here’s an example: https://www.linkedin.com/pulse/canadian-banks-trafficking-digital-identities-canadians-herman/

Somewhat dated but still relevant. i.e. I’m not seeing any deposits being made to my bank account when my banks traffic my personal digital identity information for additional revenue.

This is also a huge theme/motivation behind many of the DeFi projects: trafficking in individual people’s digital identity information.

Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image002.jpg@01D75DD6.782A6DB0]



From: Adrian Gropper <agropper@healthurl.com>
Sent: June 9, 2021 4:36 PM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: VC HTTP Authorization Conversation

Is it wise for us to make a scope resolution without at least one or three foundational use-cases?

As a self-sovereign subject, I need to consider my options in dealing with issuers.

Do I have a choice of issuers? For example, my driving credential is very different from a blood test credential.

Do I have the ability for attenuated delegation? For example, if my blood test credential includes both Cholesterol and HIV results?

Do I have a choice of mediators? For example, "Sign-In with Apple" includes a bi-directional email blinding service which I might use to get a refund receipt from a cash purchase.

Do I have a choice of verifiers? For example, an essential gov service may choose to insist on a "Real ID" driver's license to let me into a Federal building for a tax payment but my local pharmacy lets me pick up controlled substances for a family member without security theater.

Do I have a choice of wallets? For example, I can get a US Passport (hard to carry), a US Passport Card (fits on the back of my iPhone), a digital credential that's presented in Apple Wallet, or simply hope that my fingerprints and iris scan will be acceptable when I try to cross the border because I'm in Global Entry.

Do I have a choice to avoid VCs all together? For example, I can pay with my Visa card credential, I can pay with my Apple Pay credential, or I can pay with digital or physical cash (including gold). Lack of verifiability can be a good thing in cases where human relationships and social norms are preferable - like dating.

Is the *scope* of the VC-HTTP group the right place to have this discussion? Maybe not. Please provide a concrete counter-proposal that W3C and our broader SSI community can consider.

-Adrian



On Wed, Jun 9, 2021 at 2:31 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> 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


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