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> 
Sent: Wednesday, July 21, 2021 6:45 PM
To: steve.e.magennis@gmail.com; '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

 

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#sectio
n-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/