Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: use did:jwk for testing dids and vc-jwt in the vc-jwt-test-suite #10

Open
OR13 opened this issue Sep 6, 2022 · 7 comments
Open

Comments

@OR13
Copy link
Collaborator

OR13 commented Sep 6, 2022

  • Provide example key pairs
  • Provide example DIDs
  • Provide example VC signed by DIDs
  • Provide example VP signed by DIDs
@bellebaum
Copy link

The VC-data-model spec was very explicit about DIDs not being a dependency of VCs. Can the test suite be written in a way which nonetheless does not depend on a correct implementation of did:jwk?

@OR13
Copy link
Collaborator Author

OR13 commented Sep 12, 2022

@bellebaum yes, assuming iss / kid -> publicKeyJwk is happening correctly.

The point of using did:jwk would be... that its trivial to show how this mapping should be done.

The problem is not explaining sufficiently how you get verification material...

I propose we cover that concretely for DIDs, URLs, and anything else.

@OR13 OR13 changed the title Proposal: use did:jwk for test suite. Proposal: use did:jwk for testing dids and vc-jwt in the vc-jwt-test-suite Sep 12, 2022
@David-Chadwick
Copy link

Our initial implementation tried to avoid using did's altogether. The Issuer uses an X.509 PKC of type domain validated, so that the verifier can make a TLS connection to the domain and pick up the X.509 PKC from there (e.g. in PEM format). The iss is set to the domain name. Registering an IANA well-known for this page would take the verifier straight to the right web page.
Alternatively if using OIDC4VCI, the verifier can pick up the metadata of the issuer from its OIDC well known page, and from there the jwks uri parameter in order to get the public key from there.
In both cases the kid could be set to did:jwk or the prefix from draft-chadwick-oauth-jwk-uri-00.txt to avoid the use of did's completely. (The method is the same, base64URL encode, but the URL prefix is different that's all).

@OR13
Copy link
Collaborator Author

OR13 commented Sep 13, 2022

To be clear, I am not proposing the test suite only cover DIDs... I am proposing the test suite cover ALL legal "issuer" identifier formats.

I am strongly opposed to "verify with this public key" without describing "how to get this public key".

@Sakurann
Copy link

I have nothing against using did:jwk - it should be an option that would have the most utility to the testers while being the least controversial.

just to document... a way to avoid using DIDs would be, for the issuer provide a certificate (how to get this key becomes just use this key) and for the Holder, in the VC pass the pubKey by value using cnf JWT claim defined in RFC7800, and use jwk Header in VP. but I am not sure how widespread and useful this way would be for the testers.

@OR13
Copy link
Collaborator Author

OR13 commented Jun 30, 2023

@Sakurann we can add tests like you suggest after we follow up on w3c/vc-jose-cose#111

@OR13
Copy link
Collaborator Author

OR13 commented Jun 30, 2023

I started work on a test suite here: https://github.com/transmute-industries/vc-jwt-test-suite

@OR13 OR13 transferred this issue from w3c/vc-jose-cose Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants