CIP-0066 | NFT Identity #294

Padierfind · 2022-07-12T22:53:05Z

The current CIP ID is set to 066, but this can be changed to any arbitrary number.

shawnim · 2022-07-12T23:27:12Z

Excellent proposal!
Well designed and presented.
Two small nitpicks:
Line 44 "platofrms" -> "platforms"
Line 215 "The focous of this standard is on easy-of-use & flexibility." -> "The focus of this standard is on ease-of-use & flexibility."
Nice work!
I think this will benefit both creators and NFT platforms.

rphair · 2022-07-13T03:32:32Z

thanks; looking forward to the pending material 😎

Padierfind

Fixed some spelling mistakes and added DID example.

Padierfind · 2022-07-13T15:08:46Z

Thank you for the feedback @shawnim! Thats very helpful. I went over the whole text again and fixed the mistakes.

And thanks @rphair. The DID Example is now in. Only a nice-to-have explanation graphic missing.

BadrulAlomIOG · 2022-07-13T17:02:35Z

Feedback based on Zoom call.

Think the unnamed token should be called something like "Collection Metadata token" to make it easier to understand
Need to safeguard against the following scenario:

Bad actor creates and NFT colleciton with their actual details
Later they go an modify the social media data attached to their unnamed token to a fake social media profile
This reduces problem down to still having to verify the DID or policy ID itself. (Capturing the actual metadata like this may be redundant?).

Does the solution require Twitter to agree to be an credential validator? If so this would limit adoption and is it better than the social media account owner publicly stating their public ID/policy key

Padierfind · 2022-07-14T00:21:32Z

Okay, I added the images explaining the structure & changed the title from unnamed token to "Collection Token" like @BadrulAlomIOG suggested. I think that's a very good idea!

@BadrulAlomIOG regarding your third point: No, it does not require Twitter to be a credential validator. Twitter has a login function through the OAuth standard, that's all which is required for issuing the identity.

rphair

I believe this is promising & worth discussion with some other NFT projects & platforms that are currently debating a new CIP here (#299). As soon as some preliminaries are met I would be happy to invite them over to review this CIP if they haven't discovered it already in the meantime. 😎

rphair · 2022-07-15T00:25:29Z

CIP-066/README.md

@@ -0,0 +1,426 @@
+---
+CIP: 066
+Title: NFT Identity


Suggested change

Title: NFT Identity

Title: NFT Project Identity

Making the title more specific will be helpful, since NFT Identity is too general for people to know what it's really about. NFT Project Identity would match what you describe in the Abstract & Motivation, or perhaps NFT Collection Identity if that's not too specific.

I would even suggest NFT Verification Standard as it is the verifier's identity being used, not the NFT's identity.

rphair · 2022-07-15T00:36:25Z

CIP-066/README.md

+
+## Practical Example
+
+Let's imagine Paris Hilton wants to release an NFT collection on Cardano.


Use of the particular celebrity Paris Hilton doesn't add anything to the substance of the CIP. If the "story" were a bit shorter and maybe used a more generic term e.g. "celebrity" then there would be room in the reader's attention for at least one other use case: that of the unknown artist who's less followed on social media & has less likelihood of being authenticated through a conventional platform.

Agreed. Alternatively, could pick a nameless name like John Doe / Jane Doe for the sake of the example.

Maetti79 · 2022-07-15T17:34:16Z

We moved the payload into the DID

Feedback based on Zoom call.

Think the unnamed token should be called something like "Collection Metadata token" to make it easier to understand

Need to safeguard against the following scenario:

Bad actor creates and NFT colleciton with their actual details

Later they go an modify the social media data attached to their unnamed token to a fake social media profile
Answer: This is not possible, you need to update your identity using the Issuer Service you used in the first place, in order to have the data Signed again.

This reduces problem down to still having to verify the DID or policy ID itself. (Capturing the actual metadata like this may be redundant?).

Does the solution require Twitter to agree to be an credential validator? If so this would limit adoption and is it better than the social media account owner publicly stating their public ID/policy key

rodolfomiranda · 2022-07-15T22:41:41Z

It's a good idea to tie a DID to an NFT, however it is not specified how those social identities can be linked to the DID. I'd assume it will be some Verifiable Credentials issued by some party to that DID. If that's the case, the issuer of the VC became the root of trust as are the NFT platforms. I'm not understanding how you solve the problem of the centralization effort. I'm probably missing something.
Or is it the stored data in the DID as shown on the example?. DIDs are controlled by the owner, not by a central identity provider, that's one of the main principles of SSI. It would be good if you can add definitions for Identity Provider and Identity Data Points and how these can be a trusted sources.

phillewis · 2022-07-16T11:10:02Z

As per my response on Twitter, I would also (as per @rodolfomiranda) suggest considering Verifiable Credentials. My suggestion on Twitter was to explore using VCs in place of the proposed Identity Token. By using an existing standard it would open the Cardano NFT space to cross chain interoperability.

I have proposed in the past that we should even consider using DIDs as NFTs. While that would be a bigger change, linking the verifier's DID to the NFT via a VC could act as a stepping stone towards a true cross chain standard for NFTs.

sean118 · 2022-07-17T07:41:11Z

What's the benefit of having a separate "Collection Token" instead of simply adding a DID reference or identity token reference field directly to the existing NFT metadata?

Edit: I think the goal of linking an NFT to its DID or an identity token may be achieved 1) without introducing this new Collection Token and 2) even without adding a new transaction_metadatum_label (725) - simply by adding a new property to the existing 721 structure (or even just an entry to the files array).

This would keep complexity low, prevent (potentially) unnecessary metadata fragmentation and keep the identity ref in closer proximity to the NFTs.

In contrast to the idea of a locked "Reference Token" discussed in the Datum Metadata Standard proposal, this Collection Token doesn't add programmability / readability from plutus scripts, and since it's minted under the same policy as the other NFTs of the collection, it has the same restrictions (eg timelock) and does not add much flexibility, so it may not be worth the added complexity. But maybe I'm also just missing something?

cent-development · 2022-07-19T12:30:50Z

A well structured CIP. Great work!
Some comments and questions for further discussions...

Agree with your suggestion of separating the verification data from the metadata of individual NFTs! This will also aid backwards compatibility and ensure support for adding verification data post mint for existing collections if needed.
The DID Document is saved to IPFS as a file in the example. Could this data be saved directly on Cardano blockchain as metadata instead, or do you foresee size to exceed Cardano metadata size limit already short term? How about storing this in a separate key 724 (or similar) or incorporating this into the Collection Token (key 725)?
The example DID Document file contains the properties verificationMethod and authentication which are linked to IAMX. Are these properties also relevant for other DID providers then IAMX or should they be left out of the generic standard or set optional?
Would've liked to see this CIP be extended with an example or at least discuss the concept for using other DID provider then IAMX. The verification standard should be flexible with regards to which DID provider to use.
The CIP could benefit from a section describing how to use the provided DID and collection data to do the actual verification by marketplaces, explorers and dapps.

Looking forward to the continued discussion :)

SebastienGllmt · 2022-07-19T08:32:05Z

CIP-066/README.md

