RE: VC HTTP API Telecon Minutes for 2021-07-13

Ah, so Party B inspects Farm A and certifies that Farm A passed GAP inspection criteria. Presumably Party B somehow memorializes the results of their inspection. Food importer now attests that Farm A has passed inspection – presumably by reviewing the memorialization issued by Party B.

 

 

From: Mike Prorock <mprorock@mesur.io> 
Sent: Monday, July 19, 2021 5:49 PM
To: steve.e.magennis@gmail.com
Cc: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; Manu Sporny <msporny@digitalbazaar.com>; Adrian Gropper <agropper@healthurl.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: Re: VC HTTP API Telecon Minutes for 2021-07-13

 

Not exactly that scenario, but similar:

Food importer attests that Farm A has passed a GAP inspection by Party B

 

Pretty common scenario in ag imports.

Michael Prorock
CTO, Founder
mesur.io <http://mesur.io> 

 

On Mon, Jul 19, 2021, 20:18 <steve.e.magennis@gmail.com <mailto:steve.e.magennis@gmail.com> > wrote:

@Michael, can you provide an example of where a claim abut a subject would be separate from the entity attesting to said claim to help me understand your distinction?

 

Would it be something like: Alice attests to the fact that Bob said something about Carol? This doesn’t seem right to me.

 

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net <mailto:mwherman@parallelspace.net> > 
Sent: Monday, July 19, 2021 3:42 PM
To: Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> >; Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com> >
Cc: W3C Credentials CG <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: Re: VC HTTP API Telecon Minutes for 2021-07-13

 

RE VCs are statements aka attestations by a cryptographic authority about a subject. 

...is more correctly worded IMO as...

"VCs are statements (lists of claims) about a subject - attested to by a cryptographic authority."

The original wording IMO suggested the source of both the statements/claims as well as well as the attestation is a cryptographic authority. I don't see this as being a truism (as a generalization). ... it's a bit centralist.

Michael

Get Outlook for Android <https://aka.ms/AAb9ysg> 

 

  _____  

From: Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com> >
Sent: Monday, July 19, 2021 8:45:54 AM
To: Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> >
Cc: W3C Credentials CG <public-credentials@w3.org <mailto:public-credentials@w3.org> >
Subject: Re: VC HTTP API Telecon Minutes for 2021-07-13 

 

On Mon, Jul 19, 2021 at 10:07 AM George Lund <george.lund@digital.cabinet-office.gov.uk <mailto:george.lund@digital.cabinet-office.gov.uk> > wrote:

<snip>

 

PS I've not had time to follow this as closely as I'd like, so apologies if I'm not making sense, but where people are questioning the need for this kind of protocol, I'd like to float a potential use case, which is that where OIDC mandates "UserInfo" as a restful endpoint for a bunch of user data, something along the lines of an "issuer" VC API might well be much more suitable and scalable. These specifications don't have to concern themselves with how a client may be authenticated or authorized, in order to be exceedingly potentially useful :-)

 

PPS I just saw Kerri's email, and I like that way of thinking too!

 

+1 this PS by George. The Issuer is just an authoritative UserInfo endpoint for a Subject. GNAP recognizes this https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#section-2.4 

 

VC-HTTP API could be scoped as _just_ a resource server. If the spec is scoped away from the authorization server, then the complexity and the implementation gap between OAuth 2 and GNAP is miniscule https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-01.html 

 

Regardless of what we name this spec, why must we tackle authorization servers in this particular CCG group?

 

- Adrian

 

On Fri, Jul 16, 2021 at 11:02 AM Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com> > wrote:

inline...

 

On Fri, Jul 16, 2021 at 8:47 AM Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> > wrote:

On 7/16/21 8:23 AM, Adrian Gropper wrote:
> I’m saying the Subject of the VC has the power to delegate interactions to 
> an agent they choose.

Adrian, you continue to conflate "access to an issued Verifiable Credential"
with the VC HTTP API does today.

 

And Manu, you continue to imply that the DHS use case is the predominant one for something as central as the API for VC issue. Please consider the cruise ship use case as well. 


Are you aware that, at present, there is no "access to an issued Verifiable
Credential" VC HTTP API call?

This is why I keep asking you to point to the endpoints that need
delegation... you're presuming endpoints that don't exist right now and are
hand waving over the (very important) details in order to make a meta point.

One variation of an "access to an issued Verifiable Credential" HTTP API call
is supported by Encrypted Data Vaults, which do support delegation via ZCAPs
and do support some variation of your cruise ship scenario. This has been
stated multiple times in multiple ways, but I think you keep missing it.

 

The EDV API, by definition, does not apply to the Issuer because the Issuer has sovereign power and the EDV does not. The Issuer has the information in the VC in the clear whereas the EDV does not. 

 

What the EDV and the Issuer do share is an identity-based relationship with someone that is typically the Subject of the VC. Because of that, I hope that the authorization protocol will be the same for Issuer, EDV, and Hubs. From a (human) agency perspective, these are all just resource servers as (GDPR) processors.  


There may be other "access to an issued Verifiable Credential" HTTP APIs in
the future... but your argument is cart before the horse... you're talking
about a non-existent VC HTTP API endpoint that sits on a Verifiable Credential
Repository (e.g., wallet).

 

No. I'm talking about VC-HTTP API as it secures the sovereign Issuer. The wallet is chosen by the Subject (to the extent the sovereign issuers and verifiers "allow") and the wallet API would benefit from sharing the authorization protocol, but this is not my primary concern. 


This isn't an argument against delegation... most of us understand the dangers
of not supporting delegation... I'm merely trying to point out that by waving
over the details, like you continue to do, you're misunderstanding what the VC
HTTP API does and does not do and continue to talk past the folks in the group
that DO understand the details of the VC HTTP API.

 

I apologize for my ignorance. I'm doing my best, including struggling to implement a FastAPI example of protected access to a VC that would demonstrate any gaps between OAuth 2 and GNAP and clarify if there's really that much difference when both are done simultaneously from the start. 

 

Note that our HIE of One project has 5+ years experience implementing an authorization server (we call it Trustee) that did OAuth 2 and UMA 2 _simultaneously_. We used this to demonstrate how an agent of the patient (the Trustee) could access the _production_ API of the largest health records vendor (Epic) and the production API of the US Medicare database, using legacy OAuth 2. At the same time, this demonstration showed how the agent interacts with self-sovereign resource servers such as a personal health record or a community-controlled registry of patients, using UMA 2. In some respects, our HIE of One group, including our collaboration with uPort from the earliest days of SSI, has more experience with VCs than the DHS use cases because ours actually _do connect_ to production private and government APIs.

 

I've also had interest from two, possibly three other groups, in implementing GNAP. 


The VC HTTP API is not a credential repository / digital wallet HTTP API. It
may become one in the future, but at this time, the group hasn't agreed to
that expansion in scope. If the group DOES agree to that expansion in scope,
it'll be far easier to make the case for delegation being a mandatory feature.

 

This, I agree with.  As mentioned above, my concern is the asymmetry of power between the sovereign and the subject. This is the fundamental premise of the Law of Agency https://en.wikipedia.org/wiki/Law_of_agency. 

 

The VC-HTTP API for Issuers is fundamental to SSI and we can either down-scope to enable agency at a higher layer or deal with it by implementing OAuth 2 and GNAP simultaneously in the specification.

 

- Adrian


-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/