Each identity anchor can be linked to multiple devices – or rather public keys of those devices – with each of those public keys eligible to add or remove other keys. In case users lose access to their identity anchor, they currently cannot track what happened. Sure, they could call
lookup(anchor) on the II canister, but that only lists the public keys that are currently linked to
anchor. What if that list doesn’t look like the user expects, such as all public keys being deleted?
From our day-to-day support operations, we know that users do sometimes lose access to their identity anchors, and we believe that having a log of operations modifying the identity anchors could be of great help in understanding what happened and how access could possibly be recovered.
Add an additional logging canister to Internet Identity. That canister will track operations that modify each identity anchor by adding or removing a public key. In more detail, the tracked data should contain:
- Operation (i.e. add vs. delete)
- Public key added/removed
- Alias of the public key added/removed
- Principal that authorized the transaction
Most of this data is effectively available anyway (through the
lookup method), except for the timestamp and the principal authorizing the transaction, so we would be leaking only little data that an adversary could not obtain otherwise. But we can make the data queryable to the user, so that users losing access to their identity anchors have the means to understand what happened (or at least technically savvy users have the means to help them). From our past experience, timestamps or authenticating principals seem to be worthwhile additions, which is why we suggest to add them here.
- Do you have any concerns related to this mechanism?
- Do you think some of the data (e.g. alias/timestamp) should not be logged?
- Do you think we should offer an opt-out for tech-savvy users that prefer not to have such data logged?
Note that there are no intentions to log users’ authentication actions or principals that a user authenticated with at a dapp, as this would be a serious threat to user privacy.