Revokation durch Dritte?

[christianheimann]

Das Beispiel des Arztrezepts ist einer meiner "Lieblingsanwendungsfälle", um jemand aussenstehendem SSI zu erklären. Ein Punkt ist für mich aber nicht befriedigend geklärt: Der "Einzug" eines Rezepts, wie dies beim Papier-Rezept in der Apotheke passiert. Welche technischen Möglichkeiten stehen im Raum, damit ein VC nur ein einziges Mal angewendet/präsentiert werden kann?

• Welche Lösungsansätze sind euch da bekannt?
• Was würde eine Apotheke berechtigen, ein bestimmtes VC zu revozieren, obwohl die Apotheke nicht gleich Aussteller ist?
• Was sichert das VC vor "missbräuchlichem" Revozieren?
• Oder ist dies etwas, was dann sektoriell, unabhängig der SSI-Kerninfrastruktur geregelt werden muss (analog z.B. eines Tickets, welches bei einem Veranstalter "entwertet" wird beim Eingang, und sich der Veranstalter dieses merkt – unabhängig des kryptografischen Beweises mittels Registry)?

---

L'exemple de l'ordonnance médicale est l'un de mes "cas d'utilisation préférés" pour expliquer la SSI à quelqu'un/e qui est nouveau au sujet. Cependant, un point n'est pas éclairci de manière satisfaisante pour moi : le "retrait" d'une ordonnance, comme cela se passe avec l'ordonnance papier à la pharmacie. Quelles sont les possibilités techniques pour qu'un VC ne soit utilisée/présentée qu'une seule fois ?

• Quelles sont les solutions que vous connaissez ?
• Qu'est-ce qui autoriserait une pharmacie à révoquer un certain CV alors que la pharmacie n'est pas l'émetteur ?
• Qu'est-ce qui protège le VC contre une révocation "abusive" ?
• Ou est-ce quelque chose qui doit alors être réglé de manière sectorielle, indépendamment de l'infrastructure centrale SSI (similaire à un billet d'entrée qui est "validé" à l'entrée chez un organisateur et que l'organisateur mémorise soi-même l'invalidation de cette preuve – indépendamment de la preuve cryptographique du registre) ?

---

L'esempio della prescrizione del medico è uno dei miei "casi d'uso preferiti" per spiegare SSI a qualcuno che viene da fuori. Tuttavia, un punto non mi è stato chiarito in modo soddisfacente: la "strisciata" di una ricetta, come avviene con la ricetta cartacea in farmacia. Quali possibilità tecniche ci sono per assicurare che un VC possa essere applicato/presentato solo una volta?

• Di quali soluzioni siete a conoscenza?
• Cosa autorizzerebbe una farmacia a revocare un certo VC, anche se la farmacia non è l'emittente?
• Cosa protegge il VC dalla revoca "abusiva"?
• O è qualcosa che deve essere regolato a livello settoriale, indipendentemente dall'infrastruttura di base SSI (per esempio come un biglietto che viene "convalidato" all'ingresso di un organizzatore di eventi, e l'organizzatore dell'evento se ne ricorda – indipendentemente dalla prova crittografica tramite registro)?

[christianheimann]

Ein paar Gedanken zu diesem Use-Case auch in diesem Artikel von Stefan Wengi: https://www.linkedin.com/pulse/fehlt-der-schweizer-e-id-die-vision-stefan-wengi/

Und zusätzlich muss man miteinbeziehen, dass es Rezepte unterschiedlicher Art gibt: Abgaben, Dauerrezepte, Substitutionen, Teilabgaben, forcierte Abgaben etc. Das Ökosystem der Medikamentenabgabe ist dadurch vielschichtig.

[pascalgottret]

Spannende Frage und Artikel.
Ich habe mir lange überlegt, wie man eine Nutzung des Credentials speichern kann, aber noch auf keine schlaue Lösung gekommen.

Für mich ist unklar, wie Wengi den Vermerk, dass das Credential benutzt wurde, auf die DLT schreiben möchte. In welcher Form wird es auf die DLT geschrieben? Wer schreibt es? Wie kann ein anderer Verifier das überprüfen?

Ich habe diese Fragen mal auf Linkedin gepostet.

[sgw]

Es braucht dazu m.E. die Möglichkeit, die Bezüge zu protokollieren. Jeder Bezug wird als Entry geschrieben und enthält Informationen, über eine erfolgte Abgabe.
Konzeptuell braucht es auch eine Möglichkeit, anhand des vorliegenden Rezepts, die Abgabe-Entries zu finden. So kann sichergestellt werden, dass ein Rezept nicht mehrfach eingelöst wird. Die entsprechende Kontrolle ist dann Aufgabe der Apotheker. Sie sind es auch die Abgabe-Entries erstellen dürfen.

[romanzoun]

Also das ist super spannender Case. SSI als die Technologie für Selbstbestimmung deiner Daten, ohne Einbezug von Dritten...
Also Tickets für Tram, Bahn, Konzerte enthalten ja Informationen für Gültigkeit und können einfach verifiziert werden. Eine Revokation ist nicht notwendig.
Bei dem Use Case haben wir kurz (20 Minuten Brainstorming) überlegt und ich möchte euch unsere Gedanken und deren Verlauf aufzeigen (dauert länger als das Überlegen):

Arzt ist in diesem Fall der Issuer, er gibt ein Rezept aus. Der Patient nimmt das Rezept als VC mit zu der Apotheke und zeigt es dort. Damit die Medikamentenausgabe erfolgt, muss der Apotheker sichergehen, dass dieser VC nicht nochmal verwendet werden darf. Das bedeutet, entweder er ruft den Arzt an und sagt, er soll revozieren (zu viel Aufwand! ausserdem, nach SSI müsste der Patient bei dem Arzt anrufen und nicht der Apotheker). Weiterhin kann der Apotheker dem Patienten zuschauen, wie er das VC in der wallet löscht (Wir haben gewisse Bedenken bei diesem Prozess). Oder am besten, der Apotheker selbst muss eine Revokation triggern. Der Issuer hat einerseits eigene Adminstration, bei der der Issuer dann die ausgestellten VCs verwaltet, aber nun bedeutet es, der Issuer muss zusätzlich eine Revocation API allen Apotheken bereit stellen, mit einem security layer, der den Zugriff regelt. Leider stehen die VC Daten nicht auf dem Ledger, sodass eine Markierung dieser Daten als „Gebraucht“ nicht stattfinden kann. Nach dem erfolgreichen Revozieren kann der Apotheker dann sein Medikament ausgeben.
Das bedeutet, jeder Issuer muss eine API anbieten, jeder Arzt…also jeden Tag kommen neue Endpoints dazu…gehen wieder und so weiter, das ist unrealistisch. Deshalb macht es in diesem Fall sinn den Issuer zu zentralisieren, einen mandatenfähigen cloud health Issuer zu bauen, der dann die einzelnen Ärzte, Krankenhäuser und Apotheken gleichermassen bedient. Die Apotheken hätten dann nur auf die Revocation API Zugriff und die Ärzte dann auf Ausstellen und die Revocation API.

Dies ist aber eine Zentralisierung der Issuer und der Issuer würde immer mitkriegen, wenn der Verifier Rezepte revoziert. Das ist dann entgegen des SSI Konzepts und es ist so, als ob man eine falsche Lösung zum Problem adaptieren möchte.
Also für diesen Case, wo die Akteure Apotheken und Ärzte sind, lohnt sich immer noch eine zentrale Lösung, denn auch wenn es den Anschein hat, es sind getrennte Issuer und Verifier, sind sie irgendwie eher eine Health Instanz, die mit einer zentralen Lösung besser fahren würden oder sogar bei der analogen Lösung bleiben, bei der ein Rezept einfach bei der Apotheke bleibt. SSI bringt hier keinen wirklichen Mehrwert, auch wenn die SSI Infrastruktur bereit stehen würde.

Was denkt ihr zu dieser Überlegung?

[sgw]

