The logic and relationships among VC-related protocols is inscrutable

[agropper]

Is there an organizing principle to the protocols being developed in W3C and DIF? There are numerous threads open on subject vs. holder, presentation exchange, authentication, and requests of all sorts. Can we step back and look for a common understanding?

Do we have a shared understanding of the following principles (all relate to the identity of the VC subject):

P1 - VCs do not depend on DIDs. Some valid VCs could use plain asymmetric keys for proof-of-control, others might reference state-assigned identifiers, and others might use biometrics.

P2 - Selective Disclosure is an important feature when a VC has multiple credentials but it is not essential. For example, a grade report credential might be damaged by selective disclosure.

P3 - Zero-Knowledge Proofs are a “nice-to-have” feature whose impact on protocol design needs to be explicitly stated.

P4 - Combining VCs issued to pairwise-pseudonymous subject identifiers is an important feature but it has had almost zero real-world experience to guide its implementation.

P5 - The Holder role combines two separate concerns: storage and control that could be separated at the protocol level.

Privacy engineering protocols based on VCs and DIDs involves a series of compromises and potential unintended consequences. For example, VCs that do not include a biometric component themselves (the way a driver’s license does) may promote the use of linked biometric credentials such as a driver’s license or they could lead to wallet certification that could result in another round of unintended centralization.

Each of P1 - 5 offers options for handling subject identity in VCs. Could we derive a rational and normalized set of protocols from these five principles alone?

[OR13]

P2 - Selective Disclosure is an important feature when a VC has multiple credentials but it is not essential. For example, a grade report credential might be damaged by selective disclosure.

I think you mean "claims"... or you mean a VP of multiple credentials.

P3 - Zero-Knowledge Proofs are a “nice-to-have” feature whose impact on protocol design needs to be explicitly stated.

I don't know what you mean. I don't think you necessarily need protocol changes to work with ZKPs.

You do tend to need protocol changes to support any kind of interactive proof, if that is what you mean.

P4 - Combining VCs issued to pairwise-pseudonymous subject identifiers is an important feature but it has had almost zero real-world experience to guide its implementation.

I am not sure what you are trying to say. Some VCs need long lived public identifiers for issuers and subjects, others don't.

P5 - The Holder role combines two separate concerns: storage and control that could be separated at the protocol level.

https://w3c.github.io/vc-data-model/#dfn-holders

A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them.

separating storage and control would place trust in the protocol, for example, you might have a passport, but if an attacker can block your ability to prove control, you can't use it.... in order to have agency, the holder needs to be able to both read its own credentials, and sign presentations, a holder could trust a protocol to assist with both... or just one... you are right that they can be separated, and there are good reasons why you might want to "sign presentations locally" but store credentials remotely...

[agropper]

@OR13 - Thanks for your review. My goal is to arrive at a consensus set of VC principles related to privacy and protocol. To the extent that the encoding of claims, issuer stuff, and signature stuff do not have a significant privacy profile, my focus is on the subject / holder and associated protocol implications to privacy.

P2 - Yes, claims is more precise. So: P2 - Selective Disclosure is an important feature when a VC has multiple claims but it is not essential. For example, a grade report credential might be damaged by selective disclosure.

P3 - A ZKP can be provided to the Verifier by either the Issuer or the Holder since both have the necessary predicates. As relates to ZKP, the protocol(s) might or might not be different depending on whether the Subject's preference is to have the Verifier contact the Issuer or the Subject.

I can imagine protocols where interactive or non-interactive ZKPs are presented by an Issuer or a Holder and the Verifier does not care. I can also imagine ZKP protocols that do not leak Verifier info to the Issuer for the same reason that we can have revocation protocols that do not leak Verifier info to the Issuer.

P4 - Identifiers for Issuers are not a first-order privacy issue. Identifiers for subjects should be same-domain pseudonymous by default to avoid correlation by the issuers. Protocol issues could arise when the subject wants to prove that two separate same-domain pseudonyms refer to the same subject.

