Re: VC HTTP Authorization Conversation

> Is the *scope* of the VC-HTTP group the right place to have this
discussion?

I think it is not.

I see the scope of the VC-HTTP-API as limited to the following:

1. HTTP endpoints for producing and consuming the W3C VC Data Model Objects
2. HTTP endpoints for producing and consuming extensions to the VC Data
Model, or data structures it relies on, like Revocation Status and
Credential Schemas
3. Recommendations for securing these HTTP endpoints using HTTP Headers.
4. Recommendations for exposing these HTTP endpoints inside and
across trust domains.

No part of my proposal above precludes GNAP from being used to get an
authorization token for these APIs, but I think it's a giant waste of time
(for this WG) talk about all the ways a JWT access token can be obtained,
when we only need to recommend 1 starting point, and acknowledge that HTTP
headers can and are used to transport tokens obtained in various other ways.

Perhaps it would be better to start a CCG work item dedicated to GNAP and
VCs?

Or a battle royal between OAuth2.0 the only "real" standard being discussed
and the drafts for GNAP, OIDF-SIOP, ZCaps with HTTP Signatures and DIDComm
hosted by the ccg?

I don't want to shut down all the excitement about how to replace OAuth 2.0
and fix its many flaws... I just don't want to talk about that every call
for this work item.

I suppose we could also solve this by forbidding the vc-http-api from
discussing authorization, and handle that in other work groups / work items
that want to secure http endpoints that exist today.

IMO, shiping the vc-http-api without a single recommended authorization
system, will mean it will never be sufficient by itself, and I see no
reason why we should recommend something other than OAuth 2.0, given the
maturity and contentiousness o all proposed alternatives.

I'd prefer we either recommend OAuth2.0 and leave the door open to other
ways to get an authorization token... or we label the vc-http-api agnostic
to authorization, and warn users that they will need to pair it with other
specs to address security issues associated with exposing http endpoints on
the internet.

I would also love to just do Issue and PR review, and have less open
discussion on calls, we seem to be discouraging asynchronous work, maybe we
can limit open discussion to 50% of the call time?

OS


On Wed, Jun 9, 2021 at 5:45 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>