Specify that it is important to validate the `issuer` value about vc-data-model

[awoie]

Also to be clear, I didn't want to normatively define the details of issuer validation in the spec. I wanted to point out that it should be mentioned that the securing mechanism is not responsible for doing that which has an impact on verifiers because now they to do that themselves which is fine.

The other concern was that in order to allow them to do this validation, the securing mechanism needs to return something that was checked they can rely on to hook up their trust framework. IMO, the verified controller would work in that case although I personally have no idea how that would work with X.509 root certificates for instance.

The point on layer violation I tried to make was that if the securing mechanism uses X.509 root certificates, then there is always kind of a layer violation happening because the verifier will need to know the details of the proof anyways. Besides that it is also unclear how that should work with the existing controller documents model.

However, I think returning the verified controller from the securing mechanism and providing actionable language such as the verifier should validate whether the verified controller is trusted, could work for me.

[awoie]

Is the following assumption on layering correct? The issuer value could be different from the issuer of the proof of the securing mechanism. Especially, if there are proof values, e.g., multiple data integrity signatures.

In that case, verifying the securing mechanism allows the verifier to trust the issuer value because they trust the issuer of the proof and the securing mechanism itself. The challenge is to allow the verifier to understand who the issuer of the proof is without having to understand all the details of the securing mechanism and proofs themselves. If the verifier needs to know the details of the securing mechanism, then this would also represent a layer violation.

[awoie]

I think it does not matter where the issuer validation happens there is a layer violation either in the VCDM or in the securing mechanism. Not saying that I have a preference where this layer violation happens but I wanted to say that I cannot see a way without that.

[awoie]

Perhaps it helps to complete the following sentences ...

• As a verifier I run the securing mechanism verification algorithm, so I can rely on (... ?) because the securing mechanism has verified the (...?).
• As a verifier I do (...?) , so I can trust the information in the VC comes from an issuer I trust.

[msporny]

Is the following assumption on layering correct? The issuer value could be different from the issuer of the proof of the securing mechanism. Especially, if there are proof values, e.g., multiple data integrity signatures.

Correct, the issuer value could be different from the verificationMethod expressed in the proof. Usually, there is a way of "following your nose" from the verificationMethod back to the issuer, such as:

verificationMethod -> controller document -> controller of controller document ==> related to issuer in some way. To provide some concrete examples:

verificationMethod	Controller Document	Controller/Issuer
https://issuer.example/#key-1 ->	https://issuer.example/ ->	https://issuer.example
did:example:abcd#key-1 ->	VDR Entry ->	did:example:abcd
did:jwk:yMS0x...MWV ->	ephemeral ->	did:jwk:yMS0x...MWV
did:web:issuer.example#key-1 ->	https://issuer.example/ ->	https://issuer.example

However, you could also have a situation where one entity is signing on behalf of another entity, such as in a university registrar signing a diploma on behalf of one of their colleges, where the issuer is the college, but the registrar is the signer:

verificationMethod	Controller Document	Controller
did:web:registrar.example#key-1 ->	https://registrar.example/ ->	https://registrar.example

... but then the issuer is the "College of Engineering" (did:web:engineering.example). In this case, one's ecosystem might fall back to a trust list, where they don't feel the need to check the verificationMethod against the issuer property, but rather they check it against another list of trusted DIDs or URLs (that will then refer to controller documents that list the key that was used in the proof).

This is why there is not /one/ algorithm for checking these things -- they can be ecosystem dependent. However, what we could do is return all of the information necessary to do the validation (such as the controller document and the controller for a verification method) from the securing mechanism interface.

If the verifier needs to know the details of the securing mechanism, then this would also represent a layer violation.

We can probably just return the controller document and the controller back from the securing mechanism verification interface so that those details can be sent on to a validation check (that the verificationMethod and the issuer and the controller line up as expected, which might require the use of a trust list (or not)).

I think it does not matter where the issuer validation happens there is a layer violation either in the VCDM or in the securing mechanism.

The approach above doesn't create a layer violation, IMO. That is because a "controller document" isn't specific to a securing mechanism, it's just "information about an entity in the world", and the controller of that document is just information contained in that document. The validation could do the validation check: "Is the issuer the same as the controller, if so, everything is good... if not, check against trust list using business logic."

Perhaps it helps to complete the following sentences ...

As a verifier I run the securing mechanism verification algorithm, so I can rely on (... ?) because the securing mechanism has verified the (...?).

As a verifier I run the securing mechanism verification algorithm, so I can rely on the data that has been secured because the securing mechanism has verified that no tampering has occurred with the data .

As a verifier I do issuer validation, so I can trust the information in the VC comes from an issuer I trust.

We do have a section on issuer validation here:

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

I'll see if I can elaborate more in that section as well as the interface between the VCDM and the securing mechanisms.

[msporny]

PR #1393 has been raised to address this issue. This issue will be closed once PR #1393 has been merged.

[iherman]

The issue was discussed in a meeting on 2023-12-20

• no resolutions were taken

View the transcript

4.4. Specify that it is important to validate the issuer value (issue vc-data-model#1386)

See github issue vc-data-model#1386.

Brent Zundel: 1386 Important to validate issuer, Oliver Terbu issuer validation; Open PR, not clearly on a path towards consensus.
… not clear that is isn't going to happen.

Manu Sporny: Mike the change you want. Is that proof needs to be removed by the alg.
… The way DI works is that proof options are secured too.

Michael Jones: don't want to return JWS parameters and proof?

Manu Sporny: any info that is secured gets returned back.
… might get us back into layer violation territory.

Dave Longley: We do have two different types of mechanisms (i) envelopes and (ii) embedded proofs. These do behave differently.

David Chadwick: Take a credential -> VC -> credential you don't have the proof.

Michael Jones: Aligned with DavidC. More of a layer violation if you get different result.
… request to David a change to PR asking for this.

Manu Sporny: This PR is about issuer validation, the thing you are requesting is something else.
… Doesn't have to do with proof being returned.

Dave Longley: Okay to return proof. Valuable to implementers. Considerations for multi-proof. And digital wallets.

Brent Zundel: encourage to the PR and what its trying to request.

David Chadwick: I have submitted issue #1399.

Dave Longley: proof is in the credential, that's what embedding is though.

Michael Jones: it is not independent. See the text of the PR. This interface returns information in the credential.

[msporny]

I wanted to point out that it should be mentioned that the securing mechanism is not responsible for doing that which has an impact on verifiers

Acknowledged, the specification currently doesn't state that it is the securing mechanism's job to verify x509 certificates (or certificate chains, or crit values, etc.)

The other concern was that in order to allow them to do this validation, the securing mechanism needs to return something that was checked they can rely on to hook up their trust framework. IMO, the verified controller would work in that case although I personally have no idea how that would work with X.509 root certificates for instance.

The verified controller is now returned by the securing mechanism verification algorithm interface (via PR #1393).

The specification is currently silent on what one does with X.509 certificates (and all the corresponding complexities when X.509 is pulled in). The specification does allow for other information to be passed through the interface, so it's possible for implementations to provide other interfaces for X.509 (or use did:jwk, or did:x509, or whatever mechanism they so choose to implement). That is, we don't limit how X.509 can be used, but we don't define it either (we would need more implementation experience before doing so).

The point on layer violation I tried to make was that if the securing mechanism uses X.509 root certificates, then there is always kind of a layer violation happening because the verifier will need to know the details of the proof anyways.

Yes, that is true. X.509 introduces a number of complexities into the processing model. That said, it's not impossible to use with VCs (Digital Bazaar has needed to implement it in our interfaces, for example -- but we would feel uneasy about standardizing that interface at the moment given how experimental it is).

Besides that it is also unclear how that should work with the existing controller documents model.

did:jwk or did:x509 documents returned as a controller document could work, as could HTTPS-based links to X.509 certificates for the controller. It is also possible to provide an alternate interface than the most basic one that's provided.

However, I think returning the verified controller from the securing mechanism and providing actionable language such as the verifier should validate whether the verified controller is trusted, could work for me.

Yes, that is what we did in PR #1393.

PR #1393 has been merged, closing.