[Openid-specs-ab] OpenID4VCI: jwt proof-of-possession and exclusivity between 'kid' and 'jwk'

Pedro Felix pedro.felix at curity.io
Tue Apr 25 15:11:20 UTC 2023


Hi,

Thanks for the reply.

I was assuming that *both* 'kid' and 'jwk' would need to the in the JWT header.
- The 'kid' to provide the DID to which the VC subject is bound.
- The 'jwk' to provide the full verification key material, which would
*need to be compatible* with the 'kid'.

Re-reading this section on the EBSI conformance V2 docs
(https://api-conformance.ebsi.eu/docs/specs/credential-issuance-guidelines#requesting-credentials-with-access),
it is stated:

- "Header - kid - string - CONDITIONAL. JWT header containing the key
ID. If the credential shall be bound to a DID, the kid refers to a DID
URL which identifies a particular key in the DID Document that the
credential shall be bound to."
- "Header - jwk - string - CONDITIONAL. JWT header containing the key
material the new credential shall be bound to. MUST NOT be present if
kid is present.REQUIRED for EBSI DID Method for Natural Persons."

So, on one side, it is stated that "If the credential shall be bound
to a DID, the kid refers to a DID URL which identifies a particular
key in the DID Document that the credential shall be bound to." On the
other side, it is stated that "MUST NOT be present if kid is
present.REQUIRED for EBSI DID Method for Natural Persons."

An alternative reading is that only the 'jwk' is sent and the issuer
infers that a Natural Person EBSI DID should be used and computes that
DID from the 'jwk'. In this case I agree that the current wording on
the OpenID4VCI is adequate and the 'kid', 'jwk', and 'x5c' are indeed
mutually exclusive.

In the meanwhile I also noticed that:

- EBSI Conformance v3 (more recent version) is using the 'key' DID
method (see https://api-conformance.ebsi.eu/docs/specs/issue-to-holder-functional-flows#in-time-issuance,
section "Credential Request") and not the 'ebsi' v2 method.
- The 'ebsi' v2 method seems to be deprecated (see drop-down on
https://api-pilot.ebsi.eu/docs/tools/did-resolver where it is stated
"Natural Person example (did:ebsi v2, legacy)".

When using the 'key' method it is enough to send the 'kid' with a DID
URL, because a DID URL using this DID method allows obtaining all the
cryptographic material without any extra information.

In conclusion, it seems that the mutual exclusiveness between 'kid',
'jwk', 'x5c', stated in OpenID4VCI, is indeed adequate. The only
"edge-case" I know would be the 'ebsi' method for Natural Persons, but
that seems to be deprecated in favor of the 'key' method.

Thanks.
Regards,
Pedro

On Tue, Apr 25, 2023 at 2:06 AM Kristina Yasuda
<Kristina.Yasuda at microsoft.com> wrote:
>
> Hi Pedro,
>
> Thank you for the question!
> If I understand correctly, with EBSI DID NP, you will only use jwk JOSE header and will not use kid JOSE header, so there is no contradiction with the spec text there, because those header parameters are to communicate the key material, not the subject's identifier.
> The problem you are raising is how to communicate the actual DID that will be the subject's identifier of a VC. I think we should probably introduce an additional claim in a JWT body for that purpose. I could imagine other use-cases when the key material provided in the header is not equal to the subject's identifier that the wallet would like the issuer to use in the issued credential. With the current design, there will be cases when the subject's identifier will be up to the Issuer to assign - for example, when the key material is provided using jwk JOSE header is subject's identifier a DID like in your case or is it only a vanilla JWT thumbprint or random string managed by the issuer? But maybe I misunderstood the issue.
>
> Best,
> Kristina
>
>
>
> -----Original Message-----
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Pedro Felix via Openid-specs-ab
> Sent: Wednesday, April 19, 2023 1:50 AM
> To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
> Cc: Pedro Felix <pedro.felix at curity.io>
> Subject: [Openid-specs-ab] OpenID4VCI: jwt proof-of-possession and exclusivity between 'kid' and 'jwk'
>
> Hi,
>
> On https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#name-proof-types
> ('jwt' proof type) it is stated that:
>
> - "kid: (...) MUST NOT be present if jwk or x5c is present"
> - "jwk: (...) MUST NOT be present if kid or x5c is present"
>
> From this I conclude that 'kid' and 'jwk' cannot both be present in the header of a proof-of-possession JWT.
>
> However there is at least a DID format where a DID URL present in the 'kid' is not enough to provide all information about the verification key. That example is the EBSI (European Blockchain Services
> Infrastructure) "Natural Person" (NP) DID format - https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/EBSI+DID+Method#EBSIDIDMethod-DIDDocumentforEBSIDIDNP.
> Note how that document states "To be able to validate any DID NP, the holder must always use jwk field in JWT Header to carry the public key materials."
>
> Given this, should the OpenID4VCI be less restrictive regarding the presence of both 'kid' and 'jwk', eventually defining when having both these fields is allowed and the conditions that must hold (i.e. the 'jwk' must be compatible with the 'kid')?
>
> Thanks.
> Regards,
> Pedro
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list