With respect to P4, it's difficult to understand the use-case where biometrics and other correlatable subject identifiers can be avoided. Let's say a subject's wallet is able to spawn linked same-domain IDs. The subject could then prove that two VCs were issued to the same link secret and that link secret was also under the subject's control at VC presentation time. However, if the two separate Issuers did not check some separate subject credential like a driver's license and embed that ID or a hash of that ID in the VC, how would the Verifier know that the Subject was not presenting VCs that were issued to a completely different person?

P5 - We agree. The Holder role can be combined with the Issuer if the Subject trusts the Issuer to honor authorization tokens. Depending on context, there are privacy benefits to both alternatives. For example, when the Issuer honors a Subject's authorization the subject can delegate authorization to an agent (self-sovereign, fiduciary or broker). That agent can provide privacy benefits to the Subject based on training and expertise and can also provide privacy benefits to the Verifier if the verifier is uneasy about sharing their credentials with the Subject.

So, can we all agree that P1-5 are the essential foundation for discussing VC-related protocols? Is there a P6?

[kdenhartog]

P3 - A ZKP can be provided to the Verifier by either the Issuer or the Holder since both have the necessary predicates. As relates to ZKP, the protocol(s) might or might not be different depending on whether the Subject's preference is to have the Verifier contact the Issuer or the Subject.

I can imagine protocols where interactive or non-interactive ZKPs are presented by an Issuer or a Holder and the Verifier does not care. I can also imagine ZKP protocols that do not leak Verifier info to the Issuer for the same reason that we can have revocation protocols that do not leak Verifier info to the Issuer.

With BBS+ as currently implemented this is true. However, there's cases with ZKPs which would make for some odd situations which wouldn't make this assumption hold anymore. For example, if someone used a link secret the issuer directly sending to the verifier also wouldn't be possible (unless the issuer is randomly generating a link secret). It would break the cryptographic guarantees by allowing the issuer to know the link secret.

Then again, if the verifier could directly contact the issuer, I'd ask what the purpose in ZKP based selective disclosure would be useful for. Why not just have the credential be issued as a fit for purpose credential? Put another way, the issuer should just generate a VC with only the claims requested and nothing more. The reason we went the crypto route for selective disclosure is because it was the simplest way for the holder to dynamically create selectively disclosed credentials in the most privacy preserving manor. However, if the holder isn't involved - it's likely no longer the simplest solution.

However, if the two separate Issuers did not check some separate subject credential like a driver's license and embed that ID or a hash of that ID in the VC, how would the Verifier know that the Subject was not presenting VCs that were issued to a completely different person?

It's probably worth distinguishing a few things here. A link secret is a method of holder binding since it's a mathematical number that's stored on device. We shouldn't conflate this with subject binding which is often the case. In many cases people recognize that this holder binding is "good enough" to qualify as subject binding as well because there's an assumption that the "what you have" device is not being shared. However, since the link secret is not inherently bound to a single device (And likely couldn't be because the subject is likely to use multiple devices) the guarantees of the holder binding are going to present practical usability constraints which are likely to make the presumption that allow it to be "good enough" as a subject binding fall apart. I'd suggest we start distinguishing these as two separate actions. For example, the most common function of subject binding today is visual confirmation of the image matching the person in front of them.

[agropper]

@kdenhartog I agree that having the Issuer respond to a capability presented by the Verifier is sometimes the "the simplest solution". Also, because the Subject always has the choice of introducing themselves as "Holder" when they receive a capability from the Issuer (instead of the VC itself), it is also the most general.

As mentioned in w3c/vc-data-model#789 (comment), our community now has the benefit of some understanding of BBS+, KERI, link secrets in the wild, the perspective of sovereign Issuers like mDL, EU and UK, and the nature of objections by EFF and various governments around mandated digital health passports.

Isn't it time for us to revisit our obsession with "Holder" as essential to SSI protocols?

Why can't we envision SSI from the perspective of delegation as a self-sovereign right co-equal with the right to use credentials without "calling home"?

