I suspected this one would be the most difficult for me to explain. Thank you for communicating this, I now know how to clear all of this from any misunderstanding.
II already integrates with other dapps. But it does this not through canister calls, but through the browser.
When you open NNS dapp, it offers you to log in with Internet Identity. When you click on this button, it opens up another browser window with the Internet Identity dapp. Then, these two dapps talk to each other (integrate) and to you, by guiding you though screens, and you getting logged in.
ICRC-35 is just a generalization of this flow, which I believe, could be applied to any other web-service.
So you propose to make any web service an identity provider?
I wouldnât explain the âintegrationâ in the way youâre suggesting - I would say wallets provide dapps with an identity, and it just so happens II does it this way.
No! Wallets provide dapps with an identity, everything like youâre saying. But users donât use wallets to talk to service B, while being at service A. Instead, service A just talks to service B directly, via the browser. The user might have identity X on service A and identity Y on service B - the integration will still work and be trustworthy, because the user (the browser) himself passes the data between dapps, without relying on any other party.
Moreover, a user might even use different wallets, interacting with services A and B - one wallet for A and another for B. Services A and B may be from completely different universes - A may be an IC-dapp, B may be a traditional centralized app. Everything will still work, because it is just a browser API.
UPD: Wallets are not even required at all, for two apps to talk to each other. A user may be authorized via Google to both of these websites.
Thatâs fantastic! Thank you a lot for this conversation. Now other people can just read it and get the right idea straight away.
I donât know. I asked on the call some time ago, if the goal of current standards is to enable interoperability, @frederikrothenberger said âYesâ.
I assume, you can count the II here, since it needs this protocol in order to provide other dapps with user identities. Yes, they use their own solution currently, but ICRC-35 was basically inspired by their solution, so it is the same thing.
You can also count MSQ. We build our business model around this - we plan to make money from people buying goods and services via MSQâs payments API.
Why? They already use the same thing. Wouldnât it be nice if this thing gets standartized and used more widely, benefiting the community as a whole, instead of only them?
If dapps can share data, they can also react to that data. Read the specification, once you have time, please. This is not just data sharing, this is a complete RPC. You can make other dapps do things you want, by sending them commands.
Now Iâm again under the impression we have a misunderstanding.
UPD:
If youâre a coding kind of guy, there is also a reference implementation with an example project. I suggest you to check it, if you want to understand the ICRC-35 better.
I donât know. I asked on the call some time ago, if the goal of current standards is to enable interoperability, @frederikrothenberger said âYesâ.
It is. However, the focus of ICRC-25 and its extensions is on use-cases that provide / manage identities. I.e. it offers interoperability between relying parties and identity providers / signers.
And in particular, we wanted to focus on enabling interoperability between relying parties and signers, without the signer having any relying party specific code / functionality. This allows the signer to provide identities to all relying parties that implement the standard, regardless of what their business logic is.
Hey there, @frederikrothenberger
Thanks a lot for your comments. Iâve posted my answer a couple of minutes ago and made the reference impl repo public (sorry for that).
Hey everyone. Following up on my vision for a universal standard that transcends fleeting trends, Iâve delved deeper into creating a transferable, platform-independent framework for public achievements.
This idea has captured my attention through my experience in the space, {r}elinkd development, ICP grant work, collaborations with PolygonID, Gitcoin Passport, POAP and more. So Iâd like to share a whitepaper that explores a framework of early concept for enhancing user reputation based on Internet Identity entity. Excited to hear your thoughts!
I would like to ask DFINTIY or everyone related to ICRC-35, when can we achieve this. All users of the IC ecosystem are suffering from wallet torture, please speed up the implementation of this plan
I have heard this 100 times in various occasions: âICP doesnât even have a good walletâ
Looking at this thread, I can understand the frustration and confusion, the thread itself hasnât been updated recently to reflect the ongoing status of the WG.
Quick reminder that the Identity & Wallets Standards WG meeting is scheduled 1 hour earlier than normal in the calendar.
Also the Ledger & Tokenization WG meeting 2 hours after that is relevant for wallet devs since one of the topics is regarding the index canister consumed by wallets to show transaction history.
By adding a heartbeat mechanism, both the Relying Party and Signer are aware of each others availability, allowing for reliable error handling when either window is closed.
The draft ICRC-39: Batch Calling standard was brought up again with an interesting example use case: approving multiple ICRC-2 allowances in a swap.
Limitations of batch calls on the IC have been discussed and an alternative standard to supersede ICRC-39 was proposed: a call sequence standard. Such a standard would allow for approving multiple calls in one go but clearly indicates that the burden of verifying if all calls succeeded is with the dapp.
Additionally it was discussed that this standard could indicate dependencies between various calls, so that the wallet knows in which sequence the calls should be made.
Iâd like to officially present to the community a new standard for review and invite for critique: ICRC-95, defining a parameter named icrc95DerivationOrigin.
Weâve known about and used the derivationOrigin parameter in authClient for years, and standardizing this now makes the parameter officially reliable for dapps and wallets to build with moving forward.
