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