w3c / vc-test-suite

Verifiable Credentials WG Test Suite
https://w3c.github.io/vc-test-suite/
BSD 3-Clause "New" or "Revised" License
69 stars 39 forks source link

vc-test-suite #95

Open nadalin opened 4 years ago

nadalin commented 4 years ago

Trying to figure out the test-suite and be able to run this on my implementation, I see the follow statement "1) encoded as standard JOSE header parameters, 2) encoded as registered JWT claim names, or ..."

I have no idea what "registered" means and where would one register and why I have to register my JWT claims?

nadalin commented 4 years ago

I don't understand this test

" verifiable credential ... To encode a verifiable credential as a JWT, specific properties introduced by thisspecification MUST be either ...3) contained in the JWS signature part... If only the proof attribute is used, the alg header MUST be set to none."

Why MUST the alg header be set to "none" does not make sense

David-Chadwick commented 4 years ago

Trying to figure out the test-suite and be able to run this on my implementation, I see the follow statement "1) encoded as standard JOSE header parameters, 2) encoded as registered JWT claim names, or ..."

I have no idea what "registered" means and where would one register and why I have to register my JWT claims?

This refers to the IANA registered JWT claim names. These are the only ones for which encode/decode transformational rules are defined in the VC data model.

David-Chadwick commented 4 years ago

I don't understand this test

" verifiable credential ... To encode a verifiable credential as a JWT, specific properties introduced by thisspecification MUST be either ...3) contained in the JWS signature part... If only the proof attribute is used, the alg header MUST be set to none."

Why MUST the alg header be set to "none" does not make sense

This is because a VC could be signed by a JSON-LD signature, or a JWS or both. The proof attribute is used for the former and is omitted for JWS. In the case being referred to, there is a JSON-LD proof with no choice of algorithm, and no JWS, but a JWT is still being created. So the alg header is set to none.

nadalin commented 4 years ago

@David-Chadwick Why do the claim names have to be registered as it's not at all clear in the test that this only applies to the claims that are transformed. It's not also clear from the specification either that this is the case

nadalin commented 4 years ago

I don't understand this test " verifiable credential ... To encode a verifiable credential as a JWT, specific properties introduced by thisspecification MUST be either ...3) contained in the JWS signature part... If only the proof attribute is used, the alg header MUST be set to none." Why MUST the alg header be set to "none" does not make sense

This is because a VC could be signed by a JSON-LD signature, or a JWS or both. The proof attribute is used for the former and is omitted for JWS. In the case being referred to, there is a JSON-LD proof with no choice of algorithm, and no JWS, but a JWT is still being created. So the alg header is set to none.

And what is the JWS Signature Value set to ?

nadalin commented 4 years ago

One of the JWT tests says "alg MUST be used for RSA and ECDSA-based digital signatures" the specification says it must be set, so test case should be just test for a registered alg value under all cases.

brentzundel commented 4 years ago

As this issue relates to the test suite, it would be best to raise this issue there. https://github.com/w3c/vc-test-suite

burnburn commented 4 years ago

In 20 Aug 2019 call:

RESOLVED: The WG believes that issue w3c/vc-data-model#713 is a question related to the test suite and the issue belongs in that repository and this will be deferred until another group picks up the specification and associated test suites.

nadalin commented 4 years ago

@burnburn This has to deal with implementing the specification and testing the specification, thus I believe it belongs here

TallTed commented 4 years ago

@nadalin - You have suggested that a change should be made to a test case, not to the specification. Thus, your issue belongs on the test suite, where that test case is found, not on the specification.

nadalin commented 4 years ago

@burnburn Someone with admin can transfer this issue over so as not to loose the thread

burnburn commented 4 years ago

Attempting to use GitHub's new transfer feature . . .

dmitrizagidulin commented 4 years ago

@mirceanis or @awoie - do you have any comments on this?