IBC Enabled DIDs #8431
Replies: 10 comments 7 replies
-
|
Thanks @AdityaSripal for the wonderful write up!!! I will try to add any points of clarification or additional points for discussion. If we take in the context of a DID Registry, this proposal would be a subset of DIDs stored in that registry. Specifically, these are The DID Registry that supports these DIDs should allow both public and private DIDs to be registered. A point of discussion is if we should explicitly separate these DIDs by using separate method names for each? To add to the discussion on herd privacy, it makes sense to explicitly break herd privacy for IBC enabled DIDs since the DIDs are being used on-chain in a public manner. This makes the connection of a DID and a DID Document implicit. I think the flow of interaction might be a little unclear. Let's look at case 1. A user want to use some on-chain service using their DID.
Case 2 just uses a module initiated request and therefore bypasses authentication. An example might be a zone voting on the cosmos hub. Maybe some zone controls a pool of tokens on the hub. They vote locally on their zone for a hub proposal, the result of this action is then sent via the DID Module to the hub, where the hub would use application logic to apply the result of the vote by the zone This proposal is mostly an extension or plugin for IBC which allows for the glue code necessary for applications to use authentication schemes hosted elsewhere. I like to think of it as the OAuth2 for on-chain interactions. Now zones can use accounts with complex authentication schemes without importing and maintaining those modules. They can also support any number of authentication schemes without having to explicitly run the code for it. These ideas are largely what I see a lot of folks in the ecosystem discussing, the benefit of this proposal is that it would prevent redundant work from being done and increase interoperability A big part of the DID spec is minimizing authentication schemes to increase interoperability. The clever trick of this proposal is that it enforces everyone to agree to use IBC which implicitly gives us interoperability for any authentication scheme. We don't have to use a small list of auth modules since IBC allows us to interact with any of them without having to implement or run those modules ourselves |
Beta Was this translation helpful? Give feedback.
-
|
I think some important understandings about this proposal is that it does not propose to do anything that cannot be done, it proposes what other combinations of solutions propose to do, but it does so in a reduced/simplified fashion by limiting the amount of connections necessary, the amount of authentication modules necessary, and the amount of application modules necessary. In comparison to Interchain Accounts, from my understanding, Interchain Accounts allow a user or some entity to interact with an account on another chain via IBC, however, this interaction requires authentication/application logic all to be performed on the chain at the other end. IBC enabled DIDs allows for:
Another question is why DIDs? This implementation could be done without some notion of DIDs. Conforming to the DID specification allows interoperability with existing DID implementations. It is not unfeasible an off-chain (but still public) application may require DIDs. It is also possible a subset of these DIDs must support on-chain IBC enabled authentication/application logic. In this case, we would need IBC enabled DIDs, not just IBC accounts. An example would be having an internet account that belongs to some community whose governance is hosted on a blockchain. To interact with the community governance, you need an IBC enabled DID. To interact with other internet accounts not in your community (and not necessarily IBC enabled) you need DIDs DIDs are not required for the IBC side of this, they just extend the use cases beyond IBC |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @AdityaSripal; this is quite comprehensive and seems well thought-out. A few questions:
Should there be an error (string) field for providing information on what kind of error occurred?
Thanks for the flow-chart - it's a little tricky to read though - have you tried Excalidraw? One concern I have with this design is that - if I understand it correctly - it basically requires giving the DID module "master authority" control over all other channels (at least any that wish to authenticate things using DIDs) - so the potential impact of bugs in the DID module itself is quite high. On the other hand, centralising authentication logic into a single module does reduce the surface area of potential bugs (vis-a-vis spreading it out between different modules). Any thoughts on these trade-offs? Another, related, question - how will channel establishment work? How does the DID module acquire the ability to send on specific application channels in the first place - can that also be authenticated in some way? Is this done by the user setting up the channel (who creates the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Chris, great questions.
Yes, the custom auth module should send back a string that provides detailed information for the user.
Yes, anyone who chooses to use DIDs as a central authentication layer is relying on the correctness of the DID module. Thus, the DID module must be carefully written to ensure correctness. Part of the design goal is to reduce the surface area of bugs. It is very important that the DID module is correct, so that custom auth modules can simply focus on authenticating a
As usual relayers will mediate channel creation. However, users can send msgs to the DID module to start a Similarly, if a user creates a new Depending on the port, the DID module will execute different callback logic. In the implementation of the IBC module, there will be a switch on the port string to execute the two different callback logic. A A The reason I namespace the ports this way is to provide versioning for the DID module and to allow fine-grained control for the custom counterparty modules. Counterparty modules can connect to a This will allow a single custom auth module to support many authentication schemes by adding suffixes to the port: Similarly with app modules, each interaction with the app can be given its own port suffix. In the case of the Chain-Naming-Service, examples might include: A detailed writeup on the exact did module callback logic will be done separately. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a flow of Case 1. If given time I will add some more cases with greater complexity. Note this is a simple case, there can be many more layers of complexity for the DID Document. It could be using multiple different services with multiple different authentications. The authentications could be on the local host (cosmos hub) or on a different chain. The ethereum chain might be used in future examples which is why it is there
|
Beta Was this translation helpful? Give feedback.
-
|
@AdityaSripal - nice write up. There is a lot to unpack. Could you explain the following concepts please?
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Did anyone use DID in URLs? We have a problem with Using Questions
|
Beta Was this translation helpful? Give feedback.
-
|
A DID is a URI. It's possible that the colons in DIDs are interpreted incorrectly by browsers and other tools. I don't know of a solution to that as of yet. I think using all user addresses as DIDs is a great idea and something we will probably incorporate. As you said, in this case we don't need a separate DID object, since the DID information can be inferred from the public key. However, as part of the design, we want to create DIDs for more complex entities (governance, validator sets, organizations etc). These complex DIDs might have more complex authentication methods, and they may have delegated permissions and capabilities to other simpler entities. However, all of that complex permissioning and authentication will be handled by the DID module. From the application point of view, there should be no difference between interacting with a DID controlled by a single user (through their blockchain address) and interacting with a DID that is really representing a complex organization with a complex authentication scheme. |
Beta Was this translation helpful? Give feedback.
-
|
@AdityaSripal - the problem is for example with grpc. It doesn't like it if we put a DID in a path (even if we do Even if we will use I think it's a problem if we will require tools to be compatible with DIDs and handle addresses which are not DID compliant (except if it's only about prepending For more context: At Regen, we were originally using |
Beta Was this translation helpful? Give feedback.
-
|
@robert-zaremba have you found solution to this problem? We are facing the exact same problem |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
On our Discord channel (core-sdk) I published a doodle to plan a DID / Group Module / x/auth sync call. Please fill today. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, Switching to According to RFC3986, colons should be fine in the path part of a URL. However, as @AdityaSripal pointed out, parser implementations may vary. Perhaps more on point: |
Beta Was this translation helpful? Give feedback.
-
I know ;) I just posted an example with hope that it will be obvious what's host and port. |
Beta Was this translation helpful? Give feedback.
-
|
@AdityaSripal Thanks for the detailed work. For the most part, it looks great. The DID syntax in particular is spot on. There are two points I'd like to raise, however. First, the non-standard use of authentication in service endpoints may cause problems as it conflates authentication and authorization. The "authentication" property at the top-level of the DID document specifies an authentication verification relationship that basically says "use this[these] verification method[s] for authentication on behalf of this DID". The authentication property in service endpoints is undefined. A key notion in this discussion is that the way JSON-LD proofs work, is that they specify a proof purpose that should match to a verification relationship as specified by the DID controller (typically in the DID document directly). For example, "authentication" is (1) listed as a verification relationship in the DID document, where it links to a verification method (public key), then in an authentication ceremony, a challenge string is signed by the private key associated with that public key in the verification method for authentication AND the proofPurpose for that signing is "authentication". The short of it is that using a verification method defined only for authentication to do authorization is a mismatch that will appear as a fraudulent purpose (because it wasn't used for authentication, it was used for authorization.) Second, the notion that some DIDs are public and some a private is a misframing that will likely cause problems. FWIW, I wrote that section in the DID Spec on service privacy considerations. The issue is multi-layered. First, public and private is not a binary distinction. I wrote about this a few years back http://blog.joeandrieu.com/2011/04/10/constellations-of-privacy/ The TL;DR is that Context matters. Some things are too private for a public restroom, while other things one may do in a public restroom are not appropriate on a public sidewalk. We participate in a myriad of contexts with a wide range of privacy. Second, all DID Documents should be considered public because the normal use of a DID requires resolving the DID to a DID Document before you can verify a secure channel of interaction. So, if you can't get to the DID Document in a publicly non-repudiatable manner (like when anchored on a DLT), you can't interact with the DID or work with it in any way. Private DID Documents are like restricting DNS records. It breaks the system. There are work arounds for these issues that we have been discussing in the InterNFT conversations, especially with regard to privatizing metadata as well as using Authorization Capabilities so that authorizations can travel with the functionality, even across chain. Happy to discuss further. |
Beta Was this translation helpful? Give feedback.
-
|
Had a quick checkup with @jandrieu . Attaching an image from a design we drafting at the beginning of the year.
|
Beta Was this translation helpful? Give feedback.
-
IBC Enabled DIDs
Background Reading
https://www.w3.org/TR/did-core/#introduction
Context
As the IBC ecosystem evolves, there will be many different applications and many different entities that will want to interact with those IBC applications. The basic use case is that a single user wants to authenticate an IBC packet being sent. This is simple enough to implement with the
x/authmodule in the SDK. Even a well-defined, constant set of users is relatively simple to implement using the MultiSig provided in thex/authmodule. These authentication schemes may be sufficient for apps like the ICS-20 token transfer module.However, the set of entities who wish to send IBC packets will naturally become more complex and diverse as the set of IBC applications becomes more complex and diverse. For example, a tendermint validator set may want to be able to authenticate and send IBC packets. Blockchain governance may also want to send IBC packets to other chains on the basis of passing a proposal. All of these entities will need to implement their own form of authentication that must pass in order to send the IBC packet. If each authentication scheme is implemented in a different way, then IBC applications that need to process an "authorizing party" before sending the IBC packet will have to explicitly enable each authentication scheme.
To take the transfer case; in order to allow blockchain governance or a validator set to authorize a transfer packet, ICS-20 either has to implement these authentication schemes itself. Or each authentication module implemented as a standalone module must include a transfer keeper which will send the packet on successful authentication. This does not scale as the number of authentication schemes and applications wish to interoperate.
Instead a uniform authentication layer that sits between specific authentication schemes and their end applications will provide a uniform interface across which entities can authenticate interactions with IBC applications. This would allow arbitrary authentication schemes to implement the interface for authenticating via the uniform authentication layer without understanding the IBC applications the user data is intended for, and applications can simply receive successfully authenticated user data from the universal authentication layer without understanding how the data was authenticated.
At the same time, as the IBC ecosystem develops; there is also a developing ecosystem around DIDs. A DID is a decentralized identifier identifying a subject (e.g. internet user, land title, image, etc) that resolves to a DID document, which can contain information on how to authenticate interactions from the subject and specifies available services related to the DID subject (Eg twitter account, inbox, etc).
The DID document for an internet user might include their public keys and which public key should be used for which interaction. Perhaps the DID document specifies an ED25519 PublicKey for authenticating web log-ins, and a JsonWebKey2020 for negotiating secret keys for communication. The (DID, DID Document) pair is maintained on a public ledger and allows the DID document to be updated, allowing other parties to authenticate interactions from the DID subject even as public keys are rotated.
This again works fine in the case of a single user or a well-defined constant set of users, since these verification methods can be encoded in a public key or multisig. However, these methods make it difficult for more complex entities like a rotating validator set or blockchain governance to identify itself with a DID and define specific verification methods for specific purposes.
We can use IBC to provide more flexibility in how DIDs authenticate and verify subject interactions AND use that DID module to serve as a uniform authentication layer for IBC applications.
Design Goals:
IBC Enabled DIDs
We can implement arbitrary authentication logic by offloading the authentication work to another module. We do this by defining a new verification type, in addition to the standard PublicKey types, called
DelegatedIBCAuthentication.The
DelegatedIBCAuthenticationtype has two required fields:delegateTo: This is the channel the DID module will delegate authentication to. The module on the other side of the channel will receive an authentication request from the DID module. If the module send back a successful acknowledgement, the DID module will interpret this as successful authentication.app-specific-verify-fields: This field contains all the application specific parameteers necessary to authenticate interaction with the DID. All parameters and data regarding authentication should be housed here, the module should simply be responsible for injesting these parameters along with user provided authentication and performing the logic necessary to authenticate. No state necessary for authentication should be stored in the counterparty module.DID Document Format
DID:
did:ibc:cosmos-hub:channel:module:module-specific-idThe DID module can delegate authentication to the module specified in the
delegateTofield by sendingDelegateAuthPacketDataover the specified channel.The module can then send back the
DelegateAuthPacketAck. If there is an error, the DID module does not authenticate the subject interaction. If the ack is a success, the DID module will authenticate the subject interaction and pass the authenticated data back to the application.Delegated IBC Services
The DID module can act as a authentication layer that sits between specific authentication schemes and applications. Thus, once an interaction of a DID subject has been correctly authenticated, the DID module should be able to send an IBC packet on behalf of the subject.
If a
DelegatedIBCServicepacket is sent with the DID's authentication relationship, then the DID module will forward the packet so long as the authentication succeeds.However, DID documents may specify services that allow delegated ability for authorized parties to send packets along specific channels.
In this case, the DID module checks that the authentication specified for the particular service requested is successful and then forwards the authenticated data to its destination.
The service on the other end of the channel, is responsible for decoding the application data and processing it. The service MAY choose to send an ACK back to the DID module, though it is not required. The DID module will simply log the success or failure of the packet in the events.
Packet Flow(s)
This design enables two possible packet flows depending on context. All packet flows must be triggered by an end user. That end user may choose to interact with the DID module, which will authenticate and then forward an IBC packet to the application module. Or they can send a msg directly to the authenticating module, which will send a packet through the DID module and then to the application module.
Use case 1:
Use case 2:
Examples
Here is a DID that defines how a chain interacts with the Chain-Naming-Service module over IBC. Here blockchain governance maintains the DID document and can send arbitrary packets to the CNS and other modules. However, the document also specifies delegated authorities that can only send packets across specific channels. DID subjects can use this to specify which authorities can send packets across which channels. Applications can use this fact to listen on multiple ports and thus provide the ability for different authorities to authorize different interactions for the same subject.
DID:
did:ibc:cosmos-hub:channel3:cns:ethermintNOTE: The names of the ids may not be human meaningful. This is a TBD part of the design. They're left here meaningful while still respecting the DID URI spec for readability.
Herd Privacy
An important notion in DIDs is the notion of herd privacy, ie the idea that indistinguishable (DID, DID Document) pairs provides some level of privacy for each indistinguishable (DID, DID Document) pair.
However, this would prevent the use of arbitrary authentication schemes and the ability to authorize IBC interactions using the DID document since the authentication schemes used and the types of IBC services supported by a DID subject leaks some information as to what the subject might be. The above example is pretty obviously describing a blockchain.
Thus, any DID that uses
DelegatedIBCAuthenticationorDelegatedIBCServiceshould not expect herd privacy. DID subjects intending to preserve privacy should stick to native verification methods and not offer any services (apart from perhaps a third-party mediator service desribed here). Furthermore, the DID subject should take care that their private DID(s) is not publically correlated with a IBC-enabled DID that they might use.PacketFlow1
PacketFlow2
Beta Was this translation helpful? Give feedback.
All reactions