Technical group

Technical Working Group of the Education and Skills Data Space

Changes at "BCD Meeting about DID Login on Portal"

Compare view mode:

HTML view mode:

Title (Français)

+Réunion Log In with BCD

Title (Deutsch)

Title (Italiano)

Title (English)

+BCD Meeting about DID Login on Portal

Title (Català)

Title (Castellano)

Description (Français)

+
Participants
- Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), @Perrin, @Laurine B, @Mathieu S
Déroulé

Présentation du prototype : https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home et échanges

Luc nous a présenté ce que BCD a commencé à concevoir, à savoir un webwallet.

Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité côté BCD.

Conclusions

Chaque utilisateur du portail aurait 1 compte mywallet par Entreprise, par exemple :

En tant que Matt Sonatti, je devrais utiliser (et donc posséder) :
- Un compte mywallet “Inokufu” lorsque je publie des services marqués Inokufu sur le portail
- Un compte mywallet “X” lorsque je décide de publier des services marqués X sur le portail
Me login/logout de wallets lorsque je passe d’une entreprise à une autre

L’utilisateur se log à son compte Entreprise sur le wallet, à ce moment il est automatiquement logué sur son entreprise (pas de double login)

Il faut envisager une V0 sans organisme accréditeur d’identité pour les particuliers et les entreprises, sinon “on peut attendre 2025”.

Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité, avec notamment, dans une V0, la fourniture de 2 preuves essentielles pour qu’une personne puisse participer au portail :

L’utilisateur est bien celui qu’il prétend être. En V0 il est suggéré d’utiliser une API Particulier

L’entreprise est bien celle qu’elle prétend être. En V0 il est suggéré d’utiliser une API Entreprise

Prometheus doit servir de preuve de concept réel pour motiver les organismes à fournir ces infras d’émission de VC. En attendant, nous devons utiliser des palliatifs à base d’API entreprise/particulier.

Questions en suspens/Points bloquants

Quel est l’état d’avancement de production de mywallet.cloud ?

Dans cette V0, que comportent les VC Enterprise et Citizen ?

Est-ce que c’est BCD qui se charge de l’implémentation des API Particulier et Entreprise pour la création des VC ? Ou est-ce que c’est à Prometheus de le faire ?

Ce choix a plusieurs impacts :

Si c’est Prometheus qui est en charge de la liaison entre le DID en provenance de mywallet et les preuves de connexion via les API particulier et entreprise :
- L’utilisateur fait le lien en se logant via ces API sur Prometheus auquel cas c’est Prometheus en charge de l’implémentation des API
- Prometheus devient responsable de traitement car c’est Prometheus qui stocke la preuve de lien entre ces deux entités dans une BDD
Si c’est BCD qui est en charge de la liaison entre le DID mywallet et les preuves de connexion via les API particulier et entreprise :
- L’utilisateur fait le lien en se logant via ces API sur Mywallet.cloud auquel cas c’est BCD en charge de l’implémentation des API
- BCD devient responsable de traitement car c’est BCD qui stocke la preuve de lien entre ces deux entités dans une BDD
Actions
- Revoir le prototype @Mathieu S
- Faire une note sur les risques et les responsabilités engagées dans la V0 (Tiers de confiance) @Laurine B
- Programmer un nouvel atelier @Mathieu S
- Réaliser les spécifications fonctionnelles et techniques de la V0 @Perrin

