Open alenhorvat opened 1 year ago
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
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: https://github.com/openid/OpenID4VP/issues/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: https://github.com/w3c/vc-test-suite/issues/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.
Good morning Alen, Thank you very much for your valuable comments. Below some relevant information:
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.
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:
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!
Good afternoon Alen,
Could I ask you to confirm if I have correctly understood your initial thinking on the bulleted list that you provided?
Sorry: I did want to have all the text in one comment, but somehow I failed. Will keep going:
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?
No worries :)
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.
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!