Skip to content
AirCommerce Architecture Portal

Template interface description

VERSION: Meaningful name of the interface version

Section titled “VERSION: Meaningful name of the interface version”

  • INTRODUCED BY: Link to HLD that defined this interface version

  • IMPLEMENTED BY: TBD (when ICD is ready, put here link to ICD, providing major version number)

  • DEPRECATED BY: Link to HLD that deprecated this interface version

  • Owner application: Name the application this interface belongs to

  • Interface patterns: Put here links to relevant sections of the Architecture Patterns page (use link to full pattern page!) with the name of the patterns implemented by this interface.

  • Security scenario: Select one of: event-over-PubSub/event-over-HTTP/command-over-HTTP/command-over-PubSub and one of: client authority/internal authority

(TIP)

Describe here the design of the interface, technical requirements that must be met by this interface, high level guarantees the interface should provide, how it should work (on high level) and what should be specified in the relevant ICD (if not clear from the interface patterns linked above). Mention how this interface supports a specific use case if it’s relevant (details should be described in the use case itself).

Define v* anchors to the sections to enable reliable linking and link to the right version of the interface wherever it’s relevant.

VERSION: Meaningful name of another interface version

Section titled “VERSION: Meaningful name of another interface version”

  • INTRODUCED BY: Link to HLD that defined this interface version

  • IMPLEMENTED BY: TBD (when ICD is ready, put here link to ICD, providing major version number)

  • Owner application: Name the application this interface belongs to

  • Interface patterns: Put here links to relevant sections of the Architecture Patterns page (use link to full pattern page!) with the name of the patterns implemented by this interface.

  • Security scenario: Select one of: event-over-PubSub/event-over-HTTP/command-over-HTTP/command-over-PubSub and one of: client authority/internal authority

(TIP) If there are more active versions of the interface, add more sections describing subsequent versions.

High Level Design Use Cases

Section titled “High Level Design Use Cases”
Showing 1 of 1 high-level designs
DateAuthorStatusTitle
1970-01-01Your NameAcceptedUse case template

Threat Assessments

Section titled “Threat Assessments”

(TIP)

Each subsection below is one threat assessment, linked to the HLD that triggered it. Add a new subsection when this interface is first introduced, or when an HLD changes its security properties (new trust boundary, changed data sensitivity, modified security scenario). Not every HLD that uses this interface needs an entry — only those that require (re)assessment.

For external interfaces (access: external), use the STRIDE per Interaction table (3 columns: Threat | Question | Mitigation):

[HLD title](link to HLD) — YYYY-MM-DD

Section titled “[HLD title](link to HLD) — YYYY-MM-DD”

Reason: Interface introduced / Re-evaluated because [reason]

Threat Question Mitigation
Spoofing Can an actor pretend to be someone/something else? e.g., OAuth2 token validation via Service Mesh
Tampering Can data be modified in transit or at rest? e.g., HTTPS in transit, input validation on receipt
Repudiation Can an actor deny having performed an action? e.g., Comprehensive audit logging with correlation IDs
Information Disclosure Can data leak to unauthorized parties? e.g., Response filtering by OrgID permissions
Denial of Service Can the service be made unavailable? e.g., Rate limiting at API Gateway
Elevation of Privilege Can an actor gain unauthorized access? e.g., Role-based access control via IAM

If a threat is not applicable, write “N/A — <reason>” in the Mitigation column (e.g., “N/A — no user identity context in this data flow”).

For internal interfaces (access: internal), use the security checklist:

[HLD title](link to HLD) — YYYY-MM-DD

Section titled “[HLD title](link to HLD) — YYYY-MM-DD”

Reason: Interface introduced / Re-evaluated because [reason]

  • Is strictly confidential data (e.g., traveler PII, travel documents, payment data, PCI, credentials — see Data Classification Policy) excluded from event payloads whenever it is unnecessary and feasible to do so?
  • Can the sender’s identity be verified?
  • Are there authorization checks preventing cross-application data access beyond what is needed?

Add notes for any “No” answers explaining the rationale or planned follow-up.