No credential to lose
There is no password to hash, no reset link to send and no contact detail to confirm, because a sign-in is approved on a device the person already trusts rather than typed into a form.
CorePass Connector
CorePass Connector gives your application a passwordless login built on OAuth 2.0: a person signs in by scanning a QR code with an application they already carry, and your servers store no password, no email address and no phone number. The same integration requests verified identity data, approved field by field on the person's own phone before any of it reaches you.
Sign in
Scan with CorePass
Or tap the link on a phone. The approval happens in the application, and your page never sees a credential.
Quickstart
Nothing here is a sketch: every snippet below is the code the integration actually ships with, and the only thing standing between an empty project and a working sign-in is a client CorePass issues you. Verified identity data is the same integration, one call further on.
CorePass issues the client your application authenticates with and registers the redirect URI it comes back to. Everything else lives in your own environment, so there is nothing to configure on the page a person actually sees.
# The credentials CorePass issues for your client, in your own environment.
COREPASS_GATEWAY=https://auth-develop.corepassdev.eu
COREPASS_CLIENT_ID=<your client id>
COREPASS_CLIENT_SECRET=<your client secret>
COREPASS_REDIRECT_URI=https://your.example/callback
COREPASS_SCOPE="openid offline offline_access" The login page is yours to design; only two elements are fixed. A person on a desktop scans the QR code, a person on a phone taps the link, and login.js polls for the approval and redirects when it arrives.
<!-- The file has to be called login.html, and its sign-up twin register.html. -->
<img alt="{{.link}}" src=" data:image/png;charset=utf-8;base64,{{.qrcode}}" />
<button>
<a class="link" href="{{.link}}"> Login with CorePass </a>
</button>
<form id="login-form" method="POST">
<input type="hidden" name="challenge" value="{{.challenge}}" />
<input type="hidden" name="identifier" value="{{.identifier}}" />
<input type="hidden" name="session" value="{{.session}}" />
</form>
<script src="static/js/login.js"></script> The person returns to your redirect URI with an authorization code. Exchange it with the CorePass app-auth library, and the token you get back carries the person's Core ID — their address in the Core ecosystem, and the identifier you key your own user records on.
GET /callback?code=<authorization code>&state=<your state> HTTP/1.1
Host: your.example The login is now working, and the same Core ID is the key to everything else. Ask the connector which of the fields you care about this person has verified, and you have the answer your onboarding flow needs before it asks them for anything.
curl --request POST \
--url https://auth-develop.corepassdev.eu/api/v1/blockchain/verified \
--header 'Content-Type: application/json' \
--data '{
"user": "ab22b1671b4f7ccc0b16a87514adde84513b6348232e",
"items": ["IDCARD_DOB", "DRIVER_LICENSE_DOCUMENT_NUMBER", "EMAIL"]
}' {
"verifiedItems": ["EMAIL"],
"unVerifiedItems": ["IDCARD_DOB", "DRIVER_LICENSE_DOCUMENT_NUMBER"]
} How it works
Your server is only told the result. The person's credentials never leave the application on their phone, which is what removes the password, the reset flow and the stored contact details from your side of the integration at once. What your application receives is an authorization code, and behind it a token naming the person by their Core ID.
Your login page
shows the QR code and the mobile link the connector generated for this session.
The CorePass app
scans it, and the person approves the sign-in on a device only they hold.
The connector
settles the approval and redirects the person back to you with an authorization code.
Your application
exchanges the code for a token carrying the Core ID, and the person is signed in.
The bigger picture
Registration forms, password resets, email confirmation and manual document checks are each a system to build, secure and keep compliant, and each one is a copy of somebody's personal data that your organisation becomes responsible for. CorePass Connector replaces all four with one verified exchange that the person approves on their phone, leaving your application with an identifier and only the fields it asked for.
Verified data
Name the fields your compliance process actually needs — a date of birth, a document number, an address, an email address — and the person sees exactly that list on their phone before approving it. Nothing is uploaded, scanned or typed a second time: the values arrive at the callback you registered, each one carrying the pepper that lets you check it against the registry months later.
curl --request POST \
--url https://auth-develop.corepassdev.eu/api/v1/kyc/qrcode \
--header 'Content-Type: application/json' \
--data '{
"user":"ab72a31c718d343b45e558099ec503087f734433785d",
"items":["DRIVER_LICENSE_DOCUMENT_NUMBER"],
"callback":"https://your.example/kyc/callback",
"statusCallback":"https://your.example/kyc/status",
"expiration":1675946886
}' Verified businesses
A business has no phone of its own, so its members vote, and the data is released only when enough of them approve within a fixed twenty-four hour window. What reaches your endpoint is a signed attestation whose claims carry the values, which means a legal name, a registration number or a director's role cannot be read at all without verifying the signature first.
curl --request POST \
--url https://api-develop.corepassdev.eu/api/v1/kyb/data-requests \
--header 'Authorization: <api key>' \
--header 'Idempotency-Key: 4b7f1c2e9a0d4f83' \
--header 'Content-Type: application/json' \
--data '{
"businessWalletAddress": "cb12…",
"fields": ["BUSINESS_LEGAL_NAME", "BUSINESS_REGISTRATION_NUMBER"],
"optionalFields": ["BUSINESS_VAT_NUMBER"],
"purpose": "Onboarding a business customer for wholesale orders",
"reference": "your-own-id"
}' Value of your data
Every credential an application stores is a credential it has to protect, rotate and eventually explain. CorePass Connector moves that responsibility back to the person it belongs to, and leaves your application holding an identifier, a consent trail and the handful of verified values it was granted.
There is no password to hash, no reset link to send and no contact detail to confirm, because a sign-in is approved on a device the person already trusts rather than typed into a form.
A data request names the fields and nothing else. The person reads that list, approves it on their phone, and the values arrive at the endpoint you registered — with the ones they declined simply absent.
Every field arrives with the pepper that fingerprinted it, so you can ask the Core Blockchain registry later whether a value you still hold is valid, without ever going back to the person.
Enterprise ecosystem
CorePass Connector lets an organisation digitise and automate identity verification while simplifying its KYC and AML obligations, maintaining GDPR compliance and adapting to the jurisdiction it operates in — because the personal data stays with the person, and what your systems hold is a record of what was granted and when. Business disclosure is prepaid in Swiss francs, priced per field, and refunded whenever a request is refused or expires.
Frequently asked questions
The questions below are the ones that come up before an integration starts. Everything after that point is answered in the documentation, and anything neither covers is a short email away.
Yes. A person installs the CorePass application, creates an account and then uses it to sign in anywhere CorePass Connector is integrated, which means the account they create for you is the same one they already use elsewhere. There is nothing for them to remember and nothing for you to reset.
The person's Core ID — their address in the Core ecosystem — and whatever your own application chooses to keep alongside it. There is no password to hash, no email address to confirm and no phone number to hold, because none of those are part of the flow.
The login is four steps and reads in about five minutes: register the client, put the QR snippet in your login page, handle the redirect back, and make your first call. Requesting verified identity data is a second, larger piece of work, because it adds a callback endpoint you have to register and verify.
You name the fields you want, one at a time, from the published vocabulary — a date of birth, a document number, an address, an email address — and the person sees exactly that list on their phone before approving it. Asking for less is both cheaper and far more likely to be approved.
Call the verified-items endpoint before you show anything: it answers with the items the person has verified and the items they have not. If a field your process depends on comes back unverified, tell the person to complete that verification in their CorePass application, because the transfer cannot be started without it.
Every KYC callback carries a Corepass-Signature header — an HMAC-SHA256 over the timestamp and the raw request body, keyed with the webhook secret registered for your domain. KYB deliveries use a separate header and a separate secret, and the values themselves arrive inside an RS256 attestation that you verify against a published key set.
A business has no phone to approve a request, so its members vote and the data is released only when enough of them agree, inside a fixed twenty-four hour window. The values arrive inside a signed attestation rather than beside one, which means there is no way to read a legal name or a registration number without verifying the signature first.
Business field disclosure is prepaid in Swiss francs and priced per field, from registry basics at the lowest tier through documents and screening at the highest. A request reserves its quote when it is created and spends only the fields that were actually released, so a refusal or an expiry gives the money back. Signature requests are free.
A KYC callback is retried on the intervals your deployment is configured with, and the data is held until the retries are exhausted. A KYB delivery is retried for roughly nine hours, and the release can also be pulled from the API while the payload is retained, so an endpoint that was down during the window is not a lost disclosure.
Documentation
Get started
Start with the login — it is four steps and about five minutes — and add verified data when your onboarding flow is ready for it. If you would rather talk it through first, the people who built the connector answer the mailbox.
Already using CorePass? The CorePass documentation covers the application your users install.