Re structure FAPI2 baseline
Issue #499
resolved
separate out code flow from requirements that are generic
add use-cases, e.g. regulated industries, e-health, e-gov
(we need to make sure that FAPI is seen as generic, but give some specific examples)
mention conformance tests / interoperability
Comments (6)
-
reporter -
reporter -
reporter Proposed wording referring to other specs:
This profile is the base of the FAPI 2.0 Framework. Other specifications that are part of this framework and may be used together with this profile include: 1. FAPI Message Signing, we recommend this specification when messages are required to be signed for the purposes of non-repudiation. 1. FAPI CIBA, we recommend that this specificaiton is used when support is required for decoupled or cross device flows 1. Grant Management, we recommend this specification for ecosystems that require complex grant management (for example concurrent grants or strict grant lifecycles) 1. OAuth 2.0 Rich Authorization Requests (RAR) [@!I-D.ietf-oauth-rar], we recommend that this specification is used wherever the `scope` parameter is not expressive enough to convey the authorization that a client wants to obtain
-
reporter -
reporter - changed status to resolved
PR merged
-
- changed component to FAPI2: Security Profile
- Log in to comment
Maybe bring non-normative text in FAPI2 to point to RAR, message signing, grant management, etc.