[swcurran]

@agropper - Could you please explain your view about holders as they related to SSI protocols?

[OR13]

@nembal I would like to be able to move issues like this to github discussions...

[agropper]

• SSI protocols will support SSI data models for VC and DID. VCs could refer to a Subject via a DID or some other identifier.
• A person can choose a DID method and DID or some other digital identifier and approach an Issuer as their Subject.
• The Issuer can choose to honor the Subject's digital identifier or not.
• If the Issuer agrees, they can grant their Subject an access right to a VC with a requested scope of claims.
• The access right can be in the form of a capability.
• It is up to the Subject to decide to use the capability themselves or delegate it (with attenuation if possible) to a Verifier or to anyone else.

The sequence above is the essence of privacy engineering around SSI protocols. In the spirit of SSI, the Issuer must not have any excess or incidental rights other than their right to deny service. The basis for denying service could be inadequate identity proofing (they don't like the DID method or think an SMS number as identifier is inadequate for the service).

The basis for the Issuer denying service on the basis of "Holder" or Verifier credentials or characteristics needs to be seen in terms of privacy engineering. In general, the options for how to handle VCs should not be up to the Issuer. If the Subject doesn't trust the Issuer to talk directly with the Verifier then the Subject can use their capability to inject a Holder (themselves or another delegate) into the Verification process.

[nembal]

@OR13 I am looking at it today! 👌

[swcurran]

@agropper -- thanks. That's quite a different sequence from what I understand -- at least after bullet 3.

In the 4th bullet, why does the issuer "grant their Subject an access right" vs. "issues them a VC" (e.g. sends them a document that is a VC)?

[agropper]

@swcurran The reason for the 4th bullet is explained in the final paragraph. Namely, the right to exercise a capability or to delegate the capability should be the patient's. The right to delegate should belong to the patient, not the Issuer.

This is not just a corner case. Over a decade of experience with healthcare interoperability mandates, regulations, regulatory capture, and the APIs that have been promoted by the "Issuers" are a major example.

OAuth2 itself is another major example. Authentication (by the Subject) is obviously required. Dynamic Client Registration, however, is treated as optional at the discretion of the Issuer and, as we all now, it is almost never offered. UMA 2, on top of OAuth2, hoped to fix this but Issuer adoption has been almost non-existent.

SSI aims to be different and privacy engineering the protocols should give as much control and opportunity for decentralization as we did for the VC and DID data models.

[TallTed]

The reason for the 4th bullet is explained in the final paragraph.

This statement suggests a break in the logical flow of your bullets, even as it reveals that (at least some of) the bullets are insufficiently thought out. Since it is clearly needed for full understanding of the bullets, the explanation in the final paragraph (and perhaps more of that external text) should be blended into the bullet list, as new bullet points and/or as expansion of one or more of the existing bullet points.

Authentication (by the Subject) is obviously required.

You consistently make this error.

Anyone (any Issuer) may say (Issue, Assert) anything (Claims) about anything/anyone (Subject), and they may Issue that VC to any Holder.

There is no overarching technical restriction that the Subject must be the Holder of the VC's of which they are Subject at any time, nor that that Subject even be made aware of the VC's existence, not least because I don't believe there is a technical way to impose such. Laws may impose such restrictions and/or requirements, but those are well and truly out of scope for any technical group (W3C, IETF, etc.).

(There are also the inanimate Subjects, about which others have and will write a fair bit.)

[David-Chadwick]

Subjects can be inanimate entities with no possibility of holding keys or authorising anyone to do anything. One example is a company registration VC issued by a national company registration authority. The company and VC subject is a legal entity, but humans (in the form or named directors and secretaries) act on behalf of the subject. So the subjectId cannot really identify the subject (the company) since if it contains a DID or cryptographic key, it will actually point to the key holder who acts on behalf of the company (and this could be several different people). The company registration authority will know who is authorised to act on behalf of the company and will provide this person (or people) with credentials for logging into its web site and accessing the company records, updating them, and (in future) requesting a VC to be issued to him/her/them. In this case the subjectID is actually the holderID

[TallTed]

One example is a company registration VC issued by a national company registration authority. The company and VC subject is a legal entity, but humans (in the form or named directors and secretaries) act on behalf of the subject. So the subjectId cannot really identify the subject (the company) since if it contains a DID or cryptographic key, it will actually point to the key holder who acts on behalf of the company (and this could be several different people).

The subjectId absolutely can and should (and I really want to say MUST) "really identify the subject (the company)"! Handling authentication of the employees, directors, etc., and their authorization to speak/sign/act for the company, just flow into some of the most obvious use cases for delegation, among other things.

[swcurran]

The reason for the 4th bullet is explained in the final paragraph. Namely, the right to exercise a capability or to delegate the capability should be the patient's. The right to delegate should belong to the patient, not the Issuer.

OK -- I don't see you and I are likely to get agreement here. I know you have a ton more experience than I in trying to get higher level protocols (like UMA) in place, but I don't see the VC spec itself as the place to do that.

I think that a VC is a lower level concept to something that might require or use capabilities or delegation. I think a verifiable credential should be data (any data) issued by an Issuer to a specific holder, and presented (independent of the issuer) to a verifier that gives the verifier cryptographic confidence that it was issued by the issuer and presented by the (intended) holder. This aligns exactly with a paper credential.

The meaning of the data and how it used are concepts above the VC -- at the governance layer. Hence, for me, even adding "subject" into the VC spec forces a meaning onto the data that is not appropriate. Concepts like using a VC as a capability or adding to it a way to delegate it is at a higher level and should not be part of the VC specification.

[TallTed]

I agree with most of what you said, @swcurran, but this --

issued by an Issuer to a specific holder

-- does not align "exactly with [all] paper credential[s]". It does align with some, perhaps even many, but I don't think it reaches most. A great many paper credentials are not issued "to a specific holder".

Also --

even adding "subject" into the VC spec forces a meaning onto the data that is not appropriate

VCs are defined to contain a structure of subject,predicate,object or entity,attribute,value statements or triples. All of these impose some meaning on the data therein, and changing this would be a substantial change of the specification -- not to mention making VCs substantially different from the paper credentials with which you have just expressed alignment as being important.

[swcurran]

@David-Chadwick -- I'm interested that you say a registered company can't have keys.

I know of several efforts to build what amounts to a "Corporate Wallet" for businesses. Such an agent presents a verifiable credential interface (API) to the world and on the internal backend provides what amounts to a workflow engine to control the agent to initiate or respond to requests. The workflow engine might automatically handle some requests (e.g. requests for proof of registration), and would pass other requests to individuals to choose a response (e.g. request for a proof of greenhouse gas emissions). I expect that in the future, this will be a parallel component to the corporate Web Server, providing the public, suppliers and customers with access to verifiable data from the entity, and requesting the same from others.

I'm sure you have thought of all of those use cases, so I'm curious about your view that the corporate agent could not use keys to take the action at the behest of its human controllers.

For fun, check out the open source work going on with the "Business Partner Agent" from Bosch and others -- https://github.com/hyperledger-labs/business-partner-agent

[agropper]

@swcurran - If not in VC-HTTP API, where does the human right to delegate belong?

I think that a VC is a lower level concept to something that might require or use capabilities or delegation. I think a verifiable credential should be data (any data) issued by an Issuer to a specific holder, and presented (independent of the issuer) to a verifier that gives the verifier cryptographic confidence that it was issued by the issuer and presented by the (intended) holder. This aligns exactly with a paper credential.

A paper credential that has a biometric, like a driver's license, does not consider or make a distinction for a holder. Digital credentials that identify the subject by a biometric would not have to consider holder either. See https://github.com/HIEofOne/Trustee-Community/blob/master/Biometric-Health-Card.pdf for an example. My argument is that mandating a holder for VC-HTTP API is a first-order privacy engineering violation because valid VCs could include a biometric or a link to a biometric as the subject ID.

Another aspect of the @swcurran argument has to do with where the human right to delegate belongs. Some try to portray the VC-HTTP API as mostly internal to a trust domain. But the introduction of a holder as client to the VC issuer API, by definition, crosses trust domains. The human rights problem arises because there's no obvious way to restrict issue to an internal trust domain without introducing a coercive "client credentials" model for the holder.

The confusion introduced by considering holder as part of the VC API design is currently being evidenced in w3c/vc-data-model#794 and w3c/vc-data-model#795 as well as numerous discussions related to Presentation. As far as I can tell, Holder is not a normative element of the VC spec. Enabling a Verifier to issue a challenge that can only be signed by the Subject of a VC is separable from selective disclosure based on capabilities w3c/vc-data-model#788 (comment) and needs to be considered as part of our authentication protocols discussions https://identity.foundation/working-groups/authentication.html

The value of VCs depends on being trusted by Verifiers. That trust has multiple dimensions and sometimes benefits from introducing a Holder or a Presentation challenge. But not always. Privacy engineering the VC-related protocols requires us to consider unintended consequences of forcing Holder client credentials or other presumptions about the holder. Here's one current example https://www.eff.org/deeplinks/2021/08/apples-plan-think-different-about-encryption-opens-backdoor-your-private-life Can we avoid putting SSI on that slippery slope?

[swcurran]

@agropper -- What you are addressing are real concerns, but I remain firm in my statement that those concerns are rooted in the governance of the use of VCs not in the technical definition of VCs. Human rights do not come into play on what a VC is, they come into play in how VCs are used. How they are used is governance question between the participants that are using them and the control each has in their use.

Regards delegation: I don't think today's VCs (v1.0) have the necessary mechanism to inherently (in the technology) support general purpose delegation. A governance structure about how certain VCs types are used can enable delegation. I don't think it is impossible to add a general delegation mechanism to a future VC design, but it is not in the V 1.0 data model.

As far as I can tell, Holder is not a normative element of the VC spec.

This, to me, is a stunning claim. The Holder is in Figure 1 of the VC Data Model and referenced in every VC and SSI presentation I have ever seen. If it is not normative, there is a problem in the spec and that is one of my goals with vc-data-model/#795. There is a significant difference in what is conveyed in a VC to a verifier between "The issuer said X" vs. "The issuer said X to the holder/prover." I think the intention of those that conceived the VC model is the latter. Each party will still make a decision on how much they trust the technology and will mitigate their risk accordingly. But to say that the holder is not a part of the VC model is stunning. I'm pretty sure I'm not alone in that view.

That said, I think the VC Data Model V 1.0 creates a lot of confusion between the "holder" and the "subject", often implying those are the same in order to address primarily the identity use case. One of my other goals with vc-data-model/#795 is to try to reduce that confusion by talking about what is actually displayed in Figure 1, and the importance of the holder across all use cases.

A final thought on authorization. A VC that includes the holder, with the issuer binding the VC to the holder and the verifier checking that binding on presentation, provides a basic level of authorization -- only the holder is authorized to present (use) the VC. By building on top of that, using governance (e.g., the semantics of specific VCs), other authorization mechanisms can be defined for specific ecosystems.

[TallTed]

There is a significant difference in what is conveyed in a VC to a verifier between "The issuer said X" vs. "The issuer said X to the holder/prover." I think the intention of those that conceived the VC model is the latter.

Speaking as one of "those that conceived the VC model", I can tell you that my intention was the former. I believe this is also true for at least several, perhaps most, possibly all, others "that conceived the VC model". Certainly, most of us are still around, so I encourage you to ask us directly about such assumptions as above, rather than spread or act on them.

Please also note, as elaborated on here, that there is no mechanism in the existing VC Data Model by which to "bind" a VC to either a Holder or a Subject.

[swcurran]

The question was asked directly here. Unfortunately, the conversation is spread across a number of repos as the same topic is raised in different contexts.

Thanks for the insight about what the VCWG was trying to accomplish. I think that will surprise a lot of people. It makes me realize that W3C VC data model is trying to be used in many places it does not belong. Something different is needed.

I'll look at your (and others) comments on my PR to the VC Data Model, but it is obviously misguided.

[TallTed]

It makes me realize that W3C VC data model is trying to be used in many places it does not belong.

I do not think the VCDM is trying to do anything, as it is an inanimate document with zero motive force of any kind.

Certainly, people are trying to use the VCDM in ways that were not intended -- and even in ways that we expressed it should not be -- which is just like many RECs from W3 and like RFCs from IETF. I'm sure that many reading this would be happy to help clarify understanding, and to take such clarification needs back to the VCWG for potential incorporation in VCDM 1.0 errata, VCDM 1.1 revision, etc.

[kdenhartog]

Regards delegation: I don't think today's VCs (v1.0) have the necessary mechanism to inherently (in the technology) support general purpose delegation. A governance structure about how certain VCs types are used can enable delegation. I don't think it is impossible to add a general delegation mechanism to a future VC design, but it is not in the V 1.0 data model.

Minor correction for the record. There is a general purpose delegation described in the V1.0 model today. It's a bit light on the details, but does allude to methods to delegate credentials. See Appendix C for details. However, just because the delegation model exists doesn't mean it's always the best way to achieve the end goal as I described in my blog post I recently wrote on the topic.

With regards to everything else you said, I'm generally in alignment with how you're thinking about it.

[swcurran]

@kdenhartog -- I would tend to disagree that Appendix C is helpful in this area. It tries to delve into what the contents of specific VCs (and hence, outside the spec) and how they should be used (again, out of scope). Worse, it does so in such limited ways that I think it is more confusing then helpful. It is marked as non-normative, so that's good.

[kdenhartog]

I agree that it's unhelpful, but it is still described in the spec, hence the correction. I don't think the pedantic nuance I introduced matter all that much to the larger discussion at hand though from @agropper so I'll leave it at that.

[nembal]

As a test repo, I enabled discussions here to learn how it gets used.

It enables issues to stay topics affecting the spec.
Yet, the discussion page can capture important ideas (such as this). It will be a tool to answer questions (currently often done in slack) on implementing a spec.

Thanks for suggesting @OR13 the use of this feature. Let's see how we can make the best use of it.

Best,

[TallTed]

Github does make it possible to move issues to discussions (and vice versa), but this utility should generally not be used on issues with already long threads -- because even the minimal threading provided by discussions does not get applied to existing comments, and the mix of semi-threaded and un-threaded is even harder to follow than either of those on their own. It's mind boggling that they left out the option to view discussions by pure time-order, as is possible in the better threaded discussion tools I've used (best webby example is LiveJournal; best example overall is the unjustly maligned NetNews a/k/a NNTP, with messages conforming to RFC 822 et seq).

[agropper]

@swcurran - thank you for the thoughtful separation of the two core privacy issues: governance and holder assumptions.

Governance can’t fix the impact of inadequate standards. It’s called “regulatory capture”. Standards are, by their technical nature, led by implementers. The implementers, with very rare exceptions like public blockchains, are business interests and platform strategy interests. Civil society participation in standards is limited to invited experts like me who are not funded nor deemed eligible for the DHS grants that funded much of SSI (we tried).

Business interests use the standards process strategically because they know that regulators and other governance approaches will not mandate technology. They can only react to technology. Regulatory capture works by limiting the scope of effective governance. OAuth 2 / OpenID Connect are prime examples in our identity domain of regulatory capture that results in platform dominance instead of decentralization of the Internet. For example, OIDC was not suitable for public-sector privacy engineering. I worked for the US Postal Service at the time of the Connect project which had to be abandoned.

SSI is an opportunity as a foundation for the privacy engineering tools needed by public sector and consumer equity interests. Success is not guaranteed. We need to analyze, understand, and acknowledge what went wrong with OAuth 2 / OIDC and act accordingly. If W3C / DIF doesn’t do it, IETF hopefully will.

It might make sense to talk about Holder as a normative component of the VC data model standard after we try to establish a common vocabulary for the governance discussion.

[OR13]

https://w3c.github.io/vc-data-model/#jwt-encoding
https://w3c.github.io/vc-data-model/#zero-knowledge-proofs
https://w3c.github.io/vc-data-model/#presentations-0

Holder is a normative part of the VC Data Model.

If present, the value of the holder property is expected to be a URI for the entity that is generating the presentation.

see also:

https://w3c.github.io/vc-data-model/#conformance

The VC Data Model is a data model specification... some the the data model's it defines show up in protocols, link OIDC, or DIDComm or GNAP.

Those protocols are where governance must be applied since those protocol implementations have the ability to harm real world users... for example:

1. A VC about having a diseases does not harm a user in the abstract.
2. An authorization server that discloses this VC in a VP without consulting the subject does harm to the subject.

Governance applies to software operators, and for good reason, they are the ones who can defend or harm users.

Here is a private key:

{
    "id": "did:key:z6Mkm7tbinuFXqZ25WYB7x7vefXtBjcPfZEMtTfTAHNAtrG1#z6Mkm7tbinuFXqZ25WYB7x7vefXtBjcPfZEMtTfTAHNAtrG1",
    "type": "JsonWebKey2020",
    "controller": "did:key:z6Mkm7tbinuFXqZ25WYB7x7vefXtBjcPfZEMtTfTAHNAtrG1",
    "publicKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "YwuGJTjp_bVob4i_k3-z-_ZcX9ubcsNvwQHZZT77sXI"
    },
    "privateKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "YwuGJTjp_bVob4i_k3-z-_ZcX9ubcsNvwQHZZT77sXI",
      "d": "7wtMHkNlrwdryN3H3pgbZmDYJ5lNs8QBcQDBIQ0pycg"
    }
  }

