Stories and acceptance criteria TBD.

Clarification and Motivation

As Tezos Profiles grows, it's going to need additional public account credentials to build a stronger foundation for a user's identity. In order to bolster these efforts, we must continue to introduce additional verifications on the platform, starting with a number of social profile verifications.

To better support the Tezos developer community, Tezos Profiles should enable linking GitHub accounts through credentialing.

Acceptance Criteria

As a user:

• I can connect my wallet to Tezos Profiles and view available credentials
• I can obtain a GitHub credential through Tezos Profiles by:
  • Entering my GitHub handle
  • Signing a message containing my handle and additional information
  • Including this message in a Gist on GitHub
  • Verifying that Gist based on its link
• I can add this GitHub credential to my existing smart contract if I've already deployed a profile.

As a deployer of the Cloudflare Worker for Twitter Verifications, I want the bot to fallback to HTTP GET requests to Twitter in the case where I was not able to obtain a Twitter API Key.

Use TezosSignature2021 (spruceid/ssi#170) for profile credential proof.

Other changes:

• Use IRI for CoreProfile term.
• Verify credential after issuing it, as a sanity check.
• Output VC to console.

Patch

Applies to 7fd3712

From ebed3b31f83267ed01c1e88e284530f5d4c85330 Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner" <[email protected]>
Date: Fri, 16 Apr 2021 17:41:29 -0400
Subject: [PATCH] Sign profile credential with TezosMethod2021

---
 dapp/src/core_profile.ts | 47 +++++++++++++++++++++++++---------------
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/dapp/src/core_profile.ts b/dapp/src/core_profile.ts
index 7a21ec1..0ab7e35 100644
--- a/dapp/src/core_profile.ts
+++ b/dapp/src/core_profile.ts
@@ -1,6 +1,7 @@
 import { v4 as uuid } from 'uuid';
 import { alert, dappUrl } from 'src/store';
 import { signClaim } from 'src/utils';
+import { RequestSignPayloadInput, SigningType } from '@airgap/beacon-sdk';
 
 export const signCoreProfile = async (userData, wallet, networkStr, DIDKit, profile) => {
   try {
@@ -12,7 +13,8 @@ export const signCoreProfile = async (userData, wallet, networkStr, DIDKit, prof
         {
           name: 'https://schema.org/name',
           description: 'https://schema.org/description',
-          logo: 'https://schema.org/logo'
+          logo: 'https://schema.org/logo',
+          CoreProfile: 'https://tzprofiles.me/CoreProfile'
         }
       ],
       id: 'urn:uuid:' + uuid(),
@@ -29,31 +31,30 @@ export const signCoreProfile = async (userData, wallet, networkStr, DIDKit, prof
 
     let credentialString = JSON.stringify(credential);
     const proofOptions = {
-      verificationMethod: did + '#blockchainAccountId',
+      verificationMethod: did + '#TezosMethod2021',
       proofPurpose: 'assertionMethod',
     };
 
-    const keyType = {
-      kty: 'OKP',
-      crv: 'Ed25519',
-      x: 'Y-JndzKMXwcbIY9h0snDhFQZG0Weci9zfXHgeZTaMjo',
-      d: 'tJ3uEI9_ymV3Yxk77ZKGcSOFO06j379ql8ZXJEuh6eM',
-    };
-
+    const publicKey = userData.account.publicKey;
+    const publicKeyJwkString = await DIDKit.JWKFromTezos(publicKey);
     let prepStr = await DIDKit.prepareIssueCredential(
       credentialString,
       JSON.stringify(proofOptions),
-      JSON.stringify(keyType)
+      publicKeyJwkString
     );
+    const preparation = JSON.parse(prepStr);
+    const {signingInput} = preparation;
+    const micheline = signingInput && signingInput.micheline;
+    if (!micheline) {
+      throw new Error('Expected micheline signing input');
+    }
 
-    const fmtInput = [
-      'Tezos Signed Message: ',
-      dappUrl,
-      new Date().toISOString(),
-      prepStr,
-    ].join(' ');
-
-    const signature = await signClaim(userData, fmtInput, wallet);
+    const payload: RequestSignPayloadInput = {
+      signingType: SigningType.MICHELINE,
+      payload: micheline,
+      sourceAddress: userData.account.address,
+    };
+    const { signature } = await wallet.client.requestSignPayload(payload);
 
     let vcStr = await DIDKit.completeIssueCredential(
       credentialString,
@@ -61,6 +62,16 @@ export const signCoreProfile = async (userData, wallet, networkStr, DIDKit, prof
       signature
     );
 
+    const verifyOptionsString = '{}';
+    const verifyResult = JSON.parse(await DIDKit.verifyCredential(
+      vcStr,
+      verifyOptionsString
+    ));
+    if (verifyResult.errors.length > 0) {
+      throw new Error("Unable to verify credential: " + verifyResult);
+    }
+
+    console.log(vcStr);
     return vcStr;
   } catch (e) {
     alert.set({
-- 
2.30.2

Example

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    {
      "logo": "https://schema.org/logo",
      "CoreProfile": "https://tzprofiles.me/CoreProfile",
      "name": "https://schema.org/name",
      "description": "https://schema.org/description"
    }
  ],
  "id": "urn:uuid:5fdb183c-5104-4412-a401-589fa17afe0e",
  "type": [
    "VerifiableCredential",
    "CoreProfile"
  ],
  "credentialSubject": {
    "id": "did:pkh:tz:tz1TwZZZSShtM73oEr74aDtDcns3UmFqaca6",
    "name": "asddasasd",
    "logo": "daadsdasdasddadasasddasads",
    "description": "dasadsadsadsasddas"
  },
  "issuer": "did:pkh:tz:tz1TwZZZSShtM73oEr74aDtDcns3UmFqaca6",
  "issuanceDate": "2021-04-16T21:50:04.926Z",
  "proof": {
    "@context": {
      "TezosMethod2021": "https://w3id.org/security#TezosMethod2021",
      "TezosSignature2021": {
        "@context": {
          "@protected": true,
          "@version": 1.1,
          "challenge": "https://w3id.org/security#challenge",
          "created": {
            "@id": "http://purl.org/dc/terms/created",
            "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
          },
          "domain": "https://w3id.org/security#domain",
          "expires": {
            "@id": "https://w3id.org/security#expiration",
            "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
          },
          "id": "@id",
          "nonce": "https://w3id.org/security#nonce",
          "proofPurpose": {
            "@context": {
              "@protected": true,
              "@version": 1.1,
              "assertionMethod": {
                "@container": "@set",
                "@id": "https://w3id.org/security#assertionMethod",
                "@type": "@id"
              },
              "authentication": {
                "@container": "@set",
                "@id": "https://w3id.org/security#authenticationMethod",
                "@type": "@id"
              },
              "id": "@id",
              "type": "@type"
            },
            "@id": "https://w3id.org/security#proofPurpose",
            "@type": "@vocab"
          },
          "proofValue": "https://w3id.org/security#proofValue",
          "publicKeyJwk": {
            "@id": "https://w3id.org/security#publicKeyJwk",
            "@type": "@json"
          },
          "type": "@type",
          "verificationMethod": {
            "@id": "https://w3id.org/security#verificationMethod",
            "@type": "@id"
          }
        },
        "@id": "https://w3id.org/security#TezosSignature2021"
      }
    },
    "type": "TezosSignature2021",
    "proofPurpose": "assertionMethod",
    "proofValue": "edsigtvAYxTbboKeM3PbgeH48diZk4DUwV7bCSHiNcurAUBrxZE9wpMowrREvMHJhv1SYQ6ckpFGCCCXhuf2D3QqfQnnqJzkpAg",
    "verificationMethod": "did:pkh:tz:tz1TwZZZSShtM73oEr74aDtDcns3UmFqaca6#TezosMethod2021",
    "created": "2021-04-16T21:50:04.932Z",
    "publicKeyJwk": {
      "alg": "EdDSA",
      "crv": "Ed25519",
      "kty": "OKP",
      "x": "rVEB0Icbomw1Ir-ck52iCZl1SICc5lCg2pxI8AmydDw"
    }
  }
}

https://github.com/multiformats/multihash

This could help add flexibility to users.

People who run the API service should have the option to cache results from TZKT/BCD and also Kepler for faster second loads.

Acceptance criteria:

• As an API service runner, I should be able to cache results in memory after requests are made.
• As an API service runner, I should be able to configure TTL of cache results.

Future work would include proactive caching strategies such as listening with webhooks for deployments and changes to tzProfiles.

Created directly from @sbihel's note.

Clarification and Motivation

At the moment in it's alpha state, Tezos Profiles serves the purpose of quickly enabling users to collect their first credentials based on public information. However, as it scales to include additional credentials, the interface is going to need to change in order to better serve users.

Some of the major changes include separating the page detailing available credentials and the existing profile, and also creating a better experience for those viewing existing profiles.

However, the one item that will remain the same in this initial reskin is how the workflows are conducted (e.g. Twitter) where it's an individual page detailing each step of the process until a verification criteria is met.

Acceptance Criteria

As a user:

• I can connect my wallet and see a list of available credentials with relevant associated information.
• I can view my existing credentials on a separate page, which includes some activity from the Tezos blockchain.
• I can delete any existing social media credentials from the interface and have them reappear as available credentials that can be re-issued.
• I can edit my basic profile information by batching the deletion of the previous credential and transaction for updating said credential.
• I can view what credentials have or haven't been added to my profile on-chain (based on what's still in local storage and has to be included in a transaction).
• Optional not priority: I can customize my profile (viewer) to show or hide existing credentials.

As a viewer:

• I can see existing profiles with their relevant information, but also see a template profile with information about an address if that user hasn't launched a profile

As a User, I want to be able to see a profile within 250 ms of second page load, preferably upon the first page load as well.

Currently, some profiles take several seconds to load, which could be improved with a cache. This is due to the decentralized nature of the dApp and several calls to the BCD indexer and Kepler. Because the tzprofiles.com domain is already being trusted by the user, could we use our own API and cache the results for much better and consistent performance?

For example, this profile takes 8 seconds to load completely:

I created Basic Profile Information and Twitter Account Verification

Then I clicked Deploy Profile
Signed (twice) with Kukai Wallet (tried also with Temple Wallet)
and then I got this error:
Failed to create orbit: Unauthorized

that looks like this:

browsers: Brave and Chrome
feature, bug? ;)

Clarification and Motivation

Since reskinning Tezos Profiles, we've optimized for traditional web users who've generally been the vast majority of Tezos Profiles owners but need to ensure we also have functionality for mobile if users wish to complete their workflows on their phone.

Acceptance Criteria

As a user:

• I can use a mobile phone and successfully complete verifications using the service (using a mobile wallet with signing support)

With the depreciation of Delphinet, and the migration to Florencenet since passing (currently in the adoption period) - it is critical that we have support for Florencenet in Tezos Profiles. We can keep Edonet for now until all services have migrated.

The latest beta version of Taquito should have support for Florencenet already baked in.

Dear team,
it often happens that people have multiple wallets. e.g. hot wallet, kukai twitter account and ledger cold storage. They switch tokens like NFTs from one to the other and use them for different investment purposes. In the end you need to do some reporting and if you want to connect the information the one doing it needs to store that meta information. It would be great to have this as on chain data for a service to request: "authorize to access all associated addresses"

What do you think?

Best regards
Carlo

The credential is initialized here:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://schema.org/",
    {
      "TwitterVerification": {},
      "TwitterVerificationPublicTweet": {}
    }
  ],
  "id": "urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046",
  "type": [
    "VerifiableCredential",
    "TwitterVerification"
  ],
  "credentialSubject": {
    "id": "did:pkh:tz:example",
    "sameAs": "https://twitter.com/example"
  },
  "issuer": "did:web:tzprofiles.me",
  "evidence": {
    "type": "TwitterVerificationPublicTweet",
    "handle": "example",
    "timestamp": 1619642577000,
    "tweetId": "1234567890"
  }
}

Putting that through JSON-LD Playground results in the following N-Quads:

<did:pkh:tz:example> <http://schema.org/sameAs> <https://twitter.com/example> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/TwitterVerification> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <https://www.w3.org/2018/credentials#credentialSubject> <did:pkh:tz:example> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <https://www.w3.org/2018/credentials#evidence> _:b0 .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <https://www.w3.org/2018/credentials#issuer> <did:web:tzprofiles.me> .
_:b0 <http://schema.org/handle> "example" .
_:b0 <http://schema.org/timestamp> "1619642577000"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:b0 <http://schema.org/tweetId> "1234567890" .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/TwitterVerificationPublicTweet> .

Table view:

This shows several URIs under schema.org, such as http://schema.org/tweetId, which are not meaningful.
These occur because the schema.org JSON-LD context file sets @vocab ("default vocabulary) which means undefined terms automatically get prefixed. This is good for preserving information which would otherwise not be included in the signing input, and maybe other reasons, but its use here results in bad URIs (404s on schema.org, unclear semantics) which could reduce interoperability. For this reason I would recommend not using "https://schema.org/" in context arrays, unless you are sure of the effect.

Removing https://schema.org/ from the credential's context results in an error because the terms previously defined become undefined. The only one we are using that comes from schema.org is sameAs. That term can be defined on its own:

"sameAs": "http://schema.org/sameAs"

Next there are the new Twitter verification related terms. We should decide what these terms will expand to. The way schema.org does it is to basically give each term its own page. Other namespaces have a single main URI under which the terms use fragments. These don't have to be resolvable as JSON-LD files for verification, but they should be, and they should also work as web pages so that people can look at them and reference them. I will assume below that we would use separate pages under tzprofiles.com. For examples of JSON-LD context files you can find several in ssi: https://github.com/spruceid/ssi/tree/main/contexts/
The terms needing definition are TwitterVerification, TwitterVerificationPublicTweet, handle, timestamp, tweetId. A simple way to proceed would be to define all these:

      "TwitterVerification":  "https://tzprofiles.com/TwitterVerification",
      "TwitterVerificationPublicTweet":  "https://tzprofiles.com/TwitterVerificationPublicTweet",
      "handle": "https://tzprofiles.com/handle",
      "timestamp": "https://tzprofiles.com/timestamp",
      "tweetId": "https://tzprofiles.com/tweetId"

This may be improved by changing timestamp to be an XML Datetime string which is a more common way to represent a timestamp in JSON-LD:

      "timestamp": {
        "@id": "https://tzprofiles.com/timestamp",
        "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
      }

But I'm not sure if that interferes with other usage that may require the timestamp to be an number.
Another improvement would be to scope the term definitions by the type. e.g. define handle, timestamp and tweetId under TwitterVerificationPublicTweet:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    {
      "sameAs": "http://schema.org/sameAs",
      "TwitterVerification": "https://tzprofiles.com/TwitterVerification",
      "TwitterVerificationPublicTweet": {
        "@id": "https://tzprofiles.com/TwitterVerificationPublicTweet",
        "@context": {
          "@version": 1.1,
          "@protected": true,
          "handle": "https://tzprofiles.com/handle",
          "timestamp": {
            "@id": "https://tzprofiles.com/timestamp",
            "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
          },
          "tweetId": "https://tzprofiles.com/tweetId"
        }
      }
    }
  ],
  "id": "urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046",
  "type": [
    "VerifiableCredential",
    "TwitterVerification"
  ],
  "credentialSubject": {
    "id": "did:pkh:tz:example",
    "sameAs": "https://twitter.com/example"
  },
  "issuer": "did:web:tzprofiles.me",
  "evidence": {
    "type": "TwitterVerificationPublicTweet",
    "handle": "example",
    "timestamp": "2021-04-28T21:13:07Z",
    "tweetId": "1234567890"
  }
}

There may be better semantics possible for these terms; I'm not sure.

Resulting N-Quads:

<did:pkh:tz:example> <http://schema.org/sameAs> "https://twitter.com/example" .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://tzprofiles.com/TwitterVerification> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <https://www.w3.org/2018/credentials#credentialSubject> <did:pkh:tz:example> .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <https://www.w3.org/2018/credentials#evidence> _:b0 .
<urn:uuid:04d65b86-e5ae-497f-aeff-ba7a3c0ac046> <https://www.w3.org/2018/credentials#issuer> <did:web:tzprofiles.me> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://tzprofiles.com/TwitterVerificationPublicTweet> .
_:b0 <https://tzprofiles.com/handle> "example" .
_:b0 <https://tzprofiles.com/timestamp> "2021-04-28T21:13:07Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
_:b0 <https://tzprofiles.com/tweetId> "1234567890" .

Table view:

When adding additional claims, especially private claims, users do not necessarily want to pay gas costs or reveal a public tx. How could we specify an additional orbit to list query for a claims listing, perhaps protected using Kepler authn? This way, the user can add another claim without any public tx. However, this has the disadvantage of reducing the chain-anchored data integrity (content URL and Hash), and creates a dependency on the data storage as opposed to URL scheme agnosticism (right now, it can be https:// or kepler:// or anything the user wants that tzprofiles-sdk can interpret.

Perhaps this is a new field in the smart contract storage. Top level or metadata? Maybe a different type of claim in the list?

("kepler://<orbit-id>", "<orbit-id>", "KeplerOrbit")

cc @chunningham @sbihel

Clarification and Motivation

As Tezos Profiles grows, it's going to need additional public account credentials to build a stronger foundation for a user's identity. In order to bolster these efforts, we must continue to introduce additional verifications on the platform, starting with a number of social profile verifications.

With a large number of members of the Tezos ecosystem chatting on Telegram, it's important to include Telegram as a social account credential that one could add to their profile.

Acceptance Criteria

As a user:

• I can connect my wallet to Tezos Profiles and view available credentials
• I can obtain a Telegram credential through Tezos Profiles by:
  • Entering my Telegram handle
  • Signing a message containing my handle and additional information
  • Sending this message to a telegram bot through a redirect link
  • Verifying that the correct message was sent
• I can add this Telegram credential to my existing smart contract if I've already deployed a profile.

const DIDKit = require('../../../didkit/lib/node');

Eventually maybe we will have a hybrid Neon/WASM DIDKit package so the CLI can run in a browser ;)

