JAdES/JAdESCC - additional protected/unprotected claims

[alenhorvat]

Hi,

with the evolution of new standards, formats (e.g., Decentralised identifiers, DID Documents, Verifiable Credentials) and decentralised PKI, we're trying to establish an additional way of signing key and signer information attestation and validation (next to the existing x509).

This requires additional protected/unprotected claims.

It seems that JAdESCC has a strict validation of etsiU parameters (I guess same applies for the protected header parameters).
Is there a way to include additional claims to protected/unprotected header in a conformant way or would that require extension of the JAdES standard?

Examples: adding signer attributes as W3C Verifiable Credentials (certified signer attribute supports only x509 format), or including additional information in the unprotected header (either disclosed claims in case of selective disclosure, revocation information in a different format, issuer accreditations, etc.)

Thank you!

[jccruellas]

Dear Alen,

I am currently on holidays. As soon as I come back from them (beginning of September), I will properly react to your comments

Best regards
Juan-Carlos

[alenhorvat]

Hi. Here's a related proposal in the OID(C) for transporting verifier and issuer related attributes in the header in an ETSI-compliant way: openid/OpenID4VP#36
We've tested the approach by adding non-x509 claims to the protected header and is compatible with JSON Schema and with the JAdESCC; the CC returns a warning, so we don't know whether this would be an issue with other production implementations. Is the processing rule: ignore the processing if the claim is not understood or consider the signature invalid if not understood?

Here's also a short overview of a JSON (W3C VC)-based trust model: https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/Issuers+trust+model+-+Accreditation+of+Issuers and related JSON schemas: https://code.europa.eu/ebsi/json-schema/-/tree/main/schemas/ebsi-accreditation

A related question: w3c/vc-test-suite#134

We're trying to follow the best architecture design practices (not mixing different contexts) which is also reflected in the design of JAdES.

Signer attributes provide a nice way to transport additional credentials about the signer. W3C Verifiable Credentials allow to add issuer-related claims to the payload since issuer property is an object and is easily extensible.

We seek opinion of experts in the W3C and this WG on what is the best way to transport additional issuer related credentials. In all our designs we're assuming that issuer != signer to avoid mixing of different contexts when that's actually the case (e.g., issuer may delegate the signing to an authorised 3rd party)

A similar example appears in delegated authorisation model: https://code.europa.eu/ebsi/json-schema/-/tree/feat/ebsiint-7198/schemas/ebsi-authorisation

Thank you and I hope I didn't stretch the question too much.

[jccruellas]

Good morning Alen,
Thank you very much for your valuable comments. Below some relevant information:

1. ETSI ESI TC, the committee in charge of standardization of JAdES, conducted a remote meeting yesterday. I presented your initial comments and proposed to ammend JAdES so that the text makes it clear that other header parameters than the ones specified in RFC 7515, RFC 7797, and JAdES itself may be added in both the Protected Header and within the etsiU array within the Unprotected Header.
2. This change will not require any change in the JSON schema for header parameters within the Protected Header, but it will require some change in the JSON schema for the etsiU array and its constituents. Actually, I would say that the current JSON Schema of etsiU allows for incorporating any content base64url-encapsulated (although the requirements in text does not allow it). So, apart from changing the text, some change will have to be implemented within the JSON schema of etsiU for clear JSON incorporation.
3. You somehow put on the table the possibility of including as signer attribute W3C Verifiable Credentials. Note that srAts header parameter has the component signedAssertions. Wouldn't conceptually be OK to include W3C Verifiable Credentials as signed assertions?. If instead you consider that W3C Verifiable Credentials are conceptually closer to X.509 attribute couldn't W3C Verifiable Credentials be incorporated within the component otherAttrCert? The text could be amended to include some note mentioning explicitly these credentials as one of the potential contents of this component. Which option would you consider more appropiate?. I would appreciate if you let me know your views.
4. ESI agreed in a calendar for having these changes ready. It should not take long time to get a new draft. Obviously, the draft has to be discussed within ESI and approved by its members.

As for the JAdESCC, indeed, the warning that it throws in the case you mention, assuming that I have correctly understood it, just signals that JAdESCC is unable to understand the header parameter, nothing else. Please also note that JAdESCC does not say whether a signature is valid or invalid, it only says whether the signature is conformant or not to the JAdES specification. A signature may be conformant but be invalid (certificate expired for instance). Validation of AdES signatures is standardised in ETSI EN 319 102-1.

Finally, I will take a look to the references that you mention in your last comment as soon as possible, and keep you posted on the evolution of JAdES spec. ETSI has strict rules on the distribution of draft documents (in general drafts are managed internally by the committees, and only in certain occassions it is allowed to make them public for getting comments from stakeholders).

Once again, thank you very much indeed for your very valuable comments and interest in both JAdES spec and JAdESCC tool.

[alenhorvat]

Good morning @jccruellas. Thank you for a swift response.
That's excellent news.

wrt point 3 (please note that the different credentials come from different standards/projects):
Credentials can carry different information:

• signing key attestation (close to x509)
• signer identity information (close to x509)
• issuer accreditations (right to issue the given document)
• other credentials, such as delegated authorisations, as mentioned above
• entity statements as per OpenID Federation (this is close to key attestations and/or issuer accreditations);

We can put the signer-related information in the signedAssertions.
For issuer-related information placement I'll wait for a feedback from W3C. I must have missed otherAttrCert property. I'll put this option to the list of possibilities for sharing issuer related information.

Thank you for the great work!

[jccruellas]

Good afternoon Alen,

Could I ask you to confirm if I have correctly understood your initial thinking on the bulleted list that you provided?

[jccruellas]

1. I understand that you are OK in including signing key attestation (close to x509), and signer identity information (close to x509) in signedAssertions. Am I correct?

[alenhorvat]

1. Yes

[jccruellas]

Sorry: I did want to have all the text in one comment, but somehow I failed. Will keep going:

2. Issuer accreditations: you are waiting for W3C feedback, but you do not see a semantically suitable component in srAts where to place this, as this is a component linked to signer, not to the issuer of the VC. So, you would very likely need a new signed header parameter for this.
3. Other credentials (like delegation). Am I correct if I asume that these are credentials for the signer, and that therefore signedAssertions could work?
4. entity statements from OpenID..here I have some problem, because you mention close to key attestations and/or issuer accreditations. Can these attestations be attestations for the Issuer and/or for the signer depending on the needs? If so, attestations on the signer could go into signedAssertions, and attestations on the issuer should go in this missing header parameter for placing information of issuer.

Am I understanding more or less what you mean to say?
Am I correct if somehow what seems to be missing is a placeholder for signed assertions on an entity which is not the signer (but on the issuer) and that the signer could need to incorporate in the signature?

[alenhorvat]

No worries :)

2. Correct. Issuer-related information could also go in the otherAttrCert. Issuer is one possible role; Verifier can be another one, so a generic placeholder like otherAttrCert plays nicely.
3. Yes, delegation here is related to the signer. srAts would work for this case.
4. Entity statements are protocol specific. The OIDC Fed WG is inclined towards introducing a new claim named trust_chain. But based on the previous two points, yes, it can be either srAts or otherAttrCert (or if there's a new claim).

Yes, your understanding is correct and thank you for the clarification and confirmation.
So the missing assertion is like University Accreditation stating that the org. can issue a given type of a Credential. In PKI models, this information is usually implicit or is stated in the x509 v3 extensions (we see this pattern in mDL, where key usage determines the "type" of the credential the issuer can issue). However, this pattern has some limitations. Hence an approach, either via otherAttrCert or via a new claim, would be more appropriate.