GeraldGrootRoessink
commented
1 year ago Mijn inleiding hierboven slaat helaas de plank mis door een misverstand over 'endpoint' . Ik heb dat gelezen als "de eindorganisatie", niet de (SAAS-)intermediair maar de business verantwoordelijke die met een OIN wordt geïdentificeerd in de berichtenheader. Foutje van mij.
Daarom sluit ik dit issue, maar ik sta nog wel steeds achter een best-practice voor het "niet deponeren van PKI-sleutels bij een intermedair". Dat maak ik onderwerp van een volgend issue.
In de tekst staat deze opmerking:
"Voor asynchroon verkeer (ebMS) moet ook de endpoint van de zender bekend zijn".
Maar dat is niet het enige.
In het onderwijs kennen we niet alleen de vraag-antwoord variant met WUS, maar ook de melding-(functionele )bevestiging variant. Dit wordt onder meer gebruikt door een school om te melden dat een student is ingeschreven of een diploma heeft gehaald. Hiervoor gebruiken we WSA:from. Bij ontvangst door DUO wordt gekeken, kennen we school en klopt het dat die een mandaat aan SAAS heeft gegeven?
Dat geldt ook voor het REST protocol. Dat wordt vaak gebruikt om te lezen, maar schrijven hoort ook bij REST. Dus, ook hier is de "from-parameter' relevant. Alleen niet gedefinieerd in zoiets als WSA. Dus dat moeten we zelf verzinnen.
Ik beschrijf hier de huidige stand van de Edukoppeling standaard en het is operationeel. Overigens ook met een mandatenregister. Dit wordt als het aan ons ligt maximaal afgedekt door de Digikoppeling standaard. De Edukoppeling constructie is nadrukkelijk afgestemd met de Digikoppeling community, maar dezelfde constructie opnemen in Digikoppeling ging de community te ver. Wel is toen gesproken over Edukoppeling als best-practice.
Behalve dit missend stukje over routering "achter de voordeur" zit de Edukoppeling-oplossing wel in deze handreiking. Maar het is jammer dat partijen nog heel veel zelf moeten uitzoeken en keuzes moeten maken. Mijn vriendelijke suggestie is om het partijen die met SAAS werken te verwijzen naar de concrete implementatie van Edukoppeling.