Decouple CAIP-27 from CAIP-25 and introduce CAIP-217 for Authorization Scopes #217

bumblefudge · 2023-03-02T20:57:33Z

To-do before merge

Overhauled to reorg CAIP-25 into composable blocks 💪
Closed [CAIP-25] Add CAIP-211 ("Rpc Authority Negotiation") as extension spec to CAIP-25 #211 - no longer needed, rpcEndpoints and rpcDocuments are just optional properties now 😌
Introduced ### Validation section - should this be more constrained? feels a little #yolo as-is
### Response section feels too open-ended - should forwarded responses be wrapped in metadata?
Should error messages be added?
Should references to CAIP-170 be removed, for now, as Pre-Draft: Browser-Session Data Model #170 is still in draft and there's been no discussion on it?

@hmalik88 @pedrouid please opine on the questions above and I can throw some more commits in this bad boy

CAIPs/caip-25.md

CAIPs/caip-27.md

Co-authored-by: Hassan Malik <[email protected]>

hmalik88

LGTM.

bumblefudge

LGTM, @pedrouid final check?

bumblefudge · 2023-03-29T22:59:53Z

Majorly refactored; new initial comment above

CAIPs/caip-27.md

pedrouid

Just left a single comment to replace in caip_request with provider_request for CAIP-27

Other than that... This is looking amazing! 🙏

I can feel CAIP-25 and CAIP-27 being Final very very soon 🚀

CAIPs/caip-217.md

CAIPs/caip-27.md

pedrouid · 2023-04-05T15:01:17Z

Some extra comments to fix how markdown is being rendered plus making it more consistent with CAIP-25 naming

Co-authored-by: Pedro Gomes <[email protected]>

pedrouid

👍

CAIPs/caip-217.md

CAIPs/caip-211.md

hmalik88 · 2023-04-13T14:49:14Z

CAIPs/caip-211.md

+```jsonc
+{
+  "X": {
+    methods: [A, B, C],
+    notifications: [D, E, F],
+    rpcEndpoints: [U1, U2, U3],
+    rpcDocuments: [V]
+  }
+}
+```
+MUST be taken literally, as dropping the implicit values rather than appending
+to them. It MUST NOT be interpreted as equivalent to:
+
+```jsonc
+{
+  "X": {
+    methods: [A, B, C],
+    notifications: [D, E, F],
+    rpcEndpoints: [Y1, Y2, Y3, U1, U2, U3],
+    rpcDocuments: [Z, V]
+  }
+}
+```
+
+But the latter SHOULD be returned as response if dropping the implicit values in
+favor of the requested ones is unacceptable and extending the implicit values is
+preferred. 


I think we need to think about this a bit more.

Points I agree with:

You're basically saying that the first format should be used in a request and the second should be used in a response. Reason being because the rpcDocuments in the request could potentially overwrite the implicit values for that chain so it makes sense to drop implicit values entirely.

Points that are unclear:

If the wallet/user-agent detects that the rpcDocuments are not overwriting implicit values it would include the rpc document defined in the CAIP profile for that chain which I think falls under the statement "if dropping the implicit values in favor of the requested ones is unacceptable". This is unclear to me, because what do we mean by unacceptable? Is unacceptable that the wallet isn't able to or doesn't want to match the function signature that the dapp is requesting for a particular method? In that case it should just reject the request. OR are we talking about a scenario where the request had methods in its methods array that the wallet had deemed to be implicit values?

I'm also wondering that at the point a chain has a CAIP profile with defined rpc documents, the implicit rpc document would become extraneous information in the response. Do we just have dapps include what we consider to be "implicit" values in their own rpc document endpoints until a chain has it's own CAIP profile? How do we determine when that is? This seems like a very gray area.

a. One thing to note is that we also don't want to return rpc documents for methods that haven't been requested. What happens in the likely scenario that a dapp is requesting a subset of a chain's implicit methods? Do we return the whole rpc document regardless?

Unclear # 1: by unacceptable, I meant "allowed to extend e.g. execution APIs but I neither want to allow your documents to contradict/re-define execution APIs NOR do I want to manually confirm each connection that your documents don't contradict/redefine. I can either make this more explicit in another commit... or change course if it's a faulty use-case assumption!

Unclear # 2: it's extraneous if it's in every request, in the sense that it verbosely states the obvious, but I wouldn't drop it from my responses to those verbose requests if I was a provider! what a CAIP-211 profile does is give additional confidence to the providers who want to interpret no setting as equivalent to execution-apis, and let them respond without adding it. I guess I was assuming legacy verbosity would be tolerable and just peter out over time harmlessly?

