[Openid-specs-fapi] Issue #330: potentailly misleading language WRT JWT ATs (openid/fapi)

Brian Campbell issues-reply at bitbucket.org
Thu Oct 15 17:09:16 UTC 2020

New issue 330: potentailly misleading language WRT JWT ATs

Brian Campbell:

Snippet of a slack conversation yesterday with Vittorio Bertocci:

**Vittorio**  [4:36 PM](https://identiversevi-ejm5149.slack.com/archives/D015QKUHA3T/p1602715000008000)  
I think the language in [https://bitbucket.org/openid/fapi/src/master/Financial\_API\_WD\_001.md#markdown-header-522-authorization-server](https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md#markdown-header-522-authorization-server) is somewhat confusing. In particular  

> 16.  shall provide opaque non-guessable access tokens, authorization codes, and refresh token \(where applicable\), with sufficient entropy such that the probability of an attacker guessing the generated token is computationally infeasible as per [RFC6749](https://tools.ietf.org/html/rfc6749) section 10.10;


foloowed by  

>  **NOTE**: The opaqueness requirement for the access token does not preclude the server to create a structured access token.


ultimately the NOTE is all I need to push back on anyone suggesting that JWT ATs can't be used in FAPI; but the req 16 is confusing. It does not say that the client should treat the token as opaque, it says it should _be_ opaque. So I worry that people might say that the token should be JWE, for example - structured but actually opaque


re-reading, I actually worry that the NOTE won't justify use of unencrypted JWT ATs.  
I think that is a problem. Is that the intent of the spec?

More information about the Openid-specs-fapi mailing list