5G/OAuth JAR Working Session

From IIW

OAuth JAR Working Session


Thursday 5G

Convener: Nat Sakimura, Nomura Research Institute, (@_nat_en)

Notes-taker(s): Nat Sakimura

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


Abstract

Four remaining points that came up during the IETF last call for OAuth JAR was discussed. The opinion of the participants were to partly revert the query parameter requirements to the WGLC version, add clarification on the semantics of request_uri, define a authorization server endpoint for accepting request objects, and add JWT parameters in the OAuth request parameter IANA registry.

Meeting Notes

This session was to discuss how to close the loose end of soon to become RFC OAuth JAR. 

Those points were: 

  1. Plausibility of removal of query parameter parameters in the authorization request; 
  2. Simplification and concretization of request_uri location and clarification that it is at the discretion of the authorization server that where that location can be.  
  3. Clarification that request_uri does not have to be URL, but it can be URN. 
  4. Registration of JWT parameter values like iss, exp, etc. for the OAuth Authorization Request IANA registry. 

1. Plausibility of removal of query parameter parameters in the authorization request; 

In the IETF LC, a comment came in that the duplication of the values in parameter and in the request object was a waste and having unprotected values are a security risk. To accommodate the comment, all query parameters were removed. 


Subsequently, a comment from Brian came in that client_id and scope is really useful in the query parameter for deployments for a couple of reasons: 

  • The authorization server can use them as the switch to change the processing logics before parsing the potentially encrypted token. 
  • Load Balancer etc can use the parameters to switch the backend server based on it. It cannot look inside of the JWT (especially when it is encrypted.) 
  • The group decided that bringing client_id and scope would be a very good idea. 

2. Simplification and concretization of request_uri location and clarification that it is at the discretion of the authorization server that where that location can be.  

Brian pointed out that in many implementations the authorization server cannot make a query to the external network to fetch a potentially arbitrary content as it will cause a DoS if the content was very large, etc. The support of request_uri is very complex and he would not like to implement it. 

Nat pointed out that 

  • It is at the authorization server's discretion to decide the permissible locations of request_uri. It could constrain it to be within the authorization server itself as well. 
  • While it will be more complex for the implementations since it now cannot be stateless, many customers (esp. banks) actually prefer it. 

Some discussion ensued and it was agreed that defining an endpoint at the AS to accept the request object to give out the request URI would be a good idea. The result of discussion has the impact on two specs. 

  • JAR: Make it explicit that it is at the discretion of the AS where the request_uri can be. 
  • JAR: Create an AS endpoint to accept the request object and return the request_uri. 
  • FAPI: in the mean time, have the request object endpoint duplicated in it as the deadline for FAPI is way shorter than for JAR.

3. Clarification that request_uri does not have to be URL, but it can be URN  

It was authors' intent that when it is indicated as URI, then it does not have to be URL but it can also be URN. However, there has been much feedback asking "why does it have to be URL" from multiple directions. 


It was agreed that it is a good idea to mention that the fact. 


4. Registration of JWT parameter values like iss, exp, etc. for the OAuth Authorization Request IANA registry


Brian argued that JWT parameters need to be registered by this spec. at IANA sometimes ago. Nat's response was that the comment came in too late and we are past IANA review that if we do it, we need to get back to the WG level. 


However, as the result of the discussion in item 2., it is now clear that it will get back to the WGLC, so they can now be added. 

Retrieved from "https://iiw.idcommons.net/index.php?title=5G/OAuth_JAR_Working_Session&oldid=21101"