Create 1.1 draft documents from 1.0, retaining 1.0 - #310
Open
mike-kiser-sp wants to merge 3 commits into
Open
mike-kiser-sp wants to merge 3 commits into
mike-kiser-sp wants to merge 3 commits into
Conversation
jischr
reviewed
Dec 19, 2025
| docname: openid-caep-1_0 | ||
| date: 2025-08-29 | ||
| docname: openid-caep-1_1 | ||
| date: |
Contributor
There was a problem hiding this comment.
whole line date: can be removed. it will autopopulate
Contributor
|
@mike-kiser-sp im not sure if it was discussed, but wondering if we should keep v1 and create new files for v1.1? i could see either way. |
Contributor
I would think it makes sense to keep 1.0, as that file would be the one that's updated if any errata updates are to be made. That's how, e.g., FAPI handled 1.0 / 2.0, and OID4VP is handling 1.0 / 1.1. |
Copied verbatim from the 1.0 documents with no content changes, so that the provenance is recorded in history and 1.0 vs 1.1 remains a clean diff.
Bump title/docname to 1.1 in the new documents and let the date be generated at build time. Group the specs into 1.0/ and 1.1/ folders following the layout used by OpenID4VCI and OpenID4VP, retaining 1.0 as the published Final Specifications that errata are applied to. Update the Makefile, CI workflow, .gitignore, and README for the new paths.
Events added or updated by 1.1 use the .../event-type/v1.1 base URI, while 1.0 event types are not deprecated. Taken from Yair Sarig's PR openid#329, which the WG agreed on 2026-08-11 should land in the versioning PR. The device management status change feature and its contributor entry remain in openid#329.
mike-kiser-sp
changed the title
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Creates the 1.1 draft documents while retaining the published 1.0 Final
Specifications, per the WG discussion on
2026-08-11.
This replaces the earlier approach in this PR, which renamed the 1.0 files to
1.1 and did not keep 1.0.
Approach
Follows the sequence OpenID4VCI/OpenID4VP used, as relayed by Thomas from Joseph,
so that the provenance is recorded in history and
1.0vs1.1stays a clean diff:date be generated at build time, and group the specs into
1.0/and1.1/foldersmatching the OpenID4VCI layout.
Notes
main; they simply move into1.0/.They remain the documents that errata are applied to.
README.mdgains a Final Specifications table linking the 1.0 documents(per @tulshi's point about linking 1.0 from the spec page).
Makefile, CI workflow, and.gitignoreare updated for the new paths andnow build both trees. The CAEP Interoperability Profile targets added in Create Draft-01 for OIDF Review #343 are retained.
should land here. The device management status change feature and its contributor
entry remain in Add an option to report device management status change to device compliance change signal #329, which will need a rebase onto this.
Open questions for the WG
spec_versionin the SSF examples still reads"1_0". Should the 1.1 document'sexamples say
"1_1"? Left unchanged here since it is protocol-visible contentrather than a mechanical version bump.
1.0/, since it is mid-public-review with its own version line.