unclear # a: I was assuming whole RPC document -- if machine-readable, "subsetting" that document or extracting, say, ABI signatures for function names can happen automatically, if human-readable (a permalink to a namespace's official dev docs, for example), this might be a little more onerous...

Unclear # 1: by unacceptable, I meant "allowed to extend e.g. execution APIs but I neither want to allow your documents to contradict/re-define execution APIs NOR do I want to manually confirm each connection that your documents don't contradict/redefine. I can either make this more explicit in another commit... or change course if it's a faulty use-case assumption!

This should just be a rejected request then.

Unclear # 2: it's extraneous if it's in every request, in the sense that it verbosely states the obvious, but I wouldn't drop it from my responses to those verbose requests if I was a provider! what a CAIP-211 profile does is give additional confidence to the providers who want to interpret no setting as equivalent to execution-apis, and let them respond without adding it. I guess I was assuming legacy verbosity would be tolerable and just peter out over time harmlessly?

Ok that's fair. In the scenario that a dapp is requesting some implicit methods, it should also then provide documents for those methods until as you said legacy verbosity peters out over time. We would also then naturally return said documents in the response to maintain this statefulness through the chain of events idea we spoke about.

unclear # a: I was assuming whole RPC document -- if machine-readable, "subsetting" that document or extracting, say, ABI signatures for function names can happen automatically, if human-readable (a permalink to a namespace's official dev docs, for example), this might be a little more onerous...

You're right, the openRPC document is JSON, so yes we can certainly return a subset of the document.

This should just be a rejected request then.

OK I'll push another commit aligned with this different behavior.

This should just be a rejected request then.

OK I'll push another commit aligned with this different behavior.

Cool, we should use this discussion to further explain what's going on and provide context for the code example.

…les-of-wallet-methods Feat/caip 25 include examples of wallet methods

CAIPs/caip-217.md

constrain to CAIP-25 session explicitly

d75e96d

hmalik88 reviewed Mar 3, 2023

View reviewed changes

CAIPs/caip-25.md Outdated Show resolved Hide resolved

hmalik88 reviewed Mar 3, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

hmalik88 reviewed Mar 3, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

hmalik88 reviewed Mar 3, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

bumblefudge and others added 2 commits March 3, 2023 18:12

typo

4c4ae73

Co-authored-by: Hassan Malik <[email protected]>

typo

be1aa1c

Co-authored-by: Hassan Malik <[email protected]>

hmalik88 approved these changes Mar 10, 2023

View reviewed changes

bumblefudge mentioned this pull request Mar 10, 2023

Editorial WG Mtg - 9 March ChainAgnostic/CASA#78

Closed

1 task

bumblefudge commented Mar 15, 2023

View reviewed changes

bumblefudge added 3 commits March 29, 2023 23:12

strawman CAIP-217

95c5268

fine-tuning simple CAIP-217

407691f

simplified CAIP-27

2e54eaa

bumblefudge changed the title ~~Update CAIP-27 to be constrained by CAIP-25 session authZ~~ Decouple CAIP-27 from CAIP-25 and introduce CAIP-217 for Authorization Scopes Mar 29, 2023

simplified CAIP-25

aa9506d

bumblefudge mentioned this pull request Mar 29, 2023

[CAIP-25] Add CAIP-211 ("Rpc Authority Negotiation") as extension spec to CAIP-25 #211

Closed

pedrouid reviewed Apr 1, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

pedrouid reviewed Apr 1, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

pedrouid reviewed Apr 1, 2023

View reviewed changes

pedrouid reviewed Apr 5, 2023

View reviewed changes

CAIPs/caip-217.md Outdated Show resolved Hide resolved

pedrouid reviewed Apr 5, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

pedrouid reviewed Apr 5, 2023

View reviewed changes

CAIPs/caip-27.md Outdated Show resolved Hide resolved

bumblefudge and others added 5 commits April 5, 2023 17:31

typo

ac80b88

Co-authored-by: Pedro Gomes <[email protected]>

formatting tweak

e79a945

Co-authored-by: Pedro Gomes <[email protected]>

typo

0ef0acc

Co-authored-by: Pedro Gomes <[email protected]>

typo

03884a6

Co-authored-by: Pedro Gomes <[email protected]>

typo

9300226

Co-authored-by: Pedro Gomes <[email protected]>

pedrouid approved these changes Apr 5, 2023

View reviewed changes

bumblefudge mentioned this pull request Apr 12, 2023

Add chain-agnostic RPC #24

Closed

bumblefudge and others added 6 commits April 12, 2023 19:20

make accounts optionality and semantics more explicit

f3cb8fc

make informational version of CAIP-211

66b56ff

add abstract to informational version of CAIP-211

859551d

add wallet methods to caip-25

d92e474

typo

48e0e3d

resolve

01459af

pedrouid mentioned this pull request Apr 13, 2023

Feat/caip 25 include examples of wallet methods #224

Merged

hmalik88 reviewed Apr 13, 2023

View reviewed changes

CAIPs/caip-217.md Show resolved Hide resolved

hmalik88 reviewed Apr 13, 2023

View reviewed changes

CAIPs/caip-211.md Outdated Show resolved Hide resolved

hmalik88 reviewed Apr 13, 2023

View reviewed changes

bumblefudge and others added 5 commits April 13, 2023 18:24

fine-tune abstract

555c005

typo

7f4801b

Merge pull request #224 from ChainAgnostic/feat/caip-25-include-examp…

5afcb22

…les-of-wallet-methods Feat/caip 25 include examples of wallet methods

add security considerations with negotiation example

0e72bb6

resolve conflicts

0fea9db

rekmarks reviewed Apr 20, 2023

View reviewed changes

CAIPs/caip-217.md Outdated Show resolved Hide resolved

hmalik88 reviewed Apr 21, 2023

View reviewed changes

CAIPs/caip-217.md Outdated Show resolved Hide resolved

This was referenced May 4, 2023

Added OpenRPC doc for CAIP-25 #212

Closed

Editorial WG Mtg - 4 May ChainAgnostic/CASA#83

Open

bumblefudge added 7 commits May 19, 2023 12:15

to clarify scopes object semantics

8a92f2b

to clarify the syntax of string to which each object is keyed

5076373

to clarify the semantics of the whole object in # spec section

1037853

to clarify that responses are specified per namespace, not here

96e7760

to clarify that 2 of 3 options in caip25 example are corner cases

5097a2d

remove hard requirement on as-yet unmergeddefined CAIP-170

0de8414

restore property 5 in caip171

e45f802

bumblefudge mentioned this pull request May 19, 2023

Notes for Special Meeting of RPC WG - 19 May 2023 ChainAgnostic/CASA#84

Closed

Merge branch 'master' into feat/update-caip27-to-be-constrained-by-25

5fcdf9b

bumblefudge merged commit e4fe918 into master May 19, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Decouple CAIP-27 from CAIP-25 and introduce CAIP-217 for Authorization Scopes #217

Decouple CAIP-27 from CAIP-25 and introduce CAIP-217 for Authorization Scopes #217

bumblefudge commented Mar 2, 2023 •

edited

Loading

hmalik88 left a comment

bumblefudge left a comment

bumblefudge commented Mar 29, 2023

pedrouid left a comment

pedrouid commented Apr 5, 2023

pedrouid left a comment

hmalik88 Apr 13, 2023 •

edited

Loading

bumblefudge Apr 13, 2023 •

edited

Loading

bumblefudge Apr 13, 2023

hmalik88 Apr 13, 2023

bumblefudge Apr 13, 2023

hmalik88 Apr 13, 2023

Decouple CAIP-27 from CAIP-25 and introduce CAIP-217 for Authorization Scopes #217

Decouple CAIP-27 from CAIP-25 and introduce CAIP-217 for Authorization Scopes #217

Conversation

bumblefudge commented Mar 2, 2023 • edited Loading

hmalik88 left a comment

Choose a reason for hiding this comment

bumblefudge left a comment

Choose a reason for hiding this comment

bumblefudge commented Mar 29, 2023

pedrouid left a comment

Choose a reason for hiding this comment

pedrouid commented Apr 5, 2023

pedrouid left a comment

Choose a reason for hiding this comment

hmalik88 Apr 13, 2023 • edited Loading

Choose a reason for hiding this comment

bumblefudge Apr 13, 2023 • edited Loading

Choose a reason for hiding this comment

bumblefudge Apr 13, 2023

Choose a reason for hiding this comment

hmalik88 Apr 13, 2023

Choose a reason for hiding this comment

bumblefudge Apr 13, 2023

Choose a reason for hiding this comment

hmalik88 Apr 13, 2023

Choose a reason for hiding this comment

bumblefudge commented Mar 2, 2023 •

edited

Loading

hmalik88 Apr 13, 2023 •

edited

Loading

bumblefudge Apr 13, 2023 •

edited

Loading