[Openid-specs-fapi] Issue #271: Rename and adjust FAPI profiles (openid/fapi)

tlodderstedt issues-reply at bitbucket.org
Tue Oct 8 18:58:50 UTC 2019

New issue 271: Rename and adjust FAPI profiles

Torsten Lodderstedt:

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. 

@{557058:72622bfb-6c02-4b63-903c-3790e658b913} 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:

FAPI “substantial”

* 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

FAPI “high”

* 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.

More information about the Openid-specs-fapi mailing list