Aus meiner Sicht, gilt es die Fachlichkeit noch besser zu verstehen. Insbesondere ist ein Rezept nichts binäres wenn es um die Abgabe geht. Es gibt sehr häufig mehrere Abgaben über einen längeren Zeitpunkt. Mit einer digitalen Lösung sollte auch ermöglicht werden, dass verschiedene Apotheker Abgaben auf Basis eines einzigen Rezepts machen. Beispiel: Bezug von Medikamenten auf einem Dauerrezept am Ferienort.

zusammengefasst gelten m.E. folgende Anforderungen resp. Rahmenbedingungen:

1. Die Revokation eines Rezepts hat nichts mit der Abgabe zu zun. Sie erfolgt durch den ausstellenden Arzt, wenn er z.B. einen Fehler entdeckt.

2. Auf Basis eines Rezepts können mehrere Abgaben, zu unterschiedlichen Zeitpunkten und durch verschiedene Apotheker erfolgen. (z.B. bei einem Dauerrezept)

3. Eine Abgabe muss nicht 1:1 mit dem Eintrag auf dem Rezept übereinstimmen. Der Apotheker hat hier einige Freiheiten (z.B. Abgabe von Generika, forcierte Abgabe)

4. Ein Apotheker kann zu einem Rezept den Hinweis ablegen, dass die Abgabe beendet ist.

Das ganze Set von fachlichen Anforderungen hat m.E. zur Folge, dass die einzelnen Abgaben digital protokolliert werden (mit einer Referenz auf das Rezept). Das Rezept selbst wird aber nicht veräandert.

Es stellt sich demnach die Frage, wie diese Anforderungen mittels SSI und DLT abgedeckt werden können und ob der Lösungsansatz als sinnvoll erachtet wird.

[pascalgottret]

ich habe mir das spannende Szenario nochmal genauer überlegt:

Abgabe Entries dezentral durch einen Verifier zu protokollieren benötigt meines Erachtens eine Erweiterung von SSI mithilfe Smartcontracts. Ein VC, das von einem Arzt kommt, wird z.B. in ein NFT gepackt, dass, je nach Gestaltung, "sofort entwertet" wird. Der nächste Verifier erkennt das und kann die Herausgabe des Medikament verweigern.

Ich sehe keine Möglichkeit, dass ein Verifier Einfluss auf ein Credential haben kann, ohne dass man eine zentrale Registry aufbaut und dabei Grundsätze des Datenschutzes verletzt.

Smartcontracts könnten Abhilfe schaffen.

[romanzoun]

NFT und Smart Contracts sind nicht Teil des Ledgers bei einer dezentralen PKI, wie SSI es eine ist. Auf dem Ledger steht praktisch nur der Public Key für die Verifikation.

[pascalgottret]

von welchem Ledger sprichst du? es gibt Ledger, die beides nahtlos integriert haben.

[romanzoun]

Ich spreche von Hyperledger Indy oder ION von Microsoft, die aktuell für SSI verwendet werden.

Im reinen SSI Concept sind Ledger Interaktionen nicht vorgesehen. Man hat eine P2P Verbindung zwischen Holder und Issuer und eine P2P zwischen Holder und Verifier. Der Ledger enthält nur Public Key Informationen für Verifikation. Das wird dann erweitert um Trust und cybersec. Es gibt Cheq die versuchen tokens in SSI manner, also über den Holder, zu realisieren. Wenn es um eine Infrastruktur geht, die frei gestellt wird, dann sollte diese schlank sein und an das Ziel einer eID orientiert.

Also wenn man nun für SSI Hedera Ledger nimmt oder ETH oder ADA, dann nicht wegen SSI, sondern wegen der Chain....nun ist die Frage, was ist das Ziel der Infrastruktur: Will man eine Infrastruktur für eine SSI-basierte eID oder eine ETH based Blockchain zu Verfügung stellen?

[KasparEtter]

Damit der Issuer nicht erfährt, von wem und bei wem das Credential (einmalig) eingelöst wurde, würde ich Blind Signatures verwenden.

[romanzoun]

Hyperledger URSA bietet sogar dafür was

[romanzoun]

@KasparEtter kannst du beschreiben, wie man das machen kann, also das ein verifier das ausgestellte VC revoziert mit blind signatures, ich kann dem leider nicht folgen :)

[grt-dti]

