Skip to content

The `id` property of UNTP Credential's `credentialSubject` is being set incorrectly

Impacted Sections

List UNTP specification page(s) that are impacted by this issue. For example:

Issue Description

Summary

The credentialSubject.id property is optional in the spec, but if present, should be the id of the subject about which the claims are made [ref]. If not present, the verifier can use other properties to identify the subject (product property in our case). Steve mentioned this has been brought up recently as a matter of urgency.

I'm recommending the short-term point fix of ensuring the credentialSubject.id property is not present in our models at all (this may be a post-jargon fix or something that we can chat about in Jargon, - I'll create a separate issue in Jargon for that).

Longer term, we may want to consider how we can move back towards allowing the id to be present, but be the id of the subject about which the claims are made with the extra claim properties in the same object, but it's not clear to me how we can do this with Jargon models that validate. Details below.

Invalid JSON-LD for 0.5.0 models

The 0.5.0 models defined entities such as Product in UNTP-core (see 0.5.0 UNTP core) and then inherited and extended those entities to add claim information in the credential domain, such as the 0.5.0 DPP domain, which also defines a Product entity, inheriting from the core one, and adding extra claim properties (conformityClaim, traceabilityInformation etc.). But other domains also inherited and removed properties, such as the Product defined in the 0.5.0 DCC domain while adding other properties (IDVerifiedByCAB).

This lead to invalid JSON-LD, among other reasons, because properties were being redefined when unset/removed.

Valid JSON-LD for 0.6 models - but an extra id

To enable a credential to both identify the subject of the claims as well as list the claims themselves, with 0.6.0 we moved towards a composition model, where the credentialSubject is composed of the subject (eg. product) and the claims made about that subject, together forming a separate object type. Such as the ProductPassport entity of the 0.6.1 DPP domain

ProductPassport:
  ^id:URI
  product:untp.Product
  granularityLevel:Code(granularityCode)
  conformityClaim:untp.Claim[]
  emissionsScorecard:untp.EmissionsPerformance
  traceabilityInformation:TraceabilityPerformance[]
  circularityScorecard:untp.CircularityPerformance
  dueDiligenceDeclaration:untp.Link
  materialsProvenance:untp.Material[]

It is composed of the product and the claims, so there's no more need redefine what a Product is to be able to list claims. This works, and is valid JSON-LD, but as above, we needed to include the extra id there so that Jargon treats this entity as "Blue" entity in Jargon. The comments I'd left in the jargon definition imply that without it, Jargon will re-define the credentialSubject differently to the VC context, but I suspect that comment is hung-over from when we weren't omitting the credentialSubject from our own context definitions explicitly, so it might be as simple as removing the id and ensuring the contextOmit is set for credentialSubject. I'll test this with a change.

General confusion over the credentialSubject for developers of Verifiable Credentials

It turns out that we're not the only developers who are confused about this mixed nature of credentialSubject (that is, is it the subject of the claims, or is it the claims themselves about the subject). The VC spec seems to mix the two (for reasons I'll get to below) and there have been a number of issues that have been raised about this exact confusion, you can start with 1130 or 1445 and work back from there in the comments to see how often it's come up and been re-explained.

I'm not sure whether I'm summarising the confusion 100% accurately, but it appears to be a tension between developers thinking in terms of objects with types, and the spec authors keeping the generality of graph data (which is what json-ld is). So, for the developer, it doesn't make sense for the credentialSubject to use the id of a Product (ie. it IS A product), but add a bunch of claims to that Product object as if they are attributes of the Product itself, which they aren't (necessarily). We can't then validate that the object is a Product or matches a product schema necessarily. BUT, from a graph/RDF point of view, all properties are just relationships to the subject (subject, property, value triplets) that form a graph, as explained under the Claims section of the spec. So from a VC/JSON-LD/RDF point of view, there is no issue adding claims in the same object that has the id of the Product.

So it may be that longer-term, we should move back towards this view, where the credentialSubject has the id of the subject of the claims, together with other claim data, without being a Product (or type of that data) necessarily - somehow. Whether or not we can do this with Jargon, or whether it's worthwhile if the current composition works, I'm not sure yet, that requires further thought and investigation, but certainly seems to sit more neatly with what @steve.capell originally planned, I think.

What is clear is that the current situation where we have a credentialSubject.id present but it is not the id of the subject of the claim, is incorrect. But as above, there is a smaller fix we may be able to achieve for that.

I Have

  • Added the relevant labels (e.g. WG-Adoption, WG-Conformity, WG-SupplyChain, WG-Technical, WG-Steering, etc.).
Edited by Michael Nelson