+<h1>Participants</h1><ul><li>Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowQVtx4JuV7JXxtLquo46qDjI5JMmqrV9" rel="noopener noreferrer" target="_blank">@Perrin</a>, <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W9pmee9tQm63hKag7jYFh0i1OW" rel="noopener noreferrer" target="_blank">@Laurine B</a>, <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W2YltmY3zoX1yb6aCSkoQqFt4Q" rel="noopener noreferrer" target="_blank">@Mathieu S</a> </li></ul><h1><br></h1><h1>Déroulé</h1><p>Présentation du prototype : <a href="https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home" rel="noopener noreferrer" target="_blank">https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home</a> et échanges</p><p>Luc nous a présenté ce que BCD a commencé à concevoir, à savoir un webwallet.</p><p>Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité côté BCD.</p><h1>Conclusions</h1><p>Chaque utilisateur du portail aurait 1 compte mywallet par Entreprise, par exemple : </p><p><br></p><p>En tant que Matt Sonatti, je devrais utiliser (et donc posséder) : </p><ul><li>Un compte mywallet “Inokufu” lorsque je publie des services marqués Inokufu sur le portail</li><li>Un compte mywallet “X” lorsque je décide de publier des services marqués X sur le portail </li></ul><p>Me login/logout de wallets lorsque je passe d’une entreprise à une autre</p><p>L’utilisateur se log à son compte Entreprise sur le wallet, à ce moment il est automatiquement logué sur son entreprise (pas de double login)</p><p>Il faut envisager une V0 sans organisme accréditeur d’identité pour les particuliers et les entreprises, sinon “on peut attendre 2025”. </p><p>Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité, avec notamment, dans une V0, la fourniture de 2 preuves essentielles pour qu’une personne puisse participer au portail : </p><p>L’utilisateur est bien celui qu’il prétend être. En V0 il est suggéré d’utiliser une API Particulier</p><p>L’entreprise est bien celle qu’elle prétend être. En V0 il est suggéré d’utiliser une API Entreprise </p><p>Prometheus doit servir de preuve de concept réel pour motiver les organismes à fournir ces infras d’émission de VC. En attendant, nous devons utiliser des palliatifs à base d’API entreprise/particulier.</p><h1>Questions en suspens/Points bloquants</h1><p>Quel est l’état d’avancement de production de mywallet.cloud ? </p><p>Dans cette V0, que comportent les VC Enterprise et Citizen ?</p><p>Est-ce que c’est BCD qui se charge de l’implémentation des API Particulier et Entreprise pour la création des VC ? Ou est-ce que c’est à Prometheus de le faire ?</p><p>Ce choix a plusieurs impacts : </p><p>Si c’est Prometheus qui est en charge de la liaison entre le DID en provenance de mywallet et les preuves de connexion via les API particulier et entreprise :</p><ul><li>L’utilisateur fait le lien en se logant via ces API <strong>sur </strong>Prometheus auquel cas c’est Prometheus en charge de l’implémentation des API </li><li>Prometheus devient responsable de traitement car c’est Prometheus qui stocke la preuve de lien entre ces deux entités dans une BDD </li></ul><p><br></p><p>Si c’est BCD qui est en charge de la liaison entre le DID mywallet et les preuves de connexion via les API particulier et entreprise : </p><ul><li>L’utilisateur fait le lien en se logant via ces API <strong>sur </strong>Mywallet.cloud auquel cas c’est BCD en charge de l’implémentation des API </li><li>BCD devient responsable de traitement car c’est BCD qui stocke la preuve de lien entre ces deux entités dans une BDD</li></ul><p><br></p><h1>Actions</h1><ul><li> Revoir le prototype <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W2YltmY3zoX1yb6aCSkoQqFt4Q" rel="noopener noreferrer" target="_blank">@Mathieu S</a></li><li> Faire une note sur les risques et les responsabilités engagées dans la V0 (Tiers de confiance) <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W9pmee9tQm63hKag7jYFh0i1OW" rel="noopener noreferrer" target="_blank">@Laurine B</a></li><li> Programmer un nouvel atelier <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W2YltmY3zoX1yb6aCSkoQqFt4Q" rel="noopener noreferrer" target="_blank">@Mathieu S</a></li><li> Réaliser les spécifications fonctionnelles et techniques de la V0 <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowQVtx4JuV7JXxtLquo46qDjI5JMmqrV9" rel="noopener noreferrer" target="_blank">@Perrin</a></li></ul>

Deletions

Déroulé

Présentation du prototype : https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home et échanges

Luc nous a présenté ce que BCD a commencé à concevoir, à savoir un webwallet.

Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité côté BCD.

Conclusions

Chaque utilisateur du portail aurait 1 compte mywallet par Entreprise, par exemple :

