Normative Reference

[nadalin]

JSON Web Key RFC 7517 (https://tools.ietf.org/html/rfc7517) should be listed as normative

[brentzundel]

where in the data model do you feel such a normative statement would belong?

[nadalin]

In section 6.3,1 where you mention JWKS

[brentzundel]

@awoie I believe you may be the best person to address this issue.

[brentzundel]

@nadalin, if you could clarify this for me, I would greatly appreciate it. Are you suggesting that any JWT encoded VC must normatively use JWKs?

[nadalin]

@brentzundel yes I am since these are standardized today

[awoie]

@nadalin @brentzundel RFC 7515 (JWS) defines the use of JWK as optional. RFC 7519 (JWT) does not talk about JWK at all. The way the VC specification is written allows JWK or any other means for key discovery. This would allow existing JWT parsers to use JWK and allows JWT processors with DID support to implement decentralized key discovery.

kid MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, the kid can refer to a key in a DID document, or can be the identifier of a key inside a JWKS.

I don't see any issue with that.

[nadalin]

@awoie Not understanding your point, as you need to use JWS when signing which is where JWK is defined

[awoie]

@nadalin My point is that the usage of JWK is not mandatory to identify the key to verify the JWS.

According to RFC 7517 (6. Key Identification):

The key employed can be identified using the Header Parameter methods described in Section 4.1 or can be identified using methods that are outside the scope of this specification. Specifically, the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" can be used to identify the key used.

Nevertheless, the VC specification section 6.3.1 Proof Formats allows to use JWK:

Other JOSE header parameters and claim names not specified herein can be used if their use is not explicitly discouraged.

Does this address your concern? If not are you okay to solve this issue by explicitly mentioning in the VC spec that JWK may be used to obtain the key?

[awoie]

Although the VC spec does not require DID and DID Documents, implementers could also obtain the verification key via a DID resolution process. In that case no JWK is required.

[nadalin]

@awoie I prefer to leave DIDs out of this discussion, I would prefer the later by explicit mentioning in the VC specification as I'm not sure your casual reader would pick up on this

[brentzundel]

A PR was raised for issue #485 that explicitly mentions JWKs in the data model.
@nadalin as @awoie has made clear, a normative statement requiring JWKs for JWTs is not supported by the RFCs for JWS or JWT.

I do not believe this data model should go further than those RFCs and require something they do not, as we would like to remain compatible with the JWT and JWS standards.

[nadalin]

@brentzundel JWS RFC requires use of JWK its a normative reference, the VC specification should list JWK

[brentzundel]

@nadalin could you look at PR #485 to see if this addresses your concern? My assumption is that it probably does not and that you are looking for something more.
I propose adding an informative link to the JWT and JWS RFCs so that JWKs can be properly listed.

[stonematt]

WG resolution: https://www.w3.org/2019/04/02-vcwg-minutes.html#resolution08
RESOLUTION: Add non-normative text to the specification that makes an informative reference to the JWK specification and notes that key discovery can be performed in a variety of ways including the use of JWK and DID-based key discovery.

Will close 7 days from today if no new concerns or evidence are raised by then in this issue.

[nadalin]

@stonematt To be clear this section is non-normative so there is set no interop and folks can do and use this section as they please, so people reading the spec can do what they want which means there may not be interop