Ověřitelné údaje - Verifiable credentials

Ověřitelné údaje (VC) jsou elektronickým ekvivalentem fyzických údajů, které dnes všichni máme, jako jsou: plastové karty, pasy, řidičské průkazy, kvalifikace a ceny atd. Datový model pro ověřitelné údaje je Doporučení pro konsorcium World Wide Web „Datový model Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web“ publikovaný 19. listopadu 2019.[1]

Model VC staví držitele pověření do středu ekosystému identity a dává jednotlivcům kontrolu nad jejich atributy identity. To kontrastuje s modelem federované správy identit (FIM), jak jej přijal SAML a OpenID Connect, který umisťuje poskytovatel identity (IdP) v ústřední roli jako rozdělovač atributů identity a určující, kterým poskytovatelům služeb (SP) je poskytne. Ve federovaném modelu je porušeno soukromí uživatele, protože poskytovatel identity zná každý SP, který uživatel navštíví. Na druhé straně model W3C VC se vyrovná způsobu, jakým dnes používáme identifikační karty: uživatel drží plastové karty v peněžence a může je kdykoli prezentovat komukoli, aniž by vyžadoval souhlas vydavatele karty. Takový model je decentralizovaný a dává účastníkům mnohem větší autonomii a flexibilitu.

Držitel ověřitelného pověření sedí uprostřed trojúhelníku důvěry a zprostředkovává mezi emitentem a ověřovatelem. Emitent a držitel si navzájem důvěřují, držitel důvěřuje ověřovateli a ověřovatel důvěřuje emitentovi. Jakoukoli roli v trojúhelníku může hrát osoba, instituce nebo zařízení IoT.

Standard W3C VC definuje syntaxi a sémantiku ověřitelných pověření. Mnoho různých protokolů je specifikováno pro přenášení VC z emitenta / IdP na držitele a držitele na ověřovatele. Mezi příklady patří:

  • Aries RFC 0036: Issue Credential Protocol 1.0. [2]a Aries RFC 0037: Present Proof Protocol 1.0[3]
  • David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant, Samer Wazan, Manreet Nijjar „Vylepšená správa identit s ověřitelnými pověřeními a FIDO“, IEEE Communications Standards Magazine Vol 3, číslo 4, prosinec 2019, strany 14-20

Žádný z těchto protokolů však ještě není standardizován a mohou se přesto objevit další konkurenční protokoly. Mnoho lidí, kteří dnes experimentují s VC, používají k přenosu VC mezi různými stranami nějakou příchuť HTTPS. Očekává se, že v nejbližší době bude nejoblíbenější nebo de-facto protokol (y) standardizován W3C nebo jiným normalizačním orgánem, jakmile budou získány další zkušenosti.

Jedním zajímavým rysem VC je, že držitel VC nemusí být vždy předmětem pověření. Ve většině případů budou uživatelé držet své vlastní VC, stejně jako dnes s sebou nosíme fyzické údaje, tj. Držitel a subjekt budou stejná entita. Ale nebude tomu tak vždy. Například pokud je subjektem VC zvíře a VC je očkovací certifikát, může být jeho držitelem majitel zvířete; pokud je subjekt VC kojenec a VC je rodný list, může být držitelem jeden nebo oba rodiče.

Ověřitelné údaje lze vyjádřit pomocí JSON. VC se obvykle skládá z: kontextu VC, identity emitenta, data a času vydání, data a času vypršení platnosti, typu VC, předmětu VC, jednoho nebo více atributů identity Subjekt VC a nakonec kryptografický důkaz vytvořený emitentem k zajištění integrity a autenticity VC. Žádný jednotný kontrolní mechanismus není standardizován. Naopak, datový model je dostatečně flexibilní, aby podporoval více existujících kryptografických mechanismů, jako jsou digitální podpisy. Mezi důkazní mechanismy, které implementátoři aktuálně používají, patří: Webové tokeny JSON s Webové podpisy JSON, JSON-LD důkazy a nulové znalosti pomocí schémat, jako jsou anonymní pověření IBM.

Kontext VC, definovaný pomocí @kontext JSON majetek, je a JSON-LD konstrukce, která umožňuje použít uživatelsky přívětivé výrazy JSON vlastnosti. Podle datového modelu VC musí být hodnota mnoha vlastností a URI. I když jsou globálně jednoznačné, což je důležitá vlastnost pro mezinárodně standardizovaný datový model, nejsou uživatelsky přívětivé. V důsledku toho @kontext vlastnost umožňuje definovat pro každého uživatelsky přívětivé aliasy v krátké formě URI. Díky tomu je mnohem jednodušší a uživatelsky přívětivější specifikovat VC. Níže je uveden příklad.

{  "@kontext": [    „https://www.w3.org/2018/credentials/v1“,    „https://www.w3.org/2018/credentials/examples/v1“  ],  „id“: „http://example.edu/credentials/3732“,  "typ": [„Ověřitelné pověření“, „UniversityDegreeCredential“],  „emitent“: „https://example.edu/issuers/14“,  "datum vydání": „2010-01-01T19: 23: 24Z“,  "Datum spotřeby": „2020-01-01T19: 23: 24Z“,  „credentialSubject“: {    „id“: "did: example: ebfeb1f712ebc6f1c276e12ec21",    "stupeň": {      "typ": "Bakalářský titul",      "název": "Bachelor of Science and Arts"    }  },  "důkaz": {   }}

V3 W3C jsou rozšiřitelné. K VC může být přidána jakákoli nová vlastnost nejen podle určení emitenta, ale existují také některé standardní vlastnosti, které byly definovány konkrétně jako body rozšíření. Patří mezi ně následující:

podmínky použití
jedná se o omezení týkající se používání VC emitentem
schéma
toto definuje schéma obsahu VC
důkaz
to umožňuje emitentovi říci, jaké důkazy shromáždil o subjektu a / nebo atributech před vydáním VC
postavení
ukazatele na to, kde může ověřovatel zjistit aktuální stav VC (např. zda byl zrušen).

Reference

  1. ^ „Ověřovací pověření - datový model 1.0“. www.w3.org. Citováno 2019-11-05.
  2. ^ Khateev, Nikita. „Aries RFC 0036: Issue Credential Protocol 1.0“. Github - Projekt Hyperledger Aries. Hyperledger. Citováno 5. listopadu 2019.
  3. ^ Khateev, Nikita. „Aries RFC 0037: Present Proof Protocol 1.0“. Github - Projekt Hyperledger Aries. Hyperledger. Citováno 5. listopadu 2019.