I just generated so no harm is done... but even if I stole it from someone and posted it here so they could be impersonated... its not JSON's fault, its not the JWK or JWS spec's fault... its mine and GitHub's (if this were really a stolen private key, which I promise it is not)... in such a case, the governance of GitHub should allow for the removal of this post, since private keys can be used to forge authentication and credentials... just like authorization servers can.

[TallTed]

governance of GitHub should allow for the removal of this post

And it does, by either the original poster or a CODEOWNER or some other users with specific privileges on the repo.

[TallTed]

As of yet, no VC protocols exist.

The VC Data Model allows cryptographically-based verification by a Verifier that an Issuer made the Assertions contained in a VC about one or more Subjects identified therein. That's it. All done. Any further logic applied is external to the VC Data Model.

[David-Chadwick]

As of yet, no VC protocols exist.

The VC Data Model allows cryptographically-based verification by a Verifier that an Issuer made the Assertions contained in a VC about one or more Subjects identified therein. That's it. All done. Any further logic applied is external to the VC Data Model.

The issuer is not cryptographically linked to the verification of the credential other than by its URI in the issuer property. So at best this is an indirect linkage e.g. via a DID to a DID document containing a public key, or via a http URL that is the subject id contained in an X.509 PKC containing the public key. At worst it could be a URI that does not point to any cryptographic material, in which case the verifier is stumped as to how the VC can be verified.

