Week ending August 14, 2026 — Sector Watch

RFC 10006 was published this week and turns a SIP service provider’s STIR posture into a field an enterprise can fetch. The document defines a capability set an enterprise telephony network retrieves from its provider over HTTPS, and one container in that document reports whether the provider is STIR compliant, whether it will delegate certificate authority over the number ranges it has allocated to that enterprise, which ranges those are, and the ACME directory URL where the delegate certificates are issued. An enterprise that wants to sign its own calls has had to establish each of those bilaterally with the carrier.

Standards in motion

Delegate-certificate scope becomes a field in a discovery document. RFC 10006, Automatic SIP Trunking and Peering, was published in August 2026 as a Proposed Standard from the IETF ASAP working group. Authors are Kaustubh Inamdar and Sreekanth Narayanan, both unaffiliated, and Cullen Jennings of Cisco Systems. The enterprise finds the provider’s capability server using the sip-trunking-capability link relation from RFC 9409 and retrieves a YANG-modelled document covering transport, codecs, call routing, and identity. Inside it, the secure-telephony-identity container carries three nodes: stir-compliance, a boolean; certificate-delegation, which may only appear when stir-compliance is true and states whether the provider will delegate authority over allocated number ranges to the enterprise; and acme-directory, a URI that may only appear when certificate-delegation is true and points at the ACME directory object for those certificates. The scope of the delegation — the numbers and ranges themselves — is carried in the document’s num-ranges container.

The delegation nodes are specific enough to write code against: they name the ranges and the endpoint that issues the certificates. The compliance node is not. stir-compliance is described in the module as indicating that a provider “is STIR compliant,” with no normative reference to a STIR RFC anywhere in the document, and the only certificate reference is RFC 8555, base ACME rather than any STIR delegated-certificate profile. A boolean tells an enterprise that its provider does something called STIR; it does not say which profile, which is the question that determines whether the enterprise’s own signing will validate downstream. Adoption read: the RFC has no implementation status section and names no implementers. The signal to watch is a service provider publishing a capability set at a well-known location, because the specification is worth nothing until one side of the trunk serves the document.

OpenID Connect Key Binding goes to a member vote on August 24. The OpenID Foundation gave notice on August 10 that OpenID Connect Key Binding 1.0 will be voted on between August 24 and September 7 as a first Implementer’s Draft, after a 45-day review that opened July 9 and closes August 23. The specification, draft 02 published July 30 by Dick Hardt of Hellō and Ethan Heilman of Cloudflare, binds a public key to an ID Token. The relying party adds the bound_key scope and a dpop_jkt parameter to the authentication request, then sends a DPoP header containing the SHA-256 of the authorization code with the token request; the provider returns an ID Token carrying a cnf claim (RFC 7800) with the public key. It adds no new endpoints, messages, or responses, profiling OpenID Connect, the device authorization grant, and DPoP instead. A provider advertises support by listing bound_key in scopes_supported in its discovery metadata, so a relying party can detect it without asking.

An ID Token passed from the component of a relying party that authenticated the user to a component that consumes it is a bearer token, and an attacker who captures it in transit can present it as the authenticated user. The use-cases appendix names three: a mobile app exchanging an ID Token for an access token, a split frontend and backend, and peer-to-peer authentication in messaging or video, where one instance signs its media-channel fingerprint under the bound key so the other can tie the authenticated identity to the connection. The security considerations run six subsections, including a public-key substitution attack the c_s256 claim exists to prevent. The privacy considerations run one sentence: a SHOULD that the authenticating component share the ID Token only consistently with the purpose the data was collected for. Adoption read: no implementations are named, and until the vote closes there are no IP protections for anyone who ships it. Because it is a profile over DPoP with no new endpoints, an existing provider can add it without changing its deployment shape; the cost is a metadata entry and a validation step in the token endpoint.

Implementations & adoption

The MCP interop roster closed on August 10. The commitment window for the OpenID Foundation AIIM community group’s interoperability event closed at end of day Pacific on August 10. Participants take one of five roles — MCP client, OpenID provider, OAuth authorization server, MCP gateway, MCP server — and must test at least one interaction with a participant in a complementary role. The standards under test are OAuth 2.1, the OAuth Client ID Metadata Document draft, which lets a client identify itself by a URL without prior registration, and Enterprise Managed Authorization, an MCP extension built on the Identity Assertion JWT Authorization Grant, which is in turn built on OAuth identity chaining. Two scenarios are in scope: whether only authorized agents reach enterprise resources, and whether an agent in one organization can reach an MCP server in another without the user logging in again.

MCP’s own authorization extension points at IETF OAuth drafts rather than defining a scheme of its own, which puts the agent-identity question on the open side of the axis at the specification layer. The event tests whether that holds across implementations. Each participant keeps its own matrix of which standards it tested and with how many partners, both sides agree a result before it is submitted, and the community group consolidates them into a published record. Adoption read: the participant list is not published. By October 16 each participant must show one successful test with a partner, and the results are presented at the Gartner IAM Summit in Las Vegas, December 7–9. The count to watch is pairwise tests completed.

A certificate against ETSI TS 119 461 rather than an assurance claim. Seon’s identity verification software was certified to the Extended Level of Identity Proofing under ETSI TS 119 461, reported August 14. Extended LoIP is the higher of the two levels the standard specifies, and the assessment also covered ETSI EN 319 401, the operational and security requirements for trust service providers. The certified components are document verification with NFC chip reading or an optical check with human fallback, face biometrics with passive liveness detection, injection-attack detection, and eID integration; the same report says the software was approved for age verification in Germany. TS 119 461 is the identity-proofing standard the eIDAS 2.0 regime relies on, and Extended LoIP is referenced by the EU’s incoming anti-money-laundering regulation. Adoption read: a level certified rather than a level asserted. What it is worth depends on whether member-state schemes require the certification or accept a supplier’s own attestation.

Capital & motivation

Atul Tulshibagwale co-chairs the AIIM community group running the MCP interoperability event and is Senior Director for Continuous Identity Strategy at CrowdStrike. The named authors of the CAEP Interoperability Profile, which opened its 60-day final review on July 27, sit at CrowdStrike and Okta. CrowdStrike staff are carrying the conformance work for two different open specifications in the same year, session security and agent identity.