Clarification and Motivation

Tezos Profiles currently supports tz1 addresses but lacks support for tz2. Many new users in the ecosystem will likely be going through Kukai's DirectAuth offering which generates a tz2 address, and we should ensure that those users are able to generate Tezos Profiles.

Acceptance Criteria

As a user:

• I can use Tezos Profiles with a tz2 address
• I can obtain the various credentials offered by Tezos Profiles
• I can sign and store those credentials in Kepler
• I can launch a new Tezos Profiles smart contract
• I can add credentials to my Tezos Profiles smart contract

When selecting the "localhost" option on the dapp connect wallet screen, the temple wallet tries to connect via mainnet, rather than sandboxnet. Other networks still work fine.

Clarification and Motivation

As Tezos Profiles grows, it's important to have a mix of social accounts and publicly available information for a user to associate with their public key. Outside of social accounts, proving web domain ownership is available through a number of methods. 

Additionally, if we wanted to see if a user was the owner of a traditional web domain to not only prove ownership but demonstrate it alongside ownership of a Tezos Domain, they should be able to, and receive a relevant credential that they can demonstrate.

Acceptance Criteria

As a user:

• I can connect my wallet to Tezos Profiles and view available credentials
• I can obtain a Web Domain credential by doing the following:
  • Entering my owned web domain
  • Sign a message using my Tezos wallet
  • Receive a string to add to a TXT record through my domain registrar
  • Wait for the verification (which might take time - and the service informs me of this)
  • Be able to retry in the case of retrieval failure