En tant que Matt Sonatti, je devrais utiliser (et donc posséder) :

Un compte mywallet “Inokufu” lorsque je publie des services marqués Inokufu sur le portail
Un compte mywallet “X” lorsque je décide de publier des services marqués X sur le portail

Me login/logout de wallets lorsque je passe d’une entreprise à une autre

L’utilisateur se log à son compte Entreprise sur le wallet, à ce moment il est automatiquement logué sur son entreprise (pas de double login)

Il faut envisager une V0 sans organisme accréditeur d’identité pour les particuliers et les entreprises, sinon “on peut attendre 2025”.

Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité, avec notamment, dans une V0, la fourniture de 2 preuves essentielles pour qu’une personne puisse participer au portail :

L’utilisateur est bien celui qu’il prétend être. En V0 il est suggéré d’utiliser une API Particulier

L’entreprise est bien celle qu’elle prétend être. En V0 il est suggéré d’utiliser une API Entreprise

Prometheus doit servir de preuve de concept réel pour motiver les organismes à fournir ces infras d’émission de VC. En attendant, nous devons utiliser des palliatifs à base d’API entreprise/particulier.

Questions en suspens/Points bloquants

Quel est l’état d’avancement de production de mywallet.cloud ?

Dans cette V0, que comportent les VC Enterprise et Citizen ?

Est-ce que c’est BCD qui se charge de l’implémentation des API Particulier et Entreprise pour la création des VC ? Ou est-ce que c’est à Prometheus de le faire ?

Ce choix a plusieurs impacts :

Si c’est Prometheus qui est en charge de la liaison entre le DID en provenance de mywallet et les preuves de connexion via les API particulier et entreprise :

L’utilisateur fait le lien en se logant via ces API sur Prometheus auquel cas c’est Prometheus en charge de l’implémentation des API
Prometheus devient responsable de traitement car c’est Prometheus qui stocke la preuve de lien entre ces deux entités dans une BDD

Si c’est BCD qui est en charge de la liaison entre le DID mywallet et les preuves de connexion via les API particulier et entreprise :

L’utilisateur fait le lien en se logant via ces API sur Mywallet.cloud auquel cas c’est BCD en charge de l’implémentation des API
BCD devient responsable de traitement car c’est BCD qui stocke la preuve de lien entre ces deux entités dans une BDD

Actions

Revoir le prototype @Mathieu S
Faire une note sur les risques et les responsabilités engagées dans la V0 (Tiers de confiance) @Laurine B
Programmer un nouvel atelier @Mathieu S
Réaliser les spécifications fonctionnelles et techniques de la V0 @Perrin

Additions

+
Participants
- Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), @Perrin, @Laurine B, @Mathieu S
Déroulé

Présentation du prototype : https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home et échanges

Luc nous a présenté ce que BCD a commencé à concevoir, à savoir un webwallet.

Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité côté BCD.

Conclusions

Chaque utilisateur du portail aurait 1 compte mywallet par Entreprise, par exemple :

En tant que Matt Sonatti, je devrais utiliser (et donc posséder) :
- Un compte mywallet “Inokufu” lorsque je publie des services marqués Inokufu sur le portail
- Un compte mywallet “X” lorsque je décide de publier des services marqués X sur le portail
Me login/logout de wallets lorsque je passe d’une entreprise à une autre

L’utilisateur se log à son compte Entreprise sur le wallet, à ce moment il est automatiquement logué sur son entreprise (pas de double login)

Il faut envisager une V0 sans organisme accréditeur d’identité pour les particuliers et les entreprises, sinon “on peut attendre 2025”.

Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité, avec notamment, dans une V0, la fourniture de 2 preuves essentielles pour qu’une personne puisse participer au portail :

L’utilisateur est bien celui qu’il prétend être. En V0 il est suggéré d’utiliser une API Particulier

L’entreprise est bien celle qu’elle prétend être. En V0 il est suggéré d’utiliser une API Entreprise

Prometheus doit servir de preuve de concept réel pour motiver les organismes à fournir ces infras d’émission de VC. En attendant, nous devons utiliser des palliatifs à base d’API entreprise/particulier.

