IOTA DID Communication RFC - Feedback

[JelleMillenaar]

Introduction

In this Github Discussion, you may provide feedback, comments and propose changes to the IOTA DID Communication Specification that is currently in the Request-for-Comments (RFC) phase. You can find the full specification on our wiki. The RFC phase is planned to last for at least one month, but may stay in that state longer.

The DID Communication (DIDComm) specification is built on top of the standard-in-development from the Decentralized Identity Foundation (DIF). They present a way to format and encrypt messages, while our specification focuses on providing "protocols" on top of this, which standardize how two or more identities may interact with each other. Standardization of these processes allows for interoperability between IOTA Identity powered applications, which is beneficial for establishing a strong ecosystem. After the RFC phase, the IOTA Foundation will implement the spec into the IOTA Identity framework, initially in Rust, with JavaScript bindings.

Feedback

When you want to provide feedback, please specify clearly about which section of the standard you are talking about. Specifically the protocols should be clearly stated, including which version. We may already implement some of the discussion into the specification, in which case we will update the version number. Please make use of threads to reply and feel free to spread your feedback over multiple comments in order to spawn multiple threads focused on different topics such as different protocols. Please do at least scan the discussion before commenting in order to prevent duplicated discussions.

[MikeHypercube]

It is a bit misleading that this work is referred to here and in the blog post as 'The IOTA DIDComm Specification' when DIDComm is the name of the specification developed by DIF (of which we are not a member, neither are we part of the DIDComm WG). For a reader who has not read the DIF material, it reads like this is the unique name of a specification developed by the IOTA Foundation itself rather than the name of the standard of which this is an implementation or extension. Suggest we come up with a unique name for the corresponding IOTA Standard (Assuming it is a standard in the normal sense of that word?)

[JelleMillenaar]

Protocol: Authentication
Version: 0.1

In the Authentication flow, the Requester sends the initial Challenge to the Responder, including their DID. This immediately reveals the DID of the Requester. There might be situations where the Requester wants to initiate the Authentication protocol, but not reveal his DID until the other side has done so. Would it be worth it to make the DID optional in the initial signed authentication-request? If yes, this does increase the complexity of the exchange as it would be revealed later, increasing the amount of steps needed to fulfill the authentication.

[JelleMillenaar]

Protocol: Issuance
Version: 0.1

Alternative Start

When the Issuer initiates the Issuance protocol, they might initiate with a Presentation protocol as they require more information. This Presentation request from the Holder will then be received without any context and this might even be hard to implement as their will be no "parent threadid" yet for the Issuance protocol since no messages are sent from that protocol.

Multiple Credentials

The Issuance protocol only allows a single credential to be Issued. Would it be possible to update the flow to allow multiple credentials to be given out in one interaction?

Non-repudiation

Currently, the issuance-offer contains a means of non-reputation, which might not really have a use. The Holder would have proof that the Issuer offered an Issuance, but why would he ever use that? I feel like it might be a bit overkill on the non-repudation.

[JelleMillenaar]

Protocol: Signing
Version: 0.1

Would it be possible to reuse this protocol to also allow the signing of arbitrary data, instead of just unsigned verifiable credentials? Or would this need another protocol?