Re structure FAPI2 baseline

[Dave Tonge]

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

[Dave Tonge]

Maybe bring non-normative text in FAPI2 to point to RAR, message signing, grant management, etc.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/334

[Dave Tonge]

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

‌

‌

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/343/change-name-from-baseline-to-security

[Dave Tonge]

PR merged