Questions en suspens/Points bloquants

Quel est l’état d’avancement de production de mywallet.cloud ?

Dans cette V0, que comportent les VC Enterprise et Citizen ?

Est-ce que c’est BCD qui se charge de l’implémentation des API Particulier et Entreprise pour la création des VC ? Ou est-ce que c’est à Prometheus de le faire ?

Ce choix a plusieurs impacts :

Si c’est Prometheus qui est en charge de la liaison entre le DID en provenance de mywallet et les preuves de connexion via les API particulier et entreprise :
- L’utilisateur fait le lien en se logant via ces API sur Prometheus auquel cas c’est Prometheus en charge de l’implémentation des API
- Prometheus devient responsable de traitement car c’est Prometheus qui stocke la preuve de lien entre ces deux entités dans une BDD
Si c’est BCD qui est en charge de la liaison entre le DID mywallet et les preuves de connexion via les API particulier et entreprise :
- L’utilisateur fait le lien en se logant via ces API sur Mywallet.cloud auquel cas c’est BCD en charge de l’implémentation des API
- BCD devient responsable de traitement car c’est BCD qui stocke la preuve de lien entre ces deux entités dans une BDD
Actions
- Revoir le prototype @Mathieu S
- Faire une note sur les risques et les responsabilités engagées dans la V0 (Tiers de confiance) @Laurine B
- Programmer un nouvel atelier @Mathieu S
- Réaliser les spécifications fonctionnelles et techniques de la V0 @Perrin

Deletions

Additions

+<h1>Participants</h1><ul><li>Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowQVtx4JuV7JXxtLquo46qDjI5JMmqrV9" rel="noopener noreferrer" target="_blank">@Perrin</a>, <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W9pmee9tQm63hKag7jYFh0i1OW" rel="noopener noreferrer" target="_blank">@Laurine B</a>, <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W2YltmY3zoX1yb6aCSkoQqFt4Q" rel="noopener noreferrer" target="_blank">@Mathieu S</a> </li></ul><h1><br></h1><h1>Déroulé</h1><p>Présentation du prototype : <a href="https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home" rel="noopener noreferrer" target="_blank">https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home</a> et échanges</p><p>Luc nous a présenté ce que BCD a commencé à concevoir, à savoir un webwallet.</p><p>Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité côté BCD.</p><h1>Conclusions</h1><p>Chaque utilisateur du portail aurait 1 compte mywallet par Entreprise, par exemple : </p><p><br></p><p>En tant que Matt Sonatti, je devrais utiliser (et donc posséder) : </p><ul><li>Un compte mywallet “Inokufu” lorsque je publie des services marqués Inokufu sur le portail</li><li>Un compte mywallet “X” lorsque je décide de publier des services marqués X sur le portail </li></ul><p>Me login/logout de wallets lorsque je passe d’une entreprise à une autre</p><p>L’utilisateur se log à son compte Entreprise sur le wallet, à ce moment il est automatiquement logué sur son entreprise (pas de double login)</p><p>Il faut envisager une V0 sans organisme accréditeur d’identité pour les particuliers et les entreprises, sinon “on peut attendre 2025”. </p><p>Nous n’avons pas eu l’occasion d’explorer la phase de création d’identité, avec notamment, dans une V0, la fourniture de 2 preuves essentielles pour qu’une personne puisse participer au portail : </p><p>L’utilisateur est bien celui qu’il prétend être. En V0 il est suggéré d’utiliser une API Particulier</p><p>L’entreprise est bien celle qu’elle prétend être. En V0 il est suggéré d’utiliser une API Entreprise </p><p>Prometheus doit servir de preuve de concept réel pour motiver les organismes à fournir ces infras d’émission de VC. En attendant, nous devons utiliser des palliatifs à base d’API entreprise/particulier.</p><h1>Questions en suspens/Points bloquants</h1><p>Quel est l’état d’avancement de production de mywallet.cloud ? </p><p>Dans cette V0, que comportent les VC Enterprise et Citizen ?</p><p>Est-ce que c’est BCD qui se charge de l’implémentation des API Particulier et Entreprise pour la création des VC ? Ou est-ce que c’est à Prometheus de le faire ?</p><p>Ce choix a plusieurs impacts : </p><p>Si c’est Prometheus qui est en charge de la liaison entre le DID en provenance de mywallet et les preuves de connexion via les API particulier et entreprise :</p><ul><li>L’utilisateur fait le lien en se logant via ces API <strong>sur </strong>Prometheus auquel cas c’est Prometheus en charge de l’implémentation des API </li><li>Prometheus devient responsable de traitement car c’est Prometheus qui stocke la preuve de lien entre ces deux entités dans une BDD </li></ul><p><br></p><p>Si c’est BCD qui est en charge de la liaison entre le DID mywallet et les preuves de connexion via les API particulier et entreprise : </p><ul><li>L’utilisateur fait le lien en se logant via ces API <strong>sur </strong>Mywallet.cloud auquel cas c’est BCD en charge de l’implémentation des API </li><li>BCD devient responsable de traitement car c’est BCD qui stocke la preuve de lien entre ces deux entités dans une BDD</li></ul><p><br></p><h1>Actions</h1><ul><li> Revoir le prototype <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W2YltmY3zoX1yb6aCSkoQqFt4Q" rel="noopener noreferrer" target="_blank">@Mathieu S</a></li><li> Faire une note sur les risques et les responsabilités engagées dans la V0 (Tiers de confiance) <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W9pmee9tQm63hKag7jYFh0i1OW" rel="noopener noreferrer" target="_blank">@Laurine B</a></li><li> Programmer un nouvel atelier <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowPsLj6W2YltmY3zoX1yb6aCSkoQqFt4Q" rel="noopener noreferrer" target="_blank">@Mathieu S</a></li><li> Réaliser les spécifications fonctionnelles et techniques de la V0 <a href="/ep/profile/1gg9uA1iUgdDmqkTo2qowQVtx4JuV7JXxtLquo46qDjI5JMmqrV9" rel="noopener noreferrer" target="_blank">@Perrin</a></li></ul>

Description (Deutsch)

Description (Italiano)

Description (English)

+
Participants

Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), @Perrin, @Laurine B, @Mathieu S

Course

Presentation of the prototype: https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home and exchanges

Luc presented us what BCD has started to design, namely a webwallet.

We did not have the opportunity to explore the identity creation phase on the BCD side.

Conclusions
- Each user of the portal would have 1 mywallet account per Enterprise, for example:
- As Matt Sonatti, I would need to use (and therefore own):
- An "Inokufu" mywallet account when I publish Inokufu-tagged services on the portal
- An "X" mywallet account when I decide to publish services marked X on the portal
- login/logout of wallets when I switch from one company to another
- The user logs in to his company account on the wallet, at which point he is automatically logged in to his company (no double login)
- We have to consider a V0 without an identity accreditation body for individuals and companies, otherwise "we can wait until 2025".
- We did not have the opportunity to explore the identity creation phase, including, in a V0, the provision of 2 essential proofs for a person to participate in the portal:
- The user is who they claim to be. In V0, it is suggested to use an Individual API
- The company is who it claims to be. In V0 it is suggested to use an Enterprise API
- Prometheus should be used as a real proof of concept to motivate organizations to provide these VC emission infras. In the meantime, we need to use enterprise/individual API workarounds.
Outstanding Issues/Blockers

What is the production status of mywallet.cloud?

In this V0, what is included in the Enterprise and Citizen VCs?

Is BCD implementing the Individual and Enterprise APIs to create the VCs? Or does Prometheus do it?

This choice has several impacts:

If Prometheus is in charge of the link between the DID from mywallet and the proofs of connection via the Personal and Enterprise APIs:
- The user makes the link by logging in via these APIs on Prometheus, in which case Prometheus is in charge of the API implementation
- Prometheus becomes the controller because it is Prometheus that stores the proof of link between these two entities in a DB
If BCD is in charge of the link between the mywallet DID and the proof of connection via the individual and enterprise APIs:
- The user makes the link by logging in via these APIs on Mywallet.cloud in which case BCD is in charge of implementing the APIs
- BCD becomes the controller because it is BCD that stores the proof of connection between these two entities in a DB
Actions

