RE: VC HTTP Authorization Conversation

As always Adrian, you are surfacing an insightful perspective. IMHO the conversation around ‘choice’ and ‘agency’ is still in the early stages and needs to be unknit more. At the one extreme we have the dominant authorities (be they governments or $2T corporations) dictating all the details and at the other end of the spectrum we have full sell-sovereignty that allows me to determine all aspects of receiving, storing and sharing information – which btw would include the ability / requirement to independently negotiate the terms of each and every data transaction I engage in. Maybe I even write my own wallet code. My point being neither extreme is very palatable, let alone practical. I don’t have a clear view of where all the lines of demarcation should go. Should I eschew a government issued driver’s license (or Apple ID) as identity and instead claim that 3,000 verifiable attestations from my Facebook family is a more trustworthy representation of who I am? Maybe that will work with some verifiers, maybe not with others. This is probably not the right thread to have this discussion, but I look forward to testing the proverbial fences around what a user’s ‘control’ envelope should really looks like.

-S

 

From: Adrian Gropper <agropper@healthurl.com> 
Sent: Friday, June 11, 2021 7:39 AM
To: Mike Varley <mike.varley@securekey.com>
Cc: Juan Caballero <juan.caballero@spherity.com>; Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: VC HTTP Authorization Conversation

 

Before continuing this thread, please listen to this 3 1/2 minute news story from this morning:

 

https://www.npr.org/2021/06/11/1005419007/privacy-experts-ask-should-state-issued-ids-be-stored-on-our-iphones

 

The idea of sovereign issuers and verifiers that the subject may or may not be able to choose scares people. Today, it's only privacy experts that understand enough to be scared but we're putting our entire SSI project at risk by not getting ahead of this issue.

 

Will we allow the issuers of driver's licenses to decide what wallet they go into? "You must be a $2T corporation to be trusted with "our" VC."

 

Will verifiers like TSA then decide that they will only accept a VC from a "certified" wallet.  (Where certification depends on chain-of-custody or direct $2T corporate certification).

 

How is that self-sovereign identity? How would any of us respond to those concerns?

 

The _only_ solution I see that's consistent with SSI principles is to make it clear that a self-sovereign subject can decide whether to carry a wallet and what kind of wallet they carry. That's the way it is in the analog world.

 

We've worked so hard to make VCs "self-verifying". Do we really want to screw it up at the protocol level?

 

Adrian

 

 

 

On Fri, Jun 11, 2021 at 9:49 AM Mike Varley <mike.varley@securekey.com <mailto:mike.varley@securekey.com> > wrote:

Hi Adrian,

 

> So people are suggesting that we should do OAuth2 first and then maybe do UMA or GNAP later. The group is unclear whether "later" is in another group and what customers will even care to implement attenuated delegation in the SSI protocols context. W3C might be just as happy for IETF to worry about that.

 

The problem for the VC-HTTP-API may be ‘smaller’ then what you are describing. Currently there is a gap in how service providers (issuers/holder/verifiers) consistently, in a standardized way, can generate (or “mint”), verify, or obtain/receive these credentials. The VC-HTTP-API is a (hope to be) standard API that services can integrate with to consistently achieve those functions. 

 

In other words, system builders have a problem considering the bigger questions you are asking, Adrian, because we haven’t settled on an API for reliably working with credential containers or moving credentials around; let alone worrying about how we got the credential or engaged with a person/holder to begin with. 

 

Let’s assume we solved for the perfect SSI privacy preserving, delegation authorization and trust model:

* As an issuer, what API do I call to generate a credential for this authorized session?
* As an issuer (with a credential to deliver to a holder), is there an API I can call, or an API the holder can call to transfer the credential?
* As a holder/presenter of credentials, what API do I need to support to collect a credential or present a credential presentation?
* As a verifier, with the holder’s permission, what API to I support to reveive a presentation?
* As a verifier, now that I have a credential presentation, how to I verify it for authenticity (i.e. properly signed by the involved parties/entities)
* ++ (see use cases document)  

 

VC-HTTP-API may be a “bottom up” approach, where you (and other interested in the authZ conversation) are approaching more “top down”. I believe others in the group (and I will add my name to the list) want to fully support the discussion you are driving towards with authorization and delegation, but in a sequence of operations, by the time the auth/bootstrapping/delegation/permission/policy decisioning is completed (by issuer or holder or verifier) the VC-HTTP-API just has some “work to be done”.

 

For SSI to work the way we all want it to, your questions need to be answered.

For SSI to work at all (generally), we need a standard way for components to communicate (and VC-HTTP-API is one of these methods).

 

Does that help?

 

MV

 

 

 

 

From: Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com> >
Date: Thursday, June 10, 2021 at 10:54 PM
To: Juan Caballero <juan.caballero@spherity.com <mailto:juan.caballero@spherity.com> >
Cc: Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> >, W3C Credentials Community Group <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: Re: VC HTTP Authorization Conversation

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

I'm obviously missing something, and instead of explaining it to me, people are just shouting louder and louder at why I need to get out of the way of progress.  

 

Here's what I think I understand:

*         The VC-HTTP endpoint needs to be protected by some kind of bearer token from a client or a cookie from a browser.

*         This token is subject to some "bootstrapping" protocol that may or may not be in scope for this group.

