Skip to content

Conversation

@MahdiBaghbani
Copy link
Member

Sorry I was late to read the previous PR and missed some details, here are my fixes:

  • Draft consistency fixes (IETF-RFC.md)

    • Fix internal naming mismatches in Appendix D so implementers do not copy the wrong field or token names (for example tokenEndPoint, http-sig, http-request-signatures).
  • OpenAPI alignment (spec.yaml)

    • Correct typos and example drift against the draft (capability token naming, accessTypes plural, and tokenEndPoint wording + examples).
    • Keep the draft's mixed URL forms: inviteAcceptDialog is a path, tokenEndPoint is an absolute URL.
  • Discovery JSON Schema becomes JSONC and follows the draft strictly (schemas/ocm-discovery.jsonc)

    • Use JSONC so we can document the "why" next to the schema.
    • Follow the draft lead: inviteAcceptDialog must start with /, tokenEndPoint must be http(s)://....
    • Include both legacy publicKey (deprecated) and RFC 9421 publicKeys[].

- Fix Appendix D Provider diagram tokens/fields to match the draft
  (tokenEndPoint, http-sig, http-request-signatures, publicKeys[])
- Align spec.yaml wording/examples with the draft (capability tokens, accessTypes,
  tokenEndPoint URL vs inviteAcceptDialog path)
- Move discovery schema to schemas/ocm-discovery.jsonc with draft-strict URL rules

Signed-off-by: Mahdi Baghbani <[email protected]>
Copy link
Member

@glpatcern glpatcern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Mahdi (and happy new year!). I have a comment on the comments ;)

@@ -0,0 +1,88 @@
{
// Discovery schema for OCM API Discovery (JSON Schema, JSONC for comments).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to add comments here? This is possibly to be brought to the WG chairs, also to understand how to evolve the spec and keep things aligned between the I-D, the OpenAPI file and the JSON schemas here.

Maybe I'd take this change out of the PR as the rest is pretty much good to go, and then we discuss this on its own.

| - shareTypes[] | | - exchange-token | |
| - protocols{} | | - http-sig | |
+------------------+ | - invites | |
| | - notifications | |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to see this diagram updated :) the concern is whether to put some ... and refer to the single source of truth in the same document, to avoid this part to drift?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll do it!

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.

3 participants