Review the prototype @Mathieu S

Make a note on the risks and responsibilities involved in V0 (Trusted third party) @Laurine B

Program a new workshop @Mathieu S

Realize the functional and technical specifications of the V0 @Perrin

+<p>Participants</p><p>Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), @Perrin, @Laurine B, @Mathieu S </p><h1>Course</h1><p>Presentation of the prototype: https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home and exchanges</p><p>Luc presented us what BCD has started to design, namely a webwallet.</p><p>We did not have the opportunity to explore the identity creation phase on the BCD side.</p><h1><br></h1><h1>Conclusions</h1><ul><li>Each user of the portal would have 1 mywallet account per Enterprise, for example: </li><li>As Matt Sonatti, I would need to use (and therefore own): </li><li>An "Inokufu" mywallet account when I publish Inokufu-tagged services on the portal</li><li>An "X" mywallet account when I decide to publish services marked X on the portal </li><li>login/logout of wallets when I switch from one company to another</li><li>The user logs in to his company account on the wallet, at which point he is automatically logged in to his company (no double login)</li><li>We have to consider a V0 without an identity accreditation body for individuals and companies, otherwise "we can wait until 2025". </li><li>We did not have the opportunity to explore the identity creation phase, including, in a V0, the provision of 2 essential proofs for a person to participate in the portal: </li><li>The user is who they claim to be. In V0, it is suggested to use an Individual API</li><li>The company is who it claims to be. In V0 it is suggested to use an Enterprise API </li><li>Prometheus should be used as a real proof of concept to motivate organizations to provide these VC emission infras. In the meantime, we need to use enterprise/individual API workarounds.</li></ul><p><br></p><h1>Outstanding Issues/Blockers</h1><p>What is the production status of mywallet.cloud? </p><p>In this V0, what is included in the Enterprise and Citizen VCs?</p><p>Is BCD implementing the Individual and Enterprise APIs to create the VCs? Or does Prometheus do it?</p><p>This choice has several impacts: </p><p>If Prometheus is in charge of the link between the DID from mywallet and the proofs of connection via the Personal and Enterprise APIs:</p><ul><li>The user makes the link by logging in via these APIs on Prometheus, in which case Prometheus is in charge of the API implementation </li><li>Prometheus becomes the controller because it is Prometheus that stores the proof of link between these two entities in a DB </li></ul><p>If BCD is in charge of the link between the mywallet DID and the proof of connection via the individual and enterprise APIs: </p><ul><li>The user makes the link by logging in via these APIs on Mywallet.cloud in which case BCD is in charge of implementing the APIs </li><li>BCD becomes the controller because it is BCD that stores the proof of connection between these two entities in a DB</li></ul><p><br></p><h1>Actions</h1><h1><br></h1><p> Review the prototype @Mathieu S</p><p> Make a note on the risks and responsibilities involved in V0 (Trusted third party) @Laurine B</p><p> Program a new workshop @Mathieu S</p><p> Realize the functional and technical specifications of the V0 @Perrin</p>

Deletions

As Matt Sonatti, I would need to use (and therefore own):
An "Inokufu" mywallet account when I publish Inokufu-tagged services on the portal
An "X" mywallet account when I decide to publish services marked X on the portal
login/logout of wallets when I switch from one company to another
The user logs in to his company account on the wallet, at which point he is automatically logged in to his company (no double login)
We have to consider a V0 without an identity accreditation body for individuals and companies, otherwise "we can wait until 2025".
We did not have the opportunity to explore the identity creation phase, including, in a V0, the provision of 2 essential proofs for a person to participate in the portal:
The user is who they claim to be. In V0, it is suggested to use an Individual API
The company is who it claims to be. In V0 it is suggested to use an Enterprise API
Prometheus should be used as a real proof of concept to motivate organizations to provide these VC emission infras. In the meantime, we need to use enterprise/individual API workarounds.

Outstanding Issues/Blockers

What is the production status of mywallet.cloud?

In this V0, what is included in the Enterprise and Citizen VCs?

Is BCD implementing the Individual and Enterprise APIs to create the VCs? Or does Prometheus do it?

This choice has several impacts:

If Prometheus is in charge of the link between the DID from mywallet and the proofs of connection via the Personal and Enterprise APIs:

The user makes the link by logging in via these APIs on Prometheus, in which case Prometheus is in charge of the API implementation
Prometheus becomes the controller because it is Prometheus that stores the proof of link between these two entities in a DB

If BCD is in charge of the link between the mywallet DID and the proof of connection via the individual and enterprise APIs:

The user makes the link by logging in via these APIs on Mywallet.cloud in which case BCD is in charge of implementing the APIs
BCD becomes the controller because it is BCD that stores the proof of connection between these two entities in a DB

Actions

Review the prototype @Mathieu S

Make a note on the risks and responsibilities involved in V0 (Trusted third party) @Laurine B

Program a new workshop @Mathieu S

Realize the functional and technical specifications of the V0 @Perrin

Additions

+
Participants

Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), @Perrin, @Laurine B, @Mathieu S

Course

Presentation of the prototype: https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home and exchanges

Luc presented us what BCD has started to design, namely a webwallet.

We did not have the opportunity to explore the identity creation phase on the BCD side.

Conclusions
- Each user of the portal would have 1 mywallet account per Enterprise, for example:
- As Matt Sonatti, I would need to use (and therefore own):
- An "Inokufu" mywallet account when I publish Inokufu-tagged services on the portal
- An "X" mywallet account when I decide to publish services marked X on the portal
- login/logout of wallets when I switch from one company to another
- The user logs in to his company account on the wallet, at which point he is automatically logged in to his company (no double login)
- We have to consider a V0 without an identity accreditation body for individuals and companies, otherwise "we can wait until 2025".
- We did not have the opportunity to explore the identity creation phase, including, in a V0, the provision of 2 essential proofs for a person to participate in the portal:
- The user is who they claim to be. In V0, it is suggested to use an Individual API
- The company is who it claims to be. In V0 it is suggested to use an Enterprise API
- Prometheus should be used as a real proof of concept to motivate organizations to provide these VC emission infras. In the meantime, we need to use enterprise/individual API workarounds.
Outstanding Issues/Blockers

What is the production status of mywallet.cloud?

In this V0, what is included in the Enterprise and Citizen VCs?

Is BCD implementing the Individual and Enterprise APIs to create the VCs? Or does Prometheus do it?

This choice has several impacts:

If Prometheus is in charge of the link between the DID from mywallet and the proofs of connection via the Personal and Enterprise APIs:
- The user makes the link by logging in via these APIs on Prometheus, in which case Prometheus is in charge of the API implementation
- Prometheus becomes the controller because it is Prometheus that stores the proof of link between these two entities in a DB
If BCD is in charge of the link between the mywallet DID and the proof of connection via the individual and enterprise APIs:
- The user makes the link by logging in via these APIs on Mywallet.cloud in which case BCD is in charge of implementing the APIs
- BCD becomes the controller because it is BCD that stores the proof of connection between these two entities in a DB
Actions

Review the prototype @Mathieu S

Make a note on the risks and responsibilities involved in V0 (Trusted third party) @Laurine B

Program a new workshop @Mathieu S

Realize the functional and technical specifications of the V0 @Perrin

Deletions

Additions

+<p>Participants</p><p>Luc Jarry-Lacombe (BC Diploma), Matt Sonatti (Inokufu), @Perrin, @Laurine B, @Mathieu S </p><h1>Course</h1><p>Presentation of the prototype: https://gr2lxo.axshare.com/gid://decidim-app/Decidim::Hashtag/2/id=yxkx39&p=home and exchanges</p><p>Luc presented us what BCD has started to design, namely a webwallet.</p><p>We did not have the opportunity to explore the identity creation phase on the BCD side.</p><h1><br></h1><h1>Conclusions</h1><ul><li>Each user of the portal would have 1 mywallet account per Enterprise, for example: </li><li>As Matt Sonatti, I would need to use (and therefore own): </li><li>An "Inokufu" mywallet account when I publish Inokufu-tagged services on the portal</li><li>An "X" mywallet account when I decide to publish services marked X on the portal </li><li>login/logout of wallets when I switch from one company to another</li><li>The user logs in to his company account on the wallet, at which point he is automatically logged in to his company (no double login)</li><li>We have to consider a V0 without an identity accreditation body for individuals and companies, otherwise "we can wait until 2025". </li><li>We did not have the opportunity to explore the identity creation phase, including, in a V0, the provision of 2 essential proofs for a person to participate in the portal: </li><li>The user is who they claim to be. In V0, it is suggested to use an Individual API</li><li>The company is who it claims to be. In V0 it is suggested to use an Enterprise API </li><li>Prometheus should be used as a real proof of concept to motivate organizations to provide these VC emission infras. In the meantime, we need to use enterprise/individual API workarounds.</li></ul><p><br></p><h1>Outstanding Issues/Blockers</h1><p>What is the production status of mywallet.cloud? </p><p>In this V0, what is included in the Enterprise and Citizen VCs?</p><p>Is BCD implementing the Individual and Enterprise APIs to create the VCs? Or does Prometheus do it?</p><p>This choice has several impacts: </p><p>If Prometheus is in charge of the link between the DID from mywallet and the proofs of connection via the Personal and Enterprise APIs:</p><ul><li>The user makes the link by logging in via these APIs on Prometheus, in which case Prometheus is in charge of the API implementation </li><li>Prometheus becomes the controller because it is Prometheus that stores the proof of link between these two entities in a DB </li></ul><p>If BCD is in charge of the link between the mywallet DID and the proof of connection via the individual and enterprise APIs: </p><ul><li>The user makes the link by logging in via these APIs on Mywallet.cloud in which case BCD is in charge of implementing the APIs </li><li>BCD becomes the controller because it is BCD that stores the proof of connection between these two entities in a DB</li></ul><p><br></p><h1>Actions</h1><h1><br></h1><p> Review the prototype @Mathieu S</p><p> Make a note on the risks and responsibilities involved in V0 (Trusted third party) @Laurine B</p><p> Program a new workshop @Mathieu S</p><p> Realize the functional and technical specifications of the V0 @Perrin</p>

Description (Català)

Description (Castellano)

Start Time

+2021-12-17 10:00:00 +0100

End Time

+2021-12-17 11:00:00 +0100

Address

Location (Français)

Location (Deutsch)

Location (Italiano)

Location (English)

Location (Català)

Location (Castellano)

Location hints (Français)

Location hints (Deutsch)

Location hints (Italiano)

Location hints (English)

Location hints (Català)

Location hints (Castellano)

Version number 1 out of 4 Show all versions Go back to meeting

Version author

Mathieu Strabach

Version created at 21/12/2021 09:02

Technical group

Changes at "BCD Meeting about DID Login on Portal"

Title (Français)

Title (Deutsch)

Title (Italiano)

Title (English)

Title (Català)

Title (Castellano)

Description (Français)

Participants

Déroulé

Conclusions

Questions en suspens/Points bloquants

Actions

Déroulé

Conclusions

Questions en suspens/Points bloquants

Actions

Participants

Déroulé

Conclusions

Questions en suspens/Points bloquants

Actions

Description (Deutsch)

Description (Italiano)

Description (English)

Course

Conclusions

Outstanding Issues/Blockers

Actions

Outstanding Issues/Blockers

Actions

Course

Conclusions

Outstanding Issues/Blockers

Actions

Description (Català)

Description (Castellano)

Start Time

End Time

Address

Location (Français)

Location (Deutsch)

Location (Italiano)

Location (English)

Location (Català)

Location (Castellano)

Location hints (Français)

Location hints (Deutsch)

Location hints (Italiano)

Location hints (English)

Location hints (Català)

Location hints (Castellano)