Add extension mechanism to allow different methods for VP-to-VC / holder binding to next version of standard to allow verification of rightfulness of presentation #882

awoie · 2022-06-22T13:55:43Z

A very common use case in the VC ecosystem is the presentment of VCs as VPs. Usually, the verifier is interested in whether the holder is the legitimate subject of the presented VCs, so they can answer questions such as "does the VP at the time of presentment authenticate the subject of the VC and can we assume the issuer made the same VCs about the holder in the VP?". Note, such a decision is simple in case the credentialSubject.id is the same as the holder property and the proof of the VP authenticates the holder. I believe this is also what a lot of people implemented although there is no normative definition of such a binding. While this is a simple example, there are other examples that might be a bit more complex, e.g., in case there is no credentialSubject.id which is common for ZKP-based VCs, or a subject controls multiple identifiers and those relationships are represented as same-as-relationship-VCs etc. In that situation a verifier needs to guess since it does not know the intended mechanism for binding the proof in the VP to the holder and the subject of the VC which is an issue for interoperability. Having the verifier to have this knowledge pre-populated is also possible but it prevents interoperability as well.

The current W3C VC Data Model 1.1 defines the holder property but its use is quite limited. It also doesn't allow to add new properties since the normative definition is holder MUST be a String.

For that reason I propose to change the holder property to String or Object. If it is an Object, we can add an optional holderBinding property that has an extension mechanism based on a type sub-property to allow implementers to define their own method of how such a relationship can be (ideally cryptographically) verified by the verifier. If the holderBinding is not provided, the default is always there is no binding or the binding can be established based on out-of-band information. For other mechanisms, I propose to introduce an extension registry similar to credentialStatus, evidence etc.

Example:

{
  ...
  "holder": {
    "holderBinding": {
       "type": "ExampleBindingBasedOnVCs",
       "optionalExampleBindingSpecificProperties": {
          ...
       }
    }
  },
  ...
}

Note, we cannot reuse the Data Integrity Proofs extension mechanism since each proof specification defines their own parameters and what options are hashed and signed over. We cannot reuse the evidence property, since it is less specific and currently only defined for the VC object and won't allow this decision to be made at the time of presentment.

tagging: @swcurran (since he opened a similar issue #789) and @dmitrizagidulin

Updated:

made holderBinding property optional
changed default behaviour of holderBinding not being present to original definition which is essentially undefined (i.e. no binding or depending on verifier logic).

The text was updated successfully, but these errors were encountered:

peacekeeper · 2022-06-22T18:46:42Z

In general, I like the idea of changing holder to be either String or Object, in a similar way as issuer can also be String or Object. This seems useful in situations where you want to add more information about a holder/issuer than just an identifier.

However, I am not convinced that your use case of holder binding is appropriate for this. To me, the existing proof property seems to be the correct construct.

According to the spec, proof is used to "detect tampering and verify the authorship". Isn't holder binding a part of that?

Could you explain a bit more what you mean by:

Note, we cannot reuse the Data Integrity Proofs extension mechanism since each proof specification defines their own parameters and what options are hashed and signed over.

awoie · 2022-06-23T09:13:04Z

@peacekeeper Thanks for your feedback. The Data Integrity Proof extension cannot be used (in a satisfactory manner) for the following reasons:

We would need to define a new suite and we cannot reuse existing Data Integrity Proof suites. This doesn't scale well regarding implementation and specification efforts. I want to allow existing suites such as Ed25519Signature2020, JsonWebSignature2020 etc. and I see the holderBinding as an additional relationship between the holder of the VP, the proof in the VP and the VC. This is important to support existing implementations that understand how to process those suites. Note that although Data Integrity Proofs support options, so something like the holderBinding as proposed above could be one such option but it is up to the Data Integrity Proof suite such as Ed25519Signature2020 to define what options will be used and integrity protected.
hard to support JWTs.

awoie · 2022-06-23T09:23:44Z

According to the spec, proof is used to "detect tampering and verify the authorship".

Let's use this simple example...

We have a VC with a vc.credentialSubject.id = "did:example:1", and a VP that has a vp.holder = "did:example:2" containing the VC. The proof of the VP was made by did:example:2#key-1. Further, let's assume there is a relationship between did:example:1 and did:example:2 in form of a VC that says, both are essentially the same (I know this is a bit sloppy). Even if I included those relationship-VCs in the VP, the verifier would be able to verify authorship and detect tampering, but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC. If we had a holder binding property in the proof (+ some external specification for the corresponding type), the verifier will be able to understand the holder's intention and can verify the relationship VCs in correspondence to the proof in the VP and the holder in the VP. Does this make sense?

peacekeeper · 2022-06-23T11:44:46Z

Hmm I don't really get it.

You say you cannot use a Data Integrity Proof extension because you would have to define a new suite and that this doesn't scale well, and then you say "If we had a holder binding property in the proof (+ some external specification for the corresponding type)". So you would still have to write an extension specification for your holder binding type, no? How does that scale better?

I also don't understand this part: "but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC". Why not? If there is a relationship VC in the VP, then why can't a verifier verify that the holder is the legitimate holder?

I don't feel strongly about this and wouldn't really oppose it, but to me it feels overly complicated to add this functionality to the holder property. Any other opinions?

peacekeeper · 2022-06-23T11:50:14Z

As a side note, if you want to express equivalence between did:example:1 and did:example:2, then that could be expressed via DID document properties and metadata, e.g. alsoKnownAs, equivalentId, canonicalId. But doing something similar with a VC is also a nice idea I think.

awoie · 2022-06-23T16:20:05Z

Hmm I don't really get it.

You say you cannot use a Data Integrity Proof extension because you would have to define a new suite and that this doesn't scale well, and then you say "If we had a holder binding property in the proof (+ some external specification for the corresponding type)". So you would still have to write an extension specification for your holder binding type, no? How does that scale better?

I want to allow people to reuse existing Data Integrity Proof specifications, meaning that the type in the VP proof stays the same. Also note, this approach would be backwards compatible. Furthermore, since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the VC and VP). This binding would give us a different property than that. IMO, this proof is also orthogonal to the actual proof mechanism.

I also don't understand this part: "but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC". Why not? If there is a relationship VC in the VP, then why can't a verifier verify that the holder is the legitimate holder?

They can, but there are many different methods how to accomplish this. Giving the verifier a single property to check what type of method is used, simplifies implementations by allowing profiles and helps with interop, it also helps with interop if there is a registry of supported methods that accomplish that.

Updated:

Typically, this part of the code that verifies the binding that I described above is typically outside of VC implementations, i.e. something that the verifier has to implement in addition. I want to standardize this through an extension mechanism. So that SSI framework vendors can implement something like (also note that those bindings could be pluggable to support any mechanism):

verifyVp(vp, ...)
verifyVc(vp.verifiableCredential[0..n], ...)

// this part of the code is usually VC profile specific logic and not provided by SSI frameworks (e.g., to check whether the same-as-relationship-VCs are in place). If we define an extension mechanism, then this could be part of SSI frameworks.
verifyBinding(vp)

awoie · 2022-06-23T16:30:35Z

As a side note, if you want to express equivalence between did:example:1 and did:example:2, then that could be expressed via DID document properties and metadata, e.g. alsoKnownAs, equivalentId, canonicalId. But doing something similar with a VC is also a nice idea I think.

Thanks for bringing this up. This might be certainly great in some cases but cannot be used everywhere, VCs can be used without DIDs, stronger cryptographic binding might be required, some DID methods don't support updates etc.

peacekeeper · 2022-06-23T16:40:10Z

since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the VC and VP)

I think I said the opposite, i.e. that holder binding is part of "verifying the authorship", not orthogonal to it. In your initial message you also explain that in VPs with traditional signatures, holder binding is also done via the VP's proof, i.e. in cases when "the credentialSubject.id is the same as the holder property and the proof of the VP authenticates the holder".

With your proposal, wouldn't we then end up in an inconsistent situation where holder binding is sometimes established via the proof alone, and sometimes via the proof plus something else?

In my mind, the VP proof can be used very broadly and could absolutely include information about the binding between the VC and VP, or some fancy-crypto holder binding, or anything else that's needed or useful for verifying integrity and/or authorship of the VP.

bumblefudge · 2022-06-23T18:04:06Z

Over the years, I have actually heard about many different solutions (variously elegant) to what I have come to call the "VP Containing VCs With Different credentialSubjects Problem". I think an extension-registry for properties (or values of one property) in VP.proof would be a good scaffolding for broader interoperability-- however you solve the problem in your own system with only 1 or 2 DID methods and VC schemas is all well and good, but without a registry it's very hard to accept multi-credSubj VPs from other systems, no?

bumblefudge · 2022-06-23T18:11:03Z

This also seems relevant to #879 (even if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know about this!)

OR13 · 2022-06-23T18:35:00Z

We support the holder as an object with an id member use case... its very useful when you want to provide a presentation over a name / address, etc... instead of just over a DID.

We've had a few conversations regarding this, here's the open issue tracking it:

w3c-ccg/traceability-vocab#455

decentralgabe · 2022-06-23T20:23:45Z

I'm generally in favor of the idea, though I really dislike having OR types in a specification, it makes it really hard to implement properly in a number of programming languages.

It also encourages the any spec, which I refer to as a specification that is so broad, and flexible, that it really ends up defining little: multiple documents that vary wildly can still be 'compliant'. This causes implementation hell.

bumblefudge · 2022-06-23T21:08:02Z

I really dislike having OR types in a specification

Just spitballing here, but what about this upgrade path:

V1: holder = string
V2: holder = string OR object, but string is deprecated
V2 Implementation Guide: be warned that if holder is a string, some V2 implementations MAY infer/attribute an implicit id or type.
V3: holder = object

makes V2 a little hellish to implement if you're working with production VCs and backwards compatibility issues, but way less hellish for the implementers coming on-board now?

peacekeeper · 2022-06-24T08:42:14Z

what about this upgrade path:

Whatever the decision is, I think the issuer in a VC and the holder in a VP should have the same rules, e.g. string / string OR object / object, etc.

awoie · 2022-06-24T09:45:58Z

since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the VC and VP)

I think I said the opposite, i.e. that holder binding is part of "verifying the authorship", not orthogonal to it. In your initial message you also explain that in VPs with traditional signatures, holder binding is also done via the VP's proof, i.e. in cases when "the credentialSubject.id is the same as the holder property and the proof of the VP authenticates the holder".

Existing implementations of VP verification only verify the proof against the holder (if present). They don't verify vp.holder.id equals vc.credentialSubject.id which is fine since there is no normative reference in the W3C VC spec to do so. See here for example:
https://github.com/digitalbazaar/vc-js/blob/f473944cb5261b0859457e234f8d22d1df41d269/lib/index.js#L428

A verifier application would need to ensure that vp.holder.id equals vc.credentialSubject.id after they verified the presentation. Note, there is currently no way to tell the verifier what binding was used. If the binding is not based on simple id matching, the verifier needs to guess the selected method. For that reason, I proposed the holderBinding property that allows the holder to indicate the chosen method in the VP, so the verifier can deterministically verify the selected binding method without having to guess or test different methods. IMO, this would also increase security by reducing side-effects.

With your proposal, wouldn't we then end up in an inconsistent situation where holder binding is sometimes established via the proof alone, and sometimes via the proof plus something else?

In my mind, the VP proof can be used very broadly and could absolutely include information about the binding between the VC and VP, or some fancy-crypto holder binding, or anything else that's needed or useful for verifying integrity and/or authorship of the VP.

Yes, I agree but it is a bit fuzzy and again limited. By introducing a new proof type it is just really hard to reuse existing Data Integrity Proofs such as Ed25519Signature2020, JwsSignature2020 etc. One cannot provide additional options to the proof method and expect they are going to be signed or integrity protected since the specific proof method defines what options are used/signed. Furthermore, what if someone wants to establish the binding through something that does not produce a cryptographic signature, e.g., by the evidence field. In that case, it would not count as a valid proof method since the proof method should also ensure data integrity.

The proof should ensure tamper-resistance and authorship. It does not ensure the binding between the VP proof and the VC. From the W3C VC Data Model 1.1 spec:

A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification.

There is no normative reference in the spec how this can be done. Existing implementations don't implement that binding when verifying the VP. This is expected to be done by the verifier after verifying the VPs. By defining a canonical extension mechanism, SSI framework vendors can support those methods, and provide relying parties or verifiers a comfortable and secure way to verify presented VPs correspond to the included VCs.

Updated:

More references from the W3C VC Data Model 1.1 spec:

proof
If present, the value of the proof property ensures that the presentation is verifiable. For details related to the use of this property, see Section 4.7 Proofs (Signatures).

on "verifiable" ...

verification
The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.

Then section 4.7 Proofs says ...

proof
One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a credential or presentation.

No reference that ensures binding between the holder of the VP and the VC. The authorship of a presentation is verifiable by verifying the proof of the VP against the holder property. No normative reference that anything else must be checked.

awoie · 2022-06-24T10:12:04Z

I'm generally in favor of the idea, though I really dislike having OR types in a specification, it makes it really hard to implement properly in a number of programming languages.

It also encourages the any spec, which I refer to as a specification that is so broad, and flexible, that it really ends up defining little: multiple documents that vary wildly can still be 'compliant'. This causes implementation hell.

I agree with that but I don't think we will be able to agree on one specific binding for all VP/VCs. vp.holder.id equals vc.credentialbSubject.id is just one method out of many. For example, ZKPs will definitely have different requirements. For that reason I was thinking an extension registry might be the best compromise.

awoie · 2022-06-24T11:01:08Z

I really dislike having OR types in a specification

Just spitballing here, but what about this upgrade path:

V1: holder = string V2: holder = string OR object, but string is deprecated V2 Implementation Guide: be warned that if holder is a string, some V2 implementations MAY infer/attribute an implicit id or type. V3: holder = object

makes V2 a little hellish to implement if you're working with production VCs and backwards compatibility issues, but way less hellish for the implementers coming on-board now?

Upgrade path might be the following...

If no holderBinding is present -> do exactly what you did before
If holderBinding is present -> verify binding according to type of the holderBinding after verifying the VP - VP verification just verifies the proof of the VP and the proof of the VCs individually but without verifying the correlation between them)
If holder being a String -> see 1.
If holder being an Object -> use holder.id and check if holderBinding is present, then do 1. or 2.

Note, there is still the very valid option that holder is completely unrelated to the subject in the VC. This should still be supported.

Also note, I'm also ok with defining a new top-level property for VPs which is not necessarily a sub-property of holder but I thought it would make semantically more sense to be included in the holder.

bertvannuffelen · 2022-06-24T11:52:26Z

Hi,

I tried to understand the proposed solutions, but maybe this one could also work, or it is a variant of the one being proposed.

E.g. lets agree for a VC implementation that the URI: https://system.com/agent/holder is the name for the holder of the credential. (This is called skolemization: one gives a name to a concrete item without knowing the real identity.)

Then

verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://system.example/credentials/1872",
    "type": ["VerifiableCredential"],
    "credentialSubject": {
      "id": "https://system.com/agent/holder"
      "hasValidDiploma" : "true"
    }
}],

represents the claim

<https://system.com/agent/holder> p:hasValidDiploma "true"^^xsd:boolean.

Using this agreement, the following exchange pattern can happen:

handshake about the holder's identity => both sender and receiver know the identity
exchange the diploma claim without explicit holder identity embedded

How the handshake happens, and if there is a requirement for a shared unique id between both I leave for that part.
But lets assume that the receiver knows the identity as "Jane Doe" having as id in the recievers context <https://passportnr.country/2321>.

Then the receiving system processing the claim can replace the skolem with the real identity:

<https://passportnr.country/2321> p:hasValidDiploma "true"^^xsd:boolean.

and integrate that knowledge in the subsequent data exchanges.

If I am right, it might be a variant of one of the proposed solutions and the challenge is to know what is the agreed skolem representation.
I am not sure, but is that not part a separate interaction (handshake as I called it) between sender and reciever?
As consequence the VC model has not to be changed, only a handshake needs to be defined.
And that could be considered beyond the VC spec?

jose-gataca · 2022-06-24T14:14:35Z

n if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know ab

Hi,

I think that part of the premise vp.holder.id equals vc.credentialSubject.id may be wrong. That may be true in most use cases, but we should consider the cases of Identity Delegation, in which the holder is not the subject of the credentials, but has been properly authorized by him to use them in his name.

In fact, I think the problem that should need to be solved would be vp.holder.id is accepted to represent vc.credentialSubject.id for which I am not sure if there are any proposed solutions: moreover considering that vp.holder.id and vc.credentialSubject.id may not be aliases of the same identity. I have read or heard from solutions that may make use of additional documents to the presentation, such as a Verifiable Consent or a Data Agreement, but nothing inside the W3C.

samu-gataca · 2022-06-24T15:25:41Z

Hi,
In addition to that it's necessary to ensure the claims shared by any user belongs to him. Till now, I saw 3 different ways to do that:

The user has a unique DID (universal DID) and then all the credentials attached to him have the same DID (holder) so there is no problem to ensure you are the owner for that credentials, but it's a big privacy problem. Although, I heard it in some forums, I think this alternative was discarded by most of SSI players.
Trying to solve the problem of privacy, many SSI players offer the possibility to the user to have multiples "profiles" (DIDs) and for each of that profiles the user should get the credentials to be used, so for example, the user to get a driver license to be used with several of that profiles, needs to trigger a different issuance process for any of the profiles he wants to use. The reason is VCs can not be shared between profiles (DIDs). This is what is happening with the current data model.
The user should have a different DID for each VC he wants to have, so the relationship between DIDs and VCs is 1:1. This alternative from the privacy perspective is better than the other one, but the problem comes when the user wants to share multiple VCs with one relying party, the party needs to verify all that VCs belong to the same person.

As @awoie says with the current data model I did not see the solution to do this. As @jose-gataca says, we were working on Data Agreement specification (Also it's necessary by GDPR) and maybe it's something that could help to fix the problem.

I don't really like the idea of modifying the current data model, because it has a big impact on the current implementations, so in the current services too. Also, I don't like to allow multiple types for the same property, because it causes confusion and doubts.

Regards

awoie · 2022-06-24T16:02:50Z

n if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know ab

Hi,

I think that part of the premise vp.holder.id equals vc.credentialSubject.id may be wrong. That may be true in most use cases, but we should consider the cases of Identity Delegation, in which the holder is not the subject of the credentials, but has been properly authorized by him to use them in his name.

In fact, I think the problem that should need to be solved would be vp.holder.id is accepted to represent vc.credentialSubject.id for which I am not sure if there are any proposed solutions: moreover considering that vp.holder.id and vc.credentialSubject.id may not be aliases of the same identity. I have read or heard from solutions that may make use of additional documents to the presentation, such as a Verifiable Consent or a Data Agreement, but nothing inside the W3C.

Exactly, an extension mechanism like that would be able to achieve that through a dedicated holder binding method. Similar to different credential status methods exist, different holder binding methods can exist and one can be based on the delegation pattern you just described.

awoie · 2022-06-24T17:11:51Z

Hi, In addition to that it's necessary to ensure the claims shared by any user belongs to him. Till now, I saw 3 different ways to do that:

The user has a unique DID (universal DID) and then all the credentials attached to him have the same DID (holder) so there is no problem to ensure you are the owner for that credentials, but it's a big privacy problem. Although, I heard it in some forums, I think this alternative was discarded by most of SSI players.

Trying to solve the problem of privacy, many SSI players offer the possibility to the user to have multiples "profiles" (DIDs) and for each of that profiles the user should get the credentials to be used, so for example, the user to get a driver license to be used with several of that profiles, needs to trigger a different issuance process for any of the profiles he wants to use. The reason is VCs can not be shared between profiles (DIDs). This is what is happening with the current data model.

The user should have a different DID for each VC he wants to have, so the relationship between DIDs and VCs is 1:1. This alternative from the privacy perspective is better than the other one, but the problem comes when the user wants to share multiple VCs with one relying party, the party needs to verify all that VCs belong to the same person.

As @awoie says with the current data model I did not see the solution to do this. As @jose-gataca says, we were working on Data Agreement specification (Also it's necessary by GDPR) and maybe it's something that could help to fix the problem.

I don't really like the idea of modifying the current data model, because it has a big impact on the current implementations, so in the current services too. Also, I don't like to allow multiple types for the same property, because it causes confusion and doubts.

Regards

We could make the holder binding property a top-level property, so we won't need to change the holder property itself. This would be 100% backward compatible with existing VPs. Further, you demonstrated three options of how other people approach that and one how you would approach it (based on the data agreement specification). These could be all different types of bindings without changing your spec. If we don't provide a mechanism to allow the verifier to detect such a binding, we would not achieve interop either.

So, I agree with the observed options and there are even more if we consider ZKP-based VCs but I think something like a new property + extension mechanism is necessary for interop. Note, it won't invalidate existing VP/VC implementations, 100% backward compatible.

peacekeeper · 2022-06-25T10:38:59Z

vp.holder.id equals vc.credentialbSubject.id is just one method out of many.

I think @awoie 's explanations here in this thread are really good, so I wouldn't oppose adding some new construct if really needed.

Maybe the idea I mentioned earlier (using DID Resolution and checking alsoKnownAs, equivalentId, canonicalId) would also be "one method out of many" that could be specified as some kind of extension.

We could make the holder binding property a top-level property, so we won't need to change the holder property itself.

I would support aligning the "holder" property with the "issuer" property in any case, irrespective of what the decision is here about holder binding.

alenhorvat · 2022-07-28T18:37:49Z

We have a VC with a vc.credentialSubject.id = "did:example:1", and a VP that has a vp.holder = "did:example:2" containing the VC. The proof of the VP was made by did:example:2#key-1. Further, let's assume there is a relationship between did:example:1 and did:example:2 in form of a VC that says, both are essentially the same (I know this is a bit sloppy). Even if I included those relationship-VCs in the VP, the verifier would be able to verify authorship and detect tampering, but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC.

Who asserts the relationship between "did:1" and "did:2" in the additional VC?
Is the relation deterministic, cryptographic, other?

Can you describe a case where you cannot achieve the same by including a VC that expresses the relationship between the 2 DIDs? Mandates/delegation are a typical case and you can issue a VC expressing the relationship.
Same goes if you'd like to introduce key certificates or key rotation without using a VDR.

Is the VP the right place to express the holder binding and is the holder the one who should do it? Namely, the holder binding is asserted and guaranteed by the issuer (you're identified -> you get your VCs).

Questions, that should be answered are

Who can assert the relation? (Issuer, Wallet provider?)
Is sharing 2 (or more) proofs in an authenticated session sufficient to ensure holder binding?

We also need to distinguish between VCs that can be used for identification or authentication and attestations.
Usually, you'll authenticate with an RP and you'll share your attestations within an authenticated session.

Sakurann · 2023-02-16T14:39:10Z

agreed during miami F2F

awoie · 2023-04-25T12:31:32Z

PR #1054 is pending, so may be fixed by #1054.

awoie · 2023-04-25T12:48:21Z

IMO, this is a duplicate of #789 and can be closed, or the other way around.

awoie · 2023-06-05T11:18:21Z

@swcurran @paulbastian It seems that certain WG members objected to including confirmationMethod (confidenceMethod) in the VCDM core. It will become a reserved term in the VCDM without a normative definition. I suggest we ask W3C CCG to adopt the current confidenceMethod proposal and close this issue. @swcurran would you be fine with that approach?

swcurran · 2023-06-05T22:21:18Z

I don’t understand exactly what you mean by your comment above @awoie nor what @brentzundel means in this comment on the related PR #1054.

@awoie — Do you mean that the plan is that because of the objections the PR #1504 will not be merged, but confi*Method will be reserved, with a separate W3C CCG spec created solely for that?

@brentzundel — when you say “in favour of another path forward” — it would be helpful to say what that other path is. I think you are referencing @mprorock’s idea of “put it somewhere else”? Is that correct?

As I’m not a member of the VCWG and I’ve not been at the meetings covering this topic, my input is of little value — especially at this point in the process. I stand by my belief (see #789 ) that without such a capability, the issue will be addressed in multiple ways by different groups. The issue is core to many use cases, it has to be solved. Its just a question of how many ways will it be solved, and how difficult will it be for holders and verifiers.

OR13 · 2023-06-06T02:36:48Z

I objected.

Holder binding is already solved for many different ways... Adding JSON-LD vocabulary and terms to w3id.org won't change that...

Nor will reserving terms in the core data model, without defining any concrete testable RDF classes.

Nor will exposing holder binding for Data Integrity Proofs, JWTs, Gordion knots, ACDCs, anon creds, COSE sign1s or mdocs... Different formats will handle security details differently, the core data model is not a place to do security work.

It leads to confusing, and dangerous mappings between the base cryptographic layers and semantic / RDF data model.

I suggest the work be incubated and tested concretely in community groups as data integrity proofs were for years.

When there is sufficient interoperable implementation to justify standardization and working group interest and expertise to do a good job, then the work should be picked up.

Verifiable presentations remain extremely poorly defined... Perhaps now we can focus on fixing the flaws in the existing data model instead of introducing more experimental terminology to an already very weak draft.

swcurran · 2023-06-06T15:56:08Z

Reasonable arguments, @OR13, thanks. Unfortunate that we can’t build a solution on a common base. It will be solved elsewhere.

OR13 · 2023-06-06T16:03:34Z

Unfortunate that we can’t build a solution on a common base. It will be solved elsewhere.

+1 to this, I think this suggests that Verifiable Presentations may need to be updated, or removed from the TR.

We should focus on fixing that first.

jandrieu · 2023-06-06T16:25:18Z

Verifiable presentations remain extremely poorly defined... Perhaps now we can focus on fixing the flaws in the existing data model instead of introducing more experimental terminology to an already very weak draft.

@OR13 I agree with the poor definition. That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

VPs exist because we needed a vehicle to capture the semantics of presentation--the act of presenting your credentials is itself a legally cognizable act, hence deserving of clarification of intention.

At the time of definition, it was accepted that DIDs and DID Auth provided a coherent strategy for cryptographic proof that the presenter is in control of secrets only the subject is expected to have.

That simplistic perspective hasn't held up. Its clear that if any URI can be a subject identifier, then we need a more flexible way to gain confidence that the presenter is the subject.

The solution that is emerging here is two fold.

predicates that allow the issuer to provide guidance for how a verifier my increase their confidence
predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

The first is addressed by confidenceMethod as discussed in #1054

The second is discussed in issue #860.

If you want to "fix" VPs, I invite you to start with supporting confidenceMethod and issue #860.

agropper · 2023-06-06T16:36:52Z

Just because the request for and presentation of credentials are legally recognizable acts does not mean that they should be standardized as part of SSI. See also my comments on #860.

…

On Tue, Jun 6, 2023 at 12:25 PM Joe Andrieu ***@***.***> wrote: Verifiable presentations remain extremely poorly defined... Perhaps now we can focus on fixing the flaws in the existing data model instead of introducing more experimental terminology to an already very weak draft. @OR13 <https://github.com/OR13> I agree with the poor definition. That's what confidenceMethod is addressing, but you oppose including that in the VCDM. VPs exist because we needed a vehicle to capture the semantics of presentation--the act of presenting your credentials is itself a legally cognizable act, hence deserving of clarification of intention. At the time of definition, it was accepted that DIDs and DID Auth provided a coherent strategy for cryptographic proof that the presenter is in control of secrets only the subject is expected to have. That simplistic perspective hasn't held up. Its clear that if any URI can be a subject identifier, then we need a more flexible way to gain confidence that the presenter is the subject. The solution that is emerging here is two fold. 1. predicates that allow the issuer to provide guidance for how a verifier my increase their confidence 2. predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims. The first is addressed by confidenceMethod as discussed in #1054 <#1054> The second is discussed in issue #860 <#860>. If you want to "fix" VPs, I invite you to start with supporting confidenceMethod and issue #860 <#860>. — Reply to this email directly, view it on GitHub <#882 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YIQ24E7W5O5MR7VPSDXJ5KXRANCNFSM5ZQKIELQ> . You are receiving this because you commented.Message ID: ***@***.***>

OR13 · 2023-06-06T17:33:51Z

@jandrieu

That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

Because it's not actually addressing it, its security theater that harms users... It just looks like a solution because its JSON-LD with paragraphs of text around it.

VPs exist because we needed a vehicle to capture the semantics of presentation--the act of presenting your credentials is itself a legally cognizable act, hence deserving of clarification of intention.

This is great example of how adding semantics doesn't add security.

At the time of definition, it was accepted that DIDs and DID Auth provided a coherent strategy for cryptographic proof that the presenter is in control of secrets only the subject is expected to have.

And now? Seems like we have some spec updating too do... Also, IIRC, DIDs were never a requirement for VCs so this does not sit right.

I do agree that "DID Auth" could solve for this, but where is that documented?

it could be in the core data model (its not)
it could be in data integrity proofs and related to the "authentication proof purpose". (it is) - https://www.w3.org/TR/vc-data-integrity/#proof-purposes
it could be in sd-jwt (it is)
it could be in (your fancy new security format for vc+ld+json) (it can be).

If the argument is, we need to add proof purposes too did core to enable DID Auth, and define proof normatively in order to enable holder binding... seems like we don't need confidenceMethod... and that we could do that in the core spec, with consensus.

Just to spell it out... if the issuer didn't want to ENABLE the holder to use "DID Auth" for certain VERIFIERS.... they would not issue credentials to a DID, or bind the credentialSubject to a particular public key (in any number of the 1000 key formats that exist).

See this SD-JWT PR which discusses this concept in greater detail: oauth-wg/oauth-selective-disclosure-jwt#246

This is the simplest form of holder binding, and we have still not demonstrated ANY interoperability on it... Adding more complexity will not help.

Let's see the community solve this problem and bring us demonstrated interoperability before we grant a reserved property that nobody is required to understand, and that harms security when not understood.

That simplistic perspective hasn't held up. It's clear that if any URI can be a subject identifier, then we need a more flexible way to gain confidence that the presenter is the subject.

I'm not sure I agree with this, I can see data integrity proofs have this solved already, see above link.

I'm not sure, but its possible you are wanting "evidence" with "proofPurpose", that could also be made clearer... in the spec that defines proofPurpose normatively.

The solution that is emerging here is two fold.

predicates that allow the issuer to provide guidance for how a verifier my increase their confidence

Like "credentialSubject.id" ? (half a solution, see the current draft)

predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

Like "proofPurpose" ? (not a solution since proofPurpose is not normatively defined properly in the core data model)

Let's fix proof before spending any more time on "extensions", proof is already an "extension" that causes security problems when not understood properly.... and it has quasi normative status in the vc data model and normative status in data integrity.

@agropper

Just because the request for and presentation of credentials are legally recognizable acts does not mean that they should be standardized as part of SSI.

+1 to this... and that is exactly what the working group was trying to do... Legal requirements in JSON-LD... instead of cryptographic requirements, in a securing format... See Data Integrity & SD-JWT drafts for the right way to handle this.

awoie · 2023-06-06T18:44:39Z

Unfortunate that we can’t build a solution on a common base. It will be solved elsewhere.

+1 to this, I think this suggests that Verifiable Presentations may need to be updated, or removed from the TR.

We should focus on fixing that first.

I would be +1 removing it from the spec since it is completely underspecified and leads to confusion.

brentzundel · 2023-06-06T21:34:57Z

I would oppose removing Verifiable Presentations without the addition of language that makes clear the difference between a VC sent from and issuer to a holder and a VC sent from a holder to a verifier.

Also, perhaps this proposal should exist as its own issue.

It is also not clear to me that a proposal to remove verifiable presentations wouldn't be considered new work, i.e., it may fall afoul of our current feature-freeze status.

dlongley · 2023-06-06T22:06:45Z

I oppose removing Verifiable Presentations. We should keep building incrementally on what we have so far; we should not tear things down.

jandrieu · 2023-06-06T22:14:00Z

@jandrieu

That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

Because it's not actually addressing it, its security theater that harms users... It just looks like a solution because its JSON-LD with paragraphs of text around it.

On the contrary, I believe you are conflating security with identity. This is an identity assurance question, not a security one.

Where do you see "theater" in the issuer and verifier having mechanisms to increase the confidence in recognizing the current presenter as a legitimate presenter given the use case? All of the data used for semantic evaluation is secured so I'm not seeing the disconnect you are.

VPs exist because we needed a vehicle to capture the semantics of presentation--the act of presenting your credentials is itself a legally cognizable act, hence deserving of clarification of intention.

This is great example of how adding semantics doesn't add security.

Why would it? This isn't a security question. It's an identity assurance question.

At the time of definition, it was accepted that DIDs and DID Auth provided a coherent strategy for cryptographic proof that the presenter is in control of secrets only the subject is expected to have.

And now? Seems like we have some spec updating too do... Also, IIRC, DIDs were never a requirement for VCs so this does not sit right.

Yes. That was the point of my explanation. VPs with DID Auth performed a limited but critical function in an obscure and poorly documented mechanism. What we need to do is to clarify that function with clear and rigorously documented mechanism.

I do agree that "DID Auth" could solve for this, but where is that documented?

It's currently documented in two places.

https://www.w3.org/TR/vc-data-model/#subject-is-the-holder which was apparently removed in a fit of minimalism.
https://w3c-ccg.github.io/vp-request-spec/#did-authentication in the Verifiable Presentation Request specification

it could be in the core data model (its not)

Yes. Because you fought it. It is there in the current publication https://www.w3.org/TR/vc-data-model/#subject-is-the-holder . I posit that the problems with that section aren't addressed by removing it.

it could be in data integrity proofs and related to the "authentication proof purpose". (it is) - https://www.w3.org/TR/vc-data-integrity/#proof-purposes

No, it can't. This is not an integrity mechanism. It has nothing to do with the tamper-evidence of the digital object. It has to do with mechanisms for assuring the verifier that the VC is being used by an appropriate party.

it could be in sd-jwt (it is)

The mechanism in sd-jwt appears to be limited to "Proving control over the same private key during the issuance and presentation". I agree that's functionally equivalent to DID Auth (ignoring that there's no way for a holder in SD-JWT to rotate their keys).

In fact, SD-JWT_RELEASE is functioning as a Verifiable Presentation, which supports my argument that the problem isn't that VPs are bad, it's that they need better definition.

it could be in (your fancy new security format for vc+ld+json) (it can be).

It's not a security format. It's an identity assurance mechanism. It's not a fancy new anything. It's two properties that allow issuers and holders to make statements that help verifiers apply their own business rules to determine if the VP and VCs presented are fit for their purpose.

If the argument is, we need to add proof purposes too did core to enable DID Auth, and define proof normatively in order to enable holder binding... seems like we don't need confidenceMethod... and that we could do that in the core spec, with consensus.

I don't follow your argument (even to disagree with it).

Proof purpose is about the reason a particular signature is applied. It is restricted to a few limited purposes: attestation, authentication, key agreement, capability invocation, and capability delegation.

What we need is a way, for example, for the citizenship applicant in Citizenship by Parentage to express arbitrary statements about why they are presenting the claims in the VP. Proof purpose can't explain:

the assertions that —

He is the child in the birth certificate.

The mother in the birth certificate, the person in the passport, the spouse in the marriage license are all the same person.

Just to spell it out... if the issuer didn't want to ENABLE the holder to use "DID Auth" for certain VERIFIERS.... they would not issue credentials to a DID, or bind the credentialSubject to a particular public key (in any number of the 1000 key formats that exist).

Sure. But that's the obscure, undocumented, and incomplete way to thing about identity assurance, which is documented in the current published spec as non-normative text. This conversation is about trying to draft normative text that is neither obscure nor incomplete. You're approach ignores the situations where the issuer wants to enable assurance mechanisms other than DID Auth.

See this SD-JWT PR which discusses this concept in greater detail: oauth-wg/oauth-selective-disclosure-jwt#246

Not sure what you wanted me to read in that. It's already been merged and I just read the current draft to respond to your earlier comments.

This is the simplest form of holder binding, and we have still not demonstrated ANY interoperability on it... Adding more complexity will not help.

If you mean SD-JWT-RELEASE, then ok. I can't speak to whether or not anyone has demonstrated interoperability.

However, if you mean DID auth and VPs, that is incorrect. The JFF plugfest has demonstrated plenty of interoperability for DID Auth used in exactly this manner.

Let's see the community solve this problem and bring us demonstrated interoperability before we grant a reserved property that nobody is required to understand, and that harms security when not understood.

DID Auth is a solved problem with demonstrated interoperability as defined and used in the Verifiable Presentation Request specification. What we haven't done is map that functionality to the newly proposed, generic confidenceMethod. This is work in progress, just like the SD-JWT-RELEASE you're working on elsewhere.
Please make your case for why these two mechanisms for identity assurance harms security. It is not a security function. It seems to me that the theatrics are about the over use most attempts to bind security and identity,

That simplistic perspective hasn't held up. It's clear that if any URI can be a subject identifier, then we need a more flexible way to gain confidence that the presenter is the subject.

I'm not sure I agree with this, I can see data integrity proofs have this solved already, see above link.

No. They haven't. Data integrity doesn't have the semantics of "why" at the level of claim evaluation. It only has the "why" at the level of the signature. It's per the spec that we can use any URI for a subject identifier, but the only assurance mechanisms on the table right now are either DIDs (with DID Auth) or public keys (with SD-JWT-RELEASE).

I'm not sure, but its possible you are wanting "evidence" with "proofPurpose", that could also be made clearer... in the spec that defines proofPurpose normatively.

No. @awoie's confidenceMethod and issue #860. Something for the verifier to express their intention and something for the holder to express their intention, both of which are signed over by respective cryptography.

The solution that is emerging here is two fold.

predicates that allow the issuer to provide guidance for how a verifier my increase their confidence

Like "credentialSubject.id" ? (half a solution, see the current draft)

No. That only identifies the subject. It does not, on its own, define any mechanism for convincing the verifier that the presenter is the party intended by the issuer.

DIDs have a built-in authentication affordance. No other URIs have that.

So, we really have two choices here:

Restrict credentialSubject.id to DIDs
Enable issuers to add assurance mechanisms they advocate for evaluating the presenter's claims of legitimate use.

predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

Like "proofPurpose" ? (not a solution since proofPurpose is not normatively defined properly in the core data model)

No. As mentioned above, proofPurpose only refers to the purpose of the cryptographic proof. It does not explain the purpose of why the claims are presented in the first place.

Let's fix proof before spending any more time on "extensions", proof is already an "extension" that causes security problems when not understood properly.... and it has quasi normative status in the vc data model and normative status in data integrity.

This isn't about proofs. And it isn't about security.

I think this highlights the core disconnect between the JWT advocates and the JSON-LD folks. The JWT sensbility is that keys secure data. Done. That's a fine mechanism in a two party interaction, where you already know who the signing party is and why the JWT was issued, because you are either the issuer or the recipient.

However, in a three party model, I have to deal with the semantics of the situation as a different matter. There is no gauranteed, privacy respecting mechanism to ensure that the actual entity on the other side of a transaction is, in fact, RIGHT NOW, the entity is the one you imagine. Full stop. All we can ever do is evaluate available data to establish a high enough confidence level that the current presenter is, in fact, a legitimate presenter.

That legitimacy depends on

What the issuer intended (especially wrt identifying the subject)
What the holder intended (especially wrt the relating themselves to the claims in the presented VCs)
What the verifier requires (especially what mechanisms would satisfy their need for confidence in the presenter's identity)

#3 is an internal matter for the verifier and belongs in neither the VC nor the VP.
For #1 and #2, we have the two mechanisms already proposed.

@agropper

Just because the request for and presentation of credentials are legally recognizable acts does not mean that they should be standardized as part of SSI.

+1 to this... and that is exactly what the working group was trying to do... Legal requirements in JSON-LD... instead of cryptographic requirements, in a securing format... See Data Integrity & SD-JWT drafts for the right way to handle this.

We aren't here to "standardize SSI". We're here to work on a specific specification that enables aspects of SSI.

agropper · 2023-06-07T02:33:22Z

It seems to me that implementers can choose to use VCs with total disregard for VPs. For example, we’re using VCs in a user-centric request model where the presentation protocol is GNAP. Issuers can deliver VCs to anyone based on GNAP requests. Verifiers can process GNAP requests that include one or more VCs along with purpose and accountability components. What am I missing?

…

On Tue, Jun 6, 2023 at 6:14 PM Joe Andrieu ***@***.***> wrote: @jandrieu <https://github.com/jandrieu> That's what confidenceMethod is addressing, but you oppose including that in the VCDM. Because it's not actually addressing it, its security theater that harms users... It just looks like a solution because its JSON-LD with paragraphs of text around it. On the contrary, I believe you are conflating security with identity. This is an identity assurance question, not a security one. Where do you see "theater" in the issuer and verifier having mechanisms to increase the confidence in recognizing the current presenter as a legitimate presenter given the use case? All of the data used for semantic evaluation is secured so I'm not seeing the disconnect you are. VPs exist because we needed a vehicle to capture the semantics of presentation--the act of presenting your credentials is itself a legally cognizable act, hence deserving of clarification of intention. This is great example of how adding semantics doesn't add security. Why would it? This isn't a security question. It's an identity assurance question. At the time of definition, it was accepted that DIDs and DID Auth provided a coherent strategy for cryptographic proof that the presenter is in control of secrets only the subject is expected to have. And now? Seems like we have some spec updating too do... Also, IIRC, DIDs were never a requirement for VCs so this does not sit right. Yes. That was the point of my explanation. VPs with DID Auth performed a limited but critical function in an obscure and poorly documented mechanism. What we need to do is to clarify that function with clear and rigorously documented mechanism. I do agree that "DID Auth" could solve for this, but *where* is that documented? It's currently documented in two places. 1. https://www.w3.org/TR/vc-data-model/#subject-is-the-holder which was apparently removed in a fit of minimalism. 2. https://w3c-ccg.github.io/vp-request-spec/#did-authentication in the Verifiable Presentation Request specification 1. it could be in the core data model (its not) Yes. Because you fought it. It is there in the current publication https://www.w3.org/TR/vc-data-model/#subject-is-the-holder . I posit that the problems with that section aren't addressed by removing it. 1. it could be in data integrity proofs and related to the "authentication proof purpose". (it is) - https://www.w3.org/TR/vc-data-integrity/#proof-purposes No, it can't. This is not an integrity mechanism. It has nothing to do with the tamper-evidence of the digital object. It has to do with mechanisms for assuring the verifier that the VC is being used by an appropriate party. 1. it could be in sd-jwt (it is) The mechanism in sd-jwt appears to be limited to "Proving control over the same private key during the issuance and presentation". I agree that's functionally equivalent to DID Auth (ignoring that there's no way for a holder in SD-JWT to rotate their keys). In fact, SD-JWT_RELEASE is functioning as a Verifiable Presentation, which supports my argument that the problem isn't that VPs are bad, it's that they need better definition. 1. it could be in (your fancy new security format for vc+ld+json) (it can be). It's not a security format. It's an identity assurance mechanism. It's not a fancy new anything. It's two properties that allow issuers and holders to make statements that help verifiers apply their own business rules to determine if the VP and VCs presented are fit for their purpose. If the argument is, we need to add proof purposes too did core to enable DID Auth, and define proof normatively in order to enable holder binding... seems like we don't need confidenceMethod... and that we could do that in the core spec, with consensus. I don't follow your argument (even to disagree with it). Proof purpose is about the reason a particular signature is applied. It is restricted to a few limited purposes: attestation, authentication, key agreement, capability invocation, and capability delegation. What we need is a way, for example, for the citizenship applicant in Citizenship by Parentage <https://www.w3.org/TR/vc-use-cases/#citizenship-by-parentage> to express arbitrary statements about why they are presenting the claims in the VP. Proof purpose can't explain: the assertions that — - He is the child in the birth certificate. - The mother in the birth certificate, the person in the passport, the spouse in the marriage license are all the same person. Just to spell it out... if the issuer didn't want to ENABLE the holder to use "DID Auth" for certain VERIFIERS.... they would not issue credentials to a DID, or bind the credentialSubject to a particular public key (in any number of the 1000 key formats that exist). Sure. But that's the obscure, undocumented, and incomplete way to thing about identity assurance, which is documented in the current published spec as non-normative text. This conversation is about trying to draft normative text that is neither obscure nor incomplete. You're approach ignores the situations where the issuer wants to enable assurance mechanisms other than DID Auth. See this SD-JWT PR which discusses this concept in greater detail: oauth-wg/oauth-selective-disclosure-jwt#246 <oauth-wg/oauth-selective-disclosure-jwt#246> Not sure what you wanted me to read in that. It's already been merged and I just read the current draft to respond to your earlier comments. This is the simplest form of holder binding, and we have still not demonstrated ANY interoperability on it... Adding more complexity will not help. If you mean SD-JWT-RELEASE, then ok. I can't speak to whether or not anyone has demonstrated interoperability. However, if you mean DID auth and VPs, that is incorrect. The JFF plugfest has demonstrated plenty of interoperability for DID Auth used in exactly this manner. Let's see the community solve this problem and bring us demonstrated interoperability before we grant a reserved property that nobody is required to understand, and that harms security when not understood. 1. DID Auth is a solved problem with demonstrated interoperability as defined and used in the Verifiable Presentation Request specification. What we haven't done is map that functionality to the newly proposed, generic confidenceMethod. This is work in progress, just like the SD-JWT-RELEASE you're working on elsewhere. 2. Please make your case for why these two mechanisms for identity assurance harms security. It is not a security function. It seems to me that the theatrics are about the over use most attempts to bind security and identity, That simplistic perspective hasn't held up. It's clear that if any URI can be a subject identifier, then we need a more flexible way to gain confidence that the presenter is the subject. I'm not sure I agree with this, I can see data integrity proofs have this solved already, see above link. No. They haven't. Data integrity doesn't have the semantics of "why" at the level of claim evaluation. It only has the "why" at the level of the signature. It's per the spec that we can use any URI for a subject identifier, but the only assurance mechanisms on the table right now are either DIDs (with DID Auth) or public keys (with SD-JWT-RELEASE). I'm not sure, but its possible you are wanting "evidence" with "proofPurpose", that could also be made clearer... in the spec that defines proofPurpose normatively. No. @awoie <https://github.com/awoie>'s confidenceMethod and issue #860 <#860>. Something for the verifier to express their intention and something for the holder to express their intention, both of which are signed over by respective cryptography. The solution that is emerging here is two fold. 1. predicates that allow the issuer to provide guidance for how a verifier my increase their confidence Like "credentialSubject.id" ? (half a solution, see the current draft) No. That only identifies the subject. It does not, on its own, define any mechanism for convincing the verifier that the presenter is the party intended by the issuer. DIDs have a built-in authentication affordance. No other URIs have that. So, we really have two choices here: 1. Restrict credentialSubject.id to DIDs 2. Enable issuers to add assurance mechanisms they advocate for evaluating the presenter's claims of legitimate use. 1. predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims. Like "proofPurpose" ? (not a solution since proofPurpose is not normatively defined properly in the core data model) No. As mentioned above, proofPurpose only refers to the purpose of the cryptographic proof. It does not explain the purpose of why the claims are presented in the first place. Let's fix proof before spending any more time on "extensions", proof is already an "extension" that causes security problems when not understood properly.... and it has quasi normative status in the vc data model and normative status in data integrity. This isn't about proofs. And it isn't about security. I think this highlights the core disconnect between the JWT advocates and the JSON-LD folks. The JWT sensbility is that keys secure data. Done. That's a fine mechanism in a two party interaction, where you already know who the signing party is and why the JWT was issued, because you are either the issuer or the recipient. However, in a three party model, I have to deal with the semantics of the situation as a different matter. There is no gauranteed, privacy respecting mechanism to ensure that the actual entity on the other side of a transaction is, in fact, RIGHT NOW, the entity is the one you imagine. Full stop. All we can ever do is evaluate available data to establish a high enough confidence level that the current presenter is, in fact, a legitimate presenter. That legitimacy depends on 1. What the issuer intended (especially wrt identifying the subject) 2. What the holder intended (especially wrt the relating themselves to the claims in the presented VCs) 3. What the verifier requires (especially what mechanisms would satisfy their need for confidence in the presenter's identity) #3 is an internal matter for the verifier and belongs in neither the VC nor the VP. For #1 and #2, @agropper <https://github.com/agropper> Just because the request for and presentation of credentials are legally recognizable acts does not mean that they should be standardized as part of SSI. +1 to this... and that is exactly what the working group was trying to do... Legal requirements in JSON-LD... instead of cryptographic requirements, in a securing format... See Data Integrity & SD-JWT drafts for the right way to handle this. We aren't here to "standardize SSI". We're here to work on a specific specification that enables aspects of SSI. — Reply to this email directly, view it on GitHub <#882 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YI4D2SBDUMQL7EKNYLXJ6TTHANCNFSM5ZQKIELQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

TallTed · 2023-06-07T03:14:00Z

What am I missing?

Primarily, I think you're forgetting selective disclosure.

This should surprise us a lot, given many of your previous comments in this group and elsewhere.

agropper · 2023-06-07T04:20:19Z

I don’t see why selective disclosure would be harder or even differently with GNAP requests instead of VPs.

…

On Tue, Jun 6, 2023 at 11:14 PM Ted Thibodeau Jr ***@***.***> wrote: What am I missing? Primarily, I think you're forgetting selective disclosure. This should surprise us a lot, given many of your previous comments in this group and elsewhere. — Reply to this email directly, view it on GitHub <#882 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YJNZAEZMOHHKUD7ZCDXJ7WYFANCNFSM5ZQKIELQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

awoie · 2023-06-07T09:02:29Z

I oppose removing Verifiable Presentations. We should keep building incrementally on what we have so far; we should not tear things down.

Adding VPs in the first place was a mistake imo. Even with Data Integrity we are having a situation where certain proof types don't use VPs at all. It would even compromise the unlinkability guarantees/privacy in the case of BBS+ if the derived VC were put into another signed envelope.

It is confusing for a verifier to expect VPs and/or VCs. IMO, if the holder simply adds another proof to the VC, you would achieve the same thing as VPs using simple ECDSA proofs. Note that the proof contains a verification method that allows the verifier to check who originated the proof. In that case, there is really no big difference between using a VP and a VC with an additional proof created by the holder key.

awoie · 2023-06-07T11:57:49Z

I oppose removing Verifiable Presentations. We should keep building incrementally on what we have so far; we should not tear things down.

Adding VPs in the first place was a mistake imo. Even with Data Integrity we are having a situation where certain proof types don't use VPs at all. It would even compromise the unlinkability guarantees/privacy in the case of BBS+ if the derived VC were put into another signed envelope.

It is confusing for a verifier to expect VPs and/or VCs. IMO, if the holder simply adds another proof to the VC, you would achieve the same thing as VPs using simple ECDSA proofs. Note that the proof contains a verification method that allows the verifier to check who originated the proof. In that case, there is really no big difference between using a VP and a VC with an additional proof created by the holder key.

The discussions so far should have highlighted that the issuer's intention is not only to limit who can present the VC but also to protect against cloning and simple replay attacks and improve the overall security of VPs. Adding holder binding or authentication on top of that further enhances the security measures but might be an additional process. For the former, it means that the VC needs to be linked to specific key material or a DID or similar in the first place (which the conf'method was about).

In my opinion, VPs would lose their significance without incorporating these security controls. Without them, a holder could easily add another proof to the VC and achieve the same result that VPs aim to provide in terms of semantics.

By implementing these security measures, we can ensure the integrity and authenticity of VCs and VPs, guarding against cloning and certain MITM attacks.

Neither the VCDM, nor the Data Integrity data model caters for this atm, so I created this #1138.

A potential solution might be that someone could define a XyzKeyBoundPresentationSignature2023 which semantically says that the presentation is secured by a signature that proves control over a specific claim endorsed by the issuer that is contained in the VC. In that case I might be convinced that VPs do have some purpose. Just inventing an envelope for multiple VCs is not really a meaningful reason that justifies having another top-level standalone object such as presentation or VP.

TallTed · 2023-06-07T21:09:56Z

Just inventing an envelope for multiple VCs is not really a meaningful reason that justifies having another top-level standalone object such as presentation or VP.

VPs are not just "an envelope for multiple VCs". They also enable Selective Disclosure, among other things we've discussed elsewhere.

OR13 · 2023-06-08T00:38:33Z

Verifiable Presentations only normative requirements:

@context
type

Everything else is optional.

The current spec version of a VP is essentially a JWT with alg none, being a legal value.

VPs don't enable anything, how could they, look at their requirements.

They are simply JSON-LD envelopes.

If we want them to have more significant meaning than "ld+json" we have a lot of normative changes to make.

https://github.com/transmute-industries/vc-jwt-test-suite/blob/main/data/report.json

VPs have been successfully used for lots of things based on their non existent requirements.

The list includes:

Securing multiple credentials with a new signature from the current holder.
Transformed / verifier bound representations of credentials (CL-Signatures)
Subject is holder, authentication proof purposes.
Delivering credentials to and from wallets (chapi).

I guess it's natural that we don't really have a proof requirement for Verifiable Presentations, since we don't have one for Verifiable Credentials.

In the case that we do have a proof on a presentation, it can be used to demonstrate proof of possession.

Another areas a challenge... The "verifiableCredential" graph container.

It can hold by reference or by value, but it can't hold JWT by value because they are not valid IRIs (graph node identifiers) or objects (graph nodes).

We could fix this by making a URN format for JWTs or by asserting that JWT VPs simply don't exist, and you should instead use a separate credential for proof of possession, like sd-jwt already does.

This would make presentations very different for the various "security formats" further eroding the value of VPs.

I think the truth is, VPs are basically a data integrity proof specific container.

Keeping them as they are, gives data integrity proofs tremendous flexibility, while forcing developers to handle a security data format that can be basically anything.

OR13 · 2023-06-08T02:59:21Z

Another option for VP and VC by reference is data URIs.

Now that we have a requested content type, expect to see this everywhere:

data:application/vc+ld+json, base64;ey...

data:application/vc+ld+jwt, base64;ey...

OR13 · 2023-06-20T22:05:39Z

This issue can be closed when https://github.com/w3c/vc-data-model/pull/1141/files is merged.

brentzundel · 2023-06-23T19:02:41Z

PR #1141 has been merged, closing

awoie changed the title ~~Add extension mechanism to allow proof-of-control of VPs~~ Add extension mechanism to allow different methods for proof-of-control of VCs through VPs Jun 24, 2022

awoie mentioned this issue Jun 24, 2022

vc:credentialSubject semantics #885

Closed

awoie changed the title ~~Add extension mechanism to allow different methods for proof-of-control of VCs through VPs~~ Add extension mechanism to allow different methods for proof-of-control of VCs through VPs to next version of standard Jun 24, 2022

awoie mentioned this issue Feb 27, 2023

Add confidence method to VCDM #1054

Closed

3 tasks

awoie mentioned this issue Apr 25, 2023

"bound"/"binding" terminology is a significantly stronger relationship than is actually present between VCs and their Subjects *or* Holders #821

Closed

awoie added pr exists and removed ready for PR This issue is ready for a Pull Request to be created to resolve it labels Jun 5, 2023

brentzundel closed this as completed Jun 23, 2023

Add extension mechanism to allow different methods for VP-to-VC / holder binding to next version of standard to allow verification of rightfulness of presentation #882

Add extension mechanism to allow different methods for VP-to-VC / holder binding to next version of standard to allow verification of rightfulness of presentation #882

Comments

awoie commented Jun 22, 2022 • edited Loading

peacekeeper commented Jun 22, 2022

awoie commented Jun 23, 2022 • edited Loading

awoie commented Jun 23, 2022 • edited Loading

peacekeeper commented Jun 23, 2022 • edited Loading

peacekeeper commented Jun 23, 2022

awoie commented Jun 23, 2022 • edited Loading

awoie commented Jun 23, 2022 • edited Loading

peacekeeper commented Jun 23, 2022

bumblefudge commented Jun 23, 2022 • edited Loading

bumblefudge commented Jun 23, 2022

OR13 commented Jun 23, 2022 • edited Loading

decentralgabe commented Jun 23, 2022

bumblefudge commented Jun 23, 2022 • edited Loading

peacekeeper commented Jun 24, 2022

awoie commented Jun 24, 2022 • edited Loading

awoie commented Jun 24, 2022

awoie commented Jun 24, 2022

bertvannuffelen commented Jun 24, 2022

jose-gataca commented Jun 24, 2022

samu-gataca commented Jun 24, 2022

awoie commented Jun 24, 2022

awoie commented Jun 24, 2022

peacekeeper commented Jun 25, 2022

alenhorvat commented Jul 28, 2022

Sakurann commented Feb 16, 2023

awoie commented Apr 25, 2023 • edited Loading

awoie commented Apr 25, 2023

awoie commented Jun 5, 2023 • edited Loading

swcurran commented Jun 5, 2023

OR13 commented Jun 6, 2023

swcurran commented Jun 6, 2023

OR13 commented Jun 6, 2023

jandrieu commented Jun 6, 2023

agropper commented Jun 6, 2023 via email

OR13 commented Jun 6, 2023

awoie commented Jun 6, 2023

brentzundel commented Jun 6, 2023

dlongley commented Jun 6, 2023

jandrieu commented Jun 6, 2023 • edited Loading

agropper commented Jun 7, 2023 via email

TallTed commented Jun 7, 2023

agropper commented Jun 7, 2023 via email

awoie commented Jun 7, 2023

awoie commented Jun 7, 2023

TallTed commented Jun 7, 2023

OR13 commented Jun 8, 2023 • edited Loading

OR13 commented Jun 8, 2023

OR13 commented Jun 20, 2023

brentzundel commented Jun 23, 2023

awoie commented Jun 22, 2022 •

edited

Loading

awoie commented Jun 23, 2022 •

edited

Loading

awoie commented Jun 23, 2022 •

edited

Loading

peacekeeper commented Jun 23, 2022 •

edited

Loading

awoie commented Jun 23, 2022 •

edited

Loading

awoie commented Jun 23, 2022 •

edited

Loading

bumblefudge commented Jun 23, 2022 •

edited

Loading

OR13 commented Jun 23, 2022 •

edited

Loading

bumblefudge commented Jun 23, 2022 •

edited

Loading

awoie commented Jun 24, 2022 •

edited

Loading

awoie commented Apr 25, 2023 •

edited

Loading

awoie commented Jun 5, 2023 •

edited

Loading

jandrieu commented Jun 6, 2023 •

edited

Loading

OR13 commented Jun 8, 2023 •

edited

Loading