[agropper]

I don’t understand why some comments on this Discussion show up in email but not in GitHub. Between Issues, PRs, and discussions across VC HTTP API, WACI, CCG, etc… it’s hard to process the comments in a logical way.

…

On Fri, Aug 20, 2021 at 5:40 PM Stephen Curran ***@***.***> wrote: The question was asked directly here <w3c/vc-data-model#789>. Unfortunately, the conversation is spread across a number of repos as the same topic is raised in different contexts. Thanks for the insight about what the VCWG was trying to accomplish. I think that will surprise a lot of people. It makes me realize that W3C VC data model is trying to be used in many places it does not belong. Something different is needed. I'll look at your (and others) comments on my PR to the VC Data Model, but it is obviously misguided. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/decentralized-identity/waci-presentation-exchange/discussions/96#discussioncomment-1214372>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YI5ZKKBVCV7HA4Y43TT53DS7ANCNFSM5CP6R3AQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[kdenhartog]

It is showing up for me. In the discussions, threads can exist per comment when you reply where as with issues they get shown as one giant conversation that remain in order by lineage. It's just a different UX. Scroll up about halfway through the page and you'll find it.

[agropper]

Authentication by the Subject is obviously required in order for an Issuer to create an authentic VC that Verifiers might trust. That authentication happens as part of the services being rendered by the Issuer regardless of what VCs are created for whom. Authentication for authenticity is, as you say, out of scope for VC protocols. My point is that authentication for authenticity can optionally be leveraged as part of VC protocols. For example a Subject can authenticate and request a capability that they hold until a request comes in for a VC. At that point, the capability can be attenuated and delegated to the requesting party, or the capability can be used to get a VC by the Subject themselves. That choice to delegate or proxy access to the VC rests with the self-sovereign subject.