*         Simply stopping with the token is "kicking the can down the road" inadequate for the group.

*         So the group wants to do something with OAuth2 that might or might not put the "bootstrap" in scope.

*         In (Alice-to-Bob) delegation use-cases where the client presenting the token has not pre-registered with the VC-HTTP server, OAuth2 may not be sufficient.

*         In these delegation use cases, the VC-HTTP endpoint would need to be protected by UMA or GNAP. 

*         But nobody here is arguing for UMA and GNAP is seen as presenting a delay to progress.

*         So folks want Adrian to stop insisting that Bob can be delegated by Alice to access the VC-HTTP endpoint because all of their use cases are fine with Alice and Alice's client always being an intermediary holder for the VC.

I'm OK if the group wants to keep "bootstrap", and OAuth2 along with it, out of scope but that does not seem to be acceptable to some.

 

So people are suggesting that we should do OAuth2 first and then maybe do UMA or GNAP later. The group is unclear whether "later" is in another group and what customers will even care to implement attenuated delegation in the SSI protocols context. W3C might be just as happy for IETF to worry about that.

 

How'm I doing?

 

- Adrian

 

 

 

 

 

On Thu, Jun 10, 2021 at 5:37 PM Juan Caballero <juan.caballero@spherity.com <mailto:juan.caballero@spherity.com> > wrote:

Inline

On 6/10/2021 4:52 PM, Manu Sporny wrote:

On 6/10/21 10:04 AM, Orie Steele wrote:

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.

The above feels like a good start to a scoping statement.

+1 from the use-case team.  We are coming up fast on the deadline for "first drafts" of use cases that are far enough along to anchor PRs. If you have opinions about #3 and #4 (especially an opinion like, "I would hate to see mTLS discouraged as a valid option for #3/4"), a quick way to lobby for that opinion is to submit a first-draft use case.  Feel free to "fork," riff, or expand on other peoples' submissions that are halfway to what you want to see, but too brief, too specific in in describing a solution rather than a problem, etc.  

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

+1 to this, Adrian clearly wants to have this discussion, and polling of the
VC HTTP API group is showing that there is not a lot of support for doing that
in that group:
 
https://w3c-ccg.github.io/meetings/2021-06-01-vchttpapi/#57
 
A more focused group on how one gets authorization tokens to use with the VC
HTTP API using GNAP might result in 1) a more focused discussion on that
topic, and 2) a tighter scope for the VC HTTP API.

Agreed that a tighter scope for this group will get results faster from this group.

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 expect this to turn into painful discussion for everyone involved. While I'm
pretty sure Orie was joking about this option, -1 to the concept of comparing
half-baked things against each other when we're trying to make some concrete
decisions for the VC HTTP API.

Agreed that this group needs uncontroversial, concrete results, not design constraints imported from discusssions about standards or technologies still in flux. The people volunteering to make this API testable and get it taken seriously by today's vendors of production-grade software are not volunteering to build for the future, they are volunteering to build for their paying clients and customers.

I'd prefer we either recommend OAuth2.0 and leave the door open to other ways
to get an authorization token... 

+1 to this proposal.

Everyone is unanimous in leaving the door open.  Parties asking for multiple recommendations have not volunteered to do the extra work; we have volunteers committed to doing the OAuth2 work. 

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.

-1 to this proposal, we have kicked the "authorization can" down the road long
enough... 18+ months now... let's not keep doing it when there is a fairly
clear solution that all implementers seem to feel is a viable path forward as
ONE option for authorization.

-1 as well, ONE viable option is a stronger proposition than 0 viable options, 1.5, or even 1.9.

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?

Yes, agreed. Perhaps we start out with PR review first -- because that rewards
the thing we want to see, which is work being done.
 
Then issue review, because it rewards the second thing we want to see -- which
is asynchronous work.

+1 discussing possible futures for this spec is taking up way too much time.  Given the timeline for use-cases (and my own commitment to be at all meetings until they are stabilized), I'd propose that Tuesday's agenda be:
1.) PRs
2.) Issues
3.) Use-cases 

However, the Authorization discussion HAS been processing issues. Namely:
 
https://github.com/w3c-ccg/vc-http-api/issues/108
https://github.com/w3c-ccg/vc-http-api/issues/181
https://github.com/w3c-ccg/vc-http-api/issues/187
 
I try very hard not to do open discussion that's not driving toward some sort
of PROPOSAL or POLL at the end. What I've been trying to do is to make sure
that we get to at least one concrete proposal on each call. Sometimes you
can't get there w/o discussion, which is the case with authorization... but to
be clear, we have been processing registered issues, even though we haven't
been calling them out by issue number.

Thanks for that.  Manu, you've been doing great work moving us through the issues as efficiently as possible given the lack of consensus on scope. 

-- manu
 

----------------- 
Juan Caballero 
Research Lead, 
Spherity <https://www.spherity.com>  GmbH, Emil-Figge-Straße 80, 44227 Dortmund 
Co-chair, DIF Healthcare Use-cases Discussion Group <https://www.eventbrite.com/o/dif-healthcare-special-interest-group-31363301995>  and DIF Interoperability Working Group <https://github.com/decentralized-identity/interoperability/blob/master/agenda.md>  

Berlin-based: +49 1573 5994525 Signal/whatsapp: +1 415-3101351

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.