- \n
- wir begr\u00fc\u00dfen die Betrachtung und Analyse von SSI durch das BSI<\/li>\n\n\n\n
- wir stimmen in wesentlichen Punkten \u00fcberein<\/li>\n\n\n\n
- wir sehen allerdings auch Differenzen, die wir in dieser Stellungnahme darlegen wollen<\/li>\n\n\n\n
- SSI bietet in unseren Augen Mehrwerte in dom\u00e4nen- und jurisdiktions\u00fcbergreifenden Anwendungsf\u00e4llen<\/li>\n\n\n\n
- wir freuen uns auf einen weiteren konstruktiven Austausch zwischen relevanten Akteuren, um zuk\u00fcnftige Entwicklungen in SSI mit Hinblick auf regulatorische Anforderungen planen zu k\u00f6nnen.<\/li>\n<\/ul>\n\n\n\n
IDunion<\/h2>\n\n\n\n
IDunion ist ein gef\u00f6rdertes Projektkonsortium aus dem Forschungsverbund \u201cSichere digitale Identit\u00e4ten\u201d des BMWK. Das Konsortium setzt sich aus 15 Konsortialpartnern und weiteren mehr als 40 assoziierten Partnern und Kontributoren zusammen. Das Konsortium w\u00e4chst stetig und hat internationale Partner.<\/p>\n\n\n\n
Ziel von IDunion ist der Aufbau eines vertrauensvollen, dezentralen \u00d6kosystems f\u00fcr digitale Identit\u00e4ten und Nachweise, die national wie international von nat\u00fcrlichen und juristischen Personen nutzbar sind.<\/p>\n\n\n\n
Um unser Ziel zu erreichen, gr\u00fcnden wir eine europ\u00e4ische Genossenschaft, beginnen mit der Pilotierung einfacher Anwendungsf\u00e4lle bis hin zur produktiven Umsetzung komplexer Anwendungsf\u00e4lle. Die Interoperabilit\u00e4t zu bestehenden oder anderen sich entwickelnden Technologien ist uns dabei genauso wichtig wie die Einhaltung der DSGVO und der SSI Prinzipien. Mit dieser Herangehensweise wollen wir im letzten Schritt unserer Entwicklung stark regulierte Anwendungsf\u00e4lle umsetzen und den Fokus erweitern auf Identit\u00e4ten f\u00fcr Maschinen und Dinge.<\/p>\n\n\n\n
Wir arbeiten mit anderen \u00d6kosystemen und Schaufensterprojekten zusammen und integrieren bestehende L\u00f6sungen, wie die eID-Funktion des Personalausweises in Deutschland.<\/p>\n\n\n\n
Mit einem heterogenen Partnernetzwerk im Konsortium stellen wir die Verwendung in allen wichtigen Wirtschaftszweigen sicher. Vom eGovernment und Bildung \u00fcber Finance und Industry bis hin zum eHealth. Diese Breite ist zugleich eine Herausforderung, denn die Anforderungen an die Identit\u00e4ten und Nachweise sind dadurch so unterschiedlich wie ihre Anwendungsbereiche. Die Projektergebnisse werden dabei immer mit dem Projekttr\u00e4ger als auch interessierten Ministerien geteilt und sogar gemeinsame Piloten zur Erprobung durchgef\u00fchrt.<\/p>\n\n\n\n
IDunion betreibt seit 2020 erfolgreich ein Testnetzwerk mit \u00fcber 15 Knoten, der Start eines Produktivnetzwerks zusammen mit einer Governance unter der europ\u00e4ischen Genossenschaft ist f\u00fcr 2022 geplant.<\/p>\n\n\n\n
IDunion ist nicht nur Betreiber eines technischen Netzwerks, sondern leistet auch Arbeit zur Koordination und Weiterentwicklung des SSI-\u00d6kosystems, z.B. durch OpenSource-Kontribution, Governance-Framework, Konformit\u00e4tskriterien und in der Standardisierung.<\/p>\n\n\n\n
IDunion Verst\u00e4ndnis von SSI mit DLT<\/h3>\n\n\n\n
IDunion m\u00f6chte eine L\u00f6sung basierend auf dem Konzept und Prinzipien von \u201cSelf Sovereign Identities\u201d bereitstellen, die 2016 von Christopher Allen definiert wurden. Um diese zu sch\u00fctzen, m\u00f6chten wir auf einem DLT-Netzwerk Schemadaten, Revozierungsdaten und \u00f6ffentliche Schl\u00fcssel von juristischen Personen hochverf\u00fcgbar und dezentral speichern, nicht jedoch Informationen von Privatpersonen oder mit Personenbezug. Diese liegen ausschlie\u00dflich in der Hoheit der Personen selbst, z.B. in einer Wallet.<\/p>\n\n\n\n
IDunion hat sich zun\u00e4chst f\u00fcr eine Erprobung von Hyperledger Indy\/Aries entschieden, einem der zur Zeit am weitesten entwickelten und am weitesten verbreiteten Technologiestacks. Dieser Stack erm\u00f6glicht uns, eine datenschutzfreundliche Open Source L\u00f6sung zu entwickeln.<\/p>\n\n\n\n
Neben Indy werden alternative Technologien untersucht und erprobt, wie LD Proofs, BBS+, KERI und OpenID Connect sowie andere Ledger-Technologien und Entwicklungen, wie z.B. die European Blockchain Service Infrastructure (EBSI). Wir benutzen, wo m\u00f6glich, anerkannte bestehende Standards, Methoden und Technologien.<\/p>\n\n\n\n
Das DLT-Netzwerk dient uns als Vertrauensanker sowie als Nachschlagewerk beim Prozess der Verifikation von Attributen, ohne den Aussteller selbst zu kontaktieren und nicht bei einer einzelnen vertrauensvollen Institution anfragen zu m\u00fcssen. So vermeiden wir eine etwaige Profilbildung. Um dieses Vertrauen herzustellen, erarbeiten wir ein Governance-Regelwerk, Konformit\u00e4tskriterien und pr\u00fcfen die juristischen Personen sehr gr\u00fcndlich.<\/p>\n\n\n\n
Wir setzen bei der Vertrauensbildung auf etablierte Systeme wie Zertifikate, TSP, hierarchische Vertrauensketten und distanzieren uns von fr\u00fcheren, libert\u00e4ren Ideen, die mit SSI assoziiert wurden.<\/p>\n\n\n\n
Akteure im IDunion \u00d6kosystem sollten sich gegenseitig ihre Identit\u00e4t und Authentizit\u00e4t abh\u00e4ngig vom jeweiligen Anwendungsfall best\u00e4tigen, um das Vertrauen in den Gegen\u00fcber zu wahren, bevor Daten freigegeben werden. Entsprechende Konzepte, z.B. Trusted Verifier, wurden bereits entwickelt und werden derzeit implementiert. Das Vertrauen wird hierarchisch hergestellt und \u00fcber eine Governance geregelt. In IDunion sind die Partner identifiziert und die Teilnehmer der Blockchain gehen Vertragsbeziehungen ein.<\/p>\n\n\n\n
Gemeinsamkeiten in der Bewertung von SSI<\/h2>\n\n\n\n
Wir sehen viele Gemeinsamkeiten und Zustimmungen im Eckpunktepapier des BSI:<\/p>\n\n\n\n
- \n
- F\u00fcr die vollst\u00e4ndige Digitalisierung von Prozessen in der Wirtschaft und im \u00f6ffentlichen Bereich ben\u00f6tigen wir Personen-, Unternehmens- und Ger\u00e4teidentit\u00e4ten, die die jeweils notwendigen eIDAS Vertrauensniveaus aufweisen.<\/li>\n\n\n\n
- F\u00fcr die Umsetzung von SSI ben\u00f6tigt man nicht zwingend eine Blockchain\/Ledger. Man kann SSI ohne Ledger realisieren oder als Hybridl\u00f6sung. Hier ist eine weiterf\u00fchrende Diskussion \u00fcber die Chancen und Mehrwerte einer dezentralen, verteilten L\u00f6sung interessant.<\/li>\n\n\n\n
- DIDs von Privatpersonen sollten nicht auf einem Ledger ver\u00f6ffentlicht werden; Informationen auf dem Ledger sind insbesondere f\u00fcr Unternehmensidentit\u00e4ten und Beh\u00f6rden sinnvoll.<\/li>\n\n\n\n
- Vertrauen ist insbesondere f\u00fcr regulierte Anwendungsf\u00e4lle ein essenzieller Bestandteil des gesamten \u00d6kosystems. Aus diesem Grund ben\u00f6tigen wir ein geeignetes Vertrauenskonzept, das die Authentizit\u00e4t des Issuers bzw. Verifiers sicherstellt und das auch aus Nutzersicht in der UX der Wallet Geltung findet. Dabei steht ein zentraler (staatlicher) Vertrauensanker in (dezentraler) SSI nicht im Widerspruch.<\/li>\n\n\n\n
- Standardisierungs- und Gremienarbeit ist essenziell f\u00fcr ein sicheres System und deren Bewertung. Der SSI Softwarestack wird in verschiedenen internationalen Standardisierungs- und Industriegremien entwickelt:<\/li>\n\n\n\n
- W3C Decentralized Identifiers<\/li>\n\n\n\n
- W3C Verifiable Credentials<\/li>\n\n\n\n
- DIF DIDComm Messaging (Identity Foundation)<\/li>\n\n\n\n
- Hyperledger Aries Interop Profile (1.0\/2.0)<\/li>\n\n\n\n
- OpenIDConnect (OpenIDFoundation)<\/li>\n\n\n\n
- beginnende Standardisierung der AnonCreds 1.0<\/li>\n\n\n\n
- BBS+<\/li>\n\n\n\n
- Es besteht die Notwendigkeit weiterer Standardisierungsbem\u00fchungen bei ISO, CEN (TC224), ETSI (JaDES), IETF.<\/li>\n\n\n\n
- Dar\u00fcber hinaus m\u00fcssen SSI Systeme notwendige Sicherheits- und Compliance Voraussetzungen erf\u00fcllen, die wie z.B. Kryptoagilit\u00e4t noch nicht in den technischen Systemen realisiert sind.<\/li>\n<\/ul>\n\n\n\n
Unterschiede in der Bewertung von SSI<\/h2>\n\n\n\n
Neben den zahlreichen \u00dcbereinstimmungen mit dem Eckpunktepapier des BSI haben wir zu den folgenden Themenfeldern abweichende bzw. erg\u00e4nzende Einsch\u00e4tzungen. Diese Einsch\u00e4tzungen m\u00f6chten wir hier gerne erl\u00e4utern:<\/p>\n\n\n\n
- \n
- Das heutige Verst\u00e4ndnis von SSI spiegelt keinesfalls libert\u00e4re, staatsmisstrauende Gedanken wider und verfolgt auch keine derartigen L\u00f6sungsans\u00e4tze wie das Web-of-Trust. Wir verfolgen vielmehr den Ansatz, dass es verschiedene Trust Domains geben kann (Staat, GS1, GLEIF, Banken). Im Rahmen dieser Trust Domains k\u00f6nnen Credentials ausgestellt werden. Ein Verifier kann dann zwischen Credentials aus unterschiedlichen Dom\u00e4nen unterscheiden.<\/li>\n\n\n\n
- Viele SSI-Ans\u00e4tze benutzen verteilte Systeme wie DLT\/Blockchain als Vertrauensanker mit unterschiedlichen Eigenschaften f\u00fcr Sicherheit und Privatsph\u00e4re. Wir vertreten den Standpunkt, dass Hyperledger Indy heute den Ansatz darstellt, der eine bestm\u00f6gliche Privatsph\u00e4re f\u00f6rdert.<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/idunion.org\/wp-content\/uploads\/2024\/12\/Abb_1_Systemuebersicht-IDunion.png\")
<\/figure>\n\n\n\n- \n
- Im Gegensatz zu der im Eckpunktepapier kritischen Betrachtung der DLT sehen wir in ihrem Einsatz die Chance zur Schaffung von Vertrauen in einem dezentralen Netzwerk.<\/li>\n\n\n\n
- Vertrauen wird innerhalb einer Vertrauensdom\u00e4ne unterhalb eines sehr bekannten (well-known) Vertrauensankers ausgebaut. Beispielsweise k\u00f6nnen Vertrauensdom\u00e4nen mittels TSPs nach eIDAS (z.B. Bundesdruckerei\/D-Trust) oder zus\u00e4tzlichen privaten Entit\u00e4ten (GS1 oder GLEIF) realisiert werden.<\/li>\n\n\n\n
- Wir sehen in dem Einsatz eines DLT-Netzwerkes auch die M\u00f6glichkeit der besseren Skalierbar- und Verf\u00fcgbarkeit des Gesamt\u00f6kosystems. DLT kann zudem bei der Revozierung ein h\u00f6heres Level an Privatsph\u00e4re erreichen, als ein klassisches vom Austeller verwaltetes Sperrsystem.<\/li>\n\n\n\n
- Neben den Punkten, welche Eigenschaften DLT derzeit fehlen, vermissen wir eine Betrachtung der Vorteile, die DLT gegen\u00fcber etablierten Systemen ohne Zusatzaufwand anbieten kann (unabh\u00e4ngig davon, ob diese in jedem Fall gefordert sind): Immutability & echte Dezentralit\u00e4t mit gleichberechtigten Knotenpunkten mittels Konsensus-Protokoll w\u00e4ren als Beispiele zu nennen.<\/li>\n\n\n\n
- Gleichzeitig sollte die Rolle von DLT in SSI allgemein sowie im IDunion Projekt nicht \u00fcberbewertet werden. Parallel werden in dem Projekt auch Methoden wie did:key und did:web eingesetzt, die ohne DLT auskommen.<\/li>\n\n\n\n
- Wir erkennen an, dass es keine belastbaren Sicherheitsaussagen f\u00fcr SSI als Gesamtsystem gibt, jedoch viele Subkomponenten langfristig bereits erprobt sind, z. B. Konsens-Algorithmus, Merkle Trees und Transportverschl\u00fcsselung. Sub-Komponenten, wie z.B. Zero Knowledge Proof (ZKP), m\u00f6chten wir gerne gemeinsam mit dem BSI untersuchen und bewerten, eigenst\u00e4ndig und im Zusammenspiel mit den anderen Komponenten im SSI Gesamtsystem. Die von IDunion eingesetzte DLT\/Blockchain Technologie ist eine Subkomponente, die wir w\u00e4hrend unseres Projektes auf ihre Sicherheit hin \u00fcberpr\u00fcfen werden. Die Ergebnisse werden von IDunion ver\u00f6ffentlicht.<\/li>\n\n\n\n
- Das vom BSI benannte Problem der Datensouver\u00e4nit\u00e4t kann auch SSI nicht vollst\u00e4ndig l\u00f6sen. Jedoch handelt es sich hierbei um ein technologisches Problem, das auch durch andere Technologien nicht ohne Weiteres zu l\u00f6sen ist.\u00a0 SSI bietet aber viele M\u00f6glichkeiten,\u00a0 ein sicheres und DSGVO konformes System zur Verf\u00fcgung zu stellen. DLT kann die DSGVO erf\u00fcllen, kann sie aber allein nicht durchsetzen.<\/li>\n\n\n\n
- IDunion erfordert keine Anreizsysteme wie z.B. Kryptotoken oder \u00c4hnliches. Herk\u00f6mmliche pay-per-transaction Gesch\u00e4ftsmodelle k\u00f6nnen umgesetzt werden oder ein System als staatsfinanzierte Basisinfrastruktur f\u00fcr Identit\u00e4ten.<\/li>\n\n\n\n
- In IDunion werden weder Credentials noch Hashwerte auf der DLT gespeichert. Eine wesentliche Fragestellung ist, ob Hashwerte als personenbezogenes Datum gelten. Unsere SSI L\u00f6sung ber\u00fccksichtigt dies bereits im Design und distanziert sich so von anderen SSI L\u00f6sungen.<\/li>\n\n\n\n
- Folgenden Abschnitt finden wir missverst\u00e4ndlich: \u201eDa der Verlust privater Schl\u00fcssel erfahrungsgem\u00e4\u00df nicht in jedem Fall zu verhindern ist, darf er nicht zum unwiederbringlichen Verlust von Credentials f\u00fchren.\u201c SSI bietet eine Plattform f\u00fcr verschiedene Sicherheiten, und das Schl\u00fcsselmanagement ist abh\u00e4ngig von LoA:\n
- \n
- F\u00fcr Credentials, die das Vertrauensniveau substantiell oder hoch erf\u00fcllen, muss eine Speicherung in einem sicheren Schl\u00fcsselspeicher wie SecureEnclave, Secure Elements oder HSM erfolgen. Aus diesem Grund kann unter Umst\u00e4nden kein Backup erstellt werden. In diesem Fall ist eine Revozierung des urspr\u00fcnglichen Credentials erforderlich und danach eine erneute Ausstellung (Bsp. Digitaler Personalausweis).<\/li>\n\n\n\n
- F\u00fcr Credentials, die das Vertrauensniveau niedrig erf\u00fcllen, k\u00f6nnen auch andere Mechanismen zur Anwendung kommen, wie zum Beispiel das Differential Credential Security Konzept. Au\u00dferdem kann auch ein Cloud Backup unter Beachtung der erforderlichen Sicherheitsma\u00dfnahmen realisiert werden. Bei einem Verlust kann das Credential dann aus einem Cloud Backup wiederhergestellt werden.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Chancen von SSI<\/h2>\n\n\n\n
F\u00fcr ein digitales Identit\u00e4ts- und Vertrauens\u00f6kosystem sehen wir die folgenden Chancen:<\/p>\n\n\n\n
- \n
- Die verschiedenen Nachweise k\u00f6nnen dom\u00e4nen\u00fcbergreifend kombiniert und mit semantischen Modellen durch verschiedene Akteure interpretierbar gemacht werden. Dies ist in den eID, DTC oder mDL so nicht vorgesehen. So k\u00f6nnen VCs aus der Vertrauensdom\u00e4ne des Staates kombiniert werden mit VCs aus anderen Vertrauensdom\u00e4nen wie z.B. GS1, GLEIF oder Impfnachweise. All diesen Beispielen gemein ist, dass es regulatorische oder Anwendungsfall-spezifische Vorgaben gibt, die eine E2E-Verifizierbarkeit von Daten erfordern.<\/li>\n\n\n\n
- SSI ist ein Konzept f\u00fcr ein \u00d6kosystem, in dem viele Issuer und Verifier zusammenkommen und das effiziente Prozessabfl\u00fcsse auf Basis gleicher Schnittstellen f\u00fcr diese unterschiedlichen Rollen erm\u00f6glicht. So kann eine Entit\u00e4t die Verifier- und Issuer-Rolle einnehmen. Beispielsweise identifiziert eine Beh\u00f6rde den B\u00fcrger zuerst, bevor sie ihm ein Credential ausstellt.<\/li>\n\n\n\n
- In Kombination mit einem Trust Framework, wie der eIDAS-Verordnung, kann eine dezentrale SSI-Identit\u00e4tsinfrastruktur Mechanismen f\u00fcr die Identifizierung, Authentifizierung und die Verifizierbarkeit der digitalen Nachweise bereitstellen.<\/li>\n<\/ul>\n\n\n\n
Verifiable Credentials (VC) versprechen eine vereinfachte maschinenlesbare, automatisierte und skalierbare Verarbeitung dieser Nachweise.<\/p>\n\n\n\n
Insbesondere f\u00fcr attribut- oder richtlinienbasierte Zugriffskontrolle f\u00fcr API-Endpunktsicherheit auf der Control Plane (Policy Decision Point) & Data Plane (Policy Enforcement Point) ist das von gro\u00dfer Bedeutung f\u00fcr Cybersecurity-L\u00f6sungen (siehe auch NIST Zero Trust Architecture [1] , Gaia-X).<\/p>\n\n\n\n
In den von IDunion betrachteten Anwendungsf\u00e4llen k\u00f6nnen nicht nur Menschen, sondern auch Unternehmen, Objekte und Maschinen eine dezentrale Identit\u00e4t nutzen. Die dazugeh\u00f6rigen Identifikatoren k\u00f6nnen \u00fcber Vertrauensketten, analog zu X.509-Zertifikatspfade, autorisiert werden.<\/p>\n\n\n\n
- \n
- VCs k\u00f6nnen auch eine gro\u00dfe Rolle bei der beh\u00f6rdlichen Registermodernisierung spielen und existierende Register um die Verifizierbakeit der darin enthaltenen Daten erg\u00e4nzen. (z.B. \u00f6ffentliche Register wie das der Marktstammdaten in der Energiewirtschaft). So sieht auch eIDAS 2.0 die Nutzung der \u00f6ffentlichen Register als sog. Trusted Sources vor.<\/li>\n\n\n\n
- SSI erm\u00f6glicht, die o.g. Chancen zu nutzen und dabei die Pers\u00f6nlichkeitsrechte der Menschen zu wahren. Im Gegensatz zu anderen L\u00f6sungen wird keine Profilbildung erm\u00f6glicht und auch keine personenbezogenen Daten zentral oder auf dem DLT gespeichert.<\/li>\n\n\n\n
- Statt die Benutzeraccounts von zentraler Hand zu generieren und anschlie\u00dfend Berechtigungen zuzuweisen, k\u00f6nnte der Benutzer seine DID selbst generieren. Anschlie\u00dfend muss seine Identit\u00e4t nur noch gepr\u00fcft und best\u00e4tigt werden. Berechtigungen werden vom Dom\u00e4nenverantwortlichen dezentral vergeben und mit VCs abgebildet. Die Nutzenden selbst sehen jederzeit, welche Berechtigungen sie zum aktuellen Zeitpunkt besitzen.<\/li>\n<\/ul>\n\n\n\n
Ausblick<\/h2>\n\n\n\n
Im neuesten Bericht der ENISA bef\u00fcrwortet diese die SSI Technologie und den Softwarestack als eine vielversprechende M\u00f6glichkeit:[2] \u201cApplicability to eIDAS, SSI and European eID Indy is the most advanced SSI solution based on blockchain and should be considered as one of technologies for the implementation of a European electronic identity wallet. According to the proposed revision of eIDAS, VCs will be issued by TSPs and named \u201celectronic attestation of attributes\u201d. Those trust services within the Hyperledger framework are the Stewards and trust anchors. The Indy network also provides the revocation functionality, which is required by eIDAS.\u201d<\/p>\n\n\n\n
Self-Sovereign Identity ist ein vielversprechender Kandidat f\u00fcr die (Qualified) Electronic Attestation of Attributes des neuen eIDAS Entwurfs. Wir m\u00f6chten den Austausch mit dem BSI zu diesem Thema fortf\u00fchren, um gemeinschaftlich die Potenziale von SSI zu ergr\u00fcnden und eine Digitalisierung Deutschlands auf dieser Grundlage voranzutreiben.<\/p>\n\n\n\n
\n\n\n\n[1] NIST, Zero Trust Architecture<\/p>\n\n\n\n
[2] https:\/\/www.enisa.europa.eu\/publications\/digital-identity-leveraging-the-ssi-concept-to-build-trust<\/p>\n","protected":false},"excerpt":{"rendered":"
Das Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) hat Anfang 2022 ein Eckpunktepapier zum Thema self-sovereign Identities (SSI) ver\u00f6ffentlicht. Im Folgenden m\u00f6chte das IDunion Konsortium dazu Stellung nehmen. Es wird aufgezeigt, in welchen Punkten IDunion mit dem BSI-Eckpunktepapier \u00fcbereinstimmt, und wo eine differenzierte Position vertreten wird. Wir m\u00f6chten durch unsere Erg\u00e4nzungsvorschl\u00e4ge einen \u00f6ffentlichen Dialog anregen […]<\/p>\n","protected":false},"author":1,"featured_media":719,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-749","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein"],"_links":{"self":[{"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/posts\/749","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/comments?post=749"}],"version-history":[{"count":1,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/posts\/749\/revisions"}],"predecessor-version":[{"id":751,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/posts\/749\/revisions\/751"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/media\/719"}],"wp:attachment":[{"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/media?parent=749"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/categories?post=749"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/idunion.org\/en\/wp-json\/wp\/v2\/tags?post=749"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}