ich bin gern der Spielverderber:
aber SSI (self sovereign identity) hat nun aber rein gar nichts mehr mit Rezepten zu tun - es sei denn, jemand kommt auf die Idee, JEDE (aber auch wirklich jede) auch nur im Entferntesten mit meiner Person zusammenhängende Information meiner ID anzuhängen. Das wird dann richtig eklig, wenn ich bi- oder trilaterale Verträge (die hängen ja auch an meiner Person) ebenfalls meiner SSI ankleben möchte (und den anderen Teilnehmern dieser Verträge auch noch).
Votum: hört bitte auf der E-ID Probleme anzuhängen, die dort nicht hingehören!
SSI ist eine Identität (sie beschreibt mich und gehört mir); ein Rezept ist Vertrag/Contract zwischen Arzt, Patient, Apotheke(n) und Krankenkasse (vielleicht braucht es die letztere nicht in jedem Fall) - der beschreibt eine Transaktion (auch wenn sie aus mehreren Transaktionen besteht) und gehört allen Teilnehmern zugleich.....

[grt-dti]

dazu kommt ein weiteres Votum: verfallt bitte nicht in die Arroganz, zu glauben, ihr wüsstet bessere Lösungen für eurem ursprünglichen Geschäft extrem weit entfernte Geschäftsproblemstellungen.
Nur weil jeder von uns mal krank war, zum Arzt musste und dort ein Rezept erhalten hat, ist er kein Experte für's Gesundheitswesen und kann deshalb BC's, DLT's und VC's auf das konkrete Problemfeld "Bewirtschaftung von Rezepten" anwenden.
Wie es Einstein mal schön formulierte (weiss gar nicht, ob Einstein der ursprüngliche "Erfinder" war): die Welt, die wir kennen (und verstehen), ist so extrem klein im Vergleich zur Welt, die wir nicht kennen aber kennen müssten, um die bekannte Welt wirklich verstehen zu können.

[pascalgottret]

Dein Votum "der E-ID Probleme anzuhängen" kann ich nicht nachvollziehen. Wir sprechen hier über das Ambitionsniveau 3, wobei es überhaupt nicht nur um die e-ID geht.
Dein zweites Votum "dass wir bessere Lösungen wissen" ist ebenfalls nicht nachvollziehbar. Wir wissen nicht bessere Lösungen, wir diskutieren über spannende Fragestellungen, die ggf. anderweitige Probleme lösen könnten. Zum Beispiel Ticketing Systeme. Tickets zu Events können auch nur einmal eingelöst werden. Glaubst du nicht, dass Tickets zukünftig über Credentials laufen?

Bevor wir zu Beginn an jeden Use Case als "hat nichts mit SSI zu tun" abschreiben, diskutiere ich lieber über mögliche Lösungsansätze. Wenn die Fachwelt dann sagt, dass es nicht klappt, können wir die Sache immer noch in die Schublade schieben, haben dafür neue Erkenntnisse.

Du sagst es ja selber, Rezepte sind Verträge. Genau solche Verträge können zukünftig in Kombination VC und Smart Contracts abgebildet werden. Ein Credential könnte ein Token beinhalten, der beim Gebrauch "geburnt" wird (Modewort NFT. Ja, NFT bedeutet nicht nur Kunst auf der DLT :) ). Die nächste Prüfung des Credentials schlägt fehl, weil der Token nicht mehr vorhanden ist.

[grt-dti]

Smart Contracts haben mit der VC-Idee der nationalen E-ID keine nennenswerte Berührung mehr. Ambition 3 ist die Fusion aller exklusiv einer nationalen E-ID gehörigen Bestätigungen nicht-staatlicher Akteure. Ein Rezept oder eine Eintrittskarte "gehört" nicht einer Person; es kann und muss übertragen werden können. Das Zentrum aller Ambitionen der E-ID ist die E-ID; nicht die Digitalisierung der Gesellschaft! Die ganzen schönen anderen Ideen muss man woanders diskutieren, sonst kommen wir mit der E-ID nicht voran und alles verpufft - darum "nicht der E-ID anhängen". Wir können gern über SmartContracts bei Rezepten oder Eintrittskarten diskutieren (die Eintrittskarten aber bitte nicht auf staatlicher Regulation, weil das geht den Staat nix an - bei Rezepten sieht das noch ein kleines bisschen anders aus), aber dann bitte nicht im Kontext der nationalen E-ID.

