OID4VP doğrulayıcısı: gerçek uç noktalar, gerçek politika düğmeleri, ve biri okunduğundan az anlama geliyor

Doğrulayıcı tarafı canlıdır ve capture API üzerinde kimlik doğrulamayla kapatılmıştır.

Verme ve sunma farklı protokollerdir

OID4VCI, bir kimlik bilgisini bir tutanın cüzdanının içine sokuyor. OID4VP, ondan bir kanıtı dışarı, bir doğrulayıcıya çıkarıyor. Ayrı belirtimlerdir ve bir satıcı birini diğeri olmadan gerçekleştirebilir.

İkisini de gerçekleştiriyoruz, farklı hizmetlerde: verme üstverisi capture API'nin well-known uç noktasında yayımlanıyor, ve sunum uç noktaları da capture API'de yaşıyor. Verify uygulamasının arka ucunda hiçbiri yok. OID4VP'yi yanlış hizmette arıyorsanız, doğru biçimde orada olmadığı sonucuna varacaksınız.

Gerçekte ne var olduğu

Üç uç nokta, 2026-07-31'de canlı olarak doğrulandı:

uç nokta	amaç	yoklama sonucu
PUT /v1/presentations/policy	bu doğrulayıcının neyi kabul edeceğini belirle	401
POST /v1/presentations/requests	bir sunum isteği üret (karekod / derin bağlantı)	401
POST /v1/presentations/verify	dönen bir vp_tokenı doğrula	401

401, rotanın var olduğu ve kimlik bilgisi gerektirdiği anlamına geliyor. Var olmayan bir rota 404 döndürüyor, o kontrolü çalıştırdık, ve bilinen iyi bir uç noktayı da olumlu kontrol olarak çalıştırdık. Yani bir yabancı, hesabı olmadan bu uç noktaların gerçek olduğunu teyit edebilir; ne yaptıklarını teyit edemez. Bu, doğrulama yeniden kullanımı ve seçici açıklama sayfalarındakilerden daha zayıf bir kanıttır, ve onu daha zayıf olarak derecelendiriyoruz.

Doğrulayıcı politikası, ki ilginç kısım odur

Bir doğrulayıcı yalnızca bir imzayı denetlemiyor: neyi kabul etmeye istekli olduğunu beyan ediyor. Politika şunları destekliyor:

• requested_claims, sunumun taşıması gereken nitelikler.
• accept_min_loa, kendi L1 / L2 / L3 / L3+ şemamızdan asgari bir güvence düzeyi.
• accept_issuers, ya güven kütüğüne kayıtlı her veren, ya da açık bir veren DID listesi.
• freshness_max_days, alttaki doğrulaması seçilmiş bir pencereden eski olan bir kimlik bilgisini reddet.
• ttl_seconds, üretilmiş bir isteğin ne kadar süre geçerli kalacağı.

Üzerinde durmaya değen freshness_max_days'tir, çünkü yeniden kullanımı süresiz değil savunulabilir kılan düğme odur: bir güvenen taraf, on dört ay önceki bir doğrulamanın kendi risk iştahı için yeterli olmadığına, yeniden kullanımı tamamen reddetmek zorunda kalmadan karar verebilir. "Bir kez doğrula"nın "bir kez doğrula, sonsuza dek" anlamına gelmesini durduran düzenek budur.

Okunduğundan az anlama gelen iki düğme

accept_issuers: registry_all şu anda "Solidus'u kabul et" demektir. Çeşitli bir ekosistem hakkında bir politika gibi geliyor. Güven kütüğünün tek bir işletmecisi var, biz, ve federasyon yok. İkinci bir veren olana dek, "kütükteki herhangi bir veren"i seçmekle "Solidus"u seçmek aynı karardır. Bkz. satıcıya bağımlılık.

L1/L2/L3 güvence düzeylerimiz kendi şemamızdır. eIDAS güvence düzeyleri değildirler, akredite bir güvence çerçevesi değildirler, ve hiçbir dış kurum düzeylerimizin neye karşılık geldiğini değerlendirmedi. Kendi kademelerimiz arasında bir politika ayarı olarak kullanışlıdırlar; başka kimsenin anlamını içeri aktarmıyorlar.

Bunun yapmadığı şey

• Kimlik bilgisine dayanmanın makul olup olmadığına karar vermiyor. Politika motoru, sizin belirlediğiniz kuralları uyguluyor. O kuralların düzenleyiciniz için yeterli olup olmadığı sizin kararınızdır, ve dayanma, bağlantısız hiçbir tarafın o kararı henüz üretimde vermediğini kaydediyor.
• Yükümlülüğünüzü ortadan kaldırmıyor. Üçüncü taraf doğrulamanın belirli bir düzenleyici görevi karşılayıp karşılamadığı yerleşmemiştir.
• Denetlenmemiş bir kanıtı denetlenmiş kılmıyor. Bu uç nokta tarafından doğrulanan bir BBS+ sunumu, hâlâ bağımsız hiç kimsenin incelemediği kod tarafından üretiliyor.