[Openid-specs-fapi] Issue #607: Create a Resource Server Profile on top of FAPI 2 (openid/fapi)

[M V]

New issue 607: Create a Resource Server Profile on top of FAPI 2
https://bitbucket.org/openid/fapi/issues/607/create-a-resource-server-profile-on-top-of

Mark Verstege:

Whilst FAPI has primarily concerned itself with the security layer for open data ecosystems, FAPI1 also provided requirements for resource servers including x-fapi headers. Based on the discussion here: [https://bitbucket.org/openid/fapi/issues/487/rs-must-check-x-fapi-interaction-id-is-an](https://bitbucket.org/openid/fapi/issues/487/rs-must-check-x-fapi-interaction-id-is-an), the `x-fapi-interaction-id` header is dropped from the core FAPI2 security profile, and may be included as implementation guidance. 

The practical reality is that there are common patterns emerging at the resource layer for many implementations that utilise FAPIx. Many of these patterns are built off the FAPI profiles or have opinionated implementation approaches. With the “family of profiles” approach taken with FAPI2, there could be a lot of value developing a baseline resource profile that can be commonly implemented across open data initiatives leveraging opinionated patterns, resource designs and OIDF standards. 

This would lend itself to efficiencies and lower implementation costs. Vendors could offer a framework style profile to embed any domain or initiative specific data model into, whilst still extending or constraining based on their needs. It would likely also assist with interoperability in federated ecosystem connections \(e.g. GAIN use cases\) and cross-border use cases.

**FAPI2 Resource Server Profile**

I’d be keen to explore a FAPI2 “Resource Server” Profile or “Protected Resource” Profile that could include requirements around resource scaffolding like correlation ids, idempotency patterns for action initiation \(e.g. making a payment\), data sharing request/response patterns, subscriber and event notification patterns, fraud and risk metadata.

**X-FAPI Headers**

There is benefit especially with the `x-fapi-interaction-id` being included which is in wide use as a correlation ID for many implementations. Where implemented, this could then have a set of provisions on implementation following agreed requirements \(SHALL\).

None of the x-fapi headers have been ported over to FAPI2 implementation guidance. I see less value in some of the other x-fapi headers like `x-fapi-auth-date` for example, but similar guidance could be helpful.