Isn't example 1 incomplete?

[iherman]

(Minor issue)

The structure of Example 1 is, roughly, as follows:

{
    ...
    "id": "http://example.edu/credentials/3732",
    …
    "credentialSubject" {
        "confidenceMethod" : [{
            "type": "BiometricPortraitImage",
            …
        }, {
            "type": "JsonWebKey"
            …
        }
        …
        }],
        "degree" : { … }
    },
    "proof" : { … }
}

Shouldn't there be an id value set for the credential subject, identifying the person who got the degree? I know the example is a skeleton only, but it does belong to the essence of the confidence problem that the extra confidence methods refers to that person...

[dlongley]

Shouldn't there be an id value set for the credential subject, identifying the person who got the degree?

No, a person is intentionally not given a unique identifier for privacy purposes. In a presentation, the confidence method can be selectively disclosed (when permitted by the cryptographic securing mechanism).

The confidence method is associated with the subject whether or not that subject has an identifier (because it is a property of the JSON object that expresses the subject, per JSON-LD rules). The confidence method itself may (or may not) include identifiers or sub-JSON objects with identifiers that are associated with a person, device, key, etc.

[iherman]

Ok, I understand that the example may be correct spec-wise. Stand corrected. However, I maintain that it would be better to have the id property in this example. I checked the VC spec itself: the vast majority of the example have an id value, which is the correct choice, in my view, from a didactical point of view...

[amir-hameed-mir]

I think @dlongley has a valid point with respect to privacy and how RDF/JSON-LD graphs link entire structure, how about an 'id' for the method specific identifier like hardware module or a biometric template id not the human subject identifier.

[dlongley]

+1 to @amir-hameed-mir's comment: We should put IDs in the selectively disclosable confidence method(s) somewhere, not on the person (credential subject here) -- even for didactic purposes, because we don't want to also accidentally teach the wrong lesson of putting IDs in personal VCs where they shouldn't be.

[jandrieu]

@dlongley I think we're conflating two different kinds of IDs

An ID for the subject is not an ID for the confidenceMethod.

Personally, I don't agree that IDs shouldn't be in personal VCs.

IDs in personal VCs for the subject allow the rotation of subject key material without invalidating the credential. DIDs for the subjects of long-lived credentials like degrees is a perfectly legitimate use case, especially when correlatable information such as a legal name is already included in the claim. It's not the anti-pattern that some ZKP enthusiasts claim.

Yes, in many cases we want to architect privacy preserving techniques like anonomized, single-use tokens. Those are different use cases. And for those, you don't want IDs.

Perhaps more importantly, from a correlation perspective, there is no difference between using a DID as an ID in a credentialSubject property and using a DID in a VerificationConfidence method, which I understand you support.

Are you now saying that we shouldn't have DID-based confidenceMethods?

[dlongley]

@jandrieu,

IDs in personal VCs for the subject allow the rotation of subject key material without invalidating the credential. DIDs for the subjects of long-lived credentials like degrees is a perfectly legitimate use case, especially when correlatable information such as a legal name is already included in the claim. It's not the anti-pattern that some ZKP enthusiasts claim.

Yes, in many cases we want to architect privacy preserving techniques like anonomized, single-use tokens. Those are different use cases. And for those, you don't want IDs.

Perhaps more importantly, from a correlation perspective, there is no difference between using a DID as an ID in a credentialSubject property and using a DID in a VerificationConfidence method, which I understand you support.

Are you now saying that we shouldn't have DID-based confidenceMethods?

No -- but I think what might be missing in the logic leading to that proposed conclusion/question relates to selective disclosure. When revealing claims about a subject (any subject in the graph), if that subject has an ID, its ID will be revealed along with whatever claims are revealed (to avoid conflation attacks and the representation of a claim is subject_id => property => object/value). (Side note: This is for the simple selective disclosure schemes we have today; there are more complex selective disclosure schemes that could add more flexibility but at significantly more complexity cost with additional ZKPs to avoid those conflation attacks, etc.).

In other words, if we put an ID on a node in the graph that represents a person, then selectively revealing any information about that person also reveals the ID. This isn't necessarily a problem for some use cases (as you mention, if the correlation is already there, then there's no new risk). However, it would reduce the utility of the VC for other use cases. A VC that could have previously been used with an unlinkable presentation to reveal only a single attribute of that person -- can now no longer be used for that use case.

Again, maybe that's fine -- and we should tell people to use some other VC that is modeled differently to achieve that unlinkable use case -- however, we should acknowledge that loss/lack of functionality. If, instead, everything is self-contained within a confidence method, we can do the unlinkable presentation OR use the confidence method with the same VC (each approach for different use cases).

[iherman]

This was discussed during the vcwg meeting on 02 June 2026.

View the transcript

w3c/vc-confidence-method#32

JoeAndrieu: Issue 32 started with a question - does this example need an id within the doc.

JoeAndrieu: Ivan asked whether the Credential subject needed an ID

JoeAndrieu: Sometimes you don't want an ID for privacy purposes.

JoeAndrieu: Dave also brought up the issue - he talked about the wrong lesson of putting personal IDs in a VC. A VC might have other PII in there, so you're not disclosing anything rextra.

JoeAndrieu: We are aware that we're creating points of correlation. It's necessary. Maybe we should be in something about selective disclosure.

ivan: I'm looking for some consistency across all our docs. In our other docs, we always have an ID for the subject. So it looks as if it's mandatory. Maybe we need to go back to the VCDM spec

ack

: I think that Dave's probably talking about is deep in the technical weeds. If you put a subject ID and make it selectively disclosable, you're going to be giving at out every time. Might be an issue for long-lived creds.

: Businesses and things have different privacy needs than people.

: If I put an ID for the credential subject and I allow the country of residence to be SD, then you'll give away the ID every time.

cstoecker: From a privacy POV, culture matters. Some people don't care about their privacy. Others do of course.

cstoecker: Diff between employer ID and natural person ID and have different privacy expectations.

ivan: This sounds like a VCDM issue, so I think the issue should e transferred to the VCDM repo. It's nothing to do with confidence method.

<Zakim> JoeAndrieu, you wanted to ask about selective disclosure (backwards)

JoeAndrieu: It's my responsibility and until I move it ;-)
… I like the on behalf of pattern
… When someone is acting on behalf of someone else
… That often happens with employees. We don't want everything about an individual to be mixed up with their life as an employee.

JoeAndrieu: technically, Manu was talking about BBS. Others might have a different SD method. With BBS, the ID must be disclosable

JoeAndrieu: I hadn't realised that the subject ID would be revealed if something below it was.

denkeni: I agree that this ID issue should be transferried to VCDM
… especially as it's already in wide use. We prefer the device binding. But what does it solve? Do we need an ID for everything? We're trying to increase the confidence in an VC

JoeAndrieu: Thanks - this was really good engagement

ack

: Great work on the spec so far - thanks to Scott, Denken and Joe. How far away from CR are we?

: Can we get a version 1 out fairly soon?
… And then come back and add in other features that might take longer to work through.

: Maybe 6 months for the image. Biometric later.

JoeAndrieu: 6 months sounds doable?

JoeAndrieu: We need to get the original draft spec text for what we think is simple before we get to what's complex

ivan: The problem I see is horizontal review as we mentioned earlier

JoeAndrieu: Every one of these methods needs a threat model. a11y will ask questions. Maybe not i18n. I suggest the horizontal review should begin soon.

---