…

On Tue, Aug 24, 2021 at 10:29 AM Ted Thibodeau Jr ***@***.***> wrote: The reason for the 4th bullet is explained in the final paragraph. This statement suggests a break in the logical flow of your bullets, even as it reveals that (at least some of) the bullets are insufficiently thought out. Since it is clearly needed for full understanding of the bullets, the explanation in the final paragraph (and perhaps more of that external text) should be blended into the bullet list, as new bullet points and/or as expansion of one or more of the existing bullet points. Authentication (by the Subject) is obviously required. You consistently make this error. Anyone (any Issuer) may say (Issue, Assert) anything (Claims) about anything/anyone (Subject), and they may Issue that VC to any Holder. There is no overarching technical restriction that the Subject must be the Holder of the VC's of which they are Subject at any time, nor that that Subject even be made aware of the VC's existence, not least because I don't believe there is a technical *way* to impose such. *Laws* may impose such restrictions and/or requirements, but those are well and truly out of scope for any technical group (W3C, IETF, etc.). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/decentralized-identity/waci-presentation-exchange/discussions/96#discussioncomment-1227772>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YK4ELV4X3TB3NOQZQTT6OUE5ANCNFSM5CP6R3AQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[TallTed]

Authentication by the Subject is obviously required

Again, no interaction between the Issuer and the Subject is required in any way, for a great many if not the vast majority of VCs.

