Make claim rules visible to clients and operators

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary: This PR makes claim-based access requirements more visible to both clients and operators.

Changes:

• Parse and cache OIDC Discovery claims_supported for providers.
• Publish scopes_supported in MCP Protected Resource Metadata, derived from policy scope claim rules (deduped/sorted).
• Log operator-facing warnings when a policy requests claims the provider does not advertise.
• Update MCP PRM schema + e2e fixtures/config to include and exercise scopes_supported.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

enterprise/server/include/sourcemeta/one/enterprise_server_action_auth_login_v1.h:357: report_unadvertised_claims will emit this warning on every login attempt for every missing claim, which could become very noisy (and drown out actionable logs) if a provider publishes claims_supported but omits common/custom claims. Consider whether this should be deduplicated or otherwise throttled per policy/provider.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[augmentcode]

src/self/v1/schemas/mcp/prm/response.json:39: scopes_supported currently permits an empty array, but RFC 9728 §3.2 requires zero-value arrays to be omitted (and the core metadata validator treats empty scopes_supported as malformed). Tightening the schema here (e.g., requiring at least one item) would better match the spec/implementation contract.

Severity: low

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[cubic-dev-ai]

1 issue found across 7 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/authentication/include/sourcemeta/one/authentication.h">

<violation number="1" location="src/authentication/include/sourcemeta/one/authentication.h:263">
P1: This member changes the binary layout of the public `ProviderEndpoints` value returned by `Authentication::endpoints`, so applications built against the previous 6.x header can suffer memory corruption when loaded with the new 6.x library. Preserving the layout with a separate accessor/opaque result, or making this an ABI-major release, would avoid that compatibility break.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: This member changes the binary layout of the public ProviderEndpoints value returned by Authentication::endpoints, so applications built against the previous 6.x header can suffer memory corruption when loaded with the new 6.x library. Preserving the layout with a separate accessor/opaque result, or making this an ABI-major release, would avoid that compatibility break.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/authentication/include/sourcemeta/one/authentication.h, line 263:

<comment>This member changes the binary layout of the public `ProviderEndpoints` value returned by `Authentication::endpoints`, so applications built against the previous 6.x header can suffer memory corruption when loaded with the new 6.x library. Preserving the layout with a separate accessor/opaque result, or making this an ABI-major release, would avoid that compatibility break.</comment>

<file context>
@@ -256,6 +256,11 @@ class SOURCEMETA_ONE_AUTHENTICATION_EXPORT Authentication {
+    // Discovery Section 3 calls this list non-exhaustive, so a claim missing
+    // from it is worth reporting and never worth refusing over, and a provider
+    // publishing none says nothing at all
+    std::vector<std::string> claims_supported{};
   };
 
</file context>

[github-actions]

Benchmark Index (community)

Details

Benchmark suite	Current: 727e339	Previous: afd40e9	Ratio
Add one schema (0 existing)	292 ms	333 ms	0.88
Add one schema (100 existing)	23 ms	30 ms	0.77
Add one schema (1000 existing)	82 ms	95 ms	0.86
Add one schema (10000 existing)	807 ms	824 ms	0.98
Update one schema (1 existing)	20 ms	23 ms	0.87
Update one schema (101 existing)	23 ms	31 ms	0.74
Update one schema (1001 existing)	77 ms	98 ms	0.79
Update one schema (10001 existing)	790 ms	821 ms	0.96
Cached rebuild (1 existing)	5 ms	8 ms	0.63
Cached rebuild (101 existing)	6 ms	10 ms	0.60
Cached rebuild (1001 existing)	22 ms	38 ms	0.58
Cached rebuild (10001 existing)	206 ms	327 ms	0.63
Index 100 schemas	351 ms	646 ms	0.54
Index 1000 schemas	1129 ms	1484 ms	0.76
Index 10000 schemas	11152 ms	13869 ms	0.80
Index 10000 schemas (custom meta-schema)	14097 ms	16781 ms	0.84
Index 10000 schemas ($ref fan-out)	13849 ms	16789 ms	0.82

This comment was automatically generated by workflow using github-action-benchmark.

[github-actions]

Benchmark Index (enterprise)

Details

Benchmark suite	Current: 727e339	Previous: afd40e9	Ratio
Add one schema (0 existing)	373 ms	421 ms	0.89
Add one schema (100 existing)	101 ms	107 ms	0.94
Add one schema (1000 existing)	159 ms	165 ms	0.96
Add one schema (10000 existing)	850 ms	849 ms	1.00
Update one schema (1 existing)	92 ms	99 ms	0.93
Update one schema (101 existing)	98 ms	106 ms	0.92
Update one schema (1001 existing)	167 ms	166 ms	1.01
Update one schema (10001 existing)	833 ms	862 ms	0.97
Cached rebuild (1 existing)	7 ms	9 ms	0.78
Cached rebuild (101 existing)	8 ms	12 ms	0.67
Cached rebuild (1001 existing)	25 ms	38 ms	0.66
Cached rebuild (10001 existing)	214 ms	328 ms	0.65
Index 100 schemas	474 ms	512 ms	0.93
Index 1000 schemas	1340 ms	1481 ms	0.90
Index 10000 schemas	13977 ms	14235 ms	0.98
Index 10000 schemas (custom meta-schema)	16977 ms	16942 ms	1.00
Index 10000 schemas ($ref fan-out)	16620 ms	17135 ms	0.97

This comment was automatically generated by workflow using github-action-benchmark.