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

Clarify signing and encryption of JARM responses #243

Merged
merged 3 commits into from
Sep 11, 2024

Conversation

selfissued
Copy link
Member

Fixes #216

Copy link
Contributor

@awoie awoie left a comment

Choose a reason for hiding this comment

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

Looks good to me. I'll approve after my suggestion was accepted.

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved
Copy link
Contributor

@awoie awoie left a comment

Choose a reason for hiding this comment

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

After reviewing again, I think the text is correct.

Copy link
Collaborator

@Sakurann Sakurann left a comment

Choose a reason for hiding this comment

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

the PR does not solve the issue unless it explicitly adds an option only to encrypt

@@ -708,7 +708,7 @@ Note: In the Response Mode `direct_post` or `direct_post.jwt`, the Wallet can ch

This section defines how Authorization Response containing a VP Token can be signed and/or encrypted at the application level when the Response Type value is `vp_token` or `vp_token id_token`. Encrypting the Authorization Response can prevent personal data in the Authorization Response from leaking, when the Authorization Response is returned through the front channel (e.g., the browser).

To sign, or sign and encrypt the Authorization Response, implementations MAY use JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) [@!JARM].
To sign, or both sign and encrypt the Authorization Response as a Nested JWT [@!RFC7519], implementations MUST use the JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) [@!JARM].
Copy link
Collaborator

@Sakurann Sakurann Sep 5, 2024

Choose a reason for hiding this comment

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

Suggested change
To sign, or both sign and encrypt the Authorization Response as a Nested JWT [@!RFC7519], implementations MUST use the JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) [@!JARM].
To sign, encrypt, or both sign and encrypt the Authorization Response, implementations MUST use the JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) [@!JARM] and its extension defined in this section.

without this, this PR does not solve the original issue. and nested jwt here feels redundant and confusing.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm I guess it made sense to me with the next sentence describing the "special" mode for encryption without signing but I would agree that @Sakurann's suggestion makes it clearer.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this sentence is actually getting more confusing. Kristina's suggestion now says you must use the extension in this section when you're just signing a response, which would not be correct.

I would leave the scope of this sentence at dealing with the signed or signed+encrypted cases only.

@Sakurann Sakurann merged commit 4d7e041 into openid:main Sep 11, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[JARM] Additional clarifications about signed JWT, Nested JWT and encrypted JWT
6 participants