fix: Harden signing_key to only allowing properties related to public keys

[sujoyg]

Description

The signing_key schema in discovery profiles defines public key fields (x, y, n, e) but does not set "additionalProperties": false, potentially allowing private key fields (e.g. d, p, q) to be published in discovery profiles without warning.

This changes fixes that.

Category (Required)

• Core Protocol: Changes to the base communication layer, global context, or breaking refactors. (Requires Technical Council approval)
• Governance/Contributing: Updates to GOVERNANCE.md, CONTRIBUTING.md, or CODEOWNERS. (Requires Governance Council approval)
• Capability: New schemas (Discovery, Cart, etc.) or extensions. (Requires Maintainer approval)
• Documentation: Updates to README, or documentations regarding schema or capabilities. (Requires Maintainer approval)
• Infrastructure: CI/CD, Linters, or build scripts. (Requires DevOps Maintainer approval)
• Maintenance: Version bumps, lockfile updates, or minor bug fixes. (Requires DevOps Maintainer approval)
• SDK: Language-specific SDK updates and releases. (Requires DevOps Maintainer approval)
• Samples / Conformance: Maintaining samples and the conformance suite. (Requires Maintainer approval)
• UCP Schema: Changes to the ucp-schema tool (resolver, linter, validator). (Requires Maintainer approval)
• Community Health (.github): Updates to templates, workflows, or org-level configs. (Requires DevOps Maintainer approval)

Related Issues

N/A

Checklist

• I have followed the Contributing Guide.
• I have updated the documentation (if applicable).
• My changes pass all local linting and formatting checks.
• (For Core/Capability) I have included/updated the relevant JSON schemas.
• I have regenerated Python Pydantic models by running generate_models.sh under python_sdk.

Screenshots / Logs (if applicable)

N/A

[sakinaroufid]

Also external here, but I pulled this down to try it out since I’ve been looking at discovery profiles too. This seems like a really useful guardrail (hoping this gets merged!)

One thing I noticed: it looks like additionalProperties: false should sit next to properties rather than inside it. A JWK containing "d" still validates as written, but moving the line one level up rejects it.

[sujoyg]

Thank you @sakinaroufid. This would have been prevented in the future if there was a JSON schema validation as a pre-commit hook and/or a test suite. I will try and look into that. I started a discussion about testing in general here: #388

[sujoyg]

Can someone help review this? @ptiper tagging you since you helped assigned reviewers for another PR of mine.