v11 update: TLS channel binding token access from ITlsConnectionFeature

Mettez à jour fundamentals/request-features.md après l’entrée ITlsConnectionFeature à la ligne 131, en utilisant une nouvelle zone de moniker >= aspnetcore-11.0. Inspectez d’abord la structure de monikers environnante et l’article HTTP.sys associé, puis documentez TryGetChannelBindingBytes et son comportement comme indiqué. C’est terminé lorsque la zone est équilibrée, que le lien relatif se résout et que les références d’API sont correctement rendues.

Target repository: dotnet/AspNetCore.Docs
Analyzed at commit: 4986136881f2bbf1879f10106467769df5a49932
Product source verified at: dotnet/aspnetcore @ 1fcd7ef305697a1888f3ede076010350ae9f4f8d
Source release note: TLS channel binding token access from ITlsConnectionFeature

---

🎯 Goal

⚠️ This issue is the deferred server-side half of #37710 (Negotiate authentication uses TLS channel binding). #37710 documented the consumer half — Negotiate on Kestrel automatically using the endpoint channel binding token — and explicitly deferred the API that exposes the token to application code. That API is the subject here: the new ITlsConnectionFeature.TryGetChannelBindingBytes default interface method. See Review considerations for the three concepts that must not be conflated.

ITlsConnectionFeature is documented in fundamentals/request-features.md, but only as "an API for retrieving client certificates." The new TryGetChannelBindingBytes method — which lets any server-agnostic app retrieve an RFC 5929 channel binding token — is absent. Add a version-scoped note there, cross-linking the HTTP.sys breaking-change article (which covers the HTTP.sys implementation) and #37710 (the Negotiate consumer).

This item adds a new API (TryGetChannelBindingBytes) to an existing interface, so it's a net-new symbol, not a pure behavior change.

---

✅ Coverage status summary

Legend: ✅ already documented · ✏️ update needed · 🟣 could not determine

#	Feature element from What's New	Status	Where
1	HTTP.sys implementation — configures HttpServerChannelBindProperty by default so the endpoint CBT is exposed through the new API	✅	breaking-changes/11/httpsys-channel-binding-token-enabled.md
2	Negotiate authentication consuming the endpoint CBT on Kestrel automatically	✅ (tracked)	#37710 — the consumer half; this issue is its deferred counterpart
3	ITlsConnectionFeature.TryGetChannelBindingBytes(ChannelBindingKind, out ReadOnlyMemory<byte>) — the new server-agnostic API for retrieving a channel binding token from app code	✏️	1. Update — after fundamentals/request-features.md L131
4	Kestrel implementation of the method (via SslStream.TransportContext.GetChannelBinding)	✏️	Same insertion — the note should state Kestrel supports it, not only HTTP.sys
5	Intended use — Extended Protection for Authentication (EPA) / binding credentials to the TLS channel to mitigate relay attacks	✏️	Same insertion (one sentence of purpose)

---

🔢 Version applicability

Applies to: CURRENT-ONLY
Target moniker: >= aspnetcore-11.0
Earlier versions affected: None — TryGetChannelBindingBytes is a new default interface method on net11.0. The ITlsConnectionFeature interface itself predates it and stays documented for all versions.

Article	monikerRange	Moniker state
fundamentals/request-features.md	(no front-matter monikerRange; version-agnostic article, zoned inline)	State B — the ITlsConnectionFeature entry at L131 sits in unzoned content: the preceding :::moniker-end is at L125 and the next :::moniker range=">= aspnetcore-2.2" opens at L135, so L131 is outside any zone. Adding 11.0-only content here needs only a new >= aspnetcore-11.0 zone (open + close) — no surrounding zone to close and reopen.

The insertion point is not inside any # [Tab](#tab/...) group, so no tab-nesting hazard applies.

---

📋 Coverage gap summary

A developer implementing channel-binding-aware authentication — or auditing how their app can obtain a TLS channel binding token independent of the server — looks up ITlsConnectionFeature and, in fundamentals/request-features.md, finds only "Defines an API for retrieving client certificates." The new TryGetChannelBindingBytes method, the whole point of this release note, is invisible there. The HTTP.sys breaking-change article documents the HTTP.sys server's behavior, and #37710 covers Negotiate's consumption, but the server-agnostic application API — the thing a reader of the feature interfaces page needs — is documented nowhere.

Feature announced in What's New:

ITlsConnectionFeature now exposes TryGetChannelBindingBytes, allowing applications to retrieve the TLS channel binding token (for example, the RFC 5929 endpoint token) for the current connection. Kestrel and HTTP.sys both implement it. Channel binding lets an authentication layer bind credentials to the underlying TLS channel, mitigating credential-relay attacks.

Product source confirms the API: ITlsConnectionFeature.cs declares the new default interface method:

public bool TryGetChannelBindingBytes(ChannelBindingKind kind, out ReadOnlyMemory<byte> channelBindingBytes)
{
    channelBindingBytes = default;
    return false;
}

Kestrel's implementation retrieves the token from SslStream.TransportContext.GetChannelBinding(kind). ChannelBindingKind is a dotnet/runtime type (System.Security.Authentication.ExtendedProtection); its reference below is unpinned main, since the runtime repo wasn't pinned for this analysis.

Breaking change: The HTTP.sys default-on behavior is a breaking change (documented — element 1). The API addition itself is additive (default interface method).

---

📁 Affected files

Item	Path	Lines	Section
1.	fundamentals/request-features.md	after 131	Feature interfaces list (ITlsConnectionFeature entry)

Target article uids: fundamentals/request-features

---

📝 Proposed changes

✏️ 1. Update — request-features.md, add a >= aspnetcore-11.0 zone after the ITlsConnectionFeature entry (State B)

Applies to: >= aspnetcore-11.0
Location: Line 131 — immediately after the ITlsConnectionFeature paragraph and before the ITlsTokenBindingFeature paragraph (L133), in unzoned content (State B, new zone only).

Before (lines 131–133):

<xref:Microsoft.AspNetCore.Http.Features.ITlsConnectionFeature>: Defines an API for retrieving client certificates.

<xref:Microsoft.AspNetCore.Http.Features.ITlsTokenBindingFeature>: Defines methods for working with TLS token binding parameters.

After:

<xref:Microsoft.AspNetCore.Http.Features.ITlsConnectionFeature>: Defines an API for retrieving client certificates.

:::moniker range=">= aspnetcore-11.0"

In .NET 11 and later, `ITlsConnectionFeature` also defines `TryGetChannelBindingBytes(ChannelBindingKind, out ReadOnlyMemory<byte>)`, which retrieves an [RFC 5929](https://www.rfc-editor.org/rfc/rfc5929) TLS channel binding token—for example, the endpoint token requested with `ChannelBindingKind.Endpoint`—for the current connection. Channel binding lets an authentication layer bind credentials to the underlying TLS channel, mitigating credential-relay attacks (Extended Protection for Authentication). Kestrel implements the method over `SslStream.TransportContext.GetChannelBinding`; HTTP.sys exposes the token by default (see [HttpSys enables TLS channel binding token exposure by default](../breaking-changes/11/httpsys-channel-binding-token-enabled.md)). The method returns `false` when a token isn't available for the requested `ChannelBindingKind`.

:::moniker-end

<xref:Microsoft.AspNetCore.Http.Features.ITlsTokenBindingFeature>: Defines methods for working with TLS token binding parameters.

Rationale: The insertion point is unzoned, so a single new >= aspnetcore-11.0 zone (State B) is correct — no surrounding zone to split. Placing the note directly under the ITlsConnectionFeature entry keeps the new method next to the interface it extends. The note cross-links the HTTP.sys breaking-change article (the server-specific ✅ coverage) rather than duplicating it, and points to the RFC for the token semantics.

---

✅ 2. Update — TOC

No TOC change required. The edit adds a note to an existing article; no new file is created. (Worth noting for apply order: this issue proposes no toc.yml change, so there's no composition collision with #37711's TOC insertion.)

---

✅ Action plan

1. Confirm element 1 (HTTP.sys breaking-change article) — already published.
2. Apply change 1 as a State B new zone (open >= aspnetcore-11.0, note, :::moniker-end); verify balance is net-zero (one open, one close) and the surrounding unzoned paragraphs are untouched.
3. Confirm the relative link ../breaking-changes/11/httpsys-channel-binding-token-enabled.md resolves (that article has no uid).
4. Verify ChannelBindingKind / ReadOnlyMemory<byte> render correctly inside the code span, and that <byte> isn't parsed as HTML (it's inside backticks).

---

⚠️ Review considerations

• Keep three distinct concepts separate — a reader must not conflate them:
  1. ITlsConnectionFeature.TryGetChannelBindingBytes — the server-agnostic application API (this issue). Home: fundamentals/request-features.md.
  2. HTTP.sys default CBT exposure — the server enabling HttpServerChannelBindProperty by default (breaking change, httpsys-channel-binding-token-enabled.md). This is a different, HTTP.sys-specific mechanism; it is the ✅ implementation of element 1, not a duplicate of the API note.
  3. Negotiate consuming the endpoint CBT on Kestrel — the consumer, #37710. Distinct again from HTTP.sys HttpSysOptions authentication hardening knobs such as HttpAuthenticationHardeningLevel.
• Forward-link discharge. #37710's "Review considerations" flagged this server-side/API half as deferred. This issue discharges that forward link; a reciprocal comment has been posted on #37710.
• Namespace check. request-features.md references Microsoft.AspNetCore.Http.Features.ITlsConnectionFeature, matching the product path src/Http/Http.Features/src/ITlsConnectionFeature.cs. The xref target is correct.
• 🟣 Optional Kestrel-side example. A short usage snippet could live in a Kestrel security article, but request-features.md is the canonical interface home and the right minimal fix. A worked EPA example is a larger, discretionary follow-up, not part of this gap.

---

🔗 References

• What's New section: TLS channel binding token access from ITlsConnectionFeature
• Forward-linked issue: #37710 — Negotiate authentication uses TLS channel binding (consumer half; this issue is the deferred server-side/API half).
• HTTP.sys implementation (✅): breaking-changes/11/httpsys-channel-binding-token-enabled.md
• Docset target (✏️): fundamentals/request-features.md L131
• Product source: src/Http/Http.Features/src/ITlsConnectionFeature.cs — new TryGetChannelBindingBytes default interface method.
• ChannelBindingKind: System.Security.Authentication.ExtendedProtection.ChannelBindingKind — dotnet/runtime, unpinned main (runtime repo not pinned for this analysis).