[GR] BLIP Implementing DID's and VC's into an Open Source Invoice Management Application #76
Comments
|
This looks really interesting. Let's get some time with the team here and dig in. |
|
Thank you for your consideration. If there is anything I need to elaborate on, I can provide more details. For transparency I set up a development blog at https://privateinvoice.io/ to document the steps as I work on them. |
|
@Therecanbeonlyone1969 @kthomas @Sjaaaakster @skarred14 @mehranshakeri @caleteeter @fosgate29 @stefschmidt @samratkishor @tsc members, please view / comment / vote |
|
Question around making payments with ETH. Could payments be made with all ERC20 tokens? For example with USDC? |
|
@wsdOgawa, while I think this is an interesting proposal, it is 100% not related to RFP1 #63 ... RFP1 #63 has a well-defined scope with appropriate Done Criteria, etc. This proposal a) exceeds the scope, and b) does not meet the Done Criteria of RFP1 #63. You have two separate options, as far as I see it:
As stated, it doe not meet the RFP1 #63 requirements. Sorry for being such a stickler. cc @GoldenBit0 |
I am also confused if this is related to #63 or is planned to be built based on that. |
@Sjaaaakster I think from a technical stand-point ERC20 would be signed with the same private key as with used with a ganache or rinkeby transaction. The primary focus of this proposal is on the use of VC's and DID's with respect to managing invoices. Implementing other EC20 tokens would be out of the scope of the current milestone. Features like this would be included in a separate milestone. I would like to perform a tech-spike for using EC20 tokens, and have UI mocks up for how they are managed in the application before replying with a hard "yes" on this. |
@Therecanbeonlyone1969 @mehranshakeri Looks like I need to better describe the relationship between this proposal and RFP #1. The current proposal is an invoicing application that overlaps with a lot of the Done criteria proposed in #63 but does not necessarily complete them. The reason for this is that I do not want to over-promise and under-deliver. This goal of the current milestone is to get a-simple-as-possible implementation of an open source wallet that incorporates DID's, VC's and ETH payments without optionality. Once that is complete I would make a separate proposal with the same amount of documentation as this proposal for the intended implementation and timeline for completing the rest of the criteria.
If that implies updating this proposal as a BLIP, then I can take that action. Let me know if that is the correct approach. |
|
@GoldenBit0 Accidentally unassigned myself with a miss click. Can you reassign me? |
|
@mehranshakeri @Therecanbeonlyone1969 please advise on @wsdOgawa's last message, and if a new BLIP is the best approach, I will help out. |
Based on what @wsdOgawa described, I agree with @Therecanbeonlyone1969 's proposal. If the first implementation will be the invoice use case, then let's rename this to that and a follow up for #63 when the implementation is there. |
|
A few progress updates:
My current schedule is to have the source code implementation done during June or early July at the latest. From there I expect most of my time to be devoted to testing, writing blog posts, and making videos to describe the work that was done and how the application works. And have that part done by the end up September. |
Should I rename the issue to [BLIP] Implementing DID's and VC's into an Open Source Invoice Management Application?
I think there are two options for this:
If the invoice implementation is being defined as a BLIP, then it sounds like the first one is the preferable option. Right now my priority is on execution of the functionality described in this issue. I can start blocking out a proposal for RFP #1 once I start moving into documentation. |
|
Rename is fine with me. Andreas or other involved team members are more qualified to comment on extending or creating a new impl. for RFP1. |
|
@wsdOgawa Hello, Can you ping me in the Baseline Slack (link to join) @ Sonal Patel, or email the baseline email at [email protected]? I'd like to see if you can join a call with the Technical Steering Committee this week to work through this. |
|
Progress Update:
Current Timeline:
Sure I'll send you an email with my availability. |
|
@wsdOgawa Are you available tomorrow 6/30 @ 10am est? That is the next TSC call, otherwise the group meets every other thursday. |
|
Accidentally closed when commenting^. |
|
Hi Sonal Patel,
This is Ogawa from Web Wervice Development responding to your comment from #76 (comment).
I'd be happy to hop on a call with the Technical Steering Committee sometime this week or next week. I'm on Japanese time which it somewhat difficult to find a common time to meet up.
In my experience the easiest time is 10PM JST is around 9AM EST. I can be available between 9PM and 12AM JST if that works. Otherwise you can let me know your timezone and work hours and I can make adjustments.
Which meeting software do you use, Google Meet, Zoom or Microsoft Teams?
Is there anything I should have prepared for the meeting?
- Ogawa
2022年6月30日(木) 1:27 Sonal Patel ***@***.***>:
… Accidentally closed when commenting^.
—
Reply to this email directly, view it on GitHub
<#76 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABIICFE4NNX6FGSCBWNFCQ3VRR2OBANCNFSM5WSWG3YQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hello,
Great to hear from you.
We have a call tomorrow, 6/30 @ 10am est. We use Zoom for calls and I can
send you the calendar invite or the zoom link for you to save.
You do not need to prepare anything, except being ready to walkthrough your
proposal and updates based on the comments made by TSC members.
Are you able to join tomorrow?
Best,
Sonal
…On Wed, Jun 29, 2022 at 15:46 Ogawa Kousei ***@***.***> wrote:
Hi Sonal Patel,
This is Ogawa from Web Wervice Development responding to your comment from
#76 (comment)
.
I'd be happy to hop on a call with the Technical Steering Committee
sometime this
week or next week. I'm on Japanese time which it somewhat difficult to find
a
common time to meet up.
In my experience the easiest time is 10PM JST is around 9AM EST. I can be
available
between 9PM and 12AM JST if that works. Otherwise you can let me know your
timezone
and work hours and I can make adjustments.
Which meeting software do you use, Google Meet, Zoom or Microsoft Teams?
Is there anything I should have prepared for the meeting?
- Ogawa
2022年6月30日(木) 1:27 Sonal Patel ***@***.***>:
> Accidentally closed when commenting^.
>
> —
> Reply to this email directly, view it on GitHub
> <
#76 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABIICFE4NNX6FGSCBWNFCQ3VRR2OBANCNFSM5WSWG3YQ
>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#76 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AVNUFDK6NXJWPJFI4J5577LVRSY3RANCNFSM5WSWG3YQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
6/30 is a little bit of short notice. English is not my native language, so I'll need to confirm that my translator is available. |
|
Hello,
No worries. Yes 7/14 at 10am works. Is there a direct email I can send the
invite to? Or should I send the Zoom link here?
Thanks,
Sonal
…On Wed, Jun 29, 2022 at 11:56 PM Ogawa Kousei ***@***.***> wrote:
Are you available tomorrow 6/30 @ 10am est? That is the next TSC call,
otherwise the group meets every other thursday.
6/30 is a little bit of short notice. English is not my native language,
so I'll need to confirm that my translator is available.
Can we plan on 7/14 @ 10am?
—
Reply to this email directly, view it on GitHub
<#76 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AVNUFDM3Q3PIEK47CGPE2PDVRUSINANCNFSM5WSWG3YQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Yes, can you send the zoom invite to [email protected]? Edit: Got the zoom invite link. Thanks. |
|
For the Zoom call with the TSC, I'm not sure what the agenda is. I'm ready to give a demo and take questions, so let me know how that fits into the overall meeting. If there's anything that needs to be address, I can make a note of it and follow up in this issue. |
|
Hi,
That is along the lines of what will occur. Please be ready to explain your
grant request and answer questions.
Thanks!
…On Thu, 14, 2022 at 02:39 Ogawa Kousei ***@***.***> wrote:
For the Zoom call with the TSC, I'm not sure what the agenda is. I'm ready
to give a demo and take questions, so let me know how that fits into the
overall meeting.
—
Reply to this email directly, view it on GitHub
<#76 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AVNUFDN3ZGUIVFL3JNZNF6TVT67ZHANCNFSM5WSWG3YQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Thanks for meeting with me on the call yesterday. And specifically thanks for Andreas for providing more context for RFP1. After discussing it and thinking it over, I agree that RFP#1 is describing a wallet implementation, and PrivateInvoice is an example application utilizing that implementation. I will update my source code and diagrams to that the wallet its own isolated unit, and will continue to provide updates here and on the project repository. |
|
@wsdOgawa please check the email from the Baseline e-mail account for the recording information. To clarify, are you going to re-propose to align with the RFP requirements or submit a separate scope of work as a BLIP? |
Yes, I think the appropriate response into separate Private Invoice into it's own BLIP that uses the wallet implementation described in #63. The figure below shows this relation. flowchart LR
A(BLIP - Private Invoice)
B(RFP1 - Wallet Implementation)
A -->|Create Did| B
A -->|Resolve Did| B
A -->|Issue Credential| B
A -->|Verify Credential| B
A -->|Generate Presentation| B
A -->|Send ETH| B
Which means that the title for this issue should be changed from In terms of approach, my plan is move wallet-relation functions into their own module. And then finish the core milestone for Private Invoice to finish it before switching to something else. And then use then separate out the module into it's own repository which can then used as the base for RFP1. At which point I'll open another issue to describe that work. As a side note, I'm still relatively new to cryptography. Do you have hints or resources to look at for the following two criteria?
|
GoldenBit0
changed the title
|
@wsdOgawa I changed the title of this request. @Therecanbeonlyone1969 @mehranshakeri @skarred14 @stefschmidt @fosgate29 other, please provide feedback for the second part of the above question. |
edit: payment with ETH is fine. |
|
@wsdOgawa thank you for the effort. A couple of notes:
|
"Zero knowledge" was not included in the description for RFP #1. I based the current implementation on the following bullet points.
I have a few follow up questions for clarification. Q1: My impression is that a Verifiable Credential is a signed with a did which points to a public key, has context that resolves to a JSON file, and a hash in the proof which does not require any additional information on the side of the verifier. What changes to Verifiable Credentials would be required to implement proof of correctness under zero-knowledge? Q2: I've read through https://docs.baseline-protocol.org/ several times. The term Q3: " -> should be added" is this increasing the scope or changing of the conditions of the RFP?
For the use of IPFS we wanted to have some kind of third party storage outside of the Private Invoice node with the understanding that anything written to the blockchain would be public knowledge. The current implementation is a first-pass quick and dirty solution. I'll look into the options you listed to see if this can be improved on to allow for privacy between the parties involved for implementation in a later version.
I intend to meet the criteria of the RFP for the wallet module. That was not my question, but thank you for reiterating this. |
|
@wsdOgawa-san, the BLIP is no longer directly related to RFP1. RFP#1 talk about building a capability, not a use case, as you are suggesting with this BLIP. Baseline BLIPs by their very nature should be an implementation of the baseline protocol as spelled out in the detail in the docs and in the Baseline draft specification. As to your Q1: a proof of correctness can be implemented using a zk-snark or zk-stark. Something easy to use is Gnark. Plenty of examples of how to construct a circuit that implements business rules. As to your Q2: substitute baseline pattern with baseline protocol ... see the draft specification referenced above for extensive details. As to Q3: No it does not as RFP#1 is no longer relevant for this BLIP. The wallet capability you are building is relevant and must meet the RFP#1 requirements. But the BLIP itself is unrelated to RFP#1. |
|
@wsdOgawa Please let me know if you'd like to proceed with considering this effort a 'BLIP', which means you can submit a grant request related to this effort. Once a grant request is submitted outlining the scope/milestones for your work, the TSC will then vote. If you would like to proceed with this effort as a BLIP, I will transfer this issue to the 'blip repo'. If you'd like to further the discussion on aligning these efforts with the RFP1 items, let us know. Thanks! |
Looks you're picking up what I'm putting down, so I'll go ahead and put my cards on the table. Right now my priorities are on I'm working on cleaning up the source code, swagger documentation and postman tests. As per the RFP I create a checklist of the required functions written in pseudo-code below. const rfpModule= {}
1. Passed and documented tests for DID creation and management for DID Element
rfpModule.createDidElement = (mnemonic, hdpath) => {
// Implemented
}
rfpModule.updateDidElement = (did, mnemonic, hdpath, patches) => {
// Requires business story and mocks for key rotation
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/30
}
rfpModule.removeDidElement = (did, mnemonic, hdpath) => {
// Requires a described method of Organization or Member cleanup
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/31
}
2. Passed and documented tests for VC issuance, verification, and presentation generation
rfpModule.issueCredential = (did, mnemonic, hdpath, unsignedCredential) => {
// Implemented
}
rfpModule.verifyCredential = (signedCredential) => {
// Implemented
}
rfpModule.preparePresentation = (did, mnemonic, hdpath, unsignedPresentation) => {
// Impplemented
}
3. 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
// Send Protocol Token
rfpModule.sendBitcoin = (mnemonic, hdpath, amount) => {
// Requires justification
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/32
}
rfpModule.checkBitcoinBalance = (mnemonic, hdpath, amount) => {
// Requires justification
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/32
}
// Fungible token
rfpModule.sendEthereum = (mnemonic, hdpath, amount) => {
// Implemented
}
rfpModule.checkEthereumBalance = (mnemonic, hdpath, amount) => {
// Implemented
}
// EC20 token
rfpModule.ERC20Token = (mnemonic, hdpath, amount) => {
// Requires design
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/35
}
rfpModule.ERC20Token = (mnemonic, hdpath, amount) => {
// Requires design
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/35
}
// non-fungible token
rfpModule.sendNonFungibleToken = (mnemonic, hdpath) => {
// Requires justification
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/33
}
rfpModule.checkNonFungibleToken = (mnemonic, hdpath) => {
// Requires justification
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/33
}
4. Passed and documented tests for receiving, signing, and sending messages for one BRI
rfpModule.sendBRIMessage = (signedMessage, sendToHost) => {
// Requires Documentation
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/34
}
rfpModule.signBRIMessage = (mnemonic, hdpath, message) => {
// Requires Documentation
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/34
}
rfpModule.receiveBRIMessage = (signMessage, receivedFromHost) => {
// Requires Documentation
// https://github.com/WebServiceDevelopment/PrivateInvoice/issues/34
}
module.exports = rfpModule
1. Passed and documented tests for DID creation and management for DID Element DID creation has been implemented in the application. Working on Postman and Jest tests related to creation. 2. Passed and documented tests for VC issuance, verification, and presentation generation These have been implemented in the application. Need to add jest tests for module. 3. 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 For ETH there is strong justification and alignment with using Bitcoin and NFT's might be something that we implement eventually. And we need justification for why there is an immediate business need or requirement for implementing the Baseline protocol. WebServiceDevelopment/PrivateInvoice#32 4. Passed and documented tests for receiving, signing, and sending messages for one BRI First Post: #76 (comment)
Three weeks ago: #76 (comment)
This point is blocked. I have brought it up twice and have not received an answer for this aspect of the RFP. 5. Universal Wallet Clarification This is not in the points brought up in the module, but needs to be raised as a separate issue. The language used in the RFP issue is as follows: RFP Goal
RFP Description
With the key language being used here is ideally implying optional. Universal wallet implementation is also not listed in the done criteria, which further implies it is not a requirement.
However @Therecanbeonlyone1969 wrote 10 days ago:
I would like to point out this contradiction. If implementation is required the language on the RFP should indicate as such. |
|
@wsdOgawa thank you for your detailed response. Looks like you are well on your way. The two key points you brought up are:
This is a requirement that is to be fulfilled this year. I would highly recommend using an available open-source wallet supporting e.g. ERC20 and NFTs besides ETH. There are plenty around.
The idea was that a grant proposal would extend BRI-1 or BRI-2 and, therefore, not have to worry about implementing messaging separately. If you want you can implement messaging using e.g. libp2p as long as it is compatible with the Baseline API draft standard.
Apologies that I was contradictory to the RFP language -- getting old. Yes, the language is "ideally", hence, an option. However, it is strongly encouraged to do so, and will be favorably looked upon across communities. |
Bitcoin, NFT's, and ERC20 are not included in the scope of our first post. I take it, this is positive confirmation that I can update the scope, budget and justification for the added requirements? With respect to "1 protocol token, d. fungible token, and 1 non-fungible token" requirements of RFP1 include
As the intention is to include Bitcoin and NFT's as a module, and not expose this functionality to the application, are we okay to only implement the first bullet point "Passed and documented tests for sending, receiving"?
Is there a reference implementation similar to https://ropsten.element.transmute.industries/ that would allow me to send test requests to? Where is the API for BRI-1 or BRI-2 described? Specifically can you provide documentation for the "Passed and documented tests for receiving, signing, and sending messages for one BRI" requirement described in the RFP? |
@wsdOgawa No you cannot -> you need to make a proposal for #63 and #76 separately. There is a fixed budget for #63, #76 is on top of that. We need two separate proposals, please!
No. This is part of RFP#1, and is to be included in that scope. We do not piecemeal. Please, submit 2 separate and standalone proposals. One for RFP#1 and an updated #76. The update to #76 can reference the work under RFP#1 as a prerequisite and assumes to be used. #76 does not have to use all of the implementation of #63.
@kthomas can you give guidance here, please. Thank you! |
|
I have two questions about the Bitcoin aspect of RFP#1.
Thank you. |
@wsdOgawa the RFP only says 2 public blockchains. It does not say Bitcoin and Ethereum. You can use Ethereum and Polygon. That works too -- simplifies everything because you can use the same libraries for both and open source Ethereum wallets also work with Polygon ... just saying. Make it easy for yourself. |
Thanks for the feedback. My interpretation for But it looks like the "correct" interpretation is: If that's correct, then I think I am comfortable with these conditions. I'll make Jest Tests and follow up by confirming their accuracy.
The last one that I'm not entirely sure about is:
I've asked a few questions about this previously, but is the expectation to send to a live implementation of a BRI, or is something like encoding and decoding a message in Jest without sending it enough? |
@wsdOgawa ... close you need TWO public chains e.g. Ehtereum and Polygon so it would be |
@kthomas could you please help here? @wsdOgawa you can simply use any pub/sub message bus that works for you if push comes to shove such as libp2p for perr-ro-peer coms |
|
@wsdOgawa would you be so kind, and close this issue, and create TWO clean grant requests:
They need to be cleanly separated though such that the TSC can independently vote on them. the invoice management application grant request can have a dependency on the grant request in response to the RFP in issue #63. Thank you! cc @GoldenBit0 |
Sure! |
Details on Grant Work
The details of the grant work are for implementing DID's, VC's into Private Invoice.. Private Invoice is an Open Source project under the Apache 2.0 license. The purpose of Private Invoice is to provide a self-hosted server where individuals can create invoices and send or receive from a whitelisted list of contacts. Invoice can be paid with Ethereum in the application. And the state of the invoice ('sent', 'confirmed', 'paid'), is kept consistent between each of nodes.
The scope of this proposal is to:
Note that
Private Invoiceis the name of the application in our repository for reference. As the application is available under Apache 2.0 we have no issues with submitting a fork with other branding or name if required.Motivation and Overview
At Web Service Development, we've have almost a decade of experience working with business applications. We believe that in order to demonstrate traceability※ with financial records, the following three conditions are required:
One pain point that we've experienced is trying to work with legacy banking institutions, which often require having a contact at that institution in order to get a contract to use their services. We believe that blockchain represents the future of business as it defines a specific implementation, where anyone who is able to interact with the technology to make transactions.
We also think that decentralization and creating multiple nodes for an application reduces the number of eggs in one basket and avoids having a central server with all customer data in a single location, which can either be exploited or attacked. And we believe that companies should be in control of their own data, which means hosting their own node, having access to their own keys and being in control of their own data.
※日本語では「証憑性」という造語を作成した。
証憑が真正であることを示すための条件を「証憑性」と定義する。
Value to the Baseline Protocol
The value to the baseline protocol is having another reference implementation to work with. We think that having an invoice application where the state of the invoice is managed between multiple parties is a simple application that shows the capabilities of the Baseline protocol. The ability to make payments on invoices with Ethereum is another step to encourage business adoption of blockchain technologies.
Downsides / Execution Risks / Limitations
Risks
The biggest risk is the execution of the Baseline Protocol from the documentation on https://docs.baseline-protocol.org/. The documentation tends to funnel towards BR-1 or BR2, instead of providing concept, figures or code snippets to work from. This means that in order to implement this protocol we will need to run the BR-1 implementation example and analyze how the protocol is exchanged between nodes.
The other risk we've identified is the standard issues around implementing any kind of project with respect to executing a design. In order to mitigate this risk we've done several tech-spikes to insure that we have an understanding of how all of the pieces work. And we've implemented the application in a format that doesn't rely on DID's or VC's to work as a web application, to allow us to swap out parts and still insure that the application instead of taking an all-or-nothing approach of building in new concepts from the ground up.
Limitations
One limitation that we're using Ganache for both payment and the did method. We have tech spikes for implementing the application with a testnet such as Ropsten or Rinkeby, but to make it easy to test and evaluate we're targeting Ganache.
Another limitation is that we're only allowing one mnemonic phrase per organization in the application and one did per member. Further versions of the application could have more fine grained version of key management, but for a core implementation we want to keep things simple.
NFT's and multiple blockchains, such are as protocol coin are not implemented in the scope of this proposal. The main focus is VC's, DID's, presentations, and investigation into the Baseline protocol. These features could be implemented in a later version if after making tech-spikes and drawing designs to be included into the roadmap for a later release.
Deliverables / Schedule / Milestones
We've outline a milestone with an internal due by date of September 30th 2022 for the features we intend to implement in this proposal. The milestone contains five issues which represent the deliverables outlined in this proposal.
Our plan is to finish implementation on these features before the end of August to provide time for testing and documentation in able to have a stable core release by September 30th. This time has been decided since we want to look for funding by the end of the year.
Budget and Justification
The budget being asked for this in this proposal is $10,000. The work on DID's, VC's and Ethereum is work that we intend on working on anyways, and would like some amount of funding to be able to continue to work on completely Open Source implementations of these technologies. Work on the Baseline protocol seems expensive as it means reverse engineering the source code examples from the BR-1 implementation, or it means actively working on Slack with an engineer to ask questions about implementation.
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
The text was updated successfully, but these errors were encountered: