The Internet Identity Specification
Introduction
This document describes and specifies Internet Identity from various angles and at various levels of abstraction, namely:
High level goals, requirements and use cases.
Overview of the security and identity machinery, including the interplay of identities, keys, and delegations.
Interface as used by client applications frontends, i.e., our client authentication protocol.
The interface of the Internet Identity Service backend, i.e., describing its contract at the Candid layer, as used by its frontend.
Important implementation notes about the Internet Identity Service backend.
The Internet Identity service consists of:
Its backend, a canister on ICP. More precisely, a canister on a dedicated subnet with a well-known canister id, and
its frontend, a web application served by the backend canister.
Similarly, the client applications consist of a frontend (served by a canister) and (typically) one or more backend canisters. Only the frontend interacts with the Internet Identity Service directly (via the client authentication protocol described below).
Goals, requirements and use cases
The Internet Identity service allows users to
maintain identities on the Internet Computer
log in with these identities using one out of a set of security devices
manage their set of security devices
Some functional requirements are
users have separate identities (or "pseudonyms") per client application (more precisely, per client application frontend "hostname", though see Alternative Frontend Origins for caveat about
.raw
domains)these identities are stable, i.e., do not depend on a user's security devices
the client frontends interact with any canister on the Internet Computer under the user's identity with that frontend
users do not need ever to remember secret information (but possibly per-user non-secret information)
a security device does not need to be manually touched upon every interaction with a client application; a login is valid for a certain amount of time per identity
Some security requirements are
The separate identities of a single user cannot be related merely based on their public key or principal ids, to impede user tracking.
The security of the identities does not depend on the privacy of data stored on canisters, or transmitted to and from canisters. In particular, the delegations handed out by the backend canister must not be sensitive information.
(many more, of course; apply common sense)
Some noteworthy security assumptions are:
- The delivery of frontend applications is secure. In particular, a user accessing the Internet Identity Service Frontend through a TLS-secured HTTP connection cannot be tricked into running another web application.
Just for background: At launch this meant we relied on the trustworthiness of the boundary nodes as well as the replica the boundary nodes happens to fetch the assets from. After launch, certification of our HTTP Gateway protocol and trustworthy client-side code (browser extensions, proxies, etc.) have improved this situation.
The security devices only allow the use of their keys from the same web application that created the key (in our case, the Internet Identity Service Frontend).
The user's browser is trustworthy,
postMessage
communication between different origins is authentic.For user privacy, we also assume the Internet Identity Service backend can keep a secret (but since data is replicated, we do not rely on this assumption for other security properties).
Identity design and data model
The Internet Computer serves this frontend under hostnames https://identity.ic0.app
(official) and https://identity.internetcomputer.org
(experimental).
The canister maintains a salt (in the following the salt
), a 32 byte long blob that is obtained via the Internet Computer's source of secure randomness.
Due to replication of data in canisters, the salt should not be considered secret against a determined attacker. However, the canister will not reveal the salt directly and to the extent it is unknown to an attacker it helps maintain privacy of user identities.
A user account is identified by a unique Identity Anchor, a natural number chosen by the canister.
A client application frontend is identified by its origin (e.g., https://abcde-efg.ic0.app
, https://nice-name.com
). Frontend applications can be served by canisters or by websites that are not hosted on the Internet Computer.
A user has a separate user identity for each client application frontend (i.e., per origin). This identity is a self-authenticating id of the DER encoded canister signature public key which has the form
user_id = SHA-224(DER encoded public key) · 0x02` (29 bytes)
and the BIT STRING
field of the DER encoded public key has the form
bit_string = |ii_canister_id| · ii_canister_id · seed
where the seed
is derived as follows
seed = H(|salt| · salt · |user_number| · user_number · |frontend_origin| · frontend_origin)
where H
is SHA-256, ·
is concatenation, |…|
is a single byte representing the length of …
in bytes, user_number
is the ASCII-encoding of the Identity Anchor as a decimal number, and frontend_origin
is the ASCII-encoding of the client application frontend's origin (at most 255 bytes).
A frontend_origin
of the form https://<canister id>.icp0.io
will be rewritten to https://<canister id>.ic0.app
before being used in the seed. This ensures transparent pseudonym transfer between apps hosted on ic0.app
and icp0.io
domains.
When a client application frontend wants to authenticate as a user, it uses a session key (e.g., Ed25519 or ECDSA), and by way of the authentication flow (details below) obtains a delegation chain that allows the session key to sign for the user's main identity.
The delegation chain consists of one delegation, called the client delegation. It delegates from the user identity (for the given client application frontend) to the session key. This delegation is created by the Internet Identity Service Canister, and signed using a canister signature. This delegation is unscoped (valid for all canisters) and has a maximum lifetime of 30 days, with a default of 30 minutes.
The Internet Identity service frontend also manages an identity frontend delegation, delegating from the security device's public key to a session key managed by this frontend, so that it can interact with the backend without having to invoke the security device for each signature.
Client authentication protocol
This section describes the Internet Identity service from the point of view of a client application frontend.
The client application frontend creates a session key pair (e.g., Ed25519).
It installs a
message
event handler on its ownwindow
.It loads the url
https://identity.ic0.app/#authorize
in a separate tab. LetidentityWindow
be theWindow
object returned from this.In the
identityWindow
, the user logs in, and theidentityWindow
invokeswindow.opener.postMessage(msg, "*")
where
msg
isinterface InternetIdentityReady {
kind: "authorize-ready"
}The client application, after receiving the
InternetIdentityReady
, invokesidentityWindow.postMessage(msg, "https://identity.ic0.app")
where
msg
is a value of typeinterface InternetIdentityAuthRequest {
kind: "authorize-client";
sessionPublicKey: Uint8Array;
maxTimeToLive?: bigint;
allowPinAuthentication?: boolean;
derivationOrigin?: string;
autoSelectionPrincipal?: string
}where
the
sessionPublicKey
contains the public key of the session key pair.the
maxTimeToLive
, if present, indicates the desired time span (in nanoseconds) until the requested delegation should expire. The Identity Provider frontend is free to set an earlier expiry time, but should not create a one larger.the
allowPinAuthentication
(EXPERIMENTAL), if present, indicates whether or not the Identity Provider should allow the user to authenticate and/or register using a temporary key/PIN identity. Authenticating dapps may want to prevent users from using Temporary keys/PIN identities because Temporary keys/PIN identities are less secure than Passkeys (webauthn credentials) and because Temporary keys/PIN identities generally only live in a browser database (which may get cleared by the browser/OS).the
derivationOrigin
, if present, indicates an origin that should be used for principal derivation instead of the client origin. Internet Identity will validate thederivationOrigin
by checking that it lists the client application origin in the/.well-known/ii-alternative-origins
file (see Alternative Frontend Origins).the
autoSelectionPrincipal
, if present, indicates the textual representation of this dapp's principal for which the delegation is requested. If it is known to Internet Identity and the corresponding identity has been the most recently used for the client application origin, it will skip the identity selection and immediately prompt for authentication. This feature can be used to streamline re-authentication after a session expiry.
Now the client application window expects a message back, with data
event
.If
event.origin
is not either"https://identity.ic0.app"
or"https://identity.internetcomputer.org"
(depending on which endpoint you are using), ignore this message.The
event.data
value is a JS object with the following type:interface InternetIdentityAuthResponse {
kind: "authorize-client-success";
delegations: [{
delegation: {
pubkey: Uint8Array;
expiration: bigint;
targets?: Principal[];
};
signature: Uint8Array;
}];
userPublicKey: Uint8Array;
authnMethod: "passkey";
}where the
userPublicKey
is the user's Identity on the given frontend anddelegations
corresponds to the CBOR-encoded delegation chain as used for authentication on the IC andauthnMethod
is the method used by the user to authenticate (passkey
for webauthn,pin
for temporary key/PIN identity, andrecovery
for recovery phrase or recovery device).It could also receive a failure message of the following type
interface InternetIdentityAuthResponse {
kind: "authorize-client-failure";
text: string;
}The client application frontend needs to be able to detect when any of the delegations in the chain has expired, and re-authorize the user in that case.
The @dfinity/auth-client
NPM package provides helpful functionality here.
The client application frontend should support delegation chains of length more than one, and delegations with targets
, even if the present version of this spec does not use them, to be compatible with possible future versions.
The Internet Identity frontend will use event.origin
as the "Frontend URL" to base the user identity on. This includes protocol, full hostname and port. This means
- Changing protocol, hostname (including subdomains) or port will invalidate all user identities.
- However, multiple different frontend URLs can be mapped back to the canonical frontend URL, see Alternative Frontend Origins.
- Frontend URLs on
icp0.io
are mapped toic0.app
automatically, see Identity design and data model.
- The frontend application must never allow any untrusted JavaScript code to be executed, on any page on that origin. Be careful when implementing a JavaScript playground on the Internet Computer.
Alternative frontend origins
To allow flexibility regarding the canister frontend URL, the client may choose to provide another URL as the derivationOrigin
(see Client authentication protocol). This means that Internet Identity will issue the same principals to the frontend (which uses a different origin) as it would if it were using the derivationOrigin
directly.
This feature works for canisterId
based URLs and ICP custom domains (backed by canisters) as derivationOrigin
.
This feature is intended to allow more flexibility with respect to the origins of a single service. Do not use this feature to allow third party services to use the same principals. Only add origins you fully control to /.well-known/ii-alternative-origins
and never set origins you do not control as derivationOrigin
!
https://<canister_id>.ic0.app
and https://<canister_id>.raw.ic0.app
do not issue the same principals by default . However, this feature can also be used to map https://<canister_id>.raw.ic0.app
to https://<canister_id>.ic0.app
principals or vice versa.
In order for Internet Identity to accept the derivationOrigin
the origin of the client application must be listed in the JSON object served on the URL https://<canister_id>.icp0.io/.well-known/ii-alternative-origins
(i.e. the file must be hosted by an ICP canister that must implement the http_request
query call as specified here).
JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "II Alternative Origins Principal Derivation Origins",
"description": "An object containing the alternative frontend origins of the given canister, which are allowed to use the URL this document is hosted on for principal derivation.",
"type": "object",
"properties": {
"alternativeOrigins": {
"description": "List of allowed alternative frontend origins",
"type": "array",
"items": {
"type": "string"
},
"minItems": 0,
"maxItems": 10,
"uniqueItems": true
}
},
"required": [ "alternativeOrigins" ]
}
Example
{
"alternativeOrigins": [
"https://alternative-1.com",
"https://www.nice-frontend-name.org"
]
}
The path /.well-known/ii-alternative-origins
will always be requested using the non-raw https://<canister_id>.ic0.app
domain (even if the derivationOrigin
uses a .raw
) and must be delivered as a certified asset. Requests to /.well-known/ii-alternative-origins
must be answered with a 200
HTTP status code. More specifically Internet Identity will not follow redirects and fail with an error instead. These measures are required in order to prevent malicious boundary nodes or replicas from tampering with ii-alternative-origins
.
To prevent misuse of this feature, the number of alternative origins must not be greater than 10.
In order to allow Internet Identity to read the path /.well-known/ii-alternative-origins
, the CORS response header Access-Control-Allow-Origin
must be set and allow the Internet Identity origin https://identity.ic0.app
.
The Internet Identity Service Backend interface
This section describes the interface that the backend canister provides.
Note that the interface is split into 4 categories:
- Identity management API, i.e. APIs for end-users to manage their identity.
- Legacy API.
- API v2 (experimental, incomplete).
- The aim of the API v2 is to introduce changes that cannot be made without breaking existing clients of the legacy API. While the API v2 has feature parity with the legacy API, the desired changes are not fully implemented yet:
- Methods should return proper results with meaningful errors.
- Adding explicit WebAuthn signatures to security critical operations.
- The aim of the API v2 is to introduce changes that cannot be made without breaking existing clients of the legacy API. While the API v2 has feature parity with the legacy API, the desired changes are not fully implemented yet:
- HTTP gateway protocol, required to serve
https://identity.ic0.app
. - Auth protocol, for creating signed delegations.
- Verifiable credentials protocol, for creating id alias credentials.
- Internal methods, not intended to be called by external clients.
- These are methods related to initialization of II itself and integration with its archive.
The summary is given by the Candid interface:
type UserNumber = nat64;
type PublicKey = blob;
type CredentialId = blob;
type DeviceKey = PublicKey;
type UserKey = PublicKey;
type SessionKey = PublicKey;
type FrontendHostname = text;
type Timestamp = nat64;
type HeaderField = record {
text;
text;
};
type HttpRequest = record {
method: text;
url: text;
headers: vec HeaderField;
body: blob;
certificate_version: opt nat16;
};
type HttpResponse = record {
status_code: nat16;
headers: vec HeaderField;
body: blob;
upgrade : opt bool;
streaming_strategy: opt StreamingStrategy;
};
type StreamingCallbackHttpResponse = record {
body: blob;
token: opt Token;
};
type Token = record {};
type StreamingStrategy = variant {
Callback: record {
callback: func (Token) -> (StreamingCallbackHttpResponse) query;
token: Token;
};
};
type Purpose = variant {
recovery;
authentication;
};
type KeyType = variant {
unknown;
platform;
cross_platform;
seed_phrase;
browser_storage_key;
};
// This describes whether a device is "protected" or not.
// When protected, a device can only be updated or removed if the
// user is authenticated with that very device.
type DeviceProtection = variant {
protected;
unprotected;
};
type Challenge = record {
png_base64: text;
challenge_key: ChallengeKey;
};
type DeviceData = record {
pubkey : DeviceKey;
alias : text;
credential_id : opt CredentialId;
purpose: Purpose;
key_type: KeyType;
protection: DeviceProtection;
origin: opt text;
// Metadata map for additional device information.
//
// Note: some fields above will be moved to the metadata map in the future.
// All field names of `DeviceData` (such as 'alias', 'origin, etc.) are
// reserved and cannot be written.
// In addition, the keys "usage" and "authenticator_attachment" are reserved as well.
metadata: opt MetadataMap;
};
// The same as `DeviceData` but with the `last_usage` field.
// This field cannot be written, hence the separate type.
type DeviceWithUsage = record {
pubkey : DeviceKey;
alias : text;
credential_id : opt CredentialId;
purpose: Purpose;
key_type: KeyType;
protection: DeviceProtection;
origin: opt text;
last_usage: opt Timestamp;
metadata: opt MetadataMap;
};
// Map with some variants for the value type.
// Note, due to the Candid mapping this must be a tuple type thus we cannot name the fields `key` and `value`.
type MetadataMap = vec record {
text;
variant { map : MetadataMap; string : text; bytes : vec nat8 };
};
type RegisterResponse = variant {
// A new user was successfully registered.
registered: record {
user_number: UserNumber;
};
// No more registrations are possible in this instance of the II service canister.
canister_full;
// The challenge was not successful.
bad_challenge;
};
type AddTentativeDeviceResponse = variant {
// The device was tentatively added.
added_tentatively: record {
verification_code: text;
// Expiration date, in nanos since the epoch
device_registration_timeout: Timestamp;
};
// Device registration mode is off, either due to timeout or because it was never enabled.
device_registration_mode_off;
// There is another device already added tentatively
another_device_tentatively_added;
};
type VerifyTentativeDeviceResponse = variant {
// The device was successfully verified.
verified;
// Wrong verification code entered. Retry with correct code.
wrong_code: record {
retries_left: nat8
};
// Device registration mode is off, either due to timeout or because it was never enabled.
device_registration_mode_off;
// There is no tentative device to be verified.
no_device_to_verify;
};
type Delegation = record {
pubkey: PublicKey;
expiration: Timestamp;
targets: opt vec principal;
};
type SignedDelegation = record {
delegation: Delegation;
signature: blob;
};
type GetDelegationResponse = variant {
// The signed delegation was successfully retrieved.
signed_delegation: SignedDelegation;
// The signature is not ready. Maybe retry by calling `prepare_delegation`
no_such_delegation
};
type InternetIdentityStats = record {
users_registered: nat64;
storage_layout_version: nat8;
assigned_user_number_range: record {
nat64;
nat64;
};
archive_info: ArchiveInfo;
canister_creation_cycles_cost: nat64;
// Map from event aggregation to a sorted list of top 100 sub-keys to their weights.
// Example: {"prepare_delegation_count 24h ic0.app": [{"https://dapp.com", 100}, {"https://dapp2.com", 50}]}
event_aggregations: vec record {text; vec record {text; nat64}};
};
// Configuration parameters related to the archive.
type ArchiveConfig = record {
// The allowed module hash of the archive canister.
// Changing this parameter does _not_ deploy the archive, but enable archive deployments with the
// corresponding wasm module.
module_hash : blob;
// Buffered archive entries limit. If reached, II will stop accepting new anchor operations
// until the buffered operations are acknowledged by the archive.
entries_buffer_limit: nat64;
// The maximum number of entries to be transferred to the archive per call.
entries_fetch_limit: nat16;
// Polling interval to fetch new entries from II (in nanoseconds).
// Changes to this parameter will only take effect after an archive deployment.
polling_interval_ns: nat64;
};
// Information about the archive.
type ArchiveInfo = record {
// Canister id of the archive or empty if no archive has been deployed yet.
archive_canister : opt principal;
// Configuration parameters related to the II archive.
archive_config: opt ArchiveConfig;
};
// Rate limit configuration.
// Currently only used for `register`.
type RateLimitConfig = record {
// Time it takes (in ns) for a rate limiting token to be replenished.
time_per_token_ns : nat64;
// How many tokens are at most generated (to accommodate peaks).
max_tokens: nat64;
};
// Init arguments of II which can be supplied on install and upgrade.
// Setting a value to null keeps the previous value.
type InternetIdentityInit = record {
// Set lowest and highest anchor
assigned_user_number_range : opt record {
nat64;
nat64;
};
// Configuration parameters related to the II archive.
// Note: some parameters changes (like the polling interval) will only take effect after an archive deployment.
// See ArchiveConfig for details.
archive_config: opt ArchiveConfig;
// Set the amounts of cycles sent with the create canister message.
// This is configurable because in the staging environment cycles are required.
// The canister creation cost on mainnet is currently 100'000'000'000 cycles. If this value is higher thant the
// canister creation cost, the newly created canister will keep extra cycles.
canister_creation_cycles_cost : opt nat64;
// Rate limit for the `register` call.
register_rate_limit : opt RateLimitConfig;
// Maximum number of inflight captchas.
// Default: 500
max_inflight_captchas: opt nat64;
};
type ChallengeKey = text;
type ChallengeResult = record {
key : ChallengeKey;
chars : text;
};
type CaptchaResult = ChallengeResult;
// Extra information about registration status for new devices
type DeviceRegistrationInfo = record {
// If present, the user has tentatively added a new device. This
// new device needs to be verified (see relevant endpoint) before
// 'expiration'.
tentative_device : opt DeviceData;
// The timestamp at which the anchor will turn off registration mode
// (and the tentative device will be forgotten, if any, and if not verified)
expiration: Timestamp;
};
// Information about the anchor
type IdentityAnchorInfo = record {
// All devices that can authenticate to this anchor
devices : vec DeviceWithUsage;
// Device registration status used when adding devices, see DeviceRegistrationInfo
device_registration: opt DeviceRegistrationInfo;
};
type AnchorCredentials = record {
credentials : vec WebAuthnCredential;
recovery_credentials : vec WebAuthnCredential;
recovery_phrases: vec PublicKey;
};
type WebAuthnCredential = record {
credential_id : CredentialId;
pubkey: PublicKey;
};
type DeployArchiveResult = variant {
// The archive was deployed successfully and the supplied wasm module has been installed. The principal of the archive
// canister is returned.
success: principal;
// Initial archive creation is already in progress.
creation_in_progress;
// Archive deployment failed. An error description is returned.
failed: text;
};
type BufferedArchiveEntry = record {
anchor_number: UserNumber;
timestamp: Timestamp;
sequence_number: nat64;
entry: blob;
};
// API V2 specific types
// WARNING: These type are experimental and may change in the future.
type IdentityNumber = nat64;
// Map with some variants for the value type.
// Note, due to the Candid mapping this must be a tuple type thus we cannot name the fields `key` and `value`.
type MetadataMapV2 = vec record {
text;
variant { Map : MetadataMapV2; String : text; Bytes : vec nat8 };
};
// Authentication method using WebAuthn signatures
// See https://www.w3.org/TR/webauthn-2/
// This is a separate type because WebAuthn requires to also store
// the credential id (in addition to the public key).
type WebAuthn = record {
credential_id: CredentialId;
pubkey: PublicKey;
};
// Authentication method using generic signatures
// See https://internetcomputer.org/docs/current/references/ic-interface-spec/#signatures for
// supported signature schemes.
type PublicKeyAuthn = record {
pubkey: PublicKey;
};
// The authentication methods currently supported by II.
type AuthnMethod = variant {
WebAuthn: WebAuthn;
PubKey: PublicKeyAuthn;
};
// This describes whether an authentication method is "protected" or not.
// When protected, a authentication method can only be updated or removed if the
// user is authenticated with that very authentication method.
type AuthnMethodProtection = variant {
Protected;
Unprotected;
};
type AuthnMethodPurpose = variant {
Recovery;
Authentication;
};
type AuthnMethodSecuritySettings = record {
protection: AuthnMethodProtection;
purpose: AuthnMethodPurpose;
};
type AuthnMethodData = record {
authn_method: AuthnMethod;
security_settings: AuthnMethodSecuritySettings;
// contains the following fields of the DeviceWithUsage type:
// - alias
// - origin
// - authenticator_attachment: data taken from key_type and reduced to "platform", "cross_platform" or absent on migration
// - usage: data taken from key_type and reduced to "recovery_phrase", "browser_storage_key" or absent on migration
// Note: for compatibility reasons with the v1 API, the entries above (if present)
// must be of the `String` variant. This restriction may be lifted in the future.
metadata: MetadataMapV2;
last_authentication: opt Timestamp;
};
// Extra information about registration status for new authentication methods
type AuthnMethodRegistrationInfo = record {
// If present, the user has registered a new authentication method. This
// new authentication needs to be verified before 'expiration' in order to
// be added to the identity.
authn_method : opt AuthnMethodData;
// The timestamp at which the identity will turn off registration mode
// (and the authentication method will be forgotten, if any, and if not verified)
expiration: Timestamp;
};
type AuthnMethodConfirmationCode = record {
confirmation_code: text;
expiration: Timestamp;
};
type AuthnMethodRegisterError = variant {
// Authentication method registration mode is off, either due to timeout or because it was never enabled.
RegistrationModeOff;
// There is another authentication method already registered that needs to be confirmed first.
RegistrationAlreadyInProgress;
// The metadata of the provided authentication method contains invalid entries.
InvalidMetadata: text;
};
type AuthnMethodConfirmationError = variant {
// Wrong confirmation code entered. Retry with correct code.
WrongCode: record {
retries_left: nat8
};
// Authentication method registration mode is off, either due to timeout or because it was never enabled.
RegistrationModeOff;
// There is no registered authentication method to be confirmed.
NoAuthnMethodToConfirm;
};
type IdentityAuthnInfo = record {
authn_methods: vec AuthnMethod;
recovery_authn_methods: vec AuthnMethod;
};
type IdentityInfo = record {
authn_methods: vec AuthnMethodData;
authn_method_registration: opt AuthnMethodRegistrationInfo;
// Authentication method independent metadata
metadata: MetadataMapV2;
};
type IdentityInfoError = variant {
/// The principal is not authorized to call this method with the given arguments.
Unauthorized: principal;
/// Internal canister error. See the error message for details.
InternalCanisterError: text;
};
type IdentityRegisterError = variant {
// No more registrations are possible in this instance of the II service canister.
CanisterFull;
// The captcha check was not successful.
BadCaptcha;
// The metadata of the provided authentication method contains invalid entries.
InvalidMetadata: text;
};
type AuthnMethodAddError = variant {
InvalidMetadata: text;
};
type AuthnMethodReplaceError = variant {
InvalidMetadata: text;
// No authentication method found with the given public key.
AuthnMethodNotFound;
};
type AuthnMethodMetadataReplaceError = variant {
InvalidMetadata: text;
/// No authentication method found with the given public key.
AuthnMethodNotFound;
};
type AuthnMethodSecuritySettingsReplaceError = variant {
/// No authentication method found with the given public key.
AuthnMethodNotFound;
};
type IdentityMetadataReplaceError = variant {
/// The principal is not authorized to call this method with the given arguments.
Unauthorized: principal;
/// The identity including the new metadata exceeds the maximum allowed size.
StorageSpaceExceeded: record {space_available: nat64; space_required: nat64};
/// Internal canister error. See the error message for details.
InternalCanisterError: text;
};
type PrepareIdAliasRequest = record {
/// Origin of the issuer in the attribute sharing flow.
issuer : FrontendHostname;
/// Origin of the relying party in the attribute sharing flow.
relying_party : FrontendHostname;
/// Identity for which the IdAlias should be generated.
identity_number : IdentityNumber;
};
type PrepareIdAliasError = variant {
/// The principal is not authorized to call this method with the given arguments.
Unauthorized: principal;
/// Internal canister error. See the error message for details.
InternalCanisterError: text;
};
/// The prepared id alias contains two (still unsigned) credentials in JWT format,
/// certifying the id alias for the issuer resp. the relying party.
type PreparedIdAlias = record {
rp_id_alias_jwt : text;
issuer_id_alias_jwt : text;
canister_sig_pk_der : PublicKey;
};
/// The request to retrieve the actual signed id alias credentials.
/// The field values should be equal to the values of corresponding
/// fields from the preceding `PrepareIdAliasRequest` and `PrepareIdAliasResponse`.
type GetIdAliasRequest = record {
rp_id_alias_jwt : text;
issuer : FrontendHostname;
issuer_id_alias_jwt : text;
relying_party : FrontendHostname;
identity_number : IdentityNumber;
};
type GetIdAliasError = variant {
/// The principal is not authorized to call this method with the given arguments.
Unauthorized: principal;
/// The credential(s) are not available: may be expired or not prepared yet (call prepare_id_alias to prepare).
NoSuchCredentials : text;
/// Internal canister error. See the error message for details.
InternalCanisterError: text;
};
/// The signed id alias credentials for each involved party.
type IdAliasCredentials = record {
rp_id_alias_credential : SignedIdAlias;
issuer_id_alias_credential : SignedIdAlias;
};
type SignedIdAlias = record {
credential_jws : text;
id_alias : principal;
id_dapp : principal;
};
service : (opt InternetIdentityInit) -> {
// Legacy identity management API
// ==============================
create_challenge : () -> (Challenge);
register : (DeviceData, ChallengeResult, opt principal) -> (RegisterResponse);
add : (UserNumber, DeviceData) -> ();
update : (UserNumber, DeviceKey, DeviceData) -> ();
// Atomically replace device matching the device key with the new device data
replace : (UserNumber, DeviceKey, DeviceData) -> ();
remove : (UserNumber, DeviceKey) -> ();
// Returns all devices of the user (authentication and recovery) but no information about device registrations.
// Note: Clears out the 'alias' fields on the devices. Use 'get_anchor_info' to obtain the full information.
// Deprecated: Use 'get_anchor_credentials' instead.
lookup : (UserNumber) -> (vec DeviceData) query;
get_anchor_credentials : (UserNumber) -> (AnchorCredentials) query;
get_anchor_info : (UserNumber) -> (IdentityAnchorInfo);
get_principal : (UserNumber, FrontendHostname) -> (principal) query;
enter_device_registration_mode : (UserNumber) -> (Timestamp);
exit_device_registration_mode : (UserNumber) -> ();
add_tentative_device : (UserNumber, DeviceData) -> (AddTentativeDeviceResponse);
verify_tentative_device : (UserNumber, verification_code: text) -> (VerifyTentativeDeviceResponse);
// V2 Identity Management API
// ==========================
// WARNING: The following methods are experimental and may change in the future.
// Creates a new captcha. The solution needs to be submitted using the
// `identity_register` call.
captcha_create: () -> (variant {Ok: Challenge; Err;});
// Registers a new identity with the given authn_method.
// A valid captcha solution to a previously generated captcha (using create_captcha) must be provided.
// The sender needs to match the supplied authn_method.
identity_register: (AuthnMethodData, CaptchaResult, opt principal) -> (variant {Ok: IdentityNumber; Err: IdentityRegisterError;});
// Returns information about the authentication methods of the identity with the given number.
// Only returns the minimal information required for authentication without exposing any metadata such as aliases.
identity_authn_info: (IdentityNumber) -> (variant {Ok: IdentityAuthnInfo; Err;}) query;
// Returns information about the identity with the given number.
// Requires authentication.
identity_info: (IdentityNumber) -> (variant {Ok: IdentityInfo; Err: IdentityInfoError;});
// Replaces the authentication method independent metadata map.
// The existing metadata map will be overwritten.
// Requires authentication.
identity_metadata_replace: (IdentityNumber, MetadataMapV2) -> (variant {Ok; Err: IdentityMetadataReplaceError;});
// Adds a new authentication method to the identity.
// Requires authentication.
authn_method_add: (IdentityNumber, AuthnMethodData) -> (variant {Ok; Err: AuthnMethodAddError;});
// Atomically replaces the authentication method matching the supplied public key with the new authentication method
// provided.
// Requires authentication.
authn_method_replace: (IdentityNumber, PublicKey, AuthnMethodData) -> (variant {Ok; Err: AuthnMethodReplaceError;});
// Replaces the authentication method metadata map.
// The existing metadata map will be overwritten.
// Requires authentication.
authn_method_metadata_replace: (IdentityNumber, PublicKey, MetadataMapV2) -> (variant {Ok; Err: AuthnMethodMetadataReplaceError;});
// Replaces the authentication method security settings.
// The existing security settings will be overwritten.
// Requires authentication.
authn_method_security_settings_replace: (IdentityNumber, PublicKey, AuthnMethodSecuritySettings) -> (variant {Ok; Err: AuthnMethodSecuritySettingsReplaceError;});
// Removes the authentication method associated with the public key from the identity.
// Requires authentication.
authn_method_remove: (IdentityNumber, PublicKey) -> (variant {Ok; Err;});
// Enters the authentication method registration mode for the identity.
// In this mode, a new authentication method can be registered, which then needs to be
// confirmed before it can be used for authentication on this identity.
// The registration mode is automatically exited after the returned expiration timestamp.
// Requires authentication.
authn_method_registration_mode_enter : (IdentityNumber) -> (variant {Ok: record { expiration: Timestamp; }; Err;});
// Exits the authentication method registration mode for the identity.
// Requires authentication.
authn_method_registration_mode_exit : (IdentityNumber) -> (variant {Ok; Err;});
// Registers a new authentication method to the identity.
// This authentication method needs to be confirmed before it can be used for authentication on this identity.
authn_method_register: (IdentityNumber, AuthnMethodData) -> (variant {Ok: AuthnMethodConfirmationCode; Err: AuthnMethodRegisterError;});
// Confirms a previously registered authentication method.
// On successful confirmation, the authentication method is permanently added to the identity and can
// subsequently be used for authentication for that identity.
// Requires authentication.
authn_method_confirm: (IdentityNumber, confirmation_code: text) -> (variant {Ok; Err: AuthnMethodConfirmationError;});
// Authentication protocol
// =======================
prepare_delegation : (UserNumber, FrontendHostname, SessionKey, maxTimeToLive : opt nat64) -> (UserKey, Timestamp);
get_delegation: (UserNumber, FrontendHostname, SessionKey, Timestamp) -> (GetDelegationResponse) query;
// Attribute Sharing MVP API
// =========================
// The methods below are used to generate ID-alias credentials during attribute sharing flow.
prepare_id_alias : (PrepareIdAliasRequest) -> (variant {Ok: PreparedIdAlias; Err: PrepareIdAliasError;});
get_id_alias : (GetIdAliasRequest) -> (variant {Ok: IdAliasCredentials; Err: GetIdAliasError;}) query;
// HTTP Gateway protocol
// =====================
http_request: (request: HttpRequest) -> (HttpResponse) query;
http_request_update: (request: HttpRequest) -> (HttpResponse);
// Internal Methods
// ================
init_salt: () -> ();
stats : () -> (InternetIdentityStats) query;
config : () -> (InternetIdentityInit) query;
deploy_archive: (wasm: blob) -> (DeployArchiveResult);
// Returns a batch of entries _sorted by sequence number_ to be archived.
// This is an update call because the archive information _must_ be certified.
// Only callable by this IIs archive canister.
fetch_entries: () -> (vec BufferedArchiveEntry);
acknowledge_entries: (sequence_number: nat64) -> ();
}
Identity management (legacy API)
The create_challenge
and register
methods
captcha_create
and identity_register
:::Authorization: This register
request must be sent to the canister with caller
that is the self-authenticating id derived from the given DeviceKey
.
The register
method is used to create a new user. The Internet Identity Service backend creates a fresh Identity Anchor, creates the account record, and adds the given device as the first device.
In order to protect the Internet Computer from too many "free" update calls, and to protect the Internet Identity Service from too many user registrations, this call is protected using a CAPTCHA challenge. The register
call can only succeed if the ChallengeResult
contains a key
for a challenge that was created with create_challenge
(see below) in the last 5 minutes and if the chars
match the characters that the Internet Identity Service has stored internally for that key
.
The add
method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
The add
method appends a new device to the given user's record.
The Internet Identity Service backend rejects the call if the user already has a device on record with the given public key.
This may also fail (with a reject) if the user is registering too many devices.
The remove
method
authn_method_remove
:::Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
The remove
method removes a device, identified by its public key, from the list of devices a user has.
It is allowed to remove the key that is used to sign this request. This can be useful for a panic button functionality.
It is allowed to remove the last key, to completely disable a user. The canister may forget that user completely then, assuming the Identity Anchor generation algorithm prevents new users from getting the same Identity Anchor.
It is the responsibility of the frontend UI to protect the user from doing these things accidentally.
If the device has the protected
flag, then the request must be sent to the canister with caller
that is the self-authenticating id derived from the public key of that particular device.
:::
The replace
method
authn_method_replace
:::Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
The replace
method atomically replaces a device, identified by its public key from the list of devices a user has with another one supplied as an argument.
It is allowed to replace the key that is used to sign this request. The replace method is useful to replace the recovery phrase with another one, making sure that at all times there is exactly one recovery phrase associated with the identity.
It is the responsibility of the frontend UI to protect the user from doing these things accidentally.
If the device has the protected
flag, then the request must be sent to the canister with caller
that is the self-authenticating id derived from the public key of that particular device.
:::
The enter_device_registration_mode
method
authn_method_registration_mode_enter
:::Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Enables device registration mode for the given identity anchor. When device registration mode is active, new devices can be added using add_tentative_device
and verify_tentative_device
. Device registration mode stays active for at most 15 minutes or until the flow is either completed or aborted.
The exit_device_registration_mode
method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Exits device registration mode immediately. Any non verified tentative devices are discarded.
The add_tentative_device
method
authn_method_register
:::Authorization: Anyone can call this
Tentatively adds a new device to the supplied identity anchor and returns a verification code. This code has to be used with the verify_tentative_device
method to verify this device. If the flow is aborted or not completed within 15 minutes, the tentative device is discarded.
Tentatively added devices cannot be used to login into the management view or authorize authentications for other dApps.
The verify_tentative_device
method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
For an anchor in device registration mode: if called with a valid verification code, adds the tentative device as a regular device to the anchor and exits registration mode. The registration flow is aborted if this method is called five times with invalid verification codes.
Returns an error if called for a device not in registration mode.
The lookup
query method
identity_authn_info
:::Authorization: Anyone can call this
Fetches all device data associated with a user. Since this method can be called by anyone, the information returned is limited. In particular, any fields containing potentially personal information are stripped away (such as the metadata or alias fields).
The get_anchor_info
method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Fetches all data associated with an anchor including registration mode and tentatively registered devices.
The get_principal
query method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Fetches the principal for a given user and front end.
Identity management (API V2 only)
The authn_method_metadata_replace
query method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Replaces the metadata
map of the given authn_method.
The authn_method_security_settings_replace
query method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Replaces the authn_method_security_settings_replace
map of the given authn_method. This method is split from authn_method_metadata_replace
in order to be able to introduce different security requirements for security relevant changes to authn_methods while not impeding non-critical changes (such as e.g. changing the authn_method alias).
The identity_metadata_replace
query method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
Replaces the metadata
map associated with the given identity.
Authentication protocol
The prepare_delegation
method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
The prepare_delegation
method causes the Internet Identity Service backend to prepare a delegation from the user identity associated with the given Identity Anchor and Client Application Frontend Hostname to the given session key.
This method returns the user's identity that's associated with the given Client Application Frontend Hostname. By returning this here, and not in the less secure get_delegation
query, we prevent attacks that trick the user into using a wrong identity.
The expiration timestamp is determined by the backend, but no more than maxTimeToLive
(if present) nanoseconds in the future.
The method returns the expiration timestamp of the delegation. This is returned purely so that the client can feed it back to the backend in get_delegation
.
The actual delegation can be fetched using get_delegation
immediately afterwards.
The get_delegation
query method
Authorization: This request must be sent to the canister with caller
that is the self-authenticating id derived from any of the public keys of devices associated with the user before this call.
For a certain amount of time after a call to prepare_delegation
, a query call to get_delegation
with the same arguments, plus the timestamp returned from prepare_delegation
, actually fetches the delegation.
Together with the UserKey
returned by prepare_delegation
, the result of this method is used by the Frontend to pass to the client application as per the client authentication protocol.
Verifiable Credentials Protocol
See here for the specification of the verifiable credentials protocol.
HTTP gateway protocol
The methods http_request
and http_request_update
serve the front-end assets to browesers. See here for additional details.
Internal APIs
The init_salt
method
Authorization: Can only be called by anyone.
The init_salt
method initialises the salt. Traps if the salt is already initialised.
The stats
method
Authorization: Can only be called by anyone.
Reports statistics and configuration values of Internet Identity.
The deploy_archive
method
Authorization: Can only be called by anyone.
The deploy_archive
method deploys the supplied wasm to the archive canister, given it matches the configured archive wasm hash.
The fetch_entries
and acknowledge_entries
methods
Authorization: Can only be called by the archive canister.
API for the archive canister to fetch archive entries from the Internet Identity canister and to trigger pruning of archived entries within Internet Identity.
The Internet Identity service backend internals
This section, which is to be expanded, describes interesting design choices about the internals of the Internet Identity Service Canister. In particular
Salt
The salt
used to blind the hashes that form the seed
of the Canister Signature "public keys" is obtained via a call to aaaaa-aa.raw_rand()
. The resulting 32 byte sequence is used as-is.
Since this cannot be done during canister_init
(no calls from canister init), the randomness is fetched by someone triggering the init_salt()
method explicitly, or just any other update call. More concretely:
Anyone can invoke
init_salt()
init_salt()
traps ifsalt != EMPTY_SALT
Else,
init_salt()
callsaaaaa-aa.raw_rand()
. When that comes back successfully, and stillsalt == EMPTY_SALT
, it sets the salt. Else, it traps (so that even if it is run multiple times concurrently, only the first to write the salt has an effect).all other update methods, at the beginning, if
salt == EMPTY_SALT
, they awaitself.init_salt()
, ignoring the result (even if it is an error). Then they check if we still havesalt == EMPTY_SALT
and trap if that is the case.
Why we do not use canister_inspect_message
The system allows canisters to inspect ingress messages before they are actually ingressed, and decide if they want to pay for them (see the interface spec). Because the Internet Identity canisters run on a system subnet, cycles are not actually charged, but we still want to avoid wasting resources.
It seems that this implies that we should use canister_inspect_message
to reject messages that would, for example, not pass authentication.
But upon closer inspection (heh), this is not actually useful.
One justification for this mechanism would be if we expect a high number of accidentally invalid calls. But we have no reason to expect them at the moment.
Another is to protect against a malicious actor. But that is only useful if the malicious actor doesn't have an equally effective attack vector anyways, and in our case they do: If they want to flood the NNS with calls, they can use calls that do authenticate (e.g. keeping removing and adding devices, or preparing delegations); these calls would pass message inspection.
On the flip side, implementing canister_inspect_message
adds code, and thus a risk for bugs. In particular, it increases the risk that some engineer might wrongly assume that the authentication check in canister_inspect_message
is sufficient and will not do it again in the actual method, which could lead to a serious bug.
Therefore, the Internet Identity Canister intentionally does not implement canister_inspect_message
.