Invalidate II delegation

Developers
1

If there is a way to invalidate II delegation?

It is like “sign out on all devices” feature that exist on web2.0 services.

Let’s say particular IC web app uses 30 days invalidation timeout (maxTimeToLive parameter in AuthClient.login).
Once I “login” on any device and forget to do a proper “logout” (remove delegation from localStorage) - anyone can use that delegation for the whole month!
It is my (as a user) fault, but IC could have feature to invalidate either all delegations or particular delegation.

Community developers - what do you think?

Dear @diegop @kpeacock please tag someone who can help.

4 Likes
2

I pinged the II team

3

Hi @alexeychirkov

II dev here. You raise a good point. Thanks!
There is now way to do it right now. And I agree that 30 days is very long for a non-revocable credential.

So far, the SDK team has addressed this by implementing idle timeouts. However, this is also a client side solution and can be controlled by the developer.

To give users more power, we would have to switch the way delegations are issued to make them revocable. We do have plans for that, but unfortunately have not yet had the time to address it. But it is part of the current set of requirements in the working group discussion about interoperability with regards to identity (R5).

TLDR: We are aware of the issue and are working on a solution. But resources are tight, so it might still take a while.

7 Likes
4

@frederikrothenberger Thank you for a quick response.

5

Do resources depend on ICP price in any way? Or there’s just a budget and/or limited dev power for any reason.

6

@alexeychirkov Frederik has already answered correctly about invalidating the delegation canister-side.

I’d like to note that client-side, in addition to to the idleManager logic, there is also an option available to developers to invalidate an identity in an already instantiated Agent.

If you have a reference to an Agent, you can use the invalidateIdentity method, which will set it to null and make all calls fail until you replaceIdentity with a new one.

If the Agent is inside an already initialized Actor, you can do the same for that Actor’s Agent with

Actor.agentOf(exampleActor).invalidateIdentity();
3 Likes
7

Hello. @frederikrothenberger can you please give any comments on progress?

1 Like
8

Hi @alexeychirkov

Unfortunately, this has been deprioritized. So no progress has been made on it.

9

@dominicwilliams @Jan @domwoe @emmaperetti and others

Are there incentives such as Grant,Bounty and More to address issues with low priority but community needs?

After all, existing needs are more conducive to building consensus, enhancing confidence, better build，
and better than Imaginary or ineffective needs, especially for the current IC community!

Thank you very much!Looking forward to!

10

Regarding the dapp side that receives the II delegation, you can increase security on the dapp side by using cookies:

  • store delegation in a cookie with short expiry like 24 hours
  • when you open dapp in next 24 hours, you can read the cookie and create a new 24 hours cookie
  • when dapp is opened after 24 hours, cookie is gone and you’ll have to re-authenticate with II.

This basically expires your II in 24 hours of not opening the browser.

I’ve implemented something similar in a wallet with cookies to keep the IBE identity (used for encryption) valid until the user closes the browser.

As for signing identities (II or mnemonic), I’ve secured them by delegating it to either a biometric or password identity. So users can’t use the signing identity untill they’ve used the correct biometrics or entered the correct password.

1 Like