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

Inspired by a side conversation with Stephen about the subtleties of VC bindings, there appear to be 2 (potentially new) pieces of terminology at play here (my terminology/labels):

  *   Bound VCs
  *   Unbound VCs

In the did:colors:primarycolors sample, did:colors:primarycolors is a credential id and the VC itself has no subject (no credentialSubject id claim).  This sample is an example of an Unbound VC …it has a credential id but it has no credentialSubject id.  From a Subject/Holder perspective, it’s not bound.  It’s just “data signed by an Issuer”. It can’t be used for a Verifiable Presentation because it has no credentialSubject id.

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolors",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "colors": [
          red,
          green,
          blue
      ]
    },
    "proof": { ... }
  }
}

With Bound VCs, the credentialSubject has an id claim and the value of the credentialSubject id claim (the identifier) needs to match that of the Holder for the VC to be “valid” …i.e. for it to be usable for creating Verifiable Presentations, etc.  i.e. to attest that this VC comes from or belongs to the Holder = Subject. Something I’m told should be made more clear in the VC data model spec.
How would Bound VCs be used for the “Alice says ‘Bob said he likes Carol’” credential scenario? First, Alice is not an Issuer (most likely). Alice is a Subject of a VC that Alice holds (that Alice is the Holder of). This VC will be bound to Alice: the value of the credentialSubject id claim would match Alice’s identifier (e.g. Alice’s DID).  I’m not sure about this next part, but in theory, the “Alice says ‘Bob said he likes Carol’” credential could also be issued to each of Bob and Carol.  If this is the case, in each case, the credentialSubject id would be either Bob or Carol.

I’ll read this again tomorrow to see if it still makes sense. 😊

Michael

From: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com>
Sent: July 22, 2021 5:52 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; '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

Not sure I follow you. In #1 the claim regarding the subject ‘colors’ is attested to by the issuer, not some other entity, no? In #2 if Alice makes an attestation that ‘Bob said he likes Carol’ I guess the subject would be ‘Bob’ or ‘Carol’ or ‘Bob and Carol’ but it is still Alice (the issuer) making the claim even if the only way Alice knows that Bob likes Carol was because she (Alice) saw a credential issued by Ted who said so. In this scenario is seems more like Alice is attesting to having seen a credential issued by Ted, in which case why not just present Ted’s credential to a verifier, rather than a credential generated by Alice?

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: Wednesday, July 21, 2021 6:45 PM
To: steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>; '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

Here’s 2 answers:

1. A color palette attested to by a cryptographic authority …validly constructed according to: https://www.w3.org/TR/vc-data-model/#identifiers

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolors",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "colors": [
          red,
          green,
          blue
      ]
    },
    "proof": { ... }
  }
}


2. There’s nothing to requires any claims in any credential to be truthful.  The claim can, in fact, represent complete nonsense. The only solid requirement is that they are attested to by a cryptographic authority. Alice can, in fact, attest to anything she wants to in terms of what Bob said about Carol.


From: steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com> <steve.e.magennis@gmail.com<mailto:steve.e.magennis@gmail.com>>
Sent: July 19, 2021 6:18 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; '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

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