I see a need to better define the objectives of the FAPI profiles. Additionally, the names “Read” and “Read+Write” seem to imply an assessment of the WG for what use cases the profiles shall be used. I would rather leave this decision to the application and instead suggest to convey the (security) strength of the profile.
@Nat Sakimura came up with the idea to designate them as “substantial” and “high”. This sounds good to me, we also must give the profiles a clear “profile”.
- “substantial”: - I suggest to make FAPI Read the baseline profile for applications that want to prevent replay and client impersonation.
- “high”: FAPI RW could be the profile for applications requiring non-repudiation and authenticated messages.
Some ideas what that would mean in terms of mechanisms & features:
- Add sender constrained tokens
- Add PAR and RAR, which is more functional (conveying rich authorization data) than security although PAR also has better security properties than traditional authorization requests
- Signed authorization requests and responses. I personally would prefer to make OAuth-based mechanisms, namely JARM, the default and keep response type "code token" for applications that anyway use OpenID Connect (for ID providing) and backward compatibility to simplify FAPI “high”.
- PAR MUST be used with signed request objects
- RS message signing (!)
- Adding signed token introspection responses seems reasonable to support non-repudiation for the AS to RS communication (if needed)
I think this adjustments will make FAPI even more attractive for a broader audience including new communities outside of the financial space.