Coordinate Mediation 2.0: mediate-request, mediate-grant, keylist

Coordinate Mediation tek bir soruyu yanıtlar: bir ajan, bir aracının kendi adına posta kabul etmesini nasıl sağlar ve aracı hangi adresleri kabul edeceğini nasıl öğrenir?

Küçük bir protokoldür, üç fikir, ve onu doğru yapmak çalışan bir entegrasyonun büyük kısmıdır.

1 · `mediate-request`, istemek

Ajan aracıya bir DIDComm v2 şifreli zarfı olarak bir mediate-request gönderir. Tartışmaya değer bir argüman taşımaz: bir hizmet talebidir.

Solidus Relay bunu kendi davetinde amacı olarak duyurur, böylece tek satır kod yazmadan giriş noktasını teyit edebilirsiniz:

curl -s https://relay.solidus.network/invite | jq -r '.body.goal_code'
# request-mediate

Bir isteğin kabul edilip edilmeyeceği bir politika kararıdır, bir protokol kararı değil. Bir aracı herkesi kabul edebilir ya da bir şeye göre kapı tutabilir. Solidus Relay'in ayırt edici yanı, kapısının bir API anahtarı yerine sunulmuş bir kimlik bilgisi olabilmesidir; bkz. kimlik bilgisiyle kapı tutulan aracılık.

2 · `mediate-grant`, önem taşıyan cevap

Kabul üzerine aracı mediate-grant ile yanıt verir ve bu yanıt alışverişin bütün meselesidir. Şunları taşır:

muhataplarınızın üzerinden yönlendirmesi gereken yönlendirme anahtarları ve
gönderim yapmaları gereken hizmet uç noktası.

Sonra bunları kendi DID belgenizde yayımlarsınız, yani DIDComm hizmet girdinizin serviceEndpoint ve routingKeys alanlarında. Aracılığı gerçekten açan şey o yayımdır: DID belgeniz aracıyı adlandırana kadar kimse oraya bir şey göndermez.

Solidus Relay için her iki değer de siz hiç bağlanmadan önce davette görünür:

curl -s https://relay.solidus.network/invite | jq '.services[0].serviceEndpoint'

Bu, https://relay.solidus.network/didcomm uç noktasını ve aracının did:key değerini tutan bir routingKeys dizisini döndürür.

O did:keyin ne anlama geldiğine dikkat edin. Aracının kendi kimliği kendi kendine yeterlidir ve zincire demirlenmemiştir; bkz. bir aracı için did:key ve did:solidus.

Bir mediate-deny de meşru bir cevaptır. Onu ele alın; kabul varsaymayın.

3 · Anahtar listesi, aracının hangi adresler için kabul ettiği

Bir kabul açık çek değildir. Aracı bir anahtar listesi tutar: kabul edip mesaj kuyruğuna alacağı belirli alıcı anahtarları. Ajanınız anahtarları bir keylist-update ile ekler ve aracı hangi güncellemeleri uyguladığını teyit eder.

Pratikte insanların karşılaştığı iki sonuç:

Listede olmayan bir anahtara gelen mesaj kuyruğa alınmaz. Posta kaybolmuş gibi görünüyorsa, kuyruktan şüphelenmeden önce anahtar listesini kontrol edin.
Bir anahtar eklemek yeni bir ikili kimliği devreye almanın yoludur, bir anahtarı çıkarmak da onun için kabul etmeyi durdurmanın. Muhatap başına ayrı bir anahtar kullanmak buradaki en güçlü mahremiyet denetiminiz olduğundan, anahtar listesi hareketliliği istisnai değil normaldir.

İşletimsel taraf, yani listeleme, ekleme, iptal etme ve sürüklendiklerinde ne yapılacağı, pratikte anahtar listesi yönetimi sayfasındadır.

Bütün alışveriş, sırasıyla

agent  --mediate-request-->  mediator
agent  <--mediate-grant---   mediator      (routingKeys + serviceEndpoint)
agent  --keylist-update-->   mediator      (the recipient keys to accept for)
agent  <--keylist-response-- mediator
        ...agent publishes routingKeys + serviceEndpoint in its DID document...

Ondan sonra yönlendirme anahtarınıza adreslenmiş forward mesajları gelmeye başlar ve onları Pickup Protokolüyle toplarsınız. Bkz. forward mesajı ve yönlendirme anahtarları ve Pickup Protocol 3.0.

Aracı bunu yaparak ne öğrenir

Aracılık vermek ve bir anahtar listesi tutmak, aracının hangi anahtarların aynı ajana ait olduğunu bilmesi demektir: bir anahtar listesi tam olarak budur. Mahremiyet için muhatap başına bir anahtar kullanıyorsanız, aracının onları yine de tek bir aracılık altında gruplanmış gördüğüne dikkat edin.

Bu, protokolde bir kusur değildir; aracılığın gerektirdiği şeydir. Aynı zamanda tam olarak bir mahremiyet sayfasının yüksek sesle söylemesi gereken türden bir şeydir: bir aracının görebildikleri ve göremedikleri.

Bir kütüphane kullanın

Bu zarfları elle yazmayın. Şifreleme, anahtar anlaşması ve forward sarma, ince bir hatanın sessiz kaldığı parçalardır. Bir DIDComm v2 kütüphanesi protokolü halleder; sizin işiniz onun etrafındaki politikadır. Yaygın olanların karşılaştırmaları Credo-TS ile ve Veramo ile sayfalarındadır.