Skip to content

Add rights-transparency discovery members#3

Merged
miloquinn merged 1 commit into
mainfrom
codex/rights-transparency-fields
Jul 20, 2026
Merged

Add rights-transparency discovery members#3
miloquinn merged 1 commit into
mainfrom
codex/rights-transparency-fields

Conversation

@miloquinn

Copy link
Copy Markdown
Owner

Summary

  • Adds operatorName, contactUrl, contentLicense, and rightsStatement as optional discovery-document members (SPECIFICATION.md §3, mirrored in SPECIFICATION.zh-CN.md).
  • Types them in schemas/discovery.schema.json.
  • Reference server (examples/dart_server.dart) now declares all four; tool/conformance_test.dart asserts they're present with the right shape.
  • Purely additive — no existing field, capability, or endpoint meaning changes. No version-number strings were touched; bumping protocolVersion/spec version is left to maintainers per GOVERNANCE.md's release process.

Why

An independent ORSP-compatible reader (Open Reading, github.com/miloquinn/open-reading) already ships these four fields and has for a while, using them purely for client-side transparency display (who operates a source, how to reach them, what license/authorization basis the content is served under). They were never upstreamed, so this spec currently has no normative definition for fields a real-world implementation depends on — anyone else implementing ORSP has no spec to read for this.

Compatibility

  • Optional-only: absent fields keep current behavior identical (per Compatibility rules in CONTRIBUTING.md, "Minor releases may add optional fields... only" — this doesn't require a minor bump to merge, since older clients already ignore unknown members per §2).
  • No capability token, no new endpoint, no required-field change.
  • Client behavior guidance included in the spec text: presence, absence, or content of these fields must not be treated as a legality/authorization/identity certification by any reader, registry, or the protocol itself.

Security / privacy / accessibility / copyright

  • No PII collection; these are source-operator-supplied, publicly-displayed strings the operator already controls.
  • contactUrl is constrained to absolute HTTP(S), consistent with iconUrl/websiteUrl.
  • Encourages copyright/authorization transparency rather than affecting it.

Test plan

  • dart format --output=none --set-exit-if-changed examples/dart_server.dart tool/conformance_test.dart
  • dart analyze examples/dart_server.dart tool/conformance_test.dart — no issues
  • dart run tool/conformance_test.dart — 67 checks passed
  • python scripts/validate_contracts.py / registry_tool.pycould not run locally, no Python interpreter available in this environment. Only touched schemas/discovery.schema.json with straightforward additive JSON Schema draft 2020-12 properties, but please let CI confirm.

🤖 Generated with Claude Code

An independent ORSP-compatible reader (Open Reading) already ships
operatorName, contactUrl, contentLicense, and rightsStatement as
optional discovery-document fields, letting a source identify its
operator and content authorization basis for client-side transparency
display. They were never upstreamed here, so this spec has no
normative definition for fields a real implementation already relies
on.

This adds them as optional discovery members (purely additive, no
existing field or endpoint behavior changes), documents them in both
SPECIFICATION.md and SPECIFICATION.zh-CN.md, types them in
schemas/discovery.schema.json, and has the reference server declare
them with conformance checks covering their presence and shape.

Left protocolVersion / spec version headers untouched — bumping those
is a release decision for maintainers, not something this PR assumes.
@miloquinn
miloquinn merged commit 72b0863 into main Jul 20, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant