Identifiants vérifiables
La mise en forme de cet article est à améliorer ().
La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».
Cet article est orphelin. Moins de trois articles lui sont liés ().
Vous pouvez aider en ajoutant des liens vers [[Identifiants vérifiables]] dans les articles relatifs au sujet.
Les identifiants vérifiables, ou titres vérifiables, (IV, ou verifiable credentials en Anglais, VC) sont une norme ouverte pour les identifiants numériques. Ils peuvent représenter des informations présentées par des preuves d'identification physiques, telles qu'un passeport ou un permis de conduire, mais également des choses qui n'ont traditionnellement pas d'équivalent physique, comme le fait de détenir un compte bancaire. Ils présentent certains avantages par rapport aux identifiants physiques, notamment le fait d'être signés numériquement, ce qui les rend théoriquement inviolables et instantanément vérifiables[1],[2] Néanmoins, la sécurité des identifiants vérifiables a également été remise en question[3]. Les identifiants vérifiables posent également des problèmes d'utilisabilité[4]. Les identifiants vérifiables peuvent être émis par n'importe qui, à n'importe quel sujet, et peuvent être présentées et vérifiées par tout le monde. L'entité qui génère l'identifiant est appelée l'émetteur. L'identifiant est alors remis au titulaire qui le stocke pour une utilisation ultérieure. Le titulaire peut alors prouver quelque chose à son sujet en présentant ses identifiants vérifiables à un vérificateur.
Modèle de confiance[modifier | modifier le code]
Le titulaire d'un titre vérifiable se trouve au centre d'un triangle de confiance [5], en position de médiation entre l'émetteur et le vérificateur.
- L'émetteur fait confiance au titulaire
- Le titulaire fait confiance au vérificateur
- Le vérificateur fait confiance à l'émetteur
Tout rôle dans le triangle peut être joué par une personne, une institution ou un appareil IoT.
Notons qu'étant donné qu'un identifiant vérifiable peut être créé par n'importe qui, la personne ou l'entité qui vérifie l'identifiant doit décider si elle fait confiance ou non à l'entité qui l'a émis. En cela, la situation est similaire à celle d'un employé de magasin qui doit décider s'il accepte ou non le permis de conduire d'un autre État comme preuve d'âge lors de l'achat d'alcool.
Décentralisation[modifier | modifier le code]
Le modèle VC place le titulaire d'un titre au centre de l'écosystème d'identité, donnant aux individus le contrôle de leurs attributs d'identité. Le modèle W3C VC est aligné sur celui des titres d'identité physiques : l'utilisateur détient des cartes (d'identité, permis de conduire…) et peut les présenter à n'importe qui à tout moment sans en informer l'émetteur de la carte ni lui demander d'autorisation. Un tel modèle est décentralisé et offre beaucoup plus d'autonomie et de vie privée aux participants.
Ce modèle peut-être mis en contraste avec le modèle de gestion d'identité fédérée tel qu'adopté par SAML et OpenID Connect, qui place le fournisseur d'identité dans le rôle central en tant que fournisseur d'attributs d'identité et en font le seul décideur des fournisseurs de services auxquels il acceptera de répondre ou non. Dans le modèle fédéré, le fournisseur d'identité a connaissance de chaque service visité par l'utilisateur.
Modèle de données des identifiants vérifiables 1.0[modifier | modifier le code]
Le modèle de données pour les identifiants vérifiables est une recommandation du World Wide Web Consortium (W3C), publiée le 19 novembre 2019[6] sous le titre "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the web" ("Exprimer des informations vérifiables sur le Web").
Composition[modifier | modifier le code]
Les identifiants vérifiables peuvent être exprimés en JSON et sont typiquement composés de :
- Contexte
- Émetteur
- Horodatage de l'émission
- Horodatage de l'expiration
- Type
- Sujet
- Attributs d'identité du sujet
- Preuve cryptographique pour assurer l'intégrité et l'authenticité de l'IV
{
"verifiableCredential": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "0892f680-6aeb-11eb-9bcf-f10d8993fde7",
"type": [
"VerifiableCredential",
"UniversityDegreeCredential"
],
"issuer": {
"id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
"name": "Acme University"
},
"issuanceDate": "2021-05-11T23:09:06.803Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science"
}
},
"proof": {
"type": "Ed25519Signature2018",
"created": "2021-05-17T15:25:26Z",
"jws": "eyJhbGciOiJFZERTQYjY0Il19..nlcAA",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://pathToIssuerPublicKey"
}
}
}
Alias[modifier | modifier le code]
Il est possible de décrire en langage courant certaines propriétés JSON, dans le but de rendre les identifiants plus simples à utiliser.
Le contexte VC, défini via la propriété JSON @context, est une construction JSON-LD qui permet de décrire en termes familiers des propriétés JSON. En effet, selon le modèle de données VC, de nombreuses propriétés doivent avoir pour valeur une URI. Si les URI ont l'avantage d'être globalement non-ambiguës – une propriété importante pour un modèle de données global – elles ne sont loin d'être facile à lire ou retenir. La propriété @context permet de définir des alias courts en langage commun pour chaque URI. Cela rend beaucoup plus aisée et utilisable la spécification d'IV. Un exemple est donné ci-dessous.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"expirationDate": "2020-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
}
}
Les VC W3C sont extensibles. N'importe que nouvelle propriété peut être ajoutée aux VC, au bon vouloir de l'émetteur. Les propriétés standard ont été définies spécifiquement en tant que points d'extension. Il s'agit notamment des éléments suivants :
- conditions d'utilisation – restrictions imposées à l'utilisation de l'IV par l'émetteur
- schéma – définit le contenu de l'IV
- preuve – informations recueillies par l'émetteur sur le sujet et/ou les attributs avant d'émettre l'IV
- statut – indication pour aider un vérificateur à découvrir l'état d'un IV (par exemple, s'il a été révoqué).
Sujet[modifier | modifier le code]
Il est prévu que la majorité des utilisateurs stockent leur propres IV, ie : le titulaire et le sujet d'un IV sont alors la même entité. Mais ça n'est pas une obligation et il n'est pas nécessaire pour le titulaire d'un IV d'en être le sujet. Par exemple, lorsque le sujet d'un IV est un nourrisson et que l'IV est un certificat de naissance, le titulaire peut être l'un des parents ou les deux[7].
Preuves[modifier | modifier le code]
Aucun mécanisme de preuve n'a été standardisé pour l'heure, mais le modèle de données est suffisamment flexible pour prendre en charge divers mécanismes cryptographiques existants, tels que les signatures numériques. Les mécanismes de preuve utilisés à l'heure actuelle incluent : les jetons Web JSON avec signatures Web JSON, les preuves JSON-LD et les preuves à connaissance nulle en utilisant par exemple les identifiants anonymes proposés par IBM.
Transport[modifier | modifier le code]
Divers protocoles ont été spécifiés pour transporter les IV d'un émetteur à un titulaire, et d'un titulaire à un vérificateur. Par exemple :
- Aries RFC 0036[8] : Issue Credential Protocol 1.0. , et Aries RFC 0037 : Present Proof Protocol 1.0 [9]
- David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant, Samer Wazan, Manreet Nijjar "Improved Identity Management with Verifiable Credentials and FIDO" (Amélioration de la gestion des identités grâce aux identifiants vérifiables et FIDO), IEEE Communications Standards Magazine Vol 3, numéro 4, décembre 2019, pages 14 à 20 [10]
Aucun de ces protocoles n'a été standardisé. Une grande partie des personnes qui expérimentent actuellement les IV utilisent HTTPS pour transporter les IV entre les diverses parties.
Articles connexes[modifier | modifier le code]
- Identifiants décentralisés
Notes et références[modifier | modifier le code]
- (en) « An Introduction to Verifiable Credentials », sur verifiablecredential.io
- « What are Verifiable Credentials? | Decentralized Identity Developer Docs », didproject.azurewebsites.net
- « By embracing blockchain, a California bill takes the wrong step forward », blog.mozilla.org
- Clemens Brunner, Ulrich Gallersdörfer, Fabian Knirsch, Dominik Engel et Matthes, DID and VC : Untangling Decentralized Identifiers and Verifiable Credentials for the Web of Trust, , 61–66 p. (ISBN 9781450388962, PMCID 232291138, DOI 10.1145/3446983.3446992, lire en ligne)
- « A Gentle Introduction to Verifiable Credentials », www.evernym.com (consulté le )
- « Verifiable Credentials Data Model 1.0 », sur www.w3.org (consulté le )
- « On Guardianship In Self-Sovereign Identity », www.sovrin.org (consulté le )
- Khateev, « Aries RFC 0036: Issue Credential Protocol 1.0 », Github - Hyperledger Aries Project, Hyperledger (consulté le )
- Khateev, « Aries RFC 0037: Present Proof Protocol 1.0 », Github - Hyperledger Aries Project, Hyperledger (consulté le )
- (en) Chadwick, Laborde, Oglaza et Venant, « Improved Identity Management with Verifiable Credentials and FIDO », IEEE Communications Standards, vol. 3, no 4, , p. 14–20 (ISSN 2471-2825, DOI 10.1109/MCOMSTD.001.1900020, S2CID 212706653, lire en ligne)
