Add interaction protocol registry.#680
Conversation
| with caution. | ||
| </p> | ||
|
|
||
| <table class="simple"> |
There was a problem hiding this comment.
Outstanding questions regarding this registry:
- Should we add an entry for DIDComm?
- There was recent mention that DC API is not an appropriate protocol to include here because it is captured at an earlier context in the browser. Could someone confirm this for me?
- Are there any other protocols that we should include in this registry in version 1.0?
- For the
[[OID4VCI]]and[[OID4VP]]references, these point to the listed normative references, which are locked to specific versions. However, the expectation as of now is that the keys should always point to the latest version of the protocol. Is there a way to reference a resource/document without tying it to a specific version (e.g., the way that https://www.w3.org/TR/vc-data-model/ always points to the latest published recommendation for VCDM)? - Should we add a mechanism for implementers to provide versioned protocols in addition to the latest protocol properties currently specified. For example, an implementer that wants to use version 1.1 of
aGoodProtocolmight provide a property likeaGoodProtocol_1_1/aGoodProtocol-1_1/aGoodProtocol_1.1/aGoodProtocol-1.1/\*something_else\*? This would address the concern raised by @BigBlueHat on our last call regarding the ambiguity of protocol versioning. It would place the onus on implementers to know that they should either 1) update their implementation to the latest version if they want to use the generic keys or 2) update their keys to use the versioned keys if they are not ready to take on the development cost of a version upgrade, but this may be the best way to avoid ambiguity. Open to opinions/rejections/modifications on this approach.
There was a problem hiding this comment.
Additionally, I noticed the mdoc-openid4vp protocol in Issue #537. Does that need to be added as well?
There was a problem hiding this comment.
@kezike I can propose a didcomm format after this pr landed
| Below is a registry of interaction protocols that are supported today. | ||
| There is broad interest in extracting this registry into a separate |
There was a problem hiding this comment.
I think we should avoid using the term "registry" here -- this is just a table expressing protocols known to be in use today and there isn't any formal registry or registration process (and no gating). Some kind of registry (formal or information) or "directory" is what might be created later as mentioned.
| Below is a registry of interaction protocols that are supported today. | |
| There is broad interest in extracting this registry into a separate | |
| Below is a table of interaction protocols that are supported today. | |
| There is broad interest in extracting this table into a separate |
| implementaters SHOULD use that reference as the authoritative guide | ||
| for protocol usage. In the event that there is a conflict between the | ||
| registry listed below and the external registry, implementers SHOULD | ||
| be aware of versioning differences of this specification and proceed | ||
| with caution. |
There was a problem hiding this comment.
Removes "registry" language and tweaks to normative language that can't be tested:
| implementaters SHOULD use that reference as the authoritative guide | |
| for protocol usage. In the event that there is a conflict between the | |
| registry listed below and the external registry, implementers SHOULD | |
| be aware of versioning differences of this specification and proceed | |
| with caution. | |
| implementers are expected to use that reference instead of this table | |
| for protocol usage. In the event that there is a conflict between the | |
| table below and information in the new reference, implementers | |
| ought to note versioning differences of this specification and proceed | |
| with caution. |
|
Let's not call this a registry. Simply list it as a set of related resources. |
|
Discussed: omit versioning for now, likely provide non normative guidance that protocols can include versioning in the protocol key with a specific format. Limit initial "registry" (might not want to call it a registry) to current "mainstream" protocols Mention warnings around the oid4* protocol keys and their associated versions/drafts. |
4 participants
This PR addresses Issue #642 by adding an interaction protocol registry.
💥 Error: 500 Internal Server Error 💥
PR Preview failed to build. (Last tried on Jul 20, 2026, 9:34 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Spec Generator - Spec Generator is the web service used to build bikeshed/ReSpec specs
🔗 Related URL
Error output:
This seems to be an issue with the Spec Generator service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can report the issue to the maintainers of Spec Generator directly. Please be courteous. Thank you!
If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can file an issue with PR Preview.