BlockID is a decentralized identity and reputation protocol built on the Internet Computer, enabling users to build and verify their Web3 identity through various on-chain activities. It serves as a trust layer that:
Aggregates user’s on-chain activities across multiple providers (NNS, NFT, Ledger transactions and more…)
Generates a comprehensive trust score based on verified activities
Provides secure identity verification for dApps through Verifiable Credentials
NFT credentials (ICRC-7) for achievement recognition
Enhanced privacy features
Expanded provider network
Advanced validator creation tools
Validator templates marketplace
Cross-project validation sharing
This is an open project, and we greatly welcome contributions from everyone . The source code will be made available in a few days, along with some bridging solutions for projects currently using Motoko that wish to integrate with vc flow.
Hello severin, thank you for your quick response.
Another question (i couldnt find an answer by my own) Can somehing happen to our investment by logging in with our internet identity? i mean do we have to take care WHERE we login… (sure we should but can something happen if we dont) Can our SEED phrase or something else get stolen? There are so many new websites, dapps etc where i always need to log in via my identity… is it safe…? for sure i mean just the login process itself…
II is an identity provider that gives a separate identity for every* place you log in. If you log in at a different place it is not possible to use that login to do anything related to your NNS dapp login
* It is possible to share an identity across a few places, but it is clearly labelled as such in the login screen and the NNS dapp does not participate
heya @Fern.N
do you know about identitykit?
integration of this library can make it easier for you to integrate wallets/signers that support all existing IC signers standards.
Update: BlockID sdk published: Seamless Integration for Your dApp!
We are thrilled to announce the release of our BlockID SDK, designed to make it easier than ever to integrate BlockID into your existing dApp systems. With this SDK, developers can now leverage the power of BlockID’s secure and decentralized identity solutions with just a few lines of code.
Installation
npm install @blockid/sdk
Quick Start
import { BlockID } from '@blockid/sdk';
// Initialize SDK
const blockID = new BlockID({
host: 'https://icp0.io',// Optional, defaults to https://icp0.io
appId: 'your-app-id'// Optional, defaults to 'block-id'
});
// Verify with BlockID, ensure your wallet is connected to your dApp
const result = await blockID.verifyScore({required: 10, principal: 'principal-id'});
console.log('Verification result:', result);
// Verify score with Internet Identity using VC Flow
const result = await blockID.verifyScore({required: 10, principal: 'principal-id', vcFlow: true});
console.log('Verification result:', result);
We will automatically verify it based on your input. Note that if you log in using Internet Identity for your dApp, declare vcFlow: true to seamlessly enable VC Flow.
Create your app on BlockID Dashboard and get your appId. Or use default appId and verify with BlockID.
This looks very cool! Can you give a 1000 foot view of how an app dev would use this to issue their own credential based on something in their canister?
Say I want to issue you a temporary credential that you own an nft but you are verifying it in another site where you have a diff principal. How does that work?
Thank you!
Currently, on the Internet Computer ecosystem, there’s an issue as you mentioned: Internet Identity generates completely different principals for each dApp. Therefore, I’ll break this down into two scenarios:
For users using standard wallets (with a consistent principal, like Oisy, Plug, NFID, etc.):
You’ll need to create a function with a predefined interface (see below). BlockID will call this function via our Remote Provider to verify the principal (for a consistent principal).
module {
public type VerificationResult = {
score : Nat;
message : Text;
isValid : Bool;
};
public type Self = actor {
verify : shared Principal -> async VerificationResult;
}
}
For users using Internet Identity and logging into your dApp:
In this case, the principal in your dApp will differ from the principal in BlockID. Therefore, your dApp will act as the Issuer, and BlockID will act as the Relying Party, with verification happening through the VC Flow.
We also recognize that building an Issuer or Relying Party can be quite complex. Additionally, VC Flow isn’t officially supported in Motoko yet, which is a limitation for projects built on this language. To address this, we’re learning and improving by building Bridge Issuers (built in Rust), similar to what BlockID is doing. This allows dApps to simply provide a public/private function following a standardized interface and return data with the principal generated in their dApp. We’ll handle the rest of the verification process.
I’m also new to Rust, so I’d greatly appreciate feedback and suggestions from experts to improve further!