What is Caller Info?

Developers Language Support
1

I saw these added to motoko’s Prim. What are they used for?

func callerInfoSigner() : Blob {
(prim "caller_info_signer" : () -> Blob)();
};

func callerInfoData() : Blob {
(prim "caller_info_data" : () -> Blob)();
};
2

See:

https://forum.dfinity.org/t/proposals-141500-141501-to-upgrade-ii/67754

It’s an additional canister signature signed payload that can be sent along with a delegation created by a canister. This enables canisters to ingest additional metadata tied to the principal.

Currently focusing on identity attributes like emails, but could in theory be anything. For example user access control roles on a platform with multiple canisters.

3

Fascinating. Can non-II principal providers append/sign this info as well?

So many questions…ICRC-3 is mentioned…is the canister keeping track of these somewhere? Is it public…I’d assume that emails aren’t just being written to a block log? Maybe just hashes? Is it an async request to request the data? Any more broad docs on how this all works?

4

Can non-II principal providers append/sign this info as well?
Yes, any canister that creates delegations can create signed info blobs as well.

So many questions…ICRC-3 is mentioned…is the canister keeping track of these somewhere?
I get the confusion since ICRC-3 is mostly used for block history. We solely use it’s Value candid shape in II to encode data in the info blobs, there are no block logs.

Here’s a link to a mermaid diagram that details the whole flow with II: Online FlowChart & Diagrams Editor - Mermaid Live Editor if you cross reference that with the implementation in the II repo you should be able to see all details.

Work on SDK, docs and skills are ongoing.

5

But you could do that already - passing payload as argument and verifying the payload (certified variables). What are the benefits of sending it along with the delegation?

6

The BLS signature of the info payload is verified during ingress similar to the delegation BLS signature(s), avoiding the large computation cost it would have taken to verify it within the WASM itself.

This enables a canister to receive certified details regarding a given principal in canister calls without any overhead, enabling use cases like multi canister architectures, integrations between canister etc.

7

Will canisters be able to attach this data to intercanister calls?

8

No, it’s an extension to delegations, so it’s limited to ingress (update/query) calls.