ICRC-34: Get Delegation

[plitzenberger]

The ICRC-34: Get Delegation standard defines how the relying party can request delegation identities from the user.

Draft Document: icrc_34_get_delegation.md

[frederikrothenberger]

In the working group session on February 6, 2024 we noticed that the scope of ICRC-34 is not yet settled.

In particular, there are the following open questions:

• Is ICRC-34 intended to get delegations on signer managed identities as listed by icrc31_get_prinicpals?
  • Alternatively, ICRC-34 could be renamed to "Get Session Delegation" highlighting that it is a different from global, session-independent identities.
• Which methods for session isolation are supported? Candidates are:
  • Separation by non-overlapping target restrictions. This implies that ICRC-34 is dependent on ICRC-28.
  • Separation by deriving a unique identity for each relying party.

The working group will use this issue to track progress on these questions.

CC: @plitzenberger, @sea-snake, @dostro

[sea-snake]

Working on an PR with above changes (splitting the get delegations into a global and session method) and adding ICRC-28 document.

[sea-snake]

See above PR for the changes based on above discussion.

While splitting ICRC-34 I came across the following questions:

• How does the signer non interactively decide that you can get a delegation for a given principal? Maybe this is up to the signer, probably if the user decided to share the given principal previously?
• I added the cold signer flow for the global delegation trusted origins verification. Since the cold signer has no concept of time, I defined the time as the time in the metadata responses. This is based on the assumption that old metadata responses will result in an already expired delegation and it's not possible to get a metadata response from the future. Not sure if these assumptions are correct or if there is a better approach.
• The session delegation was a lot more straightforward but I did omit the concept of delegations being scoped to the origin of the relying party. This was done based on the assumption that delegations are scoped to the session with the signer. But this might be confusing since we do want the same delegation identity even when a new session is created for the same origin on the same or another device. So maybe we should add origin scoping to this standard?

[frederikrothenberger]

How does the signer non interactively decide that you can get a delegation for a given principal? Maybe this is up to the signer, probably if the user decided to share the given principal previously?

The relying party has to first request permission for the relevant ICRC-34 / ICRC-57 scope (which requires user-interaction). Once granted, getting the actual delegation should IMHO no longer require user interaction. The restriction on specific identities IMHO also belongs on the scope (similar to the ICRC-49 scope restrictions).

I added the cold signer flow for the global delegation trusted origins verification. Since the cold signer has no concept of time, I defined the time as the time in the metadata responses. This is based on the assumption that old metadata responses will result in an already expired delegation and it's not possible to get a metadata response from the future. Not sure if these assumptions are correct or if there is a better approach.

This approach is consistent with the cold signer flow for ICRC-21. For ICRC-21, this has already been security reviewed and has been found appropriate. As such, I like and support using the same approach here as well.

The session delegation was a lot more straightforward but I did omit the concept of delegations being scoped to the origin of the relying party. This was done based on the assumption that delegations are scoped to the session with the signer. But this might be confusing since we do want the same delegation identity even when a new session is created for the same origin on the same or another device. So maybe we should add origin scoping to this standard?

The session delegation must not be scope to the signer session, as then the session identity would be lost on loss of signer session. Rather, the session identity must be bound to some property of the relying party. In case of Internet Identity that property is the origin. Depending on the transport chosen, some other property might be more appropriate. The important point here is that the property chosen must protect against impersonation by a malicious relying party.

---

Side-note on this:

even when a new session is created for the same origin on the same device

I don't think we should allow that scenario. It is confusing to the user (i.e. which session am I really interacting with) and does not provide any meaningful separation / isolation:

Given a relying party with two sessions to the same signer with different privileges, the relying party context with fewer privileges can always communicate out-of-band with the relying party context with more privileges, having that context execute undesired actions on behalf of the low privileges context.

[sea-snake]

Given a relying party with two sessions to the same signer with different privileges, the relying party context with fewer privileges can always communicate out-of-band with the relying party context with more privileges, having that context execute undesired actions on behalf of the low privileges context.

Edit: ah I see now this comment is regarding two simultaneous sessions to the same signer in the same browser, yes this should be avoided indeed.

[sea-snake]

Depending on the transport chosen, some other property might be more appropriate. The important point here is that the property chosen must protect against impersonation by a malicious relying party.

I guess this property is part of the transport layer not the icrc57 message itself. I'll mention this in the spec.

[sea-snake]

(Discussion regarding session delegation vs global delegations continues in above PR: https://github.com/dfinity/wg-identity-authentication/pull/151)

Edit: Added comments in this thread with regards to last WG meeting.

[frederikrothenberger]

I'm closing this, since the discussed changes have been implemented in the current drafts.