MCP güvenliği 2026: CIMD, RFC 9207 ve DCR'den çıkış

MCP artık kalıcı bağlantı ve oturum tutan bir protokol değil; 2026-07-28 spesifikasyonuyla birlikte durumsuz (stateless) bir request/response modeline geçti ve bu geçiş, sunucunu yetkilendirme (authorization) katmanında nasıl sertleştireceğini de değiştirdi. RFC 9207 issuer doğrulaması, Client ID Metadata Documents (CIMD) ve Dynamic Client Registration'ın (DCR) emekliye ayrılması — bu üçü aynı spec revizyonunun parçası ve birbirinden ayrı okunduğunda eksik kalıyor. Bu yazıda MCP sunucusu veya istemcisi yazan biri olarak hangi MUST/SHOULD kuralına bugün uyman gerektiğini, hangisinin geçiş dönemi fallback'i olduğunu adım adım göreceksin.

💡 Pro Tip: MCP'de yetkilendirme protokol seviyesinde hâlâ OPTIONAL — ama HTTP tabanlı sunucunda OAuth 2.1 kullanmaya karar verdiğin an, bu yazıdaki MUST kuralların tamamı senin için bağlayıcı hale geliyor.

İçindekiler

• Stateless MCP'de tehdit modeli nasıl değişti
• RFC 9207: issuer doğrulaması ve karışıklık saldırıları
• DCR'nin sorunları
• CIMD ile istemci kimliği
• Client ID Metadata Documents'in riskleri
• Geçiş dönemi: ikisini birden desteklemek
• Token kapsamı ve en az yetki
• Kendi sunucunu sertleştirme denetim listesi
• SSS
• MCP sunucusu nasıl güvenli şekilde yetkilendirilir?
• CIMD nedir, DCR'den farkı ne?
• RFC 9207 issuer doğrulaması neden zorunlu oldu?
• Stateless MCP'de her istek nasıl doğrulanır?
• DCR ne zaman tamamen kaldırılacak?
• Sonuç
• Kaynaklar

Stateless MCP'de tehdit modeli nasıl değişti

MCP ekibi 2026-07-28 tarihli duyuruda protokolün yönünü net koydu: "MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol." Bunun pratik karşılığı, initialize/initialized el sıkışmasının ve Mcp-Session-Id header'ının resmen emekliye ayrılması (SEP-2575, SEP-2567). Artık her istek kendi protokol sürümünü, istemci kimliğini ve yeteneklerini _meta alanında taşıyor.

Bunun güvenlik açısından anlamı şu: herhangi bir istek, paylaşımlı bir depolama katmanı olmadan, düz bir round-robin yük dengeleyicinin arkasındaki herhangi bir sunucu örneğine düşebiliyor. Yani sunucu tarafı oturum durumu artık transport katmanında saklı bir sır değil — kimlik doğrulama her istekte, o isteğin kendi bağlamıyla yapılmak zorunda.

Bir diğer değişiklik: Streamable HTTP istekleri artık Mcp-Method ve Mcp-Name header'larını taşımak zorunda (SEP-2243). Bu, gateway veya WAF'ının JSON body'yi parse etmeden route/metric/rate-limit kararı verebilmesini sağlıyor — ama aynı zamanda header spoofing'in yeni bir saldırı yüzeyi olduğu anlamına da geliyor.

1POST /mcp HTTP/1.1
2Host: api.example.com
3Mcp-Method: tools/call
4Mcp-Name: search_documents
5Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
6Content-Type: application/json
7 
8{"jsonrpc":"2.0","id":7,"method":"tools/call","params":{"name":"search_documents","arguments":{"query":"invoice"}}}

Gateway seviyesinde bu iki header'a güvenmeden önce mutlaka Authorization header'daki token ile birlikte doğrulaman gerekiyor — aksi halde bir istemci Mcp-Name değerini değiştirerek rate-limit veya yetkilendirme kurallarını atlatmayı deneyebilir.

