I would really like this as well. It gives you assurances that there was a signature on the other end of a third party call.
For example, for some things you want:
User A → CanisterB() → CanisterC(principalA)
But for other you want
User A → CanisterC().
And you never want:
CanisterBUpgraded() ->CaniserC(principalA
By the system providing orginalCaller I have some cryptographic guarantees and all kinds of intermediate services become possible. It seems like being able to access original caller ENABLES composable third party services amongst semi-untrusted containers. Now that I write that out, it sounds like a horrible idea. Ha!
So what do I really want? I need CanisterC to know that a call was authorized by UserA and that CanisterB didn’t just up and decide to call a function. I’d also like for CanisterB to not have to do much to pass this data to Canister C. What does this data structure look like and how do we implement it in a different manner? Can we sign some kind of data that B can pass along? Something like a JSON Web Token. It seems like CanisterB might need to alert the User of all the canisters that it might access and that doesn’t seem too practical once we get into composable services. This is not an easy problem to solve!
I guess ETH lets all called contracts access the original ECDSA v,r,s so that it can get the original caller.
Having more crypto secure data seems like a good thing in the long run. Other things I’d like to have access to from my motoko contracts while we are asking:
The current Tip of the main BLS Chain so that I can verify witnesses
The ‘blocknumber’ or ‘round number’ or what ever the current subnet agreement about what is being approved.
Cycle Limit remaining before a trap
Current XDR cycle to ICP Rate
Coinbase of the node provider that is running my transaction
Current Subnet ID
Why do I want these things? Some of them I don’t know yet, but they seem like important variables that my code could access in a crypto secure way and I might want to do that one day.