Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: typo granted in permissions #202

Merged
merged 1 commit into from
Aug 12, 2024
Merged

Conversation

peterpeterparker
Copy link
Member

Motivation

There was two small typos in icrc25_permissions. It mentionned "grandted" permissions only while the response and standard actually list all permissions, not only those that are granted.

Copy link
Contributor

@frederikrothenberger frederikrothenberger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot, LGTM!

@frederikrothenberger frederikrothenberger merged commit e67fb74 into main Aug 12, 2024
3 checks passed
@frederikrothenberger frederikrothenberger deleted the docs/typo-granted branch August 12, 2024 12:29
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants