IETF STIR WG — Meeting Notes

Date: 5 Nov 2025

Acknowledgements

• The chairs would like to thank Rob Sliva for taking excellent notes.

1) rfc8588bis (Mary Barnes)

Proposed updates

• Fix known errata (e.g., 'IET' field quoting).
• Update UUID reference (newer version is available).
• Update ATIS references: point to the version that is current at the
  time of publication of the RFC; use SIP Forum hosted mirrors where
  appropriate due to ATIS “latest-only” policy.

Discussion highlights

• Whether to make the UUID reference normative/required was
  raised; backward-compatibility concerns noted (some UUIDs embed SP
  name; usage in practice unclear).
• Call for any additional clarifications while the doc is fresh.

Decision / Rough Consensus

• Adopt 8588bis as a WG item. Room “thumbs up,” no objections.
• Chairs propose simultaneous WG adoption + WG Last Call if
  feasible.

Actions

• Mary Barnes: Submit WG version of rfc8588bis after a successful
  call for adoption.
• Chairs: Start WG Last Call in parallel.
• WG: Review for any remaining unclear text and small editorial
  fixes.

2) STIR Certificate Transparency Profile (Chris Wendt)

Status

• draft-ietf-stir-certificate-transparency considered “ready to
  go” for WG Last Call; profile keeps close to baseline CT.

Discussion highlights

• Jon Peterson: Document needs finishing touches; Security
  Considerations section currently placeholder-ish (“TODO” in
  document).
• Agreement to add/complete security considerations prior to WG Last
  Call.

Decision / Rough Consensus

• Proceed to WG Last Call after Security Considerations are
  completed.

Actions

• I-D authors (Chris Wendt et al.): Add and finalize Security
  Considerations, then notify chairs.
• Chairs: Issue WG Last Call once updated I-D is posted.
• WG: Please read and provide WG Last Call feedback.

3) Vesper Framework (Chris Wendt)

Update summary (–04)

Themes to integrate:

• Authority tokens → RTU (e.g., TNAuthList + JWT Claim
  Constraints).
• Delegate certificates → end-to-end auth.
• Transparency → ecosystem assurance/accountability.

Flow pieces: Delegate Certificate Issuance; AS/VS usage.

New Additions:

• Connected Identity.
• Claim-Constraint Transparency.

Privacy protection knobs (proposal):

• Transparent value, Semi-private (hash), Private (salted
  commitment).

Discussion highlights (requirements-first message)

• Jon Peterson:

  • Start with use cases and threat models: what data must be
    private, from whom, and why?
  • Data typically in PASSporT should be actionable at call
    time; longer-lived/entity attributes may belong in cert
    extensions (not per-call tokens).
  • Explore whether connected-identity/GLUE/SPICE attributes should
    be certificate-level (X.509 name/altName/other ext) rather
    than PASSporT claims.

• Ben Campbell:

  • Growing role of agents/AI answering calls; machine consumers
    may process more/other data than humans—implications for
    what to expose at ring-time.

• Orie Steele (as individual & later as AD):

  • Decouple selective disclosure and transparency—use cases may
    differ; don’t couple them by default.
  • Avoid adopting a protocol doc “for discussion.” Prefer a
    use-case/requirements doc to decide which bits belong in
    certs vs. tokens, and which crypto knobs are justified.

• General:

  • Acknowledge industry policy fights (KYC/KYB keys/controls).
    IETF should build sprockets, not policy—maximize
    applicability.
  • Consider B2C, C2B, and B2B scenarios explicitly.
  • If properties are mostly about certificate
    issuance/authority, prefer cert extensions over per-call
    PASSporT.

Emerging direction / Rough Consensus

• Pivot Vesper work toward a Use-Cases & Requirements document
  (informational/BCP trajectory possible), defining:

  • Clearly scoped use cases (B2C, C2B, B2B).
  • Threat models & privacy properties (what/why/when).
  • Placement guidance: what belongs in certs vs
    PASSporTs vs transparency.
  • Selective disclosure and transparency as separable
    mechanisms.

Actions

• Chris Wendt (lead), Jon Peterson (offered), and interested
  contributors: Draft an initial Use-Cases & Requirements
  document; socialize on list.
• WG: Volunteers to help define scenarios, threat models, and
  data-placement guidance.

4) Out-of-Band (OOB), ATIS-1000101, ATIS-1000105 APIs, CPS/OOB discovery (Rob Sliwa)

Proposals (early drafts)

1. X.509 optional extension with URIs for OOB endpoints (“CPS” in
   slides read as “Call Placement Service,” not “Certificate Practice
   Statement”).

   • Goal: discovery in a delegate-certificate world; backwards
     compatible (optional ext).

2. CT monitors as discovery cache: if delegate certs are logged,
   monitors can extract and offer a lookup cache for OOB
   endpoints/certs.

Discussion highlights

• Jon Peterson:

  • Beware discovery chicken/egg: needing OOB to discover cert
    vs. needing cert to discover OOB.
  • “Push everything” vs. discovery via CT monitors are
    operationally equivalent in load/complexity for small
    ecosystems like SHAKEN; CT wrapper may not reduce cost vs.
    direct distribution.
  • Security implications depend on who selects the OOB
    endpoint (CA vs. originating vs. terminating side); different
    privacy models.

• Terminology gotcha:

  • CPS here meant Call Placement Service, not Certificate
    Practice Statement (Sean Turner flagged potential confusion).

• Security properties:

  • ATIS 101 105 URL structures and endpoint patterns may have
    security issues; if referenced in IETF doc, ensure we’re not
    importing flawed patterns.

• Post-Quantum/PLONK/PLANTS aside:

  • Acknowledge interest in modern ledger/transparency/PQ trends;
    not an immediate need for STIR’s short-lived artifacts, but keep
    watching space.

Actions

• WG: Revisit OOB discovery mechanisms after use-cases & security
  models are documented.
• Authors: Consider alternative placements (existing X.509
  fields), and map who chooses endpoints in each use case.

5) Charter & Process

Discussion

• Current charter may be too broad/vague for the emerging work (e.g.,
  KYC/KYB, connected identity, transparency/SD).
• Orie Steele (AD): Prefer to tighten/modernize the charter
  and identify expected deliverables before diving deeply into a new
  requirements doc, to avoid scope creep.

Actions

• Chairs: Start a recharter discussion on the mailing list;
  propose a concise charter with named deliverables (e.g., Vesper
  Use-Cases/Requirements; sti-ct profile; rfc8588bis).
• WG: Contribute text and priorities; if list discussion stalls,
  schedule an interim focused on rechartering.

Decisions (Quick List)

• Adopt 8588bis as a WG item; pursue WG Last Call in tandem if
  ready.
• stir-certificate-transparency to WG Last Call after Security
  Considerations are completed.
• Vesper: Consensus direction to start with Use-Cases &
  Requirements (threat models, placement guidance), not protocol
  design first.
• Charter: Rechartering is timely; move discussion to list;
  interim if needed.

Open Questions

• Which Vesper use cases (B2C, C2B, B2B) require ring-time
  signals vs. post-call transactions?
• Exact threat models for semi-private/private claims (who learns
  what, when, and why)?
• Placement: which attributes go in cert extensions vs.
  PASSporT vs. transparency receipts?
• OOB discovery: who selects endpoints; how to avoid discovery
  chicken/egg; what security properties are mandatory?
• Interaction with SPICE/GLUE identifiers and knowledge-graph
  processing; alignment vs. minimal coupling.

Action Items (with owners)

1. rfc8588bis WG submission — Mary Barnes

   • Submit WG version after successful call for adoption; coordinate
     with chairs on simultaneous WG Last Call.

2. stir-certificate-transparency: Security Considerations — Chris
   Wendt & co-authors

   • Complete and post updated draft; notify chairs for WG Last Call.

3. Vesper Use-Cases & Requirements draft — Chris Wendt (lead), Jon
   Peterson (offered), volunteers welcome

   • Define scenarios (B2C/C2B/B2B), data/claim placement, threat
     models, privacy properties, and (de)coupling of SD vs.
     transparency.

4. Recharter proposal — Chairs

   • Kick off list discussion; propose concise charter +
     deliverables; plan interim if list diverges.

5. OOB discovery & CT-cache proposals — Authors/WG (deferred)

   • Re-evaluate after use-cases/charter tighten; clarify CPS (Call
     Placement Service) terminology; assess ATIS 101 105 security
     aspects before referencing.

Requests to the WG

• Please review the updated sti-ct once Security
  Considerations land.
• Participate in the recharter thread with concrete
  deliverables.
• Volunteer for the Vesper Use-Cases & Requirements drafting
  team.