Jede Idee, die wir hier diskutieren, muss einen nennenswerten Beitrag zur Gestaltung der E-ID liefern; Revokation durch Dritte (als Funktion) tut das hoffentlich noch (ich kann mir den Anwendungsfall noch nicht ganz vorstellen), aber Rezepte und Eintrittskarten tun es nicht mehr (in keinem Ambitionsniveau der E-ID)

[pascalgottret]

Dann muss mir jemand nochmal die dritte Ebene des Ambitionsniveau im Diskussionspapier "Zielbild e-ID" erklären. Da steht ziemlich deutlich: "Das Ambitions-Niveau 3 bietet das grösste Potential, das Huhn-Ei-Problem zu lösen. Im vollen
Umfang des Ökosystems wird die E-ID nur noch einen von vielen digitalen Nachweisen darstellen. Eine
Verknüpfung zur E-ID ist dabei möglich, ein digitaler Nachweis kann jedoch auch unabhängig der E-ID sein, z. B. ein Event- oder ÖV-Ticket, ein Mitgliederausweis, ein Impfausweis eines Haustieres, ein Fahrzeugausweis oder die Bescheinigung einer erfolgreichen Motorfahrzeugkontrolle für ein Auto."

[christianheimann]

@pascalgottret Du verstehst und liest das Zielbild korrekt. Die Vision mit Ambitionsniveau 3 geht über die Identität (wer bin ich) heraus. @grt-dti repräsentiert nicht die Meinung des Projektteam E-ID.

[romanzoun]

Ich muss sagen, NFTs Coins und Smart Contracts sind nicht teil von SSI. Eigentlich muss die registry nicht dezentral sein und kann einfach ein Excel in Sharepoint sein, die die Public Keys der Aussteller enthält. Ambitionslevel 3 sagt nur, dass die Privatwirtschaft digitale Nachweise als VC ausgeben können, oder diese verifizieren.

Beispiel: Zins und Kapitalausweis als VC für die Steuererklärung, oder Ausgabe von Gehaltsscheinen als VC für Kreditantrag.

Alles Beispiele, die Ohne SSI ja auch irgendwie funktionieren.

Sowas wie automatisches triggern, wie bei Smart Contracts, wird nur auf Issuer oder Verifier Seite ausgelöst und ist eine einseitige Individuallösung, die erstellt werden muss. Nicht vergessen, Issuer und Verifier wissen nichts voneinander, denn es geht alles über den Holder. Ausserdem transferierbare Nachweise bietet SSI aktuell ebenfalls nicht und wird es in Naher Zukunft auch nicht tun (Konzeptuell ist aber was in Arbeit).

Klar kann man auch Rezepte ausgeben, aber da bringt SSI keinen Mehrwert, wie ich in meinen Gedankengang oben präsentierte.
Damit ein Level 3 Use-Case entsteht, muss ein klarer Mehrwert dahinter stecken, der ein Problem für die Nutzer, oder die privatwirtschaftliche Institution löst. Welches Problem wird bei der Rezeptausstellung gelöst mit SSI und welche Mehrwert hat man dadurch? (Selber hingehen und das Rezept zeigen funktioniert)

Zusätzlich muss ich sagen, dass in meinen Augen die Identität alles ist was mich ausmacht Da ist neben der eID auch meine Versicherungskarte, auch meine Kinotickets, die mein Interessen repräsentieren, sowie Gehaltsscheine, die meine wirtschaftliche Situation repräsentieren. Da die digitalen Nachweise meinen Besitz, meine Situation, meine Eigenschaften repräsentieren, sind alle meine digitalen Nachweise die Antwort auf "wer bin ich". Deshalb heisst es Self Sovereign IDENTITY, obwohl da auch andere Sachen verwaltet werden können, als nur die eID. Also sind es nach DSG, schützenswerte personenbezogene Daten, die man am besten in seiner persönlichen Wallet speichert.

Was sagt ihr dazu?