[agropper]

*inline:*

On Tue, Aug 24, 2021 at 11:07 AM Ted Thibodeau Jr ***@***.***> wrote: Authentication by the Subject is obviously required Again, no interaction between the Issuer and the Subject is required in any way, for a great many if not the vast majority of VCs.

*I agree! But my point is that Authentication is always available and could be used as part of VC-related protocols. Authentication, for example, can be used by the Subject to request a capability from the Issuer rather than getting the VC itself. * *- Adrian*

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/decentralized-identity/waci-presentation-exchange/discussions/96#discussioncomment-1227997>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YPSOPU4FQW2YGRPBUTT6OYS3ANCNFSM5CP6R3AQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[TallTed]

@agropper -- Please take care to preserve attributions of multi-layer quotations. The casual reader could easily mistake your quote of my quote of your Authentication by the Subject is obviously required to be part of what I said.

my point is that Authentication is always available and could
be used as part of VC-related protocols. Authentication, for example, can
be used by the Subject to request a capability from the Issuer rather than
getting the VC itself

IF a sentient Holder is requesting a VC about themselves from an Issuer, then some of what you're saying might apply. However, what you seem to be suggesting is that "the Subject [should] request a capability from the Issuer rather than getting the VC", which takes them out of the realm of VC-related protocols!

[agropper]

Referenced in https://github.com/decentralized-identity/waci-presentation-exchange/discussions/96 but the discussion could just as well belong here?