FAPI2 Baseline: Sender-Constrained Authorization Code

[Takahiko Kawasaki]

FAPI 2.0 Baseline Profile (20 May 2021), 2.2.1. Requirements for Authorization Servers, The 12th clause:

12. shall only issue authorization codes and refresh tokens that are sender-constrained

To sender-constrain authorization codes, DPoP is the only solution at this moment, isn’t it?

FAPI 1.0 ID1 Part2 had a similar requirement which assumes MTLS (and Token Binding) (e.g. 5.2.2-5, 8.3.2), but the requirement was dropped due to its impracticality (cf. [Issue 202] authorization code and refresh token must be holder of key bound).

Sorry if this has already been discussed in the WG and the clause is the agreed result of the discussion.

[Filip Skokan]

It means they’re meant to be bound to a client instance which is required to authenticate.

[Takahiko Kawasaki]

It sounds that the clause adds nothing new to typical authorization server implementations although "sender-constrained" is a bit misleading as the word historically reminds us of MTLS and Token Binding. "bound to a client instance" would be better than "sender-constrained". But, the clause doesn't have a technical problem if it means just "bound to a client instance". Thank you, Filip.

[Filip Skokan]

OAuth Security Topics uses exactly the same language. E.g. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18#section-2.2.2

‌

Its meaning was clarified on the OAuth WG mailinglist.

‌

Bottom line a code/refresh token cannot be exchanged by a client other than the one it was issued to and since public clients arent a thing in FAPI sender constraining is achieved through client authentication.

[Nat Sakimura]

Callers agreed at least clarification of the language probably is needed.

Filip pointed out that it is used in the certification suite and removing it may not be appropriate.

[Brian Campbell]

Agree w/ Taka that "bound to a client instance" would be better than "sender-constrained"

Or removing the the whole clause would be okay too as it’s redundant by virtue of only allowing confidential clients and RFC 6749 requiring code and RT be bound to the client.

[Dave Tonge]

I personally think that we can remove it, and still keep the tests in the conformance suite. RFC6749 seems pretty clear on this for confidential clients.

[Takahiko Kawasaki]

It seems that options are

1. removing the clause, or
2. changing "sender-constrained" to "bound to a client instance"

Personally, I don't have any preference. Either is okay. But, some people may want to start an argument on “what a client instance means”. In that sense, removing the clause simply may be peaceful.

[Dave Tonge]

I’m in favour of removing the clause (but keeping a test as its covered by RFC6749)

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/277/remove-sender-constrained-codes-clause

[Dave Tonge]

PR merged