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

fix: assert valid jarm response #2117

Conversation

auer-martin
Copy link
Contributor

No description provided.

Copy link

changeset-bot bot commented Nov 27, 2024

⚠️ No Changeset found

Latest commit: 7ab3b38

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@TimoGlastra
Copy link
Contributor

Maybe we can add a test covering this?

@auer-martin auer-martin force-pushed the fix/assert-jarm-response-mode branch from 5cc8ed1 to eb2aa20 Compare November 30, 2024 10:22
@auer-martin
Copy link
Contributor Author

I added a basic test. It works, but I am not sure if we should include it like this.

credentials: selectedCredentials,
},
})
).rejects.toThrow()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test makes sense and is a good addition 👍 . Is there anything returned in the error indicating we're missing response encryption? Would be nice if this toThrow contains something that asserts it's the JARM that is failing here. (it also helps the client interacting with Credo as a verifier to see what's missing)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, there was not. I added a cause property now.

@auer-martin auer-martin force-pushed the fix/assert-jarm-response-mode branch from eb2aa20 to e96566d Compare December 4, 2024 10:48
@auer-martin auer-martin force-pushed the fix/assert-jarm-response-mode branch from e96566d to b27af5a Compare December 4, 2024 10:51
@@ -83,7 +83,7 @@ export function sendErrorResponse(
error: unknown,
additionalPayload?: Record<string, unknown>
) {
const body = { error: message, ...additionalPayload }
const body = { error: message, ...(error instanceof Error && { cause: error.message }), ...additionalPayload }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not compliant with the spec. there is error and error_description. But we should be cautious with just returning the error message for unknown errors.

For oid4vci i reworked it to now throw a Oauth2ServerErrorResponseError and in the place where sendErrorResponse is called i first check for instanceof Oauth2ServerErrorResponseError and then call sendOauth2ErrorResponse. Then we make sure only error messages that should be leaked to the client are leaked. (Because we only construct a Oauth2ServerErrorResponseError if needed. Can you udpate?

@TimoGlastra TimoGlastra merged commit 07a60cd into openwallet-foundation:main Dec 9, 2024
12 of 14 checks passed
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

Successfully merging this pull request may close these issues.

2 participants