search

KantaraInitiative / consent-receipt-v-next

Collection point for feature requests for Consent Receipt spec family
Other
13 stars 2 forks source link

Allow different kind of JWT signing besides RS256 #23

Open crtahlin opened 5 years ago

crtahlin commented 5 years ago

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Working with Ethereum blockchain, usage of RS256 for signing is not possible - therefore, the JWT token cannot be generated in a decentralized way. If signed JWT is a requirement, other methods should be allowed (Ethereum private key signing).

Describe the solution you'd like A clear and concise description of what you want to happen.

Allow ECDSA for signing the JWT token.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

We are using an alternative, where the RSA signed JWT is additionally signed by Ethereum private keys of both parties. (Making the RSA signing of the JWT superflous?)

Additional context Add any other context or screenshots about the feature request here.

LALeVasseur commented 4 years ago

Crt: why is ECDSA not regarded as supported? Spec doesn't seem to prohibit a particular algorithm:

672 The transmission of a JSON Consent Receipt should use the following specifications: 673 JSON Web Token (JWT) [RFC 7519] 674 JSON Web Encryption (JWE) [RFC 7516] 675 JSON Web Signature (JWS) [RFC 7515]

LALeVasseur commented 4 years ago

Should the spec be updated to support interoperability (of the consent receipt) by specifying a list of acceptable algorithms? (OpenID spec example.) Was there ever an intention to create consent receipt profiles for specific industries?

This could be a new specification.

crtahlin commented 4 years ago

@LALeVasseur You are probably right, that another algorithm is not specifically "forbiden" in the spec. We took as a reference the implementation at http://api.consentreceipt.org/doc/ , which uses RSA (aka RS256).

If more are indeed allowed, I would suggest listing the choices allowed in the spec, yes. (in our case, we are building open source solutions and would like to cover what is expected to be used.) So, maybe this issue should be renamed "Specify allowed signing algorithms".

That said, our use case (on the blockchain / decentralized storage) is to sign the consent receipt by both parties, not only for tamper protection (as I understand the purpose of signing the JWT), but also to establish that the requester of consent and giver of consent are parties in possession of a certain key. So the signing of the JWT is actually superfluous in this scenario, and it should be allowed for the JWT to not be signed, I guess ... Anyway, we had some specification clarification questions about this which are still open : https://kantarainitiative.org/confluence/display/infosharing/Specification+Clarification+Questions ; but I guess these are