• I can add this web domain credential to my existing smart contract if I've already deployed a profile.

Expected Behavior

• User clicks to connect their wallet
• Beacon prompts user to select a wallet
• User cancels request
• Splash page retains connect wallet menu item

Actual Behavior

• User clicks to connect their wallet
• Beacon prompts user to select a wallet
• User cancels request
• Menu item state is disconnect and a user has to press it before being able to reconnect

Ive tried so many times to validate all my information but it always "Awaiting Upload " status... can you please assist me with this issue?

Applies to 93f0b81.

• publicKey → verificationMethod.
• owner → controller.
• Fix structure of value in authentication.
• Add assertionMethod verification relationship (for issuing verifiable credentials).
• Update DID in Twitter Credential.

commit 6c380c23ed555c6b12cbdbcfd712601b24e9853a
Author: Charles E. Lehner <[email protected]>
Date:   Thu May 6 20:27:58 2021 -0400

    Fix DID document

diff --git a/dapp/public/.well-known/did.json b/dapp/public/.well-known/did.json
index da95861..48a9000 100644
--- a/dapp/public/.well-known/did.json
+++ b/dapp/public/.well-known/did.json
@@ -1,14 +1,12 @@
 {
   "@context": "https://w3id.org/did/v1",
   "id": "did:web:beta.tzprofiles.com",
-  "publicKey": [{
+  "verificationMethod": [{
        "id": "did:web:beta.tzprofiles.com#owner",
        "type": "Ed25519VerificationKey2018",
-       "owner": "did:web:beta.tzprofiles.com",
+       "controller": "did:web:beta.tzprofiles.com",
        "publicKeyJwk": {"kty":"OKP","crv":"Ed25519","x":"h1DQir9DTFOC3Y_MyL-oH5r-YUsM94Mi-vNgQCpxKww"}
   }],
-  "authentication": [{
-       "type": "Ed25519Signature2018",
-       "publicKey": "did:web:beta.tzprofiles.com#owner"
-  }]
+  "authentication": ["did:web:beta.tzprofiles.com#owner"],
+  "assertionMethod": ["did:web:beta.tzprofiles.com#owner"]
 }
diff --git a/worker/src/lib.rs b/worker/src/lib.rs
index f0d5ba6..e4445d4 100644
--- a/worker/src/lib.rs
+++ b/worker/src/lib.rs
@@ -71,7 +71,7 @@ fn build_vc_(pk: &JWK, twitter_handle: &str) -> Result<Credential> {
           "id": format!("did:pkh:tz:{}", &hash_public_key(pk)?),
           "sameAs": "https://twitter.com/".to_string() + twitter_handle
       },
-      "issuer": "did:web:beta.tzprofiles.me"
+      "issuer": "did:web:beta.tzprofiles.com"
     }))?)
 }
 

Description

Encountered issues with an ill-formed type and an unexpected annotation in a Tezos smart contract, which is causing a server error (500) when attempting to deploy or interact with the contract.

Error Details

• Ill-Formed Type Error: The structure of the storage section in the smart contract does not comply with Michelson language standards. The usage of set, pair, and big_map appears to be incorrectly nested or combined.

• Unexpected Annotation Error: Annotations such as %claims and %contract_type are either misused or placed incorrectly within the code structure.

Log

Http error response: (500) [{"kind":"permanent","id":"proto.018-Proxford.michelson_v1.ill_formed_type","identifier":"storage","ill_formed_expression":[{"prim":"parameter","args":[{"prim":"pair","args":[{"prim":"unit"},{"prim":"pair","args":[{"prim":"pair","args":[{"prim":"set","args":[{"prim":"pair","args":[{"prim":"pair","args":[{"prim":"string"},{"prim":"bytes"}]},{"prim":"string"}]}],"annots":["%claims"]},{"prim":"string","annots":["%contract_type"]}]},{"prim":"pair","args":[{"prim":"big_map","args":[{"prim":"string"},{"prim":"bytes"}],"annots":["%metadata"]},{"prim":"address","annots":["%owner"]}]}]}]}]},{"prim":"storage","args":[{"prim":"option","args":[{"prim":"set","args":[{"prim":"pair","args":[{"prim":"pair","args":[{"prim":"string"},{"prim":"bytes"}]},{"prim":"string"}]}],"annots":["%claims"]}]}]},{"prim":"code","args":[[{"prim":"CAR"},[{"prim":"CDR"},{"prim":"CAR"},{"prim":"CAR"}],{"prim":"SOME"},{"prim":"NIL","args":[{"prim":"operation"}]},{"prim":"PAIR"}]]}],"location":19},{"kind":"permanent","id":"proto.018-Proxford.michelson_v1.unexpected_annotation","location":20}]

At the moment, users are able to deploy their profile after they've verified both core profile information and their Twitter handle. We need to make sure that any user can verify any amount of information they wish to about themselves, and enable deployment even with a single verification.

This issue depends on an updated UI - especially as we continue to add additional verifications and enable users to crawl available verifications.

After signing Basic Info, users should be directed back to the main page.

Currently, they can click "Complete Verification" again and sign another credential, which is a confusing workflow if they already signed it, with the little back arrow difficult to find. Perhaps change the button to "Return to Profile" after the credential is signed.

Furthermore, "Complete Verification" is inaccurate naming because they are not verifying anything, they are just signing the information. "Sign Data" might be a better action here.

As per: https://gitlab.com/tzip/tzip/-/blob/450e59b30ae92deeeb4b4c84bff20e9b05bc8a39/proposals/tzip-24/tzip-24.md

We should further add metadata to smart contract deployment describing the TZIP-024 instance as a tzprofile (perhaps under an appropriate TZIP-016 key) so it's easier to query. TZIP-024 may be used for other applications than tzprofiles, so it is important that we define the resolution steps for the tzprofiles explicitly.

Furthermore, the TZIP-024 reference in the interfaces metadata value should ideally reflect a hash of the commit containing the TZIP definition.

This application defines some application-specific JSON-LD terms for the Verifiable Credentials being issued:
https://github.com/spruceid/tzprofiles/blob/a0dcb9d/worker/src/lib.rs#L51-L67
https://github.com/spruceid/tzprofiles/blob/a0dcb9d/dapp/src/basic_profile.ts#L19-L25

