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

Accept RSA Signing Algorithms #88

Closed
vincentkelleher opened this issue Feb 12, 2024 · 6 comments
Closed

Accept RSA Signing Algorithms #88

vincentkelleher opened this issue Feb 12, 2024 · 6 comments

Comments

@vincentkelleher
Copy link

Hi 👋

In our goal of supporting OIDC4VCI/OIDC4VP protocols in the Gaia-X ecosystem we based ourselves on your OID4VCI lib which is very easy to get up to speed with thanks to the documentation and examples.

Our Use Case

Gaia-X Clearing Houses currently need an EV SSL certificate in order to be able to issue compliance verifiable credentials. Those certificates are mostly delivered with RSA signing algorithms and are costly so we wanted to try using those with your library to avoid having to ask members to buy new EV SSL certificates with EdDSA, ES256 or ES256K signatures.

The Issue

We noticed that you implemented a closed list of algorithms with the Alg enum and that a check is done to make sure the credential request proof uses a supported algorithm. The following error is raised :

image

I have tried adding the PS256 algorithm we use to the Alg enum and everything works fine 👍

Thoughts

As jwtVerifyCallback is the method that's depending on the signing algorithm and that this callback is defined by the developer using the library, hence its responsibility, wouldn't it be possible to remove this check and just leave it to the implementer ?

If not, would it be possible to add widely used algorithms to the Alg enum or even leave the implementing developer define it in the VcIssuer metadata ?

It would be my pleasure to exchange with you about this 😊

@nklomp
Copy link
Contributor

nklomp commented Feb 12, 2024

Hi @vincentkelleher Thanks for the nice words. Actually the OID4VC libs need an awful lot of work on the doc side, but given everything is changing below our feet, we only expect to do that over the next few months. Good to hear you can find your bearing though.

Yeah you bring up some valid points. The primary reason is to protect the developer a bit from making mistakes by implementing an identifier that is not officially recognized, whilst also providing strong type support. At the same time I agree that we should not really be a barrier for new algorithms being implemented, since we do not make many assumptions about signing to begin with. Probably we should just extend the mechanism to also accept strings next to the enum. Or better yet move to a union type of string literal values as well as the string type. Then we have the best of both worlds. An IDE doing autocompletion/suggestions, but also allows having new Algos.

BTW happy to have short introduction call to see if and how we can help to begin with, given we also are working in certain Gaia-X related projects

@nklomp
Copy link
Contributor

nklomp commented Feb 12, 2024

In the mean time we will add PS256 to the Alg enum, but that would be followed by refactoring the Alg code.

@vincentkelleher
Copy link
Author

Hi @nklomp,

Thanks for your answer 👍

If you want I can produce the merge request with the changes, the only thing I'm not confortable with is that I didn't find any tests covering the parts I mentioned like the statement that throws the algorithm error. I don't know what the guidelines are in this project about testing.

Furthermore, I like to base myself on the Jwt.io Libraries page to list all the algorithms to be supported. It lists all the main algorithms on the market to date.

I would be delighted to have an introduction call with you 👍 You can contact me at vincent.kelleher@gaia-x.eu to set up that call.

@nklomp
Copy link
Contributor

nklomp commented Feb 15, 2024

Sorry for the late reply.

If you would be happy to provide the PR that would be most welcome. Regarding the test coverage; we need to up that for this library indeed. We will be doing some refactoring and documentation work soon, now the specs are stabilizing a bit more; that is also the moment in which we will up coverage significantly. So ideally you would provide some increased test coverage for it, but we are okay at this point if that isn't the case.

Let me reach out after next week to setup a call to see if and where we can help out eachother.

vincentkelleher pushed a commit to vincentkelleher/Sphereon-OID4VCI that referenced this issue Feb 21, 2024
…ess, refs Sphereon-Opensource#88

Signed-off-by: Vincent Kelleher <vincent.kelleher@gaia-x.eu>
vincentkelleher pushed a commit to vincentkelleher/Sphereon-OID4VCI that referenced this issue Feb 21, 2024
…ess, refs Sphereon-Opensource#88

Signed-off-by: Vincent Kelleher <vincent.kelleher@gaia-x.eu>
vincentkelleher pushed a commit to vincentkelleher/Sphereon-OID4VCI that referenced this issue Feb 21, 2024
…ess, refs Sphereon-Opensource#88

Signed-off-by: Vincent Kelleher <vincent.kelleher@gaia-x.eu>
@vincentkelleher
Copy link
Author

vincentkelleher commented Feb 21, 2024

I've raised a Pull Request with a change to allow any algorithm as its the responsibility of the implementer to manage the signature part. It also increases the coverage of the part I've modified 😊

Thank you for the quick commit to support other algorithms 👍

@nklomp
Copy link
Contributor

nklomp commented Mar 12, 2024

Forgot to close this issue while merging the PR. Thanks again for the PR

@nklomp nklomp closed this as completed Mar 12, 2024
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

2 participants