[mike-kiser-sp]

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.0 vs 1.1 stays a clean diff:

1. Add new SSF, CAEP, and RISC documents 1.1 from 1.0 — verbatim copies, no content changes.
2. Update SSF, CAEP, and RISC document versions to 1.1 — bump title/docname, let the
   date be generated at build time, and group the specs into 1.0/ and 1.1/ folders
   matching the OpenID4VCI layout.
3. Declare the v1.1 CAEP event type base URI — see below.

Notes

• The three 1.0 documents are byte-identical to main; they simply move into 1.0/.
  They remain the documents that errata are applied to.
• README.md gains a Final Specifications table linking the 1.0 documents
  (per @tulshi's point about linking 1.0 from the spec page).
• The Makefile, CI workflow, and .gitignore are updated for the new paths and
  now build both trees. The CAEP Interoperability Profile targets added in Create Draft-01 for OIDF Review #343 are retained.
• The v1.1 CAEP event type base URI is taken from Add an option to report device management status change to device compliance change signal #329, which the WG agreed on 08-11
  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_version in the SSF examples still reads "1_0". Should the 1.1 document's
  examples say "1_1"? Left unchanged here since it is protocol-visible content
  rather than a mechanical version bump.
• The CAEP Interoperability Profile stays at the repo root rather than moving into
  1.0/, since it is mid-public-review with its own version line.
• Per @thomasdarimont, the 1.1 changes will require conformance suite updates.

[jischr]

whole line date: can be removed. it will autopopulate

[jischr]

@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.

[jogu]

@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.

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.

[appsdesh]

@mike-kiser-sp Looks like this will not handle the previous IDs in this proposal. Also, would this increase manual work with every revision bump? Should we consider using git tags when we freeze a version?