- edited description
Review FAPI1 security considerations for clarity
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.
Comments (8)
-
reporter -
We discussed on the call and agreed this wold be a good approach.
-
-
assigned issue to
-
assigned issue to
-
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
-
### 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
-
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.
-
-
- changed status to resolved
Merged PR 438
- Log in to comment