-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NEP-551: Rich online digital tokens #551
base: master
Are you sure you want to change the base?
Conversation
Thank you @cableguard for submitting this NEP. I would like to ask the @near/working-groups members to assign 2 Technical Reviewers to complete a technical review. (see expectations below). Just for clarity, Technical Reviewers play a crucial role in scaling NEAR ecosystem as they provide their in-depth expertise in the niche topic while work group members can stay on guard of the NEAR ecosystem. The discussions may get too deep and it would be inefficient for each WG member to dive into every single comment, so NEAR Developer Governance designed this process that includes subject matter experts helping us to scale by writing a summary with the raised concerns and how they were addressed. |
Looking forward to the @near/working-groups to assign the technical reviewers. Is there anything I can do to help? |
@cableguard I'm from @near/working-groups , I can start a review, is it still relevant? |
@fadeevab I would love for the review to start. This is particularly relevant now as besides a VPN implementation, I am now completing a MVP that leverages RODIT for stateless mutual API authentication, including webhooks. It is not hard to manage RODIT using only NEAR CLI, but standardization can only bring benefits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The summary of my initial review:
- The NEP must be structured in such a way that provides a quick easy insight into the subject matter and a technical specification that would be easy to use by developers.
- The protocol is not fully clear, I need more time to analyze it.
- Diagrams should be included for better understanding.
- Formatting must be fixed across the document.
- Unnecessary information must be removed. I pointed out 1 concrete issue so far.
The document is a bit overloaded overall.
@@ -33,6 +33,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement | |||
| [0452](https://github.com/near/NEPs/blob/master/neps/nep-0452.md) | Linkdrop Standard | @benkurrek @miyachi | Final | | |||
| [0455](https://github.com/near/NEPs/blob/master/neps/nep-0455.md) | Parameter Compute Costs | @akashin @jakmeier | Final | | |||
| [0514](https://github.com/near/NEPs/blob/master/neps/nep-0514.md) | Fewer Block Producer Seats in `testnet` | @nikurt | Final | | |||
| [0529](https://github.com/near/NEPs/blob/master/neps/nep-0529.md) | Rich Online Digital Tokens spec | @cableguard | Draft | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Align table formatting according to other rows.
Authors: Vicente Aceituno Canal <[email protected]> | ||
Status: Draft | ||
DiscussionsTo: https://github.com/nearprotocol/neps/pull/529 | ||
Type: Extensible Non fungible token (Rich Online Digital Token) akin to digital certificates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type: Extensible Non fungible token (Rich Online Digital Token) akin to digital certificates | |
Type: Standards Track | |
Category: Contract |
@@ -0,0 +1,322 @@ | |||
--- | |||
NEP: 529 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NEP number should be the same as the Pull Request (rename the file name also).
NEP: 529 | |
NEP: 551 |
@@ -0,0 +1,322 @@ | |||
--- | |||
NEP: 529 | |||
Title: Rich Online Digital Tokens |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand, you invented the naming and you get used to the naming (as I see your old articles at the Internet), however, personally, I would call it RNFT
(rich NFT), or ENFT
(extensible NFT), or such, to underline that it's an NFT with additional special properties.
|
||
## Summary | ||
|
||
Properly designed custom non-fungible-tokens (RODiT) can complement or replace digital certificates for most purposes. The design presented in this NEP can be easily extended for any number of use cases that use digital certificates. among them, mutual authentication, electronic mail, digital signing, code signing and time stamping. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should start plainly with a human-readable description that "this standard introduces Rich Online Digital Tokens (RODiT) and a standard interface for RODiT that allows that and that".
Answer the following questions:
- What is standardized here?
- What is RODiT?
You should move the Scope paragraph here (partially... simplify!).
|
||
-----------------; | ||
|
||
The reference implementation of RODiT uses implicit accounts ([https://docs.near.org/integrator/implicit-accounts](https://docs.near.org/integrator/implicit-accounts) ). Upon creation, RODiT can be sent to final addresses or to an address from where RODiT can be distributed to final endpoint addresses. Practitioners can use NEAR CLI or NEAR CLI RS to view the content of a RODiT or send it to an address. The reference implementation uses a bash script to make handling the RODiT sets more user friendly. It can be found here: [https://github.com/cableguard/cgroditvpn](https://github.com/cableguard/cgroditvpn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence is important for understanding what you present in the NEP. I would recommend putting a sequence diagram into the NEP for a better understanding of the protocol. mint -> address -> final address
.
Check the SBT NEP for the reference: https://github.com/near/NEPs/blob/master/neps/nep-0393.md
* cgroditwallet.sh: List of available accounts | ||
* cgroditwallet.sh _accountID_: Lists the RODiT Ids in the account and its balance | ||
* cgroditwallet.sh _accountID_ keys: Displays the accountID and the Private Key of the account | ||
* cgroditwallet.sh _accountID_ roditId: Displays the indicated RODiT | ||
* cgroditwallet.sh _fundingaccountId_ _unitializedaccountId_ init: Initializes account with 0.01 NEAR from funding acount | ||
* cgroditwallet.sh _originaccountId_ _destinationaccountId_ roditId: Sends ROTD from origin account to destination account | ||
* cgroditwallet.sh genaccount: Creates a new uninitialized accountID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The custom script should be out of the scope of the NEP.
5. Legitimate: The endpoint checks if the Issuer is legitimate, in other words, if it has been authorized by the Service Provider to issue RODiT for its subjectuniqueidentifierurl, by checking if there is a DNS entry using the peer’s RODiT token\_id that follows the format _SMARTCONTRACTID.smartcontract.subjectuniqueidentifierurl_. If the entry does not exists, the smart contract has been revoked. The reference implementation uses the function _pub fn verify\_rodit\_smartcontract\_istrusted_ for this check. (Note: Do we need to check if the RODiT root is Live and Active) | ||
6. Valid: The endpoint may check optional properties of the RODiT, like location, number of transactions per minute, among other use cases. | ||
|
||
Reference Implementation - Minimum Viable Interface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub fn verify_hasrodit_getit( | ||
rodit_id: [u8;RODIT_ID_SZ], | ||
rodit_id_signature: [u8;RODIT_ID_SIGNATURE_SZ], | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a markdown code block "```rust ... ```" and also format the code with rustfmt
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For tokens, method naming should start with a prefix of the token type: ft_transfer
, nft_transfer
, sbt_mint
, enft_verify_what?
|
||
## Motivation | ||
|
||
Public Key Infrastructure is a prevalent way to use public key encryption. The original motivation of this NEP proposal are the many flaws in Public Key Infrastructure. It is beyond the scope of this NEP to explain these flaws in detail, please refer to the sources \[1\]\[2\]\[3\]\[4\]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Provide a plain/dry motivation, something like that:
Replacing PKI (Public Key Infrastructures) with the blockchain tokens of special configuration. Using blockchain-issued tokens equivalent to digital certificates can provide better functionality than traditional digital certificates (PKI) without compromising security
.
Thanks @fadeevab I will implement the necessary improvements over the next few days |
Minimal support for Rich Online Digital Tokens as described in the whitepaper at https://github.com/cableguard/roditwhitepaper/tree/main