Skip to content
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

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

cableguard
Copy link

Minimal support for Rich Online Digital Tokens as described in the whitepaper at https://github.com/cableguard/roditwhitepaper/tree/main

@cableguard cableguard requested a review from a team as a code owner June 22, 2024 11:49
@victorchimakanu
Copy link

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.

@cableguard
Copy link
Author

Looking forward to the @near/working-groups to assign the technical reviewers. Is there anything I can do to help?

@ori-near ori-near added WG-contract-standards Contract Standards Work Group should be accountable S-draft/needs-author-revision A NEP in the DRAFT stage that needs an author revision. A-NEP A NEAR Enhancement Proposal (NEP). labels Jul 22, 2024
@fadeevab
Copy link
Contributor

@cableguard I'm from @near/working-groups , I can start a review, is it still relevant?

@cableguard
Copy link
Author

@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.

Copy link
Contributor

@fadeevab fadeevab left a 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:

  1. 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.
  2. The protocol is not fully clear, I need more time to analyze it.
  3. Diagrams should be included for better understanding.
  4. Formatting must be fixed across the document.
  5. 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 |
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Type: Extensible Non fungible token (Rich Online Digital Token) akin to digital certificates
Type: Standards Track
Category: Contract

@@ -0,0 +1,322 @@
---
NEP: 529
Copy link
Contributor

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).

Suggested change
NEP: 529
NEP: 551

@@ -0,0 +1,322 @@
---
NEP: 529
Title: Rich Online Digital Tokens
Copy link
Contributor

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.
Copy link
Contributor

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:

  1. What is standardized here?
  2. 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)
Copy link
Contributor

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

Comment on lines +166 to +172
* 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
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix the formatting around the document, it's not rendered properly:

image

Comment on lines +197 to +200
pub fn verify_hasrodit_getit(
rodit_id: [u8;RODIT_ID_SZ],
rodit_id_signature: [u8;RODIT_ID_SIGNATURE_SZ],

Copy link
Contributor

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.

Copy link
Contributor

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\].
Copy link
Contributor

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.

@cableguard
Copy link
Author

Thanks @fadeevab I will implement the necessary improvements over the next few days

@flmel flmel changed the title Rich online digital tokens NEP-551: Rich online digital tokens Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NEP A NEAR Enhancement Proposal (NEP). S-draft/needs-author-revision A NEP in the DRAFT stage that needs an author revision. WG-contract-standards Contract Standards Work Group should be accountable
Projects
Status: DRAFT
Development

Successfully merging this pull request may close these issues.

5 participants