FAPI2.0 OSCAL Profile

[bitbucket-import-issues]

Originally submitted by Damian Hickey (Damian Hickey) on 2026-01-29

Hi All,

I’ve been exploring the automated compliance documentation space which led me to https://pages.nist.gov/OSCAL/ and I was wondering if the group considered an FAPI2.0 OSCAL profile (perhaps against NIST 800-53) which would bridge the gap between the security profile and automated GRC/audit tooling? I’ve performed some initial investigation (and make no assertion it’s even feasible yet) but thought I’d reach out to the group first to see if anyone has explored this.

Thank you

Damian

‌

---

Bitbucket status: open

Bitbucket origin: issue 851

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2026-01-30

Thanks, Damian. Are you going to be available on the next Wednesday call?

[bitbucket-import-issues]

Originally submitted by Damian Hickey (Damian Hickey) on 2026-01-30

Hi Nat, thanks for accepting the topic. I’m unable to make next Wednesday but will be able to on the following Wednesday.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2026-02-04

Thanks for letting me know. I will take this issue up on the Feburary 11 then.

[bitbucket-import-issues]

Originally submitted by Damian Hickey (Damian Hickey) on 2026-02-10

Great, will join. Is there anything I should prepare?

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2026-02-18

Discussed on 2026-02-11 Atlantic call

Background

Damian Hickey introduced #839, which he raised on Bitbucket and was invited by Nat to discuss with the group.

• Duende's identity server can be configured to be FAPI 2.0 conformant. Damian explored the next stage: automated compliance reporting for auditors.
• Auditors need to understand if a system is fully or partially compliant, what remediations exist, and whether configuration drift has caused non-compliance over time.
• Duende is building an HTML/PDF report for auditors that gives a configuration breakdown of the identity server. Looking further ahead, Damian explored OSCAL (Open Security Controls Assessment Language) — a NIST-driven standard for machine-readable schema defining how a system conforms to a set of controls.
• The core question: can an OSCAL profile be defined for FAPI 2.0 that maps FAPI controls to machine-readable, auditable representations consumable by GRC systems (such as Drata, Vanta, etc.)?

Discussion

Dima Postnikov: FAPI has a narrow set of requirements focused on security and interoperability. Conformance testing already covers everything prescribed by the profile, but there are gaps — things that must be true for the system to be secure (e.g., storing private keys in a secure location) that cannot be verified during conformance test execution. Automating those untested assumptions in machine-readable form could add value. The topic is potentially broader than FAPI alone, but FAPI-specific controls could be a focused starting point.

Joseph Heenan: New to OSCAL. Generated a sample OSCAL catalogue for FAPI via Codex (ChatGPT) to explore feasibility — link shared in chat: gist.github.com/jogu/aa1fe54248e389edbf51eb8bbc523fc3. Noted that conformance test failures could potentially be written out as OSCAL findings. Observed that current conformance tool adoption has been driven by regulators mandating conformance by law; OSCAL could represent an alternative pathway via auditors rather than regulators. Judged the topic worth further investigation. After the main discussion, confirmed that BCP 195 states that implementations should support TLS 1.3.

George Fletcher: Questioned whether evidence gathering via OSCAL would be globally applicable or jurisdictionally specific, and whether feasibility exists for a single viable profile covering multiple jurisdictions. Noted the challenge of maintaining layered controls when global and jurisdiction-specific controls diverge. Suggested OSCAL feels orthogonal to the core FAPI spec — more of a useful GRC evidence-gathering tool — and expressed uncertainty about how to turn it into a formal standard alongside FAPI.

Damian Hickey: Acknowledged jurisdictional complexity. Noted that OSCAL supports layered profiles — a base layer with jurisdiction-specific extensions on top — which could help manage variance. Emphasized that the envisioned OSCAL profile would be complementary to, not a replacement for, conformance testing: the conformance test is an outside-in black-box check, whereas an OSCAL endpoint would be an inside-out self-assertion. Both would be needed; an auditor would still need to verify that a system's OSCAL endpoint is not simply asserting compliance without basis.

Dima Postnikov: Agreed with the complementary nature of the two approaches. Also raised trust marks as an alternative mechanism (e.g., "this entity has been certified by the OpenID Foundation as a compliant implementation as of date X"). Recommended the issue also be discussed in the Ecosystem Support Community Group, which has broader ecosystem representation. The group consensus was that no one is objecting to the topic; it is worth exploring within the FAPI context.

Action Items

• Damian Hickey: Develop a few specific OSCAL examples relevant to FAPI 2.0 (focusing on controls that are within FAPI scope), and explore an initial OSCAL profile draft for FAPI. Update Bitbucket FAPI2.0 OSCAL Profile #839 with findings.
• Dima Postnikov: Mention the OSCAL topic in the next Ecosystem Support Community Group call.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2026-03-25

Do you have an update Damian?

[bitbucket-import-issues]

Originally submitted by Damian Hickey (Damian Hickey) on 2026-04-07

Will be picking this back up shortly.