Skip to content

JARM (JWT Secured Authorization Response Mode) #208

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

Open
TakahikoKawasaki opened this issue Feb 3, 2021 · 5 comments
Open

JARM (JWT Secured Authorization Response Mode) #208

TakahikoKawasaki opened this issue Feb 3, 2021 · 5 comments
Labels
status: on-hold We can't start working on this issue yet type: enhancement A general enhancement

Comments

@TakahikoKawasaki
Copy link

JARM (JWT Secured Authorization Response Mode) support.

JARM (response_mode=*.jwt) has a considerably big impact on authorization server implementations. It is recommended that the feature be designed and implemented from the beginning.

@TakahikoKawasaki TakahikoKawasaki added the type: enhancement A general enhancement label Feb 3, 2021
@jgrandja
Copy link
Collaborator

jgrandja commented Feb 17, 2021

@TakahikoKawasaki

The Warning section in the JARM draft states:

This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Based on this, I'm reluctant to implement this. It also seems quite early in the review phase.

However, I do see value in providing an extension point that would allow an Authorization Server implementation to customize the Authorization response parameters using JARM or response_mode=form_post #207

@jgrandja jgrandja added the status: on-hold We can't start working on this issue yet label Feb 17, 2021
@jgrandja
Copy link
Collaborator

jgrandja commented Feb 17, 2021

Related #207 (Authorization Response customization #139)

@TakahikoKawasaki
Copy link
Author

In spite of the excerpted sentence, the specification itself is stable. JARM is mentioned in the Financial-grade API (FAPI) specification. Authorization servers that support FAPI Part 2 must support JARM or be able to issue an ID token from the authorization endpoint.

@jgrandja
Copy link
Collaborator

@TakahikoKawasaki As an FYI - so you're more familiar with our development process - new feature development starts off with a closed API and we incrementally open it up when it becomes more stable and requires end-consumer customization. Hence, the reason why you cannot customize the Authorization Request or Response at the moment.

#139 captures end-consumer customization requirements at a high-level for consolidating into one ticket. From there, I will open a new ticket with details related to one of the feature requirements when it's time to "open up". I'm aware that customizing the Authorization Request/Response and Token Request/Response is an MVP requirement. These extension points will allow Authorization Server implementations to implement JARM, response_mode=form_post, etc.

@jgrandja
Copy link
Collaborator

Given that JARM is not needed in FAPI 2.0 (see Main Differences to FAPI 1.0), we might not implement this capability.

the authorization response is reduced to only contain the authorization code, obsoleting the need for integrity protection

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: on-hold We can't start working on this issue yet type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants