ICRC-28/34: Clarify confusing sections #204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR resolves the findings with regards to confusing wording that were found in the prod sec review. It also adds a recommendation for approval flows for tradable assets in ICRC-28 in order to guide developers looking to get rid of approvals when interacting with ledgers.
dostro
reviewed
Aug 15, 2024
topics/icrc_28_trusted_origins.md
Outdated
| **MUST** not implement ICRC-28: ICRC-28 privileges the listed entities to potentially act independently on behalf of the signer, which is a security risk in the context of tradable assets and shared infrastructure. | ||
| **MUST NOT** implement ICRC-28: ICRC-28 privileges the listed entities to potentially act independently on behalf of the signer, which is a security risk in the context of tradable assets and shared infrastructure. | ||
|
|
||
| > **Note:** If autonomy is required in the context of tradable assets it is recommended to use relying party delegations as per [ICRC-34](./icrc_34_delegation.md) in conjunction with [ICRC-2](https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-2/README.md) or https://github.com/dfinity/ICRC/blob/main/ICRCs/ICRC-37/ICRC-37.md. |
There was a problem hiding this comment.
What does it mean to require autonomy?
There was a problem hiding this comment.
I meant that an entity can act autonomously. I have changed the wording. Hopefully it is clearer now.
dostro
reviewed
Aug 15, 2024
dostro
approved these changes
Aug 28, 2024
dostro
added a commit
that referenced
this pull request
Nov 1, 2024
* docs: typo granted in permissions (#202) * docs: Get Accounts -> Accounts (#208) * ICRC-27/49: Clarify permission check (#207) * ICRC-27/49: Clarify permission check Clarify the permission check step in message processing to be aligned with the 3-state permission change previously made in ICRC-25 (see #185). * Add reference to ICRC-25 permission states * ICRC-28/34: Clarify confusing sections (#204) * ICRC-28/34: Clarify confusing sections This PR resolves the findings with regards to confusing wording that were found in the prod sec review. It also adds a recommendation for approval flows for tradable assets in ICRC-28 in order to guide developers looking to get rid of approvals when interacting with ledgers. * Clarify wording on recommendation for ICRC-2 and ICRC-37 * Add suggested note * Reword recommendation to use approval flows * ICRC-34: Align permission check with ICRC-25 * Update permission check to be consistent with ICRC-27/49 * ICRC-21: Add validation step for the consent message request sender (#203) * ICRC-21: Add validation step for the consent message request sender This PR includes a validation step in the cold signer use-case to explicitly validate the `sender` property of the icrc21_consent_message request. A note is added to the hot signer use-case to use the same identity (or the anonymous one) to fetch the consent message and sign the requested call. * Clarify authentication section * ICRC-21: Clarify sender for consent message request (#209) * ICRC-21: Clarify sender for consent message request Incorporate feedback from @peterpeterparker that it was unclear which identity should be used by the signer to request the consent message. Additionally, the requirements for fetching the consent message in the cold-signer use-case have been clarified as well. * Replace hot signer with chain-connected component * ICRC-25: Rename Network Error Category to Transport Channel (#212) * ICRC-25: Rename Network Error Category to Transport Channel The "Network" error category is renamed to "Transport Channel" to include any error related to communications with signer (and the signer with the IC). A new error is introduced (4001) to communicate unexpected interruption of the communication channel between the rp and the signer. In particular this error can be used if the user dismisses the UI elements of the signer early without completing the interaction (i.e. close browser tab or extension window). * Fix typo Co-authored-by: sea-snake <[email protected]> --------- Co-authored-by: sea-snake <[email protected]> * docs: fix link to icrc-21 (#213) --------- Co-authored-by: David Dal Busco <[email protected]> Co-authored-by: Frederik Rothenberger <[email protected]> Co-authored-by: sea-snake <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR resolves the findings with regards to confusing wording that were found in the prod sec review.
It also adds a recommendation for approval flows for tradable assets in ICRC-28 in order to guide developers looking to get rid of approvals when interacting with ledgers.