FAPI-RW: Require pkce when using PAR

[Joseph Heenan]

As mentioned at https://bitbucket.org/openid/fapi/issues/304/are-duplicates-of-the-response_type-and#comment-58471296 and discussed on this week’s call, we should require PKCE support when using PAR with FAPI1 RW.

The reasons for requiring it are:

1. It moves the onus to be secure from client side to server side, which is important as we have seen many clients in the OpenBanking UK ecosystem that just don’t implement the existing security checks like s_hash or checking the signatures on id_tokens.
2. It aligns with the OAuth security BCP and FAPI2.

The reason for only requiring it for PAR is that mention of PAR will be new to FAPI-RW ID3 (ID2 only mentions the pre-IETF pushed request objects spec), so requiring it for PAR will not be a breaking change. (We previously made the decision not to enable it for the non-PAR case as we did not want to force that level of upheaval onto the UK OB ecosystem.)

‌

‌

[Ralph Bragg]

This gets my vote.

[Tom Jones]

it turns out that there are better ways to secure the client than PKCE, which has the defect of url hijacking. Would it be possible to say PKCE or better?

[Joseph Heenan]

Hi Tom, for interoperability reasons FAPI tends to make explicit recommendations.

Can you outline these “better ways” please? Is there a link for the url hijacking attack you mention?

Thanks!

‌

[Tom Jones]

if you want FAPI to just support UKOBIE i propose that you change the name from FAPI to UKOBIE and stop trying to claim it can be used for other purposes.

You mischaracterize my statement. This is why i opposed the attack model that you guys have adopted. It is not sufficient for good security to state that that you have addressed all known attacks, The weakness is that anyone can claim to “own” any uri redirect. It is last install wins.

[Joseph Heenan]

Hi Tom

When I say “FAPI tends to make explicit recommendations for interoperability reasons”, that statement is in no way specific to OBIE.

In general, if you want a FAPI certified client and a FAPI certified server to work together out of the box, you need statements along the lines of “both client and server need to do <x>”. If a server decided to require PKCE, and a client decides to only support something “better than PKCE”, they won’t work together.

Can you explain the better alternative to PKCE you’re referring to please?

The weakness is that anyone can claim to “own” any uri redirect. It is last install wins.

Are you referring to mobile operating systems and claimed https urls here, or something else?

Thanks

Joseph

‌

[Tom Jones]

the charter for this group seems to be ambiguous about specifying security protocols. In case you have not read it i pasted the scope below. Don’t get me wrong, interop is a good thing, but it is not included in your charter. I happen to prefer technology neutrality, which sometimes conflicts with interop. I have no plans to introduce new security protocols into this forum. I would, however, state that IMHO PKCE has a limited life time before a better solution is introduced. Perhaps adding PKCE as a negotiated option would work better long term. Or perhaps a layer of indirection as is enabled by a BCP.

3) Scope

The group will define

• JSON format to represent account related data, e.g., Account Representation, Transactions, Current Status,
• REST API for the accounts,
• security profiles for OpenID Connect and OAuth,
• Purchase history of commerce site, and
• Receipt Data

‌

[Joseph Heenan]

Hi Tom,

Thanks. I don’t think the scope being limited to creating a security profile for OIDC/OAuth means we can ignore interoperability.

If I understand correctly, you are saying that there isn’t currently anything that is better than PKCE.

My experience of such issues in that past is that there is an intention to update the FAPI specification as and when there is something better that the WG feels is suitable to endorse. So if we don’t currently know of anything better suited than PKCE, we would (for this revision of the document) only recommend PKCE.

[Joseph Heenan]

For clarity, now I see I explicitly mentioned OpenBanking when opening the ticket and that is perhaps what Tom was referring to: I mentioned OpenBanking UK there as an example of the largest FAPI ecosystem (about 60 OPs and 200+ RPs) that currently exists. We have seen some behaviours in that ecosystem that weakened security, and have every reason to suspect the same behaviours will happen in other ecosystems that deploy FAPI, and hence we want to do our best to plug that gap before the spec sees wider adoption.

[Tom Jones]

I fully support your last statement. I object to the idea that it's my way (PKCE) or the highway.

[Daniel Fett]

Just for the record,

This is why i opposed the attack model that you guys have adopted. It is not sufficient for good security to state that that you have addressed all known attacks,

That is exactly what our approach is not about.

The weakness is that anyone can claim to “own” any uri redirect.

Seems like that is very well covered by our attacker model.

[Dave Tonge]

Merged in par-pkce (pull request #189)

FAPI-RW: Require PKCE when using PAR

• FAPI-RW: Require PKCE when using PAR

See discussion at:

https://bitbucket.org/openid/fapi/issues/307/fapi-rw-require-pkce-when-using-par

closes #307

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Stuart Low Approved-by: Nat Sakimura

→ <<cset 08eef3d114c3>>