Managing Identity Verification
Last updated
Last updated
In the Griffin AI network, the verification of identities is a fundamental component ensuring the security and integrity of interactions within the ecosystem. This process uses cryptographic key pairs and is tightly integrated with network activities.
Identity verification within Griffin AI utilizes public and private keys to authenticate and authorize network actions securely. Each participant, upon entering the network, generates a cryptographic key pair. The private key is securely stored and managed by the participant, ensuring it never transmits across the network. Conversely, the public key is registered in the decentralized ID registry, becoming part of the participant's Griffin ID. This public key does not disclose the identity of its holder but enables other network participants to verify the authenticity of actions initiated by the holder.
When a service request, particularly for accessing an AI model, is initiated towards a Service Provider (SP), it is imperative for the SP to authenticate and authorize the request effectively. Here’s how the process unfolds:
Signature Requirement: Every request sent to an SP must be cryptographically signed using the private key of a Signer. This signature ensures that the request originates from an authentic source.
Signature Verification: Upon receiving a request, the SP extracts the Signer's public key embedded in the request and verifies the request’s signature against this key. This step confirms that the request was indeed signed by the holder of the corresponding private key.
Identity Confirmation: After verifying the request signature, the SP consults the Griffin distributed database to retrieve the Root Identity ID associated with the Signer. This Root Identity ID acts as a unique identifier for the user within the network.
Authorization and Access Control: With the verified identity, the SP can then apply any relevant authorization logic. This might include checking if the user holds a specific NFT required for access, or verifying if the user’s account balance covers the service cost. If the criteria are met, the service is provided; otherwise, access is denied.
Balance Adjustment: For services that involve transactional costs, the SP pre-calculates the cost of the request and matches it with the user’s outstanding balance. If sufficient, the balance is reduced accordingly to cover the cost of the executed service.
This procedure applies to all sensitive transactions conducted over the network. For example, SPs sign their responses to inference requests using their private keys. The recipient – whether a user or a CP – can then verify the signature against the SP's public key and confirm the associated Griffin ID. This verification confirms that the response was indeed sent by the designated SP. Combined with a distributed reputation system that evaluates all SPs, this mechanism significantly improves the accountability of SP and trust that users place in these providers. The same applies to other entities offering their services such as CP and AI agents.