[Openid-specs-fapi] Issue #330: potentailly misleading language WRT JWT ATs (openid/fapi)
issues-reply at bitbucket.org
Thu Oct 15 17:09:16 UTC 2020
New issue 330: potentailly misleading language WRT JWT ATs
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;
> **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