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

You got it.

Michael Prorock
CTO, Founder
mesur.io

On Mon, Jul 19, 2021, 21:07 <steve.e.magennis@gmail.com> wrote:

> 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
>
>
>
> On Mon, Jul 19, 2021, 20:18 <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>
> *Sent:* Monday, July 19, 2021 3:42 PM
> *To:* Manu Sporny <msporny@digitalbazaar.com>; Adrian Gropper <
> agropper@healthurl.com>
> *Cc:* W3C Credentials CG <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>
> *Sent:* Monday, July 19, 2021 8:45:54 AM
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* W3C Credentials CG <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> 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>
> wrote:
>
> inline...
>
>
>
> On Fri, Jul 16, 2021 at 8:47 AM Manu Sporny <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/
>
>