+
+```
+{
+ "725": {


Can we get CDDL formats for these? At the end of the day, the Cardano chain stores stuff in CBOR and not JSON

Agreed. Ideally, we make it a self-contained file separate from the rest (e.g. 725.cddl)

SebastienGllmt · 2022-07-19T14:53:29Z

CIP-066/README.md

+
+#### 2. Collection Token
+
+This is an unnamed token, as first described in the [CIP-0027](hhttps://github.com/cardano-foundation/CIPs/tree/master/CIP-0027).


FYI this idea conflicts with CIP67 #298

Ideally this CIP would be split into two CIPs: one that proposes the double-indirection scheme for minting policies introduced in this CIP (and have it be as a competitor to CIP68) and one that leverages the first CIP for an identity standard

KtorZ · 2022-08-16T15:30:25Z

CIP-066/README.md

+
+Most of these platforms create a centralized database of verified projects and have arbitrary rules that define which NFTs get verified on the respective platform. Not only is this not scalable because it relies on a case-to-case verification process often done manually and requires the NFT creators to go through the verification process on an increasing amount of different platforms, but it is also highly centralized and doesn't utilize a global cross-platform verification method.
+
+## High Level Overview


Please nest this (and Practical Example below) under Specification

KtorZ · 2022-08-16T15:31:29Z

CIP-066/README.md

+
+By connecting an NFT collection to one or multiple Digital Identifiers, the creator of the NFT collection has the option to attach verification data points to the collection. 
+
+Each of these data points stores information about a direct connection between the NFT collection and some sort of identity medium. This identity medium could be a scoial account, a KYC process, a phone number or anything else where an identity is directly linked to an account or something similar.


Suggested change

Each of these data points stores information about a direct connection between the NFT collection and some sort of identity medium. This identity medium could be a scoial account, a KYC process, a phone number or anything else where an identity is directly linked to an account or something similar.

Each of these data points stores information about a direct connection between the NFT collection and some sort of identity medium. This identity medium could be a social account, a KYC process, a phone number or anything else where an identity is directly linked to an account or something similar.

KtorZ · 2022-08-16T15:32:51Z

CIP-066/README.md

+
+## Practical Example
+
+Let's imagine Paris Hilton wants to release an NFT collection on Cardano.


Agreed. Alternatively, could pick a nameless name like John Doe / Jane Doe for the sake of the example.

KtorZ · 2022-08-16T15:34:10Z

CIP-066/README.md

+
+## Specification
+
+This is the registered `transaction_metadatum_label` value


Please make sure to also edit the corresponding registry from CIP-0010

KtorZ · 2022-08-16T15:35:38Z

CIP-066/README.md

+
+#### 2. Collection Token
+
+This is an unnamed token, as first described in the [CIP-0027](hhttps://github.com/cardano-foundation/CIPs/tree/master/CIP-0027).


Suggested change

This is an unnamed token, as first described in the [CIP-0027](hhttps:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027).

This is an unnamed token, as first described in the [CIP-0027](https:https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027).

KtorZ · 2022-08-16T15:46:46Z

CIP-066/README.md

+| Component | description |
+| --------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
+| DID | The actual Decentralized Identity Document where the information about the connected identity data points is stored. |
+| Collection Token | This token is minted under the policy ID of the NFT collection. It defines the connecton to the DID or the Identity Token. |


Suggested change

| Collection Token | This token is minted under the policy ID of the NFT collection. It defines the connecton to the DID or the Identity Token. |

| Collection Token | This token is minted under the policy ID of the NFT collection. It defines the connection to the DID or the Identity Token. |

KtorZ · 2022-08-16T15:48:26Z

CIP-066/README.md

+#### 3. Identity Token
+
+This token can be created under a seperate policy ID, so that it can be used for multiple collections at once.
+The policy can also be left unlocked in case the identity information requires changes at some later date. 


How is this "token" defined and updated in practice? Is it assumed that the last minting transaction would prevail? In which case, are previous identity tokens meant to be burnt?

KtorZ · 2022-08-16T15:49:07Z

CIP-066/README.md

+{
+ "725": {
+ "<policy_id>": {
+ "<collection_name>": {


How is the collect_name defined? Is there any restrictions beyond those of the protocol? Can an identity token's metadata carry multiple collections?

KtorZ · 2022-08-16T15:56:49Z

CIP-066/README.md

+
+To keep NFT metadata compatible with changes coming up in the future, we use the **`version`** property.
+
+## Rationale


Some unanswered questions in the document that would deserve an explanation in this section:

Why bother with two approaches (collection token vs identity token) instead of a single one. It seems that one is clearly a superset of the other, and thus, make the other redundant. If the claim is about offering a simple alternative for those who don't want to go the "complex" way then I'd argue that this is misleading at most as, most implementations will likely end up implementing both making the system ultimately more complex than if there was only one generic and capable way.

How does exactly are the metadata tied to an NFT collection (beyond the policy id)? Can anyone publish identity metadata at any time after the mint? Does this has to happen during the mint? If so, then, what's the justification w.r.t the current metadata spoofing issues affecting CIP-0025.

Why adopting this particular format? It seems like this is mainly backed by the W3C Recommendation but this is only vaguely mentioned in the specification. If this W3C recommendation is meant to become an industry-grade standard then it'd be nice to highlight this in the rationale section.

KtorZ · 2022-08-16T15:58:13Z

CIP-066/README.md

+
+[IAMX](https://iamx.id/) will be creating a tool to create the DIDs that will be integrated natively into [NMKR](https://www.nmkr.io/) studio.
+
+By displaying this solution at the Catalyst Guild Hall we hope to reach more creators that are willing to integrate this solution.


If a reference implementation exist, I'd strongly suggest to include some test vectors as examples in this section to help other implementations to also happen. As mentioned also in some other comments, the data is ultimately stored on-chain as binary (CBOR). Thus, test vectors should include at least a CBOR representation of the metadata, and possibly a JSON / YAML one for human-readability.

rphair

The issue of the CIP title came up again in the CIP meeting # 51 today. Although some words could be added like [NFT...] {Collection, Issuer, {Verifier, Verification}} indicating the agent or function, @KtorZ made the good point that this is really just the W3C DID standard implemented on Cardano & that's what should be reflected in the CIP title.

So it's important to quality and complete the title by including W3C, DID and/or whatever language they use to indicate what a DID is, plus the fact that this can be referenced & stored in Cardano native token metadata.

The meeting also suggested clarifying & cleaning up the presentation... @Padierfind I think that's just a matter of addressing all the review comments above. 🙏

essbante-io · 2022-08-22T23:56:11Z

Adding data points into a DID may raise some eyebrows in the SSI world. DIDs have been designed to decouple the identifier from the identity. The proposed implementation is pushing the identity of the creator into the DID. I understand this is not the usual context for an SSI implementation and some oddness is to be expected. Theoretically, the identity pieces should be separated from the DID (issued as Verifiable Credentials).

On the same topic, the payload field used to store the data points is not a core property of the DID document specification https://www.w3.org/TR/did-core/#did-document-properties. I guess it can be added as an extension, but in that case, the details of the property should be specified to know what to expect (see: https://www.w3.org/TR/did-core/#extensibility)

I see the trust in this solution is placed on the Identity Provider and the DID, but I don't see a mechanism to link the DID to the "trusted" Identity Provider. Is the Identity Provider going to function as a trust registry and publish the DIDs it has provided?

Also, I'm missing the use of signatures. The power of the DIDs comes from using the keys to sign data or prove DID ownership, but I don't see signatures used. Most likely, the implementation can be done with a more straightforward Identifier structure. (meaning: most of the DID document properties are optional. Authentication and verificationMethod are they needed?)

Data protection regulations: Considering the implementation proposes publishing what can be considered PII into an immutable public ledger. It's recommendable to validate with an expert on data protection regulations the responsibility and liability of the Identity Provider.

lohanspies · 2022-08-30T13:47:27Z

I have proposed in the past that we should even consider using DIDs as NFTs.

@phillewis do you have anything written down regarding using DIDs as NFTs? That is in my opinion the ultimate solution.

phillewis · 2022-08-30T16:53:45Z

I have proposed in the past that we should even consider using DIDs as NFTs.

@phillewis do you have anything written down regarding using DIDs as NFTs? That is in my opinion the ultimate solution.

@lohanspies I have provided some extended thoughts on this in my comment on the CIP-0068 PR at #299 (comment), as it could address the requirements that both this and CIP-0068 are trying to address, rather than as 2 separate bespoke solutions.

I would be happy to discuss further if you are interested.

Wolfy18 · 2022-11-02T20:25:12Z

Do we have a consensus over DIDs metadata? The key for decentralized identity are cryptographic keys which payment address natively depend on (payment.vkey and payment.skey Key Pairs )

Following the web3 standard for DIDs ; A DID is a simple text string consisting of three parts: 1) the did URI scheme identifier, 2) the identifier for the DID method, and 3) the DID method-specific identifier. Also, a DID document contains information associated with the DID, such as ways to cryptographically authenticate a DID controller.

DID method-specific identifier can be the CBORHex serialized wallet address, following this schema

We could store a JSON package in IPFS, like the one below, and upload a DID document which can be an encrypted version of a Identity Verification Certificate issued by a credit bureau (Experian, Transunion, Equifax, Okta).

Ex:
ipfs:https://QmPPrHGV5UeG7YB9YJ1sVMhvb3NCtjPPFg8ksCtHWzuFVh

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "issuer": "did:example:456", # https://bakrypt.io DID 
  "authentication": [{
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "5820d84d47b1eecc9efc6008a65a7e179a8da8d7d5fe050b6ca3bfffe360d19f88a7"
  }]
}

As I mentioned before, the publicKeyMultibase can be represented as the cborHex value of verification key (Public Key).

cat payment.vkey

{
    "type": "PaymentVerificationKeyShelley_ed25519",
    "description": "Payment Verification Key",
    "cborHex": "5820d84d47b1eecc9efc6008a65a7e179a8da8d7d5fe050b6ca3bfffe360d19f88a7"
}

Therefore we could attach a data structure to a token by minting a transaction as the following.

Ex:
Metadata Structure linked to an ADA token

{
  "<DID_metadatum_label>": {
    "subject": <CBORHEX_paymentaddress>,
    "document": "ipfs:https://QmPPrHGV5UeG7YB9YJ1sVMhvb3NCtjPPFg8ksCtHWzuFVh"
  }
}

The ownership of the identity verification certificate can be authenticated by using the signing key (Private key) of the current holder of the minted DID token. Only the legitimate wallet that was used to mint the token is able to decrypt the data of the verification certificate by using the secret key of this wallet (payment.skey).

A verifier can request the issuer to validate the existence of the certificate via APIs, and if necessary the verifier can request the token holder (Wallet owner) to "sign" a transaction and decrypt the Biometric picture on request, only if its authorized by the wallet owner.

https://www.w3.org/TR/did-core/#a-simple-example

Lets try to reach a consensus over this! There are so many use cases for this type of applications. Lets elaborate this idea. We're trying to push development efforts for this which many of us feels its imperative for the ecosystem.

KtorZ · 2022-11-30T18:15:45Z

@Wolfy18 I don't there's any consensus yet. This proposal is pretty much on hold without much sign of activity for a while. There hasn't been much engagement from the authors regarding the feedback given so far so I am not quite sure what's the state of this proposal and whether it is to be withdrawn?

cc @Padierfind

Wolfy18 · 2022-11-30T19:45:44Z

@Wolfy18 I don't there's any consensus yet. This proposal is pretty much on hold without much sign of activity for a while. There hasn't been much engagement from the authors regarding the feedback given so far so I am not quite sure what's the state of this proposal and whether it is to be withdrawn?

cc @Padierfind

Thank you for taking the time to respond. Well I think this a really good feature that can enable Cardano to add more use cases in the real world.

If anyone’s interested, take a look at this interview I did a couple of days ago during the Cardano Summit in NYC. I’m talking about the subject, some use cases and how to get there.

Fast forward to minute 14:40s 😜

https://youtu.be/3mIs9ROtpow

Again, these are only raw ideas of how to get there leveraging platforms and services that we currently use in our day to day. These ideas are changing constantly and keep in mind that can be wrong! That’s the whole point, let’s have a discussion on how to make this happen. I’m already working on two CIPs to kickstart the whole conversation

KtorZ · 2023-01-17T11:05:26Z

Closing due to inactivity. Feel free to open again to revive the debate.

rphair · 2023-01-17T12:32:15Z

FYI @KtorZ I think we have to add the number 0066 back into the title because there are other discussions that reference this material by the pending CIP number: here e.g. #299 (comment) and in message threads. I had a PM just last week that referred to it by number alone (also hinting it might be used in an implementation) & these references will be broken unless we allow the number to persist as an artefact. If you feel strongly otherwise, just change it again & I'll leave it that way. 😎

PatrickTobler · 2023-05-15T17:55:39Z

Hey, @KtorZ , I would like to re-open this pull request. The standard is live and being used by more than a hundred NFT collections out there.

PS: I'm currently locked out of my original Github account... So don't mind the new account please. Lost my Yubikey :'D

rphair · 2023-05-16T10:28:40Z

that's great news @PatrickTobler - it was only closed when we hadn't heard from you for a while. I'm sure I'm not alone in being happy to see that this will be moving forward again 😎

rphair

@PatrickTobler it wasn't just "we didn't hear from you for a while" that caused this proposal to be closed... it was mainly that the comments, from almost the first review, hadn't been answered. It's good to hear that the specification has been progressing & getting implemented over the last 9 months, but if we can't document this in the PR or the CIP draft then we still don't know what to do with the pull request.

Here are the next things we need you or your team to do:

1 - the CIP format has changed since this draft was written; please review the updated format and put the header & outline in the form we are currently using. Otherwise we would have to review & mark this up with the same 12 differences or so which have emerged for everyone who wrote proposals back in 2022 before the update:

https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md

This includes most especially

the header data, which in your case still has the wrong CIP number, as already reported (not matching the PR title which has the correct number 66);
the directory name itself which (currently CIP-066) doesn't have the correct number of 4 digits so it can't be merged as it exists now;
the outline of section headers which match our required template only loosely: https://github.com/cardano-foundation/CIPs/blob/master/.github/CIP-TEMPLATE.md

2 - settle the question about the CIP title as per #294 (comment) (still unanswered). The current header title NFT Identity has two words with huge overlap and are therefore much more general than what's specifically proposed here. I wouldn't block it on this alone, but the editorial suggestion to make the title more specific needs a robust discussion.

3 - we've become more emphatic about documenting all on-chain data in CDDL format, since chain data is in CBOR; so unless I'm wrong about the target please update the Specification section accordingly.

4 - go back & finally address the old reviews. If the questions have been answered in the meantime with your practical development & what you've learned since then, please update the CIP draft itself as necessary. In either case please make a comment on each of those review points so either your or editors an officially resolve all of them.

5 - update Path to Active with your current implementation progress, and put in this format please: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#path-to-active

If we can do this via GitHub in the next week or so, we can add this for Review at the next CIP meeting with the goal of getting it marked for Last Check once we can verify we have a current & properly formatted document, and that your real-world progression to Active status matches the document.

Also please note here if your new GitHub ID is unable to modify this PR branch. We would definitely want to preserve the review history rather than opening up a new PR. 🤯

It is also generally helpful if you allow contributors on the CIP repo (i.e. editors) to also modify your branch: which we currently cannot; which increases our overhead in fixing format problems. 🙏

Added file from clone to fork

522dfdf

rphair added the Waiting for Author Proposal showing lack of activity or participation from their authors. label Jul 13, 2022

changed some text and fixed spelling mistakes

1e69256

Padierfind commented Jul 13, 2022

View reviewed changes

rphair removed the Waiting for Author Proposal showing lack of activity or participation from their authors. label Jul 13, 2022

Padierfind added 7 commits July 14, 2022 01:42

changed location of payload

b36ee96

Added graphics

a29761d

Changed paths for images.

311e778

changed paths for images

c6a6691

changed paths for images

d378588

changed graphic

4f36f62

change to structure§

1d15315

rphair reviewed Jul 15, 2022

View reviewed changes

This was referenced Jul 19, 2022

CIP-0068 | Datum Metadata Standard #299

Merged

CIP-0054? | Cardano Smart NFTs #263

Merged

KtorZ changed the title ~~CIP-0066? | Created NFT Identity CIP~~ CIP-0066? | NFT Identity Aug 2, 2022

KtorZ added Candidate CIP labels Aug 2, 2022

SebastienGllmt reviewed Aug 2, 2022

View reviewed changes

KtorZ reviewed Aug 16, 2022

View reviewed changes

rphair reviewed Aug 16, 2022

View reviewed changes

rphair added the Waiting for Author Proposal showing lack of activity or participation from their authors. label Aug 16, 2022

KtorZ added Process and removed Standard labels Aug 17, 2022

rphair mentioned this pull request Nov 30, 2022

CPS-0001 | Metadata Discoverability and Trust #371

Open

KtorZ closed this Jan 17, 2023

KtorZ changed the title ~~CIP-0066? | NFT Identity~~ CIP-? | NFT Identity Jan 17, 2023

KtorZ changed the title ~~CIP-? | NFT Identity~~ CIP-???? | NFT Identity Jan 17, 2023

rphair changed the title ~~CIP-???? | NFT Identity~~ CIP-0066 | NFT Identity Jan 17, 2023

rphair reopened this May 16, 2023

rphair reviewed May 16, 2023

View reviewed changes


		## Practical Example

		Let's imagine Paris Hilton wants to release an NFT collection on Cardano.


		#### 2. Collection Token

		This is an unnamed token, as first described in the [CIP-0027](hhttps://github.com/cardano-foundation/CIPs/tree/master/CIP-0027).


		Most of these platforms create a centralized database of verified projects and have arbitrary rules that define which NFTs get verified on the respective platform. Not only is this not scalable because it relies on a case-to-case verification process often done manually and requires the NFT creators to go through the verification process on an increasing amount of different platforms, but it is also highly centralized and doesn't utilize a global cross-platform verification method.

		## High Level Overview


		By connecting an NFT collection to one or multiple Digital Identifiers, the creator of the NFT collection has the option to attach verification data points to the collection.

		Each of these data points stores information about a direct connection between the NFT collection and some sort of identity medium. This identity medium could be a scoial account, a KYC process, a phone number or anything else where an identity is directly linked to an account or something similar.


		## Specification

		This is the registered `transaction_metadatum_label` value

	\| Collection Token \| This token is minted under the policy ID of the NFT collection. It defines the connecton to the DID or the Identity Token. \|
	\| Collection Token \| This token is minted under the policy ID of the NFT collection. It defines the connection to the DID or the Identity Token. \|


		To keep NFT metadata compatible with changes coming up in the future, we use the `version` property.

		## Rationale


		[IAMX](https://iamx.id/) will be creating a tool to create the DIDs that will be integrated natively into [NMKR](https://www.nmkr.io/) studio.

		By displaying this solution at the Catalyst Guild Hall we hope to reach more creators that are willing to integrate this solution.

CIP-0066 | NFT Identity #294

Are you sure you want to change the base?

CIP-0066 | NFT Identity #294

Conversation

Padierfind commented Jul 12, 2022 • edited Loading

shawnim commented Jul 12, 2022

rphair commented Jul 13, 2022

Padierfind left a comment

Choose a reason for hiding this comment

Padierfind commented Jul 13, 2022

BadrulAlomIOG commented Jul 13, 2022

Padierfind commented Jul 14, 2022

rphair left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rphair Jul 15, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Maetti79 commented Jul 15, 2022 • edited Loading

rodolfomiranda commented Jul 15, 2022

phillewis commented Jul 16, 2022

sean118 commented Jul 17, 2022 • edited Loading

cent-development commented Jul 19, 2022

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rphair left a comment • edited Loading

Choose a reason for hiding this comment

essbante-io commented Aug 22, 2022

lohanspies commented Aug 30, 2022

phillewis commented Aug 30, 2022

Wolfy18 commented Nov 2, 2022 • edited Loading

KtorZ commented Nov 30, 2022

Wolfy18 commented Nov 30, 2022

KtorZ commented Jan 17, 2023

rphair commented Jan 17, 2023 • edited Loading

PatrickTobler commented May 15, 2023 • edited Loading

rphair commented May 16, 2023

rphair left a comment • edited Loading

Choose a reason for hiding this comment

Padierfind commented Jul 12, 2022 •

edited

Loading

rphair Jul 15, 2022 •

edited

Loading

Maetti79 commented Jul 15, 2022 •

edited

Loading

sean118 commented Jul 17, 2022 •

edited

Loading

rphair left a comment •

edited

Loading

Wolfy18 commented Nov 2, 2022 •

edited

Loading

rphair commented Jan 17, 2023 •

edited

Loading

PatrickTobler commented May 15, 2023 •

edited

Loading

rphair left a comment •

edited

Loading