Clarify intended purpose of FAPI 1.0 profiles

Issue #312 resolved
Nat Sakimura created an issue

All the references within the documents also need to be changed.

Comments (12)

  1. Nat Sakimura reporter
    • changed status to open

    Just add some explanatory text to introduction. Since the current name is quite well known now, keep the naming as is.

  2. Dima Postnikov

    Current FAPI 2 introduction is good:

    This document is Part 2 of FAPI that specifies the Financial-grade API and it provides a profile of OAuth that is suitable to be used in write access to financial data (also known as transaction access) and other similar higher risk access. This document specifies the controls against attacks such as: authorization request tampering, authorization response tampering including code injection, state injection, and token request phishing. Additional details are available in the security considerations section.

    Although it is possible to code an OpenID Provider and Relying Party from first principles using this specification, the main audience for this specification is parties who already have a certified implementation of OpenID Connect and want to achieve a higher level of security. Implementors are encouraged to understand the security considerations contained in section 8.7 before embarking on a 'from scratch' implementation.

    Is it sufficient?

    Alternatively, it can be made more generic:

    This document is Part 2 of FAPI that specifies the Financial-grade API and it provides a profile of OAuth that is suitable to be used for high risk access (read or write), for example, read access to highly sensitive data or write access to financial data (also known as payment initiation).

    What does everyone think?

  3. Dima Postnikov

    Pull request: https://bitbucket.org/openid/fapi/pull-requests/193 for Part 2.

    Part 1 looks good already: “This document is Part 1 of FAPI that specifies the Financial-grade API and it provides a profile of OAuth that is suitable to be used in the access of read-only financial data and similar use cases. A higher level of security profile is provided in Part 2, suitable for read and write financial access APIs and other similar situations where the risk is higher.”

  4. Log in to comment