Repository navigation
docs: cite requirements that exist - #7
Merged
xgreenx merged 1 commit intoSep 8, 2026
Merged
Conversation
`attestation.rs` says it plainly: REQ-COMMON-47 through -61 are not in the published specification. They were written in libid PR #12, which defined this byte layout and closed on 2026-08-20 without merging. The module kept the numbering on the intent of upstreaming the layout under those identifiers. That has not happened, and the contracts are the side that decides: they were the second implementation carrying the same vocabulary, and libid-org/libID-contracts#27 drops it there. This follows, so the two keep naming the same rules by the same names. Where a published requirement says the same thing, the citation moves to it: -47, -49, -61 -> REQ-COMMON-33, which has the Notary Service take the attested data and its signature and return one decision covering that signature over exactly those bytes, and decide nothing profile-specific. -56 -> REQ-COMMON-21 and REQ-COMMON-21A, which have the notary authenticate the TLS server identity and the Platform Verifier compare the authenticated authority byte for byte with its pinned constants. -48, -57, -59 and -60 have no published counterpart. The rules stay, stated in full where they were; only the identifiers go. The one they were standing in for is REQ-COMMON-18, which requires a Platform Profile to fix the attestation format and leaves the format to the profile author -- so the module header now says the layout is the profile's rather than calling itself section 9.1, which is attestation verification and its fee and defines no bytes. Comments only. 100 tests, clippy and nightly fmt unchanged. Assisted-by: Claude Opus 5 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
xgreenx
marked this pull request as ready for review
September 7, 2026 22:03
This was referenced Sep 7, 2026
SupremaLex
approved these changes
Sep 8, 2026
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
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.
Stacked on #2 (
feat/ceremony-constructions). Comments only — no behaviour changes.attestation.rsalready said it, under a heading of its own:REQ-COMMON-47through-61are not in the published specification. They come from libid#12, which defined this byte layout and closed on 2026-08-20 without merging. The module kept the numbering on the intent of upstreaming the layout under those identifiers.That has not happened, and the contracts decide what these names mean — they carry the same vocabulary and libid-org/libID-contracts#27 drops it there. This follows, so both sides keep naming the same rules by the same names.
Where each one went
-47,-49,-61REQ-COMMON-33-56REQ-COMMON-21,-21A-48,-57,-59,-60-57that is now spelled out: the freshness window the verifier enforces is measured fromcreatedAt, so a reading the observed party could choose would be a window it could choose.The requirement they were collectively standing in for is
REQ-COMMON-18, which has a Platform Profile fix the attestation format and leaves the format to the profile author. The module header now says the layout is the profile's, instead of calling itself "the attestation format of ceremony-common section 9.1" — §9.1 is attestation verification and its fee, and defines no bytes.Verification
cargo +nightly fmt --all -- --checkcargo clippy --workspace --all-targets -- -D warningscargo test --workspace— 100 passedSibling
#6 removes
libid-attestationson the same base. The two do not touch the same files.