Bu geçişin ölçek boyutu da göz ardı edilmemeli: MCP ekibi aynı duyuruda Tier-1 SDK'larda ayda yaklaşık yarım milyar indirmeye ulaşıldığını, TypeScript ve Python SDK'larının her birinin 1 milyar toplam indirme eşiğini geçtiğini paylaştı. Bir protokolün bu ölçekte "stateful"dan "stateless"a geçmesi, geriye dönük uyumluluğun neden bu kadar dikkatli ele alındığını da açıklıyor — dört Tier-1 SDK (TypeScript, Python, Go, C#) 2026-07-28 spec'ini duyuru günü itibarıyla konuşuyor, Rust SDK ise beta seviyesinde destek veriyor. Kendi sunucunu güncellerken önce kullandığın SDK'nın bu spec sürümüne geçip geçmediğini kontrol etmek, header/iss doğrulaması eklemekten önce gelen bir ön koşul.

RFC 9207: issuer doğrulaması ve karışıklık saldırıları

MCP'nin "tek istemci, birden çok sunucu" dağıtım şekli, klasik bir OAuth "mix-up" (karışıklık) saldırısına özellikle açık: istemci birden fazla yetkilendirme sunucusuyla konuşuyorsa, kötü niyetli bir sunucu kendini başka bir sunucunun yerine geçirip authorization code'u çalabilir. Spec bu açığı SEP-2468 ile kapattı: "Authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code."

Burada önemli bir ayrım var — MCP'de yetkilendirmenin kendisi hâlâ OPTIONAL, yani her MCP implementasyonu OAuth kullanmak zorunda değil. Ama OAuth kullanan implementasyonlarda RFC 9207 issuer doğrulaması artık MUST seviyesinde bir istemci gereksinimi. Yani doğru okuma "OAuth kullanan MCP istemcileri için issuer doğrulaması zorunlu" — "MCP'nin her yerinde zorunlu" değil.

Pratikte bu, istemcinin yönlendirmeden önce hangi issuer'a gittiğini kaydetmesi ve dönen iss parametresini bu kayıtla karşılaştırması demek. Ama iss yokluğunda koşulsuz reddetmek spec'e aykırı: iss gönderen sunucular bunu metadata'da authorization_response_iss_parameter_supported alanını true yaparak ilan etmek ZORUNDA ve istemcinin davranışı bu bayrağa bağlı:

Yani iss geldiğinde bayraktan bağımsız olarak her zaman karşılaştırılır:

1// SEP-2468: davranış AS bayrağına bağlı; geçerse code döner, değişim çağırana ait
2function validateAuthorizationResponse(
3  params: URLSearchParams,
4  recordedIssuer: string,
5  issParameterSupported: boolean | undefined,
6): string {
7  const returnedIssuer = params.get("iss");
8  const code = params.get("code");
9 
10  if (returnedIssuer === null) {
11    // Yalnız sunucu desteği ilan ettiyse iss yokluğu reddetme sebebi
12    if (issParameterSupported === true) throw new Error("Missing iss");
13  } else if (returnedIssuer !== recordedIssuer) {
14    // RFC 9207: issuer uyuşmazlığı = olası mix-up saldırısı
15    throw new Error(`Issuer mismatch: got ${returnedIssuer}`);
16  }
17 
18  if (code === null) throw new Error("Missing code");
19  return code;
20}

SEP-2468 teklifi 2026-03-25'te açıldı, 2026-05-17'de merge edildi; conformance senaryoları ise spec deposunda değil, ayrı modelcontextprotocol/conformance deposunda yaşıyor ve 2026-05-19'da #220 ile beş senaryo olarak eklendi (auth/iss-supported, auth/iss-not-advertised, auth/iss-supported-missing, auth/iss-wrong-issuer, auth/iss-unexpected); auth/iss-normalized senaryosu ise 2026-05-22'de #304 ile geldi — test edilebilir bir uyum kriteri.

DCR'nin sorunları

Dynamic Client Registration (RFC 7591), bir MCP istemcisinin çalışma anında yetkilendirme sunucusuna kayıt isteği atıp bir client_id/client_secret çifti alması yöntemiydi. 2026-07-28 spec'i bunu resmen deprecated ilan etti — CIMD lehine. Spec metni DCR'yi artık birincil mekanizma değil, geriye-uyumluluk için dahil edilmiş bir seçenek olarak tanımlıyor.

Bunun arkasında somut bir acı nokta var. DCR ile kayıt olan istemciler application_type alanını belirtmezse, OIDC altında varsayılan değer "web" oluyor — bu da yetkilendirme sunucusunun localhost veya native redirect URI'lerini reddetmesine yol açıyor. CLI araçları ve masaüstü MCP istemcilerinde karşılaşılan "invalid redirect_uri" hatalarının kaynağı çoğu zaman bu default'tur — duyurunun kendi ifadesiyle: "this is likely why". Spec bunu MUST'a bağlıyor: MCP istemcileri DCR sırasında uygun bir application_type belirtmek ZORUNDA (SEP-837).

İkinci sorun, kimlik bilgilerinin taşınabilirliği. SEP-2352 ile client credential'lar artık kesin biçimde onları veren issuer'a bağlanıyor — bir yetkilendirme sunucusundan alınan client_id/client_secret çiftini başka bir sunucuda yeniden kullanamazsın. Bu, çok-sunuculu MCP dağıtımlarında her AS için ayrı bir kayıt state'i tutman gerektiği anlamına geliyor.

Takvim de tahmine bırakılmış değil: spec'in "Deprecated Features" kayıt sayfası DCR satırında en erken kaldırma zamanını "First revision released on or after 2027-07-28", deprecation kaydını da PR #2858 olarak veriyor. Bu bir kaldırma tarihi değil, kaldırmaya uygun hale geldiği eşik — fiili kaldırma release hazırlığında Core Maintainer kararıyla alınır ve daha geç olabilir. Politika DCR'ye özel de değil; Roots/Sampling/Logging ve eski HTTP+SSE transport için de geçerli.

Bu politikanın pratik sonucu şu: mevcut DCR entegrasyonunu bugünden yarına sökmek zorunda değilsin. Ama yeni bir MCP istemcisi veya sunucusu yazıyorsan, DCR'yi birincil yol olarak seçmenin artık spec'e aykırı bir tercih olduğunu bilerek başlaman gerekiyor — "çalışıyor" ile "spec'in önerdiği yol" arasındaki fark, 12 aylık pencere kapandığında bakım borcuna dönüşecek.

CIMD ile istemci kimliği

Client ID Metadata Documents (CIMD), DCR'nin çözdüğü "önceden ilişki olmayan istemci-sunucu" problemini kayıt isteği atmadan çözüyor. Fikir basit: client_id artık rastgele bir string değil, doğrudan bir HTTPS URL. Bu URL, client_id, client_name ve redirect_uris gibi alanları içeren bir JSON metadata belgesine işaret ediyor.

Spec, MCP istemcileri ve yetkilendirme sunucularının CIMD'yi desteklemesini SHOULD seviyesinde istiyor — draft-ietf-oauth-client-id-metadata-document-00 taslağına dayanarak (henüz RFC değil, IETF taslak aşamasında). client_id URL'i HTTPS şemasını kullanmalı ve bir path bileşeni içermeli, örneğin https://example.com/client.json.

1{
2  "client_id": "https://mcp-client.example.com/oauth/client.json",
3  "client_name": "Örnek MCP İstemcisi",
4  "redirect_uris": ["https://mcp-client.example.com/oauth/callback"],
5  "token_endpoint_auth_method": "none",
6  "grant_types": ["authorization_code"],
7  "response_types": ["code"]
8}

Yetkilendirme sunucusu tarafında normatif seviyeler farklı: URL biçimli bir client_id gördüğünde belgeyi çekmesi beklenir (SHOULD), çektiğinde ise iki doğrulama zorunludur (MUST): belgedeki client_id alanının URL ile birebir eşleşmesi ve istemcinin sunduğu redirect URI'lerin belgedeki listeye karşı kontrolü. Bu kontrollerden biri eksikse, CIMD DCR'den daha güvenli değil — sadece kayıt adımını ortadan kaldırıyor, doğrulama sorumluluğunu ortadan kaldırmıyor.

Sunucu bu desteği ilan etmek için OAuth Authorization Server Metadata içine client_id_metadata_document_supported alanını eklemeli; istemci bu alana bakıp CIMD kullanıp kullanamayacağına karar veriyor.

Client ID Metadata Documents'in riskleri

CIMD kayıt adımını ortadan kaldırıyor, ama yerine yeni bir sorumluluk koyuyor: yetkilendirme sunucusu artık istemcinin verdiği bir URL'i çalışma anında çekmek zorunda. Spec bunu boşlukta bırakmıyor — CIMD uygulayan yetkilendirme sunucuları, OAuth Client ID Metadata Document taslağının 6. bölümündeki güvenlik değerlendirmelerini dikkate almak ZORUNDA; MCP spec'i bu maddelerin kendisine göre önemli olanlarını da ayrı bir güvenlik bölümünde sayıyor.

Birincisi SSRF. Bir client_id URL'i, pratikte yetkilendirme sunucusuna "şu adrese git ve içeriği getir" demenin bir yolu; saldırgan buraya iç ağda duran bir servisi ya da yalnız sunucudan erişilebilen bir uç noktayı koyabilir. Spec bunu SHOULD seviyesinde uyarıya bağlıyor: metadata belgesi çeken yetkilendirme sunucuları Server-Side Request Forgery risklerini hesaba katmalı. Kendi AS'ini yazıyorsan bunun pratik karşılığı, fetch'i uygulama sunucusunun genel HTTP istemcisiyle yapmamak: şema ve port allowlist'i, yönlendirme sayısına sınır, yanıt boyutu ve zaman aşımı kapağı, mümkünse ayrı bir çıkış yolu.

İkincisi daha ince ve CIMD'nin kendi tasarımından geliyor. Belgedeki client_id alanının URL ile birebir eşleşmesi zorunluluğu, birinin senin metadata belgeni kendi adresine kopyalayıp barındırmasını engelliyor — ama yetkilendirme sunucusuna senin URL'ini sunup senin istemcin gibi davranmasını engellemiyor. Spec bunu açıkça yazıyor: Client ID Metadata Documents tek başına localhost URL taklidini önleyemez. Yerel bir geri-dönüş adresi, o portu kimin dinlediğini kanıtlamaz; belge meşru, ad meşru görünür.

Bu yüzden spec yükün kalanını yetkilendirme sunucusunun onay ekranına devrediyor: yalnız localhost redirect URI'si taşıyan istemciler için ek uyarı gösterilmeli (SHOULD), gerekirse ek attestation mekanizmaları istenebilir (MAY) ve yetkilendirme sırasında redirect URI'nin hostname'i kullanıcıya açıkça gösterilmek ZORUNDA (MUST). Buna ek olarak yetkilendirme sunucuları, hangi alan adlarından gelen metadata belgelerini kabul edeceklerine dair güven politikaları uygulayabilir (MAY) — kurumsal bir MCP dağıtımında CIMD'yi yalnız kendi alan adlarınla sınırlamak, bu maddenin en ucuz ve en etkili uygulaması.

Buradan çıkan ders şu: CIMD'yi "DCR'nin zahmetsiz hali" diye okumak yanlış. Kayıt veritabanını sildin, ama karşılığında fetch katmanını sertleştirme ve onay ekranını doğru kurma sorumluluğunu üstlendin. Bu iki maddeyi atlarsan CIMD, DCR'den daha güvenli bir yol olmaktan çıkar.

Geçiş dönemi: ikisini birden desteklemek

Bugün prod'da yazdığın bir MCP istemcisi hem CIMD destekleyen hem henüz DCR'de kalmış sunucularla konuşacak. Spec bunun için net bir öncelik sırası tanımlıyor — istemci tarafında şu sırayla dene:

DCR ile CIMD arasındaki farkı özetlemek gerekirse:

Pratik tavsiye: yeni bir MCP istemcisi yazıyorsan CIMD'yi birincil yol yap, DCR'yi yalnızca sunucu CIMD desteğini ilan etmiyorsa devreye sok — ikisini aynı anda "eşit öncelikli" kod yoluna koyma, spec'in öncelik sırasını birebir uygula.

Token kapsamı ve en az yetki

CIMD veya DCR ile client kimliğini çözmek yeterli değil — token'a hangi kapsamların (scope) bineceği ayrı bir karar. Spec burada 401 yanıtına net bir sorumluluk yüklüyor: MCP sunucuları WWW-Authenticate header'ında bir scope parametresi vermeli (SHOULD) ve istemciler bu kapsamları o istek için yetkili kabul etmek zorunda (MUST).

1HTTP/1.1 401 Unauthorized
2WWW-Authenticate: Bearer realm="mcp-api",
3  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
4  scope="tools:search_documents tools:read_only"

Spec'in tanımladığı öncelik sırası iki maddeden ibaret: önce WWW-Authenticate challenge'ında verilmişse oradaki scope kullanılır; scope yoksa Protected Resource Metadata belgesindeki scopes_supported kapsamlarının tamamı istenir, scopes_supported tanımsızsa scope parametresi hiç gönderilmez. Dikkat et: bu liste authorization server metadata'sında değil, korunan kaynağın metadata belgesinde duruyor.

Yani en az yetki mekanizması istemcinin listeyi filtrelemesi değil: spec scopes_supported'ı temel işlevsellik için gereken minimal küme olarak tanımlıyor, ek kapsamlar step-up authorization akışıyla kademeli isteniyor. Daraltma sorumluluğu sunucuda.

Bu ayrım özellikle çoklu-tool sunan MCP sunucularında önemli: bir dosya-arama tool'u çağıran bir istek, dosya-silme kapsamını taşıyan bir token ile yetkilendirilmemeli — token sızarsa hasar, o token'a bağlı kapsamla sınırlı kalır.

Kendi sunucunu sertleştirme denetim listesi

Yukarıdaki kuralları tek tek uygulamak yerine, kendi MCP sunucunu gözden geçirirken şu maddeleri sırayla kontrol edebilirsin:

• RFC 9728 Protected Resource Metadata: MCP sunucuları bunu uygulamak ZORUNDA; authorization_servers alanı en az bir sunucu içermeli.
• Discovery çift yolu: Sunucu, WWW-Authenticate header'ında resource_metadata URL'i VEYA /.well-known/oauth-protected-resource well-known URI'sinden birini sağlamalı; istemci ikisini de desteklemek zorunda.
• AS başına ayrı state: Pre-registered ve saklanan DCR credential'ları sunucular arası yeniden kullanılamaz (SEP-2352) — CIMD client_id URL'leri bu kuralın dışında, taşınabilir.
• iss doğrulaması: OAuth kullanıyorsan, authorization response'taki iss parametresini beklenen issuer ile karşılaştır, uyuşmazlıkta code'u reddet (RFC 9207, SEP-2468).
• CIMD önceliği: client_id_metadata_document_supported alanını ilan et, DCR'yi yalnızca fallback olarak tut.
• Header doğrulama: Mcp-Method/Mcp-Name header'larına gateway seviyesinde güvenmeden önce, Authorization token'daki kapsamla çapraz kontrol et.
• Scope challenge: 401 yanıtlarında WWW-Authenticate içinde scope parametresi ver; istemcinin en az yetkiyle isteyebilmesini sağla.
• SDK sürümü: TypeScript, Python, Go, C# Tier-1 SDK'ları 2026-07-28 spec'ini konuşuyor; Rust SDK beta destek veriyor — sunucun hangi SDK'yı kullanıyorsa migration notlarını oradan takip et.

Bu liste bir kerelik bir denetim değil — spec'in kendisi deprecation politikasıyla (12 ay minimum) kademeli değişime izin veriyor, yani sertleştirmeyi de kademeli, ölçülebilir adımlarla yapabilirsin.

Denetim listesinin sırası da rastgele değil: önce keşif (RFC 9728 + discovery çift yolu) doğru çalışmıyorsa, istemci hiçbir zaman doğru yetkilendirme sunucusuna ulaşamaz — iss doğrulaması veya CIMD önceliklendirmesi gibi sonraki adımların hiçbir anlamı kalmaz. Bu yüzden sertleştirmeye her zaman keşif katmanından başla, kimlik doğrulama detaylarına oradan ilerle.

SSS

MCP sunucusu nasıl güvenli şekilde yetkilendirilir?

Yetkilendirme MCP protokol seviyesinde OPTIONAL'dır, ama HTTP tabanlı bir sunucu OAuth 2.1 kullanacaksa 2026-07-28 spec'i zorunlu bir iskelet tanımlar: sunucu RFC 9728 Protected Resource Metadata'yı uygulamak ZORUNDA, istemci de yetkilendirme sunucusunu RFC 8414/OIDC Discovery ile keşfetmek ZORUNDA. Bu, kurumsal kimlik sağlayıcıları arkasında spec seviyesinde tanımlı bir entegrasyon yolu anlamına gelir.

CIMD nedir, DCR'den farkı ne?

CIMD'de client_id bizzat bir HTTPS URL'dir; bu URL'de barınan JSON metadata dosyası istemcinin kimlik bilgilerini taşır ve sunucu bunu çalışma anında çekip doğrular, kayıt veritabanı tutmaz. DCR ise sunucuya canlı bir kayıt isteği atıp client_id/secret alır; 2026-07-28 spec'inde DCR "MAY support" seviyesine düşürülmüş, geriye-uyumluluk için tutulan bir yoldur.

RFC 9207 issuer doğrulaması neden zorunlu oldu?

MCP'nin tek istemci-çok sunucu dağıtım şekli, bir yetkilendirme sunucusunun diğerinin yerine geçtiği mix-up saldırısına özellikle açık. İstemcinin, yönlendirmeden önce kaydettiği issuer ile authorization response'taki iss parametresini karşılaştırıp uyuşmazlıkta code'u reddetmesi SEP-2468 ile zorunlu hale getirildi.

Stateless MCP'de her istek nasıl doğrulanır?

initialize/initialized el sıkışması ve Mcp-Session-Id kalktı; her istek kendi protokol versiyonunu, istemci kimliğini ve yeteneklerini _meta alanında taşır, Mcp-Method ve Mcp-Name HTTP header'ları ile gateway seviyesinde yönlendirilip yetkilendirilebilir. Oturum benzeri bir durum gerekiyorsa, bu artık transport'ta gizli değil, uygulama seviyesinde bir handle (ör. bir sepet ya da oturum tanıtıcısı) olarak modele argüman şeklinde geri veriliyor.

DCR ne zaman tamamen kaldırılacak?

Spec'in "Deprecated Features" kayıt sayfası DCR için en erken kaldırmayı "First revision released on or after 2027-07-28" olarak veriyor (kayıt: PR #2858). Bu bir kaldırma tarihi değil, kaldırmaya uygun hale geldiği eşik; fiili kaldırma Core Maintainer kararıyla daha geç de olabilir. Pratikte DCR'yi 2027-07-28'e kadar çalışır varsayıp geçişi o pencereye yayabilirsin.

Sonuç

MCP'nin 2026-07-28 spec revizyonu, protokolü hem daha ölçeklenebilir (stateless, herhangi bir sunucu örneğine düşebilen istekler) hem de yetkilendirme açısından daha net kılıyor: RFC 9207 issuer doğrulaması OAuth kullanan istemciler için MUST, CIMD kayıt-öncesi ilişki gerektirmeyen istemciler için önerilen (SHOULD) yol, DCR ise geriye-uyumluluk fallback'i. Bu üçünü ayrı ayrı değil, spec'in tanımladığı öncelik sırasıyla (pre-registered → CIMD → DCR → manuel) tek bir karar noktasında ele almak, geçiş döneminde hem güvenliği hem bakım maliyetini kontrol altında tutuyor.

MCP ekosisteminin geri kalanını daha derinden görmek istersen Claude Code MCP: Model Context Protocol ile AI Plugin Ekosistemi yazısı protokolün plugin tarafını, MCP (Model Context Protocol): AI Entegrasyon Standardı yazısı ise genel entegrasyon modelini anlatıyor. Sunucu tarafında birden çok agent koordine ediyorsan Claude Code Multi-Agent Teams: Paralel AI Agentlarla Geliştirme yazısına, tool-use ve planner-loop mimarisine bakmak istersen Agentic AI: Tool Use, Planner Loops ve Production Agent Mimarisi yazısına göz atabilirsin. Genel API/network sertleştirme pratiklerini de iOS Network Security Advanced: Sıfırdan Zırhlı İletişim yazısıyla karşılaştırabilirsin.

Kaynaklar

• Model Context Protocol — 2026-07-28 duyuru yazısı — Stateless geçiş, SEP-2468/2575/2567/2243/837/2352 özetleri ve SDK istatistikleri
• MCP Specification 2026-07-28 — Authorization — RFC 9207, RFC 9728, scope/least-privilege kuralları
• MCP Specification 2026-07-28 — Client Registration — CIMD ve DCR karşılaştırması, öncelik sırası
• MCP Specification 2026-07-28 — Authorization Server Discovery — RFC9728 discovery mekanizmaları
• SEP-2468 pull request — Issuer (iss) claim önerisinin merge kaydı
• WorkOS — MCP 2026 spec ve agent authentication — Bağımsız analiz, RC ve final tarih teyidi
• MCP Specification 2026-07-28 — Deprecated Features — DCR deprecation kaydı (PR #2858) ve en erken kaldırma eşiği
• MCP Specification 2026-07-28 — Authorization Security Considerations — CIMD SSRF ve localhost taklidi riskleri, AS yükümlülükleri
• Auth0 — CIMD vs DCR MCP registration — CIMD mekaniğinin bağımsız teyidi