🛠️Technical considerations

Decentralized IDentifiers (DIDs), private keys and derivation path

For Altme Wallet we have chosen to use the DID method did:key for practical reasons.

It is a DID method which has numerous libraries. Other DID methods can be used, but it seems to us, on the other hand, that it is preferable to be relatively far from the DID methods which are deduced from the blockchains and which could leave the opportunity to confuse the private key of an identity with that of an account used for a transaction.

A description of the did key method is available here : https://w3c-ccg.github.io/did-method-key

Altme Wallet can also support : did:ebsi, did:tz; did:pkh; did:sol; did:ion, did:eth, did:web.

For private keys it seems to us for example extremely dangerous to use by simplification the same private key of a blockchain address to support a decentralized identity.

The obvious risk is to eventually have an immediate correlation between an identity document issued for a user DID and blockchain transactions.

For this, the choice we have made is to derive the private key(s) of our identity with a specific path different from that used for the crypto wallets. Currently we use the derivation m/44’/5467’/0’/0 for the generation of identity keys which avoids any collision with that used for Tezos wallets m/44’/1729’/0’/0 or Metamask m/44’/60’/0’/0 while keeping the same passphrase. Altme is registered on the BIP44 registry list for the path “5467” : https://github.com/satoshilabs/slips/blob/master/slip-0044.md

Altme Wallet and Altme Web3 Issuer support Ed25519, Secp256k1, P-256 and RSA keys.

The proof of blockchain address ownership

It is a verifiable credential which is issued by the “crypto account” of the wallet itself and whose subject is the identity (DID) carried by the wallet. Once presented to a verifier, it is a credential that has the signature of the two private keys.

This credential is one of the most important of the universal wallet because it makes it possible to establish in a peer to peer mode a link between the DID and the addresses of the transactions while guaranteeing the maximum protection of the user’s identity. For instance if you want to prove that the owner of a blockchain address is over 18 years old, you will need to transfer 2 verifiable credentials to the verifier: the first proving the link between the user’s DID and the age attribute (over 18), the second proving that the DID is the owner of the blockchain address.

For this very specific verifiable credential we use the DID method did:pkh perfectly fitted for DIDs associated to crypto addresses : cf https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md

{
    "@context": [
          "https://www.w3.org/2018/credentials/v1",
              {
                      "TezosAssociatedAddress" : {
                              "@id" : "https://github.com/TalaoDAO/context#tezosassociatedaddress",
                              "@context" : {
                                      "@version": 1.1,
                                      "@protected": true,
                                      "id": "@id",
                                      "type": "@type",
                                      "accountName" :  "https://github.com/TalaoDAO/context#accountname",
                                      "associatedAddress" : "https://w3id.org/security#blockchainAccountId",
                                      "issuedBy": {
                                              "@id": "https://schema.org/issuedBy",
                                              "@context": {
                                                      "@version": 1.1,
                                                      "@protected": true,
                                                      "name" :  "https://schema.org/name"
                                              }
                                      }
                      }
                }
              }
      ],
      "id" : "urn:uuid:4cd16825-5872-43e5-8a56-7a2c5d5cb2f7",
      "type": [
              "VerifiableCredential",
              "TezosAssociatedAddress"
      ],
      "issuer" : "did:pkh:tz:tz1YtKsJMx5FqhULTDzNxs9r9QYHBGsmz58o",
      "credentialSubject" : {
      "id" : "did:key:zQ3sheeB1CHmCzYWxW13opsYv9AiS4atUAwfwzFoM2gRpifPb",
      "type" : "TezosAssociatedAddress",
              "associatedAddress" : "tz1YtKsJMx5FqhULTDzNxs9r9QYHBGsmz58o",
              "accountName" : "Account 1",
              "issuedBy" : {
                "name" : "My wallet"
          }
      }
 }

Example of a proof of blockchain account ownership verifiable credentials with did:pkh:tz as the DID method of the crypto wallet for a Tezos account (JSON-LD format

Wallet rendering of blockchain account proofs of ownership in Altme Wallet

Web3 verifiers and on-chain integration with anonymous whitelist

The Verifier is the module of an application or a standalone application whose purpose is to verify the correctness and origin of a user’s verifiable identifiers/verifiable presentations.

In an SSI environment for Web2 applications, the user carries their data in their wallet. At each onboarding he is able to present his credentials.

In a Web3 environment, the question of data persistence arises for asynchronous actions such as an NFT drop or an ICO conditioned by specific conditions (age, location, …). Verifiable credentials are inherently off-chain because they protect user data and regulations in many countries now include the right to be forgotten. It is therefore not possible to have an on-chain copy of a verifiable credential. In this case it is necessary to keep on-chain a list of addresses that have presented themselves beforehand, sometimes several weeks before the action.

The choice we have made is to use anonymous whitelists created at application startup. The whitelists are generated by a smart contract which makes it possible to create whitelists adapted to each use case and then to add the blockchain addresses of the users of the service. It is created at the same time as the verifier. It must be able to be consulted by a smart contract of the application.

Of course, the whitelist identifier must remain insignificant to avoid any correlation between a user’s blockchain address and one or more attributes of his identity.

The verifier pays the transaction fee and the DID of the verifier must be known to the smart contract to validate the forwarding address.

Web3 verifiers and on-chain integration with Soulbound token (SBTs)

This is an experimental feature currently in test on Tezos Ghostnet and Fantom Tesnet.

An SBT is minted when a credential is issued for a specific address. Smart contracts can then check the token and the user can see the token in his Altme Wallet and other crypto wallets.

For obvious privacy reasons, no personal data is stored on-chain and on IPFS.

Features

WALLET :

IOS and ANDROID mobile devices
Framework Flutter/Dart for IOS and ANDR09D
Open sources code Apache 2.2 license
3D liveness test and document authetification with Passbase sdk : https://passbase.com/
Age estimation through Yoti Ai engine : https://yoti.world/yoti-age-estimation-dema/
API Google Play integrity and IOS Device check
Live Chat with https://matrix.org

SSI :

VC/VP W3C data model in JSON-LD and JWT format : https://www.w3.org/TR/vc-data-model/
Crypto curves and alg : RSA, Ed25519, secp256k1 and P-256
DID core https://www.w3.org/TR/did-core/ with did:key, did:ebsi, did:tz; did:pkh; did:ion, did:eth, did:web
Signature scheme : RSASignature2018, Ed25519VerificationKeys, EcdsaSecp256k1Signature2019,EcdsaSecp256r1Signature2019, EcdsaSecp256k1RecoverySignature2020, Eip712Signature2021, SolanaSignature2021, JsonWebSignature2020
Data exchange protocols supported
- SiopV2 : https://openid.net/specs/openid-connect-self-issued-v2-1_0.html
- OIDC4VCI : https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
- Verifiable Presentation Request with QueryByExample and DID Auth https://w3c-ccg.github.io/vp-request-spec/
- Presentation Exchange (PEX) : https://identity.foundation/presentation-exchange/ -
- Credential manifest with wallet rendering https://identity.foundation/wallet-rendering/
Stack DIDKit from SpruceId https://www.spruceid.dev/didkit/didkit
EBSI Conformant wallet

Crypto :

Tezos blockchain, Mainnet and Ghostnet https://tezos.com/
Ethereum Mainnet https://ethereum.foundation/
Polygon Mainnet https://polygon.technology/
Fantom Mainet https://fantom.foundation/
Binance https://www.binance.com/en/bnb
Web3 provider Infura
TzKT indexer for Tezos = Moralis API for EVMs
TezID for whitelisting on Tezos with smart contract entry points and Off chain APIs : https://tezid.net/
Beacon for Tezos blockchain https://docs.walletbeacon.io/
WalletConnect 1.7.x fpr EVM chains https://walletconnect.com/

PreviousGive an Identity to your crypto wallet NextAltme Saas

Last updated 1 year ago