Re: VC HTTP Authorization Conversation

On 6/9/21 6:36 PM, Adrian Gropper wrote:
> Is it wise for us to make a scope resolution without at least one or three 
> foundational use-cases?

For the VC HTTP API -- absolutely!

Narrowing the scope of the VC HTTP API specification so that the issuance
process of authorization tokens is out of scope is a very good thing, and as
Justin said, is an entirely separable thing.

That the VC HTTP API doesn't have to have meta-discussions around all the
questions you highlight below will help us focus and is a perfectly reasonable
thing to do WHEN there are other groups (like the DIDWG, VCWG, and CCG that
are considering the higher level questions you raise). It's not that they're
not important questions, and it's not that people aren't thinking about
them... it's that the VC HTTP API isn't the proper venue for these questions.

Things that are out of scope for the VC HTTP API can be in scope for a
separate CCG Work Item or WG. For example, the VC HTTP API is not the place to
debate details over the VC Data Model or Ecosystem (that's the VCWG), or how
decentralized identifiers are created/used (that's the DIDWG), or how the VCs
are protected (that's the forthcoming LDSWG).

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

This is out of scope for the VC HTTP API. It can be a discussion topic and/or
work item in the CCG.

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

This is out of scope for the VC HTTP API. It can be a discussion topic and/or
work item in the CCG and/or the VCWG. I will note that the entire VC Data
Model is set up around being able to have a choice in issuers, so it's a bit
strange that you're asking this question in the first place.

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

This is out of scope for the VC HTTP API.

When an interoperable specification for attenuated delegation exists, and
implementers are interested in folding it into their implementations (and have
demonstrated that they have done so), then it can become in scope.

Gating the VC HTTP API on technology that hasn't been integrated into any of
the 8+ implementations that we have today of the VC HTTP API will create an
unnecessary block on the work.

This question is a good one for the groups working on GNAP or ZCAPs.

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

This question is out of scope for the VC HTTP API.

It's a question for the folks working on CHAPI or WACIPex.

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

This question is out of scope for the VC HTTP API.

It can be a discussion topic and/or work item in the CCG and/or the VCWG. As
with the issuer question you have above, the entire VC Data Model is set up
around being able to have a choice in verifiers, so it's a bit strange that
you're asking this question in the first place.

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

This question is out of scope for the VC HTTP API, but is in scope for the
CHAPI and WACIPex work.

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

If you want to avoid VCs all together, you probably are not interested in the
"Verifiable Credential" HTTP API. :)

You may be more interested in raising that question in ISO/IEC JTC 1/SC 17.

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

I have provided my personal opinion to your scoping questions above; they're
all good questions, and all out of scope for the VC HTTP API work item.

> Please provide a concrete counter-proposal that W3C and our broader SSI
> community can consider.

For each question you raised above, I have counter-proposed where those
questions should be explored.

-- manu

-- 
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 Thursday, 10 June 2021 13:30:50 UTC