NEP-551: Rich online digital tokens #551

cableguard · 2024-06-22T11:49:18Z

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

victorchimakanu · 2024-07-04T21:08:36Z

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 · 2024-07-09T07:13:40Z

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

fadeevab · 2024-09-16T16:25:31Z

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

cableguard · 2024-09-17T07:33:17Z

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

fadeevab

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.

fadeevab · 2024-09-17T12:09:27Z

README.md

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


Align table formatting according to other rows.

fadeevab · 2024-09-17T12:11:54Z

neps/nep-0529.md

+Authors: Vicente Aceituno Canal <cableguard@cableguard.org>
+Status: Draft
+DiscussionsTo: https://github.com/nearprotocol/neps/pull/529
+Type: Extensible Non fungible token (Rich Online Digital Token) akin to digital certificates


Suggested change

Type: Extensible Non fungible token (Rich Online Digital Token) akin to digital certificates

Type: Standards Track

Category: Contract

fadeevab · 2024-09-17T12:14:17Z

neps/nep-0529.md

@@ -0,0 +1,322 @@
+---
+NEP: 529


NEP number should be the same as the Pull Request (rename the file name also).

Suggested change

NEP: 529

NEP: 551

fadeevab · 2024-09-17T12:40:11Z

neps/nep-0529.md

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


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.

fadeevab · 2024-09-17T12:43:02Z

neps/nep-0529.md

+
+## 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.


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

fadeevab · 2024-09-17T12:49:10Z

neps/nep-0529.md

+
+-----------------;
+
+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)


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

fadeevab · 2024-09-17T12:49:58Z

neps/nep-0529.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


The custom script should be out of the scope of the NEP.

fadeevab · 2024-09-17T12:50:49Z

neps/nep-0529.md

+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


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

fadeevab · 2024-09-17T12:51:39Z

neps/nep-0529.md

+pub fn verify_hasrodit_getit(
+    rodit_id: [u8;RODIT_ID_SZ],
+    rodit_id_signature: [u8;RODIT_ID_SIGNATURE_SZ],
+


Use a markdown code block "```rust ... ```" and also format the code with rustfmt.

For tokens, method naming should start with a prefix of the token type: ft_transfer, nft_transfer, sbt_mint, enft_verify_what?

fadeevab · 2024-09-17T13:05:37Z

neps/nep-0529.md

+
+## 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\].


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 · 2024-09-17T17:23:21Z

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

flmel · 2024-09-27T08:46:36Z

@cableguard
Those could be of help
https://github.com/near/NEPs/blob/master/neps/nep-0001.md
https://github.com/near/NEPs/blob/master/nep-0000-template.md

“cableguard@cableguard.org” and others added 20 commits June 21, 2024 08:07

nep509

e5ee4ef

Update nep-0509.md

0ed468e

Update nep-0509.md

5e9b882

Update nep-0509.md

807698a

Update nep-0509.md

5a09645

Update nep-0509.md

b8e3803

Update nep-0509.md

8a4399f

Update nep-0509.md

f2c11c8

Update nep-0509.md

ae4634a

Update nep-0509.md

39a7aa6

Update nep-0509.md

58f2b25

Update nep-0509.md

9d7fbf5

nep519

cc10716

nep529 a

8fad757

typos

809e23d

mvi

1ed5363

renamed

7b42100

typos

5eeccf2

added 529 to readme

b9b8449

reviewed

3fdf7e8

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

lint fixed

4be93f3

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 requested changes Sep 17, 2024

View reviewed changes

flmel changed the title ~~Rich online digital tokens~~ NEP-551: Rich online digital tokens Sep 27, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NEP-551: Rich online digital tokens #551

NEP-551: Rich online digital tokens #551

cableguard commented Jun 22, 2024

victorchimakanu commented Jul 4, 2024

cableguard commented Jul 9, 2024

fadeevab commented Sep 16, 2024

cableguard commented Sep 17, 2024

fadeevab left a comment

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

fadeevab Sep 17, 2024

cableguard commented Sep 17, 2024

flmel commented Sep 27, 2024

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


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


		-----------------;

		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)


		## 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\].

NEP-551: Rich online digital tokens #551

Are you sure you want to change the base?

NEP-551: Rich online digital tokens #551

Conversation

cableguard commented Jun 22, 2024

victorchimakanu commented Jul 4, 2024

cableguard commented Jul 9, 2024

fadeevab commented Sep 16, 2024

cableguard commented Sep 17, 2024

fadeevab left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cableguard commented Sep 17, 2024

flmel commented Sep 27, 2024