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