• BasicProfile
• TwitterVerification
• TwitterVerificationPublicTweet
  • handle
  • timestamp
  • tweetId

It would be helpful for people trying to understand these verifiable credentials to be able to resolve these IRIs as URLs in a web browser to get some specification/documentation of the IRI and its intended meaning. Currently they are resources directly under tzprofiles.com - but they are not served by this web app. Either the web app should serve them or they should be changed to use a different domain name, e.g. ld.tzprofiles.com. They could also be namespaced by date and/or topic. They could be consolidated under one or more primary resources (pages) using the fragment id to distinguish them (like how security-vocab works), or they could be kept as separate primary resources (like how schema.org works).

Clarification and Motivation

As Tezos Profiles grows, it's going to need additional public account credentials to build a stronger foundation for a user's identity. In order to bolster these efforts, we must continue to introduce additional verifications on the platform, starting with a number of social profile verifications.

With a large number of members of the Tezos ecosystem chatting on Discord, it's important to include Discord as a social account credential that one could add to their profile.

Acceptance Criteria

As a user:

• I can connect my wallet to Tezos Profiles and view available credentials
• I can obtain a Discord credential through Tezos Profiles [tentative] by:
  • Entering my Discord handle
  • Signing a message containing my handle and additional information
  • Sending this message to a Discord bot through a redirect link
  • Verifying that the correct message was sent from the right account
• I can add this Discord credential to my existing smart contract if I've already deployed a profile.

Motivation and Clarification

We need a way for users to delete existing credentials that they may have in order to update them. For example, if a user needs to switch their primary associated Twitter account, or changes their alias, they should be able to delete their credentials and go through the same workflows to add them back to their existing smart contract.

Acceptance Criteria

As a user:

• I can delete any credentials under "My Credentials"
• I can see deleted credentials back under "Available Credentials" to go through the workflows again
• I can go through the credential workflow and send a transaction that updates my existing Tezos Profile.

At the moment notifications on tzprofiles appear by default at the top of the application. When certain verifications require users to scroll down from the top nav, they are unable to see the notifications if they're happening. We need to make sure that notifications are visible no matter where a user is on the page.

Clarification and Motivation

Along with social profile verifications, we should enable users to demonstrate ownership over an Ethereum address (EIP-712) and associate it with their profile. In doing so, you've now created a basic cross-chain link allowing a Tezos account to demonstrate a particular transaction history on another chain by proving that they own a particular account. From here, it can be possible to associate even deeper cross-chain credentials even at the dapp level so long as a user can prove basic ownership over an account.

Acceptance Criteria

As a user:

• I can connect my wallet to Tezos Profiles and view available credentials
• I can obtain an Ethereum Account Controller credential through Tezos Profiles by:
  • Connecting my Ethereum wallet such as MetaMask or TrustWallet
  • Signing an EIP-712 based challenge
  • Verifying completion of the signature
• I can add this Ethereum Account Controller credential to my existing smart contract if I've already deployed a profile

In the network selection the old test network hangzhounet is still displayed and using a local node with Ithacanet does result in a network error

