Therecanbeonlyone1969
commented
2 years ago @wsdOgawa thank you so much! Great start. Currently missing in the design are:
- Update of a DID document (all properties)
- Present a Verifiable Presentation
It might be worthwhile considering to only use Manage DID and then have a selector for a supported DID method (in this case did:key and did:element) that drives in the different modules one for each did method. Similar for VC management. It might be good to have a selector for available VC schemas to be issued. Similarly, if you want, being able to support VC revocation might be nice but not required.
I do not understand though, are you going to submit a grant request for implementing your solution for RFP#1 or not? The former was the ask.
cc @GoldenBit0
GoldenBit0
mehranshakeri
wsdOgawa
Details on Grant Work
This was a design that I derived from asking questions on this issue: https://github.com/eea-oasis/baseline-grants/issues/76. The goal was to try to get an apples-to-apples design of the work being requested in RFP #1.
Motivation and Overview
The motivation here was to see if I could create a design that was close to what was being requested. Working on implementing this would be too much of a detour for how much time I have to work on open source.
Value to the Baseline Protocol
Contributing something that takes the text requirements in the RFP and converts it into more clearly defined requirements. (Maybe?)
Downsides / Execution Risks / Limitations
Limitation: It's just a picture.
Deliverables / Schedule / Milestones
Milestones:
Budget and Justification
Budget: $0 Justification: Posting wireframe design
Applicant Background
Kousei Ogawa (self) has thirty years of working in the IT industry in Japan working for a large corporation before creating his own company. He has extensive knowledge with working with CentOS and open source technologies. And has been managing the server-side Javascript Application server Jaxer for business use in Japan under the GPL license.
Community Grant Agreement
I understand and agree to the 'Process for Approved Grants' outlined here
Network Overview
Below is an image of what I think the network will look like. At the center is the wallet module which would take a mnemonic, hdpath, along with other arguments depending on the function being called. In front of the module would be an Express or other http server that would take the post body from the client, pass them directly into the module and return the response.
There would be two paths served by the http server. One would be the wallet visualization which would combine with data stored locally on the client to provide functionality on the client. And the other path would provide the Swagger/OpenAPI documentation.
The wallet module itself would require network access to Ethereum, Polygon, Element, Baselin, and IPFS. Either as a service running on localhost, testnet, or production node.
Mnemonic
This would be the splash page for the application. That would describe what the wallet is, and define a mnemonic that would be auto-filled for each page as a parameter. There might be a better design on this that allows for multiple mnemonics. My goal here was to try and keep it simple.
did:key
This is not a requirement in RFP #1.
did:keyis useful for debugging, so I included a page for it.Passed and documented tests for DID creation and management for DID Element
In this page I copied what was done in
did:key. The create part is pretty straightforward, but I'm not sure what requirements would need to be defined for "management". Right now I have create, and deactivate. Not sure how much control over the did is implied, and what design is needed to effectively take advantage of the functionality.Passed and documented tests for VC issuance, verification, and presentation generation
Resolve did
Also not required, but useful
Issue Credential
Once issued, the page would move
Verify Credential.Verify Credential
Prepare Presentation
In this case it seems like having the ability to store credentials that have been issued, and then selected them to be in a presentation. This is another point where the design could be improved because I was trying to use the simplest possible approach.
Passed and documented tests for sending, receiving, and visually representing in a User Interface 1 protocol token, d. fungible token, and 1 non-fungible token for at least two public blockchains
I tried to design this without duplicating the work that Metamask already provides. This was the part that was too far removed from the Invoice application to try and integrate it, which is why I split of the wallet design.
Polygon
Ethereum
Same UI as Polygon.
Looks like I forgot fungible tokens in this design. This part of the RFP on its own is too time consuming for the design and implementation for someone like me who isn't familiar with these things.
Passed and documented tests for receiving, signing, and sending messages for one BRI
I asked a lot of questions about this, but I'm not 100% clear on it. The way I represented it was to decode and encode a BRI message similar to a JWT.