-
Notifications
You must be signed in to change notification settings - Fork 18
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
Conversation
There was a problem hiding this 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.
There was a problem hiding this 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.
There was a problem hiding this 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]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Oliver Terbu <[email protected]>
Fixes #216