Verify result with error renders the errors array as a string: this results in Error: Unable to verify credential: [object Object]. Fix by joining the array, as done in dapp/src/store.ts, assuming the errors array of the verification result contains strings.

From 14894a1b4f1c9ed592461f120ef001dfd8f73b57 Mon Sep 17 00:00:00 2001
From: "Charles E. Lehner" <[email protected]>
Date: Mon, 24 May 2021 09:39:15 -0400
Subject: [PATCH] Improve rendering verify result errors

---
 dapp/src/basic_profile.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dapp/src/basic_profile.ts b/dapp/src/basic_profile.ts
index ff0d855..d08ba7b 100644
--- a/dapp/src/basic_profile.ts
+++ b/dapp/src/basic_profile.ts
@@ -75,7 +75,7 @@ export const signBasicProfile = async (
       await DIDKit.verifyCredential(vcStr, verifyOptionsString)
     );
     if (verifyResult.errors.length > 0) {
-      const errorMessage = `Unable to verify credential: ${verifyResult}`;
+      const errorMessage = `Unable to verify credential: ${verifyResult.errors.join(', ')}`;
       alert.set({
         message: errorMessage,
         variant: 'error',
-- 
2.30.2

Hello team,

Could you please update the Dapp website to make it possible to deploy tezos profile contract on Hangzhounet ?

Best regards

Clarification and motivation

When users are searching for someone's Tezos profile, they should be able to view profiles based on another user's Tezos domain that resolves to their public key. For example, instead of searching for tz1dE...a1c3, I could simply search for rocco.tez and the relevant public key associated with that domain would be pulled up.

Acceptance Criteria

• As a user, I can search for another user's profile based on their owned Tezos domain.
• As a user, I can see what domains are owned by a particular Tezos Profile

Clarification and Motivation

As Tezos Profiles grows, it's going to need additional public account credentials to build a stronger foundation for a user's identity. In order to bolster these efforts, we must continue to introduce additional verifications on the platform, starting with a number of social profile verifications.

A majority of the users on the platform will likely be artists attempting to verify their identity against their public key in order to prove the authenticity of their created works (and to prevent copy-minting). Next to Twitter, Instagram is another incredibly popular platform for artists and should be included as an available credential.

Acceptance Criteria

As a user:

• I can connect my wallet to Tezos Profiles and view available credentials
• I can obtain an Instagram credential through Tezos Profiles by:
  • Entering my Instagram handle
  • Signing a message containing my handle and additional information
  • Including this message in a comment on an existing post on Instagram
  • Verifying that comment based on the permalink from the Instagram web application
• I can add this Instagram credential to my existing smart contract if I've already deployed a profile.

Clarification and Motivation

At the moment, there's no warning for users that have pending claims that notifies them to either add them to an existing profile or deploy a new profile. We need to ensure that users are aware of the next steps after completing workflows, and guide them towards solidifying those claims.

Acceptance Criteria

As a user:

• After going through a workflow, I am prompted and informed of what I need to do next in order to add my verifications successfully to my profile
• I am warned when I have verifications that are pending, and that warning informs me of what I need to do next in order to add my verifications successfully

Do something similar to what's seen in:

https://tzcomet.io/#/explorer%3Fexplorer-input%3DKT1W4wh1qDc2g22DToaTfnCtALLJ7jHn38Xc

Clarification and Motivation

As a viewer of someone's Tezos Profile, I should be able to view and download the credentials associated with the verifications and attestations made by the Tezos Profile's service about public information.

Acceptance Criteria

As a user:

• I can view someone's Tezos Profile and download and view the credentials associated with their verifications.

In a future iteration of the project we should find a way to compile the /lib/ copy at buildtime rather than checking it in, to minimize risk of drift between the two versions.

Tezos Profiles should support Granadanet if a user wishes to test out functionality using the testnet. At the same time, support for Edonet and Florencenet should be discontinued, as support for both testnets will soon be unavailable.

This change affects both the user's connection and the profile viewer.

For the end user, N-Quads, while technically correct, are very difficult to understand. Users want to know what they're signing, and this makes their experience less certain. Instead, we should provide them the message to be signed if they want, but present to them JSON that is easy to digest. We can use a similar approach as we have with EIP712 signing, where the canonicalized message hash is a field within an otherwise human-readable JSON object.