Altme's documentation
  • 🧾Introduction
    • 📋What is Self Sovereign Identity ?
    • 🕵️Altme solution suite is made up of 3 components
      • 🗂️Altme Wallet
      • 📇Altme Saas
      • 📇Altme Web3 issuer
    • 🗂️Give an Identity to your crypto wallet
    • 🛠️Technical considerations
  • ☁️Altme Saas
    • Quick start
      • ⬇️Download Altme Wallet from Apple or Google store
      • 📁Get more credentials in your wallet
      • 🔒Connect to the Altme Saas platform to setup a SSI verifier
      • 📲Integration in your app
    • Beacon integration
      • 🖥️Overview
      • 🏅Verify the age of your users (+13, +18) in a dApp
      • 📲Receive the Verifier data with a webhook in your backend
      • 🪙On-chain and off-chain access with TezID
      • 💾Verify other data with other credentials
      • 📇Issue a Welcome card in a dApp
      • ✅Check user data of your Issuer (no code)
      • ✅Check user data of your Issuer with a webhook
      • 🕵️Under the hood : the process flow of a Beacon Verifier
    • OpenID integration
      • 🖥️Overview
      • 1️Example 1 with an “implicit flow” with no code
      • 1️Example 1 with an “authorization code flow” in Python
    • EBSII integration
  • 🗂️Alme Wallet
    • Protocols overview
      • 🔑Collecting a verifiable credential
      • 🔑Requesting a verifiable presentation
    • Credential offer protocol
      • 🧘‍♀️Motivation
      • 📖Issuer implementation
    • 🖥️Credential manifest of the credential offer protocol
    • 💰Wallet rendering
      • 📝Input descriptors
    • Presentation request query types
      • 🧘‍♀️Motivation
      • 📖Verifier implementation
      • 🔐DIDAuth
      • QueryByExample
      • QBE Examples
    • ✅Issuers and Verifiers return codes accepted by wal
    • 🔗Universal link
      • 🖥️Access from a desktop viewer
      • 📱Access from smartphone viewer
  • *️Others
    • 📂Flow between wallet, dApp and Verifier
      • 📱Hybrid dApp onboards a user with VCs
      • 📱dApp onboards a user with VCs
      • 📱dApp adds a user in whitelist
    • 📍Indices and tables
      • 📁Index
      • 🔍Search
    • 👨‍💻Show source
Powered by GitBook
On this page
  1. Alme Wallet
  2. Presentation request query types

DIDAuth

PreviousVerifier implementationNextQueryByExample

Last updated 2 years ago

If Query.type = “DIDAuth” , then it is a basic authentication request that does not include a verifiable credential : there is no selection of credential to propose to the user, call the function didkit.DIDAuth(did, “{“ challenge ”:“ …. ”,“ domain ”:“ ….. ”}”, key) which will create an empty presentation used only for authentication. The presentation passed with the POST request will look like this:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "type": "VerifiablePresentation",
  "proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2021-08-28T16:13:23.740Z",
    "challenge": "d602e96d-08cb-11ec-a6fa-8d5c53eaebfb",
    "domain": "talao.co",
    "jws" : "eyJhbGciOiJFUzI1NksiLCJjcml0IjpbImI2NCJdLCJiNjQiOmZhbHNlfQ..PgpEElB1tvcY9tdzK6EDKLvysj3vcH-zg5EIiGpk_q4m0NrAmjA81B7QdVvKllSzzfKw-1oTJuu4b4ihCvMXRwA"
  },
  "holder": "did:ethr:0xee09654eedaa79429f8d216fa51a129db0f72250"
}

If Query.type =”QueryByExample “then it will take the user selects credentials in a list constituted according to the criteria specified in “credentialQuery.example”. Then it will be necessary to call the didkit.issuePresentation (…) function as what is currently done (there is no change in the function call).

Refer to for more information.

🗂️
🔐
https://w3c-ccg.github.io/vp-request-spec/#query-by-example