potentailly misleading language WRT JWT ATs

[Brian Campbell]

Snippet of a slack conversation yesterday with Vittorio Bertocci:

Vittorio  4:36 PM
I think the language in 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 section 10.10;

4:36

foloowed by

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

4:39

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

4:40

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?

[Joseph Heenan]

I’ve always read it as “that can be treated by the client as opaque” or some such, but the wording appears to date back to 2016ish, so I can’t speak as to the original intent.

The conformance suite doesn’t have any tests for opaqueness or otherwise.

[Brian Campbell]

I’ve read it in the same way. Or more just assumed that it was supposed to be about opaqueness to the client. But I can certainly sympathize with Vittorio’s reading of the current language.

[Dave Tonge]

remove “opaque”
change note to say something along the lines of: tokens are usually opaque to clients, but this profile allows structured tokens to be used for resource servers…

[Dima Postnikov]

may be we should more specific but still address “non-guessable”:

16.  shall provide non-guessable access tokens (if access token is not structured), 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 section 10.10;

and add

Access tokens should be opaque to clients (used by resource servers).

Access tokens could be either structured or unstructured.

‌

[Joseph Heenan]

“shall provide non-guessable access tokens (if access token is not structured), “

Structured access tokens still have to be non-guessable (and typically achieve this by being signed)

‌

[Dima Postnikov]

I was thinking about “non-guessable“ in a different way… but I agree with you Joseph.

16.  shall provide 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 section 10.10;

and

Access tokens should be opaque to clients (used by resource servers).

Access tokens could be either structured or unstructured.

‌

[Dima Postnikov]

Created pull request: https://bitbucket.org/openid/fapi/pull-requests/210

First section above didn’t need a change.

[Dave Tonge]

Resolved with this PR: https://bitbucket.org/openid/fapi/pull-requests/210