Review FAPI1 security considerations for clarity

[Joseph Heenan]

Most recently discussed on https://bitbucket.org/openid/fapi/pull-requests/429 - I cannot remember where we previously discussed this, but in FAPI2 we were careful to make the security considerations quite clear on why we felt items from the security analysis were in most cases not real world issues.

e.g. https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html#section-5.6.5 includes language like:

“A pre-condition for this attack is that the attacker has control of an authorization server that is trusted by the client to issue access tokens for the target resource server.”

and

“The pre-conditions for this attack do not apply to many ecosystems and require a powerful attacker.”

We should review the FAPI1 baseline & advanced security considerations and revise them in errata, so that ecosystems adopting FAPI1 do not feel like they need to take measures like requiring at_hash in id_tokens unless the very specific criteria apply to them. I think in many cases we’ll be able to reuse text from FAPI2.

‌

[Dave Tonge]

We discussed on the call and agreed this wold be a good approach.

[Dave Tonge]

We should decide which attacks, we classify in this way:

### 8.3.2 Client credential and authorization code phishing at token endpoint
### 8.3.3 Identity provider (IdP) mix-up attack
### 8.3.5 Access token phishing
### 8.4.2 Authorization request parameter injection attack
### 8.4.3 Authorization response parameter injection attack

‌

‌

[Dave Tonge]

### 8.3.2 Client credential and authorization code phishing at token endpoint

adjust to make clear that code can be replated even if mutual tls is used

[Tom Jones]

odd choice of words. Repeating my concerns from the beginning of Fett’s insistence on adding an attacker ==> the attack model is the wrong one to use for developing code. A risk based threat analysis is better suited to developing a solution. Some attacks apply to some solutions and not others. Only the architect and developer teams can determine which vulnerabilities need to be addressed in a design. Only a threat model analysis can be presented as proof of cybersecurity to a CISO or corporate board.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/438