FAPI2 Baseline: Sender-Constrained Authorization Code

[bitbucket-import-issues]

Originally submitted by Takahiko Kawasaki (Takahiko Kawasaki) on 2021-05-26

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.

---

Bitbucket status: resolved

Bitbucket origin: issue 413

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2021-05-26

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

[bitbucket-import-issues]

Originally submitted by Takahiko Kawasaki (Takahiko Kawasaki) on 2021-05-26

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.

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2021-05-26

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.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2021-06-02

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.

[bitbucket-import-issues]

Originally submitted by Brian Campbell (Brian Campbell) on 2021-06-02

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.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2021-06-02

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.

[bitbucket-import-issues]

Originally submitted by Takahiko Kawasaki (Takahiko Kawasaki) on 2021-06-12

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.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2021-06-16

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

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2021-06-23

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

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2021-06-23

PR merged