...
- Welcome & Introductions
- EFWG Community Topics & Announcements
- Presentation from Philipp Etschel from Bosch: "SSI from a developer's perspective"
- Q&A / Discussion
- Philipp Etschel presentation: SSI from a Developers Perspective
- Philipp - solution developer at Bosch
- Acknowledgement of personal bias (as everyone has)
- How can we give all the devices an identity? came into the concept of SSI, adding SSI into devices.
- Master data - difficult to manage all the data
- Agent (aries cloud agent) wallet
- Profile of your organization
- wallet with credentials
- Can issue credentials and also verify them (issuer side and verifier side)
- Schemas configured for your agent
- Organizational profile - public information, helps to solve master data problem
- SSI design is made for individuals (peer-to-peer) and this presents challenges for organizations/companies
- E.g. want details available for companies in credential exchange (like bank account info etc.)
- Consider if SSI is solution or is there other technologies that are better
- Public profiles are also helpful because DIDs are not human readable and a profile helps with human trust.
- What are some of the challenges in creating the project?
- 2 challenges - 1 set, related to what you are doing - the whole SSI stack. It is developing. Business use cases do not always perfectly fit SSI (access management is an example that fits very well), but the need for a public profile takes effort to add to SSI.
- 2nd set of problems - specific to BPA - how do we build systems that are scalable and how do we make it work for the enterprise. How does the software manage the wallets. Need lots of wallets and DIDs and this needs to be scalable and efficient. Missing lots of API features to create new wallets and DIDs for example.
- May need to stop prototype and start from scratch.
- Architectural side and Ecosystem side
- Third issue - how to introduce and onboard people into SSI.
- The world doesn't always match up with the nice picture/general model
- Ecosystem is very fragmented (e.g. hundreds of DID methods).
- There is no stack that covers all parts of the ecosystem
- By design it is interoperable (DID methods, resolver, documents) but in function it is not because of the fragmentation.
- Talking the same language but not interoperable
- Current answer: look at your ecosystem and who you want to interact with and then pick your stack so you can work with them.
Admin Reminder : remember to re-subscribe to new meeting calendar
...