authz-server-parity

Enforces synchronized changes across PingOne Authorize gateway, mock server, and BFF replicas.

1|Updated Jun 25, 2026
One-click install
npx skills add https://github.com/curtismu7/AI-DEMO2 --skill authz-server-parity-curtismu7
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: authz-server-parity
Source: https://github.com/curtismu7/AI-DEMO2/tree/main/pingone/authz-server-parity
Command: npx skills add https://github.com/curtismu7/AI-DEMO2 --skill authz-server-parity-curtismu7

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Changes to the PingOne Authorize decision contract often get applied to only one component, causing the mock authorization server to silently diverge from the real PingOne integration and breaking the production switch. ## Core Features & Use Cases - Three-Way Parity Rule: Mandates that any decision contract change be mirrored across the MCP gateway, demo_authz_server, BFF simulated authorize service, and PingGateway groovy filter in the same commit. - Contract Reference: Documents the decision endpoint path, request parameters, response shape, DecisionContext values, and introspection format that must stay in sync. - Use Case: When adding a new parameter like TransactionAmount to buildAuthorizeParameters() in the gateway, follow the checklist to update decision.js, simulatedAuthorizeService.js, and the groovy filter before marking the auth work done. ## Quick Start Read this skill before modifying any PingOne Authorize integration code and apply the parity checklist to every affected replica file.

Frequently Asked Questions about authz-server-parity

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new parameter to the PingOne Authorize decision request?▼

Add the parameter to buildAuthorizeParameters() in PingOneAuthorizeClient.ts, then mirror it in demo_authz_server/routes/decision.js, simulatedAuthorizeService.js, and the p1az-decision.groovy filter in the same commit.

How do I add a new DecisionContext to the authorization policy?▼

Add the context emission in the gateway guard or BFF route, implement the handler branch in demo_authz_server/routes/decision.js, replicate it in mcpToolAuthorizationService.js and the groovy filter, then document it in the skill.

Which components must stay in sync for PingOne Authorize parity?▼

Five replicas implement the decision contract: the MCP gateway PingOneAuthorizeClient, the mock decision.js, the BFF simulatedAuthorizeService.js, mcpToolAuthorizationService.js, and the PingGateway p1az-decision.groovy filter.

Why does switching from the mock to real PingOne Authorize break?▼

Breakage happens when the mock diverges from the real decision contract because a change was applied to only one component. The mock is a drop-in replacement swapped via the PINGAUTHORIZE_ENDPOINT config, so any drift surfaces only at production switchover.

Does ChipAuthorization come from the MCP gateway?▼

No, ChipAuthorization is emitted by the BFF API server in verticalManifest.js, not the gateway. The gateway only produces McpToolCall, McpRequest, and McpToolsList contexts.