RFC 302 Aries Interop Profile beyond existing implementations

[troyronda]

On the topic of RFC 302:

I understand that initial implementations coming from Indy want to better define interop between themselves. My interest is in contributing to a DIDComm protocol that leverages relevant standards and is agnostic to a particular DID network or governance framework.

Of course, I want to support existing Indy-based interop efforts, but at the same time, I am concerned about how this proposal (and associated labeling & process ideas) impact our efforts that are not rooted in Indy and initial formats.

With that context, my concerns with this proposal are:

1. The connotations of "stable" and "1.0". I believe a decentralized/P2P interop protocol should have usage in multiple ledger systems, multiple ecosystems (and use the relevant standards). It would be good to see more inclusion in the DIF interop efforts.
2. It seems to be contravening the RFC proposal process. The RFC status and lifecycle should not be superseded by a protocol suite definition. Protocol suites seem like an independent concern from RFCs.
3. We haven't defined what happens to the rest of the community efforts (to achieve a DIDComm applicable to a wider ecosystem). i.e., we don't want to lose sight of getting to a standards-first interop approach that is agnostic of DID networks and ecosystems.

• How do we ensure that RFCs do not become locked down as has been suggested in the PR (Initial version of the Aries Stable RFC #302)?
• How do we ensure that this proposed protocol suite actually moves forward as new efforts complete? Will we end up needing an "Aries X" protocol suite based on the "X" branch of aries-rfcs that is defined as didcomm.org?
• Who else will be working on this other branch of DIDComm?
• How do we ensure that the labels and processes still facilitates other community efforts, like aries-framework-go, that do not use the definitions in this protocol suite proposal.

[swcurran]

My thoughts on these comments:

1. We are not declaring Aries itself to be 1.0 (which would require what you are saying to be complete), but rather defining a way for authors to independently deploy working software we have today that is likely to work together with other implementations for a period of time. We've been building for 2 years, and have had more-or-less interoperable implementations with 2 other groups for about 8 months. We'd like all of those deploying solutions to be able to work with what we and others build.

I believe that multi-ledger support can be implemented on an Aries Stable 1.x base, but until someone wants to invest in trying to do that, we'll never know. Failing that, we'll wait for the efforts of Aries Core, etc. I can't at this time see a way to include the DIF Interops efforts available today, but look forward to combining DIDComm and DIF Interop efforts.

2. RFC 302 is a concept RFC, not a feature and I don't see that it contravenes the RFC lifecycle other than to say that certain PRs to the RFC will need community approval, much as changing the status of a protocol needs community approval. When the DIDComm RFCs move to some place else, this RFC will remain with Aries, as it is not about DIDComm, it just references the protocols.

3. Evolving DIDComm is a separate concern and not the purpose of RFC 302. Evolving DIDComm needs to be done - absolutely, and I think (hope) Rouven has some information on that, but that's very separate from this effort. Likewise, building out a non-Indy-SDK basis for Aries needs to be done - what's been called Aries Core. That absolutely needs to be done.

On your points:

1. I suggest that some folks - perhaps led by you - will at some point define an Aries Stable 2.0.0 target that all agent builders can aim towards. We (VON Team) will continue to be working on the efforts beyond Aries Stable 1.0 to implement new protocols, continuing to help with the creation of Aries Core, and enabling support for multiple ledgers. This RFC is because we have fully working software and we're struggling to make it work with other fully working (but slightly different) software.

2. I don't know what you mean by "X" branch.

3. As to who will be working on the "other branch of DIDComm" - If you mean on evolving the DIDComm protocols, I think it is the same group of people that have been doing it to now - hopefully with more folks from DIF contributing. We certainly don't want to see that effort slow down in any way. In our experience on this effort, defining a protocol takes WAY longer than implementing an agreed upon protocol.

4. As you mention above, the goals of aries-framework-go are such that there is little interest in Aries Stable 1.0, and so I recommend defining (now or when you are closer) Aries Stable 2.0 and build to that - along with others (including ACA-Py - we'll try to keep up). Your team will see the same benefit when the time comes of being able to interop with others, as we would like to see now with the working software we have.

[swcurran]

I've put in a PR #320 to change the name to Aries Interop Profile per the call yesterday, and to further refine 1.0.0 a little. Can we close this issue? @troyronda @dhh1128

What else is needed to get that RFC to an Accepted state? IMHO, we've had AIP 0.9.0 since the IIW in March, and so I'd like to get us to 1.0.0 pretty quickly.

[troyronda]

Hi @swcurran . Thanks very much for updating your proposal to AIP.

1. Resolved. We are talking about interoperability profiles and assigning versioning to the profile. This versioning is independent of the project and codebases.
2. I agree with the point that the AIP RFC needs community discussion to update. I was more curious about what was meant by "any of the links".

and/or any of the links to concept and feature RFCs.

I assume that the linked RFCs follow the normal RFC lifecycle. If that remains the intended meaning, it wouldn't hurt to make that point explicitly.
3. I agree it is a separate concern... as long as we don't get stuck :).

Regarding "On your points":

1. Agree - we should start mapping out the next target batch of RFCs (part of the "we don't get stuck" story).
2. "X" was simply a placeholder for whatever we call the next target batch of RFCs. E.g., 2.x.x, Core, ...
3. Agree.
4. Correct, we are really primarily targeting a "next" Aries iteration (aligned with the above goals). Of course there is still overlap in aries-framework-go with some of this RFC list. A longer topic beyond the current discussion, of course.

[troyronda]

One other point beyond my replies above.

I was wondering if a protocol like RFC 95 (Basic Message) is part of the Interop Profile. (or if there end up being levels ... e.g., "basic profile" vs "extra features"... just a thought).

[swcurran]

I think we are in agreement on the following, and it is certainly the intention of the RFC to mean what you have said:

I agree with the point that the AIP RFC needs community discussion to update. I was more curious about what was meant by "any of the links".

and/or any of the links to concept and feature RFCs.

I assume that the linked RFCs follow the normal RFC lifecycle. If that remains the intended meaning, it wouldn't hurt to make that point explicitly.

In the AIP RFC, for each major AIP version, there are a list of links to specific commits (never to master) of the referenced RFCs. Any change to those reference links in the AIP to point to other commits requires builder community agreement, as each such change could impact the adherence of implementations/deployments to the AIP version, or the creation of a new version.

The RFCs absolutely continue to evolve completely independent of the AIP process.

On this question:

I was wondering if a protocol like RFC 95 (Basic Message) is part of the Interop Profile. (or if there end up being levels ... e.g., "basic profile" vs "extra features"... just a thought).

I don't think we should have the additional nuance of basic vs. extra until we find we need it. As such the "Is RFC 0XXX in or out for AIP X.X.X?" would be the builder community debate/decision.

My opinion (FWIW) specifically on RFC 95 is that (a) it's the easiest protocol to support and (b) we think it will be very helpful in many B2C scenarios. In fact, we think the more advanced ActionMenu (not yet an RFC) is also going to be very important.

[troyronda]

@swcurran This issue should probably be closed. Thoughts?
I don't think there were any remaining discussion topics in this thread?

Any change to those reference links

As mentioned above, you are talking about changes to the links in the AIP RFC not the linked-to documents.

[swcurran]

Agreed. I think we've made good progress on what this is going to be. Now to try it and see what it is :-). I'm already seeing for example that being able to quickly see the difference between what's in the AIP and what's in the RFC on master is pretty interesting for maintenance. It needs to be automated.

Let's close this and more discussions will happen in other issues and PRs.