Add some more text to Introduction

[Nat Sakimura]

Currently, it only talks about the FAPI 2 family and not specifically on this document. Perhaps adding a paragraph like the one below would help readers.

FAPI 2.0 is comprised by several documents. At the time of writing, they are:

• FAPI 2.0 Attacker model
• FAPI 2.0 Security profile
• FAPI 2.0 Message signing

This document specifies the process for a client to obtain sender-constrained tokens from the authorization server, which is supposed to be used in conjunction with identity or session management specifications such as OpenID Connect, which is the assumption for its formal security analysis.

‌

[Bjorn Hjelm]

I support this idea as it would help readers who aren’t familiar with FAPI 2.0 (such as CAMARA participants) to better understand the FAPI 2.0 document structure.

[Dima Postnikov]

Not sure we need to mention FAPI2 Trust Framework discussed here: https://bitbucket.org/openid/fapi/issues/432/fapi2-trust-framework-structure

[Dima Postnikov]

Re last paragraph, may be we should say that end-user authentication and session management are out of scope?

[Nat Sakimura]

For the last paragraph, there are arguments that it is not helpful.

It was also pointed out that it may have already been addressed by the changes in the text of the attacker model. Nat to check that and comeback for it.

For the 1st paragraph, Nat to create a PR.

[Brian Campbell]

Re last paragraph, may be we should say that end-user authentication and session management are out of scope?

Out of scope but assumed to be in place and correct? That’s kinda what this https://openid.bitbucket.io/fapi/fapi-2_0-attacker-model.html#section-5-6.4 in the attacker model says:

Identity and session management: End user's identity proofing, authentication, identity and access management on a client or authorization server are out of scope for this specification. It is assumed that clients ensure that sessions of different users are properly protected from each other and from attackers. Clients retrieving identity attributes using OpenID Connect are required to check whether the identity attributes returned fulfills their requirements.

‌

Which I think are the “changes in the text of the attacker model” that Nat mentioned.

‌

‌

[Nat Sakimura]

Fixing #638

→ <<cset 451f34ea67ce>>

[Dave Tonge]

Merged in Nat-Sakimura/fapi2_0securityprofilemd-edited-online-w-1709604138326 (pull request #474)

Fixing #638

• Fixing #638
• fapi-2_0-security-profile.md edited online with Bitbucket
• fapi-2_0-security-profile.md edited online with Bitbucket
• Merged in Nat-Sakimura/fapi2_0securityprofilemd-edited-online-w-1710923129974 (pull request #480)

fapi-2_0-security-profile.md edited online with Bitbucket

Approved-by: Daniel Fett Approved-by: Joseph Heenan Approved-by: Dave Tonge

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Joseph Heenan

→ <<cset 3c76f9363abe>>

[Dave Tonge]

Merged in Nat-Sakimura/fapi2_0securityprofilemd-edited-online-w-1709604138326 (pull request #474)

Fixing #638

• Fixing #638
• fapi-2_0-security-profile.md edited online with Bitbucket
• fapi-2_0-security-profile.md edited online with Bitbucket
• Merged in Nat-Sakimura/fapi2_0securityprofilemd-edited-online-w-1710923129974 (pull request #480)

fapi-2_0-security-profile.md edited online with Bitbucket

Approved-by: Daniel Fett Approved-by: Joseph Heenan Approved-by: Dave Tonge

Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Joseph Heenan

→ <<cset 3c76f9363abe>>