JARM: the type of expires_in in authorization response JWT

[Takahiko Kawasaki]

4.1.2. Response Type "token" in JARM (Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0) shows an example of authorization response as follows:

{
   "iss":"https://accounts.example.com",
   "aud":"s6BhdRkqt3",
   "exp":1311281970,
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "state":"S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw",
   "token_type":"bearer",
   "expires_in":"3600",
   "scope":"example"
}

In the example, the type of the value of the expires_in is "string", but it should be "number" if we strictly follow the definition of expires_in which is found in A.14. "expires_in" Syntax in RFC 6749.

A.14.  "expires_in" Syntax

   The "expires_in" element is defined in Sections 4.2.2 and 5.1:

     expires-in = 1*DIGIT

[Brian Campbell]

The syntax and definition of "expires_in" means it could be represented as a JSON number. However, in the normal fragment encoding all the authorization response parameters are strings. So it arguably might be more straightforward to just say that in JARM all the authorization response parameters are also strings. Maybe.

One way or the other, JARM should probably be specific about it.

Should we decide to make "expires_in" a JSON number, some text along the lines of the following taken from https://tools.ietf.org/html/rfc6749?#section-5.1 might be good enough.

   Parameter names and string values are included as JSON strings.
   Numerical values are included as JSON numbers. 

as well as changing the example to "expires_in":3600,

[Takahiko Kawasaki]

In order to say "in JARM all the authorization response parameters are also strings", the specification would also have to state "exp is not regarded as an authorization response parameter (, so its value doesn't have to be a string)". Otherwise, the value of the exp claim would have to become a string, too.

[Brian Campbell]

It would define how the authorization response parameters are encoded into the JWT but not the standard JWT claims.

Something along the lines of '... by encoding the authentication response parameters as claims of the JWT, with each parameter name as the claim name and its value as a JSON string."

[Brian Campbell]

Pull request #83 proposes to address this by saying that "Authorization endpoint response parameter names and string values are included as JSON strings and numerical values (e.g., expires_in value) are included as JSON numbers." while also changing the expires_in value in the example to be a number rather than a string (i.e. no quotes).

[Brian Campbell]

pull request #83 was merged at f10eba4 to fix this