Customized Non-fungible tokens for VPN operations

[alanesmizi]

Dear All,

I am preparing a NEP proposal for a implementation of NFTs for VPN operations. To summarize, the advantages of this approach are:

• Authentication: Being in control of an signed NFT-like token (or Rich Online Digital Token,or RODiT, as we call it) in a point in time can be used as authentication credentials.
• Self-Configuration: Including in the RODiT the VPN configuration can make the user journey simpler.
• License: Including in the RODiT the license number, duration, and connected services like maximum bandwidth or number of simultaneous sessions, can greatly simplify operations for the VPN provider.
• Privacy: Using RODiT protects the privacy of the user as you can buy, sell to a third party, dispose, return or renew your RODit-based VPN subscription without ever using a phone or email address.

We will soon have a demo ready.

Please ask any questions you may have, except "Why, oh why?" ;)

[frol]

So far it is not clear why NFT standard needs to be extended at all. Can you share your reasoning?

[joe-rlo]

Hello

A couple questions:

• What is the reasoning of having items like configuration within the NFT vs application side?
• What part of the current NFT standard do you see being extended to achieve this?
• Is this a specific business case or is there larger implications for it?

Thank you

[alanesmizi]

Hi! - By having the configuration included, the endpoint can configure itself upon reception of the NFT. For example taking the use case of IoT, we can create and distribute IoT devices and decide later how they will be configured. By having the configuration included in the NFT, we don't need to actually access the device remotely to configure it, we can send the configuration to its blockchain address. We break a potential chicken-and-egg situation where we need to access securely a device to be able to configure it so we can access it securely. Thinking about commercial VPN end users, many experience difficulties configuring Wireguard endpoints. By including the configuration we can make user on boarding simpler for the user. This is just from the top of my head. - There is very little of the current standard that can be reused, as this proposal intends to have mostly information in the NFT as opposed to meta-information. This is possible only because NEAR NFTs can be created for a reasonable cost. - There are larger implications, too long to elaborate here. Among them: Replacing digital certificates X.509, as they have not evolved for the last 10 years and have many shortcomings, enabling user interaction with web services without registration, like when people used to just walk into shops, and implications about breaking the log in oligopoly of Big Tech on user identity (login with Google, Facebook, etc) None of these in scope for this proposal but implementing this technology may have long reaching implications. Vicente Aceituno https://vaceituno.medium.com 29 Aug 2023, 02:03 by ***@***.***:

…

Hello A couple questions: What is the reasoning of having items like configuration within the NFT vs application side? What part of the current NFT standard do you see being extended to achieve this? Is this a specific business case or is there larger implications for it? Thank you — Reply to this email directly, > view it on GitHub <#499 (comment)>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ7M2Z7NNQ2C2ICBMILQGZ3XXUWUNANCNFSM6AAAAAA36PCE6A>> . You are receiving this because you authored the thread.> Message ID: > <near/NEPs/repo-discussions/499/comments/6847550> @> github> .> com>

[alanesmizi]

Hi It is not an expansion, it is an altogether different type of non-fungible token. Kind Regards Vicente Aceituno https://vaceituno.medium.com 28 Aug 2023, 23:59 by ***@***.***:

…

So far it is not clear why NFT standard needs to be extended at all. Can you share your reasoning? — Reply to this email directly, > view it on GitHub <#499 (comment)>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ7M2Z5HPFWQ3TMCJWRCITLXXUIFHANCNFSM6AAAAAA36PCE6A>> . You are receiving this because you authored the thread.> Message ID: > <near/NEPs/repo-discussions/499/comments/6846965> @> github> .> com>

[alanesmizi]

Let's elaborate further - With a digital certificate, the associated key pair is static. With a NFT like this proposal, the key pair can change as often as desired. - If you had a digital certificate associated with a license or subscription, you would not be able to trade it in any way as key pairs, essentially a new certificate would need to be re-created by the issuer. - With digital certificates key verification is off-line, with NFT as proposed, key verification is on-line and real time. - Traditional certificates are complex to deliver, with a mechanism for key creation, certificate signature requested, etc. NFTs as proposed are created by the issuer and sent to a wallet address. - X.509 is not a flexible standard where you can add any information you need for a use case. NFTs as suggested have self-configuration and license info included, other similar use cases may also embed pertinent info. - X.509 certificates lack separation of concerns. With the proposed standard, we can check via separate mechanisms if a NFT-like token is: in possession of the user in real time, if it is authentic, if it is valid for the intended use, and if the user is the owner of the token (this last feature is not implemented in this proposal) Kind Regards Vicente Aceituno https://vaceituno.medium.com 29 Aug 2023, 09:24 by ***@***.***:

…

Hi It is not an expansion, it is an altogether different type of non-fungible token. Kind Regards Vicente Aceituno +34683493094 https://vaceituno.medium.com 28 Aug 2023, 23:59 by ***@***.***: > > > > > So far it is not clear why NFT standard needs to be extended at all. Can you share your reasoning? > > > > > — > Reply to this email directly, >> view it on GitHub <#499 (comment)>>> , or >> unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ7M2Z5HPFWQ3TMCJWRCITLXXUIFHANCNFSM6AAAAAA36PCE6A>>> . > You are receiving this because you authored the thread.>> Message ID: >> <near/NEPs/repo-discussions/499/comments/6846965>> @>> github>> .>> com> > > > >

[alanesmizi]

Forgot to mention that for the IoT use case, in order to install a digital certificate you would normally need privileges in the device, and the process for key creation, certificate request and installation is far from straightforward. With tokens as suggested, they private key is created in the device and the device does not need to participate in the token creation that can happen later, simplifying the whole process. Vicente Aceituno https://vaceituno.medium.com 29 Aug 2023, 09:23 by ***@***.***:

…

Hi! - By having the configuration included, the endpoint can configure itself upon reception of the NFT. For example taking the use case of IoT, we can create and distribute IoT devices and decide later how they will be configured. By having the configuration included in the NFT, we don't need to actually access the device remotely to configure it, we can send the configuration to its blockchain address. We break a potential chicken-and-egg situation where we need to access securely a device to be able to configure it so we can access it securely. Thinking about commercial VPN end users, many experience difficulties configuring Wireguard endpoints. By including the configuration we can make user on boarding simpler for the user. This is just from the top of my head. - There is very little of the current standard that can be reused, as this proposal intends to have mostly information in the NFT as opposed to meta-information. This is possible only because NEAR NFTs can be created for a reasonable cost. - There are larger implications, too long to elaborate here. Among them: Replacing digital certificates X.509, as they have not evolved for the last 10 years and have many shortcomings, enabling user interaction with web services without registration, like when people used to just walk into shops, and implications about breaking the log in oligopoly of Big Tech on user identity (login with Google, Facebook, etc) None of these in scope for this proposal but implementing this technology may have long reaching implications. Vicente Aceituno +34683493094 https://vaceituno.medium.com 29 Aug 2023, 02:03 by ***@***.***: > > > > > Hello > > > A couple questions: > > What is the reasoning of having items like configuration within the NFT vs application side? > What part of the current NFT standard do you see being extended to achieve this? > Is this a specific business case or is there larger implications for it? > > Thank you > > > > > — > Reply to this email directly, >> view it on GitHub <#499 (comment)>>> , or >> unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ7M2Z7NNQ2C2ICBMILQGZ3XXUWUNANCNFSM6AAAAAA36PCE6A>>> . > You are receiving this because you authored the thread.>> Message ID: >> <near/NEPs/repo-discussions/499/comments/6847550>> @>> github>> .>> com> > > > >

[alanesmizi]

Dear All,

Looking forward for more questions. Any objections to a NEP proposal being submitted on this topic?

Kind Regards

[frol]

I still don't understand what you want to change and why. Here are some points:

1. NFTs are all public data, you cannot share a private key in it (I am not sure if I caught it correctly from your messages, but it sounds like that would be required)
2. There are plenty of metadata fields to use, and you can define your own metadata fields. So far I did not hear you talking about changing the methods (like nft_transfer), so I still don't understand what you want to change on the standard level, and why do you need to have a standard in the first place. Why won't you just go and implement your own even if totally custom contract?

[alanesmizi]

Hi Vlad,

I can see what is missing in the way I explained the proposal. It needs to be more generic, as VPN is only a specific use case.

No, private keys would not be published. That would be beyond stupid.

I may have misunderstood what the NEP standards are used for. My intention is that wallets could adopt this proposal easily, as having it published as a NEP would mean having some backing from BOS / NEAR.

I will write a detailed NEP where VPN is presented just as an example and hopefully that will make the proposal easier to understand.

The core idea is replacing X.509 digital certificates with an alternative based on blockchain using NFTs. The advantages and disadvantages will be explained in the NEP proposal.

[frol]

I may have misunderstood what the NEP standards are used for. My intention is that wallets could adopt this proposal easily, as having it published as a NEP would mean having some backing from BOS / NEAR.

If that is the case, NEP is the right place. Please, learn more about NEPs in NEP-001