EBL 3.0: SD-2840: Remove TODO from specs

[HenrikHL]

User description

SD-2840: Remove TODO from the specs

---

PR Type

Documentation

---

Description

• Remove TODO comments from specification files

• Clean up outdated task markers in schema documentation

• Maintain existing example values and descriptions

---

Diagram Walkthrough

flowchart LR
  A["TODO Comments in Specs"] -- "Remove" --> B["Clean Documentation"]
  B -- "Preserve" --> C["Examples and Descriptions"]

Loading

File Walkthrough

Relevant files

Documentation

EBL_ISS_v3.0.3.yaml Remove TODO from issuanceManifestSignedContent                      ebl/v3/issuance/EBL_ISS_v3.0.3.yaml Removed TODO comment from issuanceManifestSignedContent field Kept existing JWS example and description intact +0/-1      EBL_PINT_v3.0.0.yaml Remove TODO comments from PINT specification schemas          pint/v3/EBL_PINT_v3.0.0.yaml Removed 5 TODO comments from various schema fields Cleaned up task markers from lastEnvelopeTransferChainEntrySignedContentChecksum, EnvelopeManifestSignedContent, previousEnvelopeTransferChainEntrySignedContentChecksum, issuanceManifestSignedContent, EnvelopeTransferChainEntrySignedContent, EnvelopeTransferFinishedResponse, and EnvelopeTransferFinishedResponseSignedContent Preserved all example values and field descriptions +0/-9

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #SD-2840 🟢 Remove `TODO` comments from the modified specification files. ⚪ Confirm that all remaining TODO occurrences across the full repository/spec set (outside the shown diff hunks) have been removed.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Align inconsistent examples for clarity Align the inconsistent top-level and property-level examples for lastEnvelopeTransferChainEntrySignedContentChecksum in the EnvelopeTransferFinishedResponse schema to avoid confusion. pint/v3/EBL_PINT_v3.0.0.yaml [990-1004] EnvelopeTransferFinishedResponse: type: object required: - lastEnvelopeTransferChainEntrySignedContentChecksum - responseCode example: lastEnvelopeTransferChainEntrySignedContentChecksum: d56a93a7e9f86a2d895df818e0440bdca6ffe03246e2fee14131f2e66c84c75a responseCode: RECE properties: lastEnvelopeTransferChainEntrySignedContentChecksum: type: string minLength: 64 maxLength: 64 pattern: ^[0-9a-f]+$ description: | This attribute should contain the checksum of the last [`EnvelopeTransferChainEntrySignedContent`](#/EnvelopeTransferChainEntrySignedContent) entry in the [`EblEnvelope.envelopeTransferChain[]`](#/EblEnvelope) list received. The checksum is computed using SHA-256 hash algorithm according to [RFC 6234](https://datatracker.ietf.org/doc/html/rfc6234). - example: 20a0257b313ae08417e07f6555c4ec829a512c083f3ead16b41158018a22abe9 + example: d56a93a7e9f86a2d895df818e0440bdca6ffe03246e2fee14131f2e66c84c75a [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies an inconsistency between a top-level example and a property-level example, which can cause confusion. Fixing this improves the clarity and usability of the API specification.	Low
More