Defining objective criteria for protocol comparison

[mathieuglaude]

Here are some ideas based on prior conversations and yesterday's kickoff session:

About

1. Specification link and versioning: Availability of specification documents and version history
2. Specification Status: The maturity and stability of the protocol specification
3. Specification Body: The organization responsible for maintaining the protocol
4. Profile Objective(s): The primary goals and use cases the protocol is designed for
5. OSS/IPR: The open-source status and intellectual property rights associated with the protocol
6. TRL: Technology Readiness Level: Adoption and readiness of the technology

Use Case Support

1. Additional Features: Additional features and capabilities provided by the protocol
2. Support for Additional Trust Tasks: The protocol's support for other trust-related tasks
3. Offline/Online Support: The protocol's support for offline and online scenarios
4. Designed for Mobile Device Use: Is the protocol designed to be used by mobile devices
5. Designed for Web Browser Use: Is the protocol designed to be used by browsers on any computing devices
6. Use Case Flexibility: The various types of use cases supported by the protocol
7. Relationship Context: The dynamics of connections among parties in the protocol

Other ideas

1. Architecture dependencies (e.g., on layer 2 transport mechanisms) (e.g., client-server architectures vs p2p)
2. Features (e.g., online/offline)
3. Architectures
4. Support of credentials (e.g., mDL isn't W3C)
5. Regulatory compliance (eIDAS 2.0)
6. Logical operations and/or XOR (being able to make a cred request for 2 different credentials - e.g., show me a covid pass and national id in one cred exchange request)
7. Rigidity and flexibility of protocol (e.g., how you can construct a proof request or issuance - comparing predicate proofs vs age proofs in mDL - mDL is rigid as issuer predefines the predicates - vs in Aries presentation exchange I can do greater than 1 or 2)
8. Do any of these protocols have implementation standards to help people adopting (e.g., best practices, test suites, certification programs which are signs of maturity)
9. Combining protocols - such as creating a DIDComm connection and then using OpenID4VCI for an issuance flow
10. Identifiers supported (classic web ids vs decentralized ids)
11. Developer Learning Curve: The difficulty level for developers to learn and integrate the protocol
12. Deployment Complexity: The complexity and cost associated with implementing the protocol
13. Performance/Scalability: The protocol's efficiency and ability to handle growth
14. Security: The various security features and mechanisms provided by the protocol
15. Privacy: The protocol's data protection and confidentiality features
16. Initiation Mechanism(s): The method(s) used to initiate a credential exchange.
17. Transport Mechanism(s): The method(s) of communication used for the protocol.
18. Deployment Viability: The likelihood of the protocol being widely adopted and deployed.

[vladevs]

IMHO, it would help (with protocol comparison) if we split the criteria into categories

• Why? -> What is the problem(s) the protocol is trying to solve? In our list, this would be Profile Objective(s). Once this is clearly defined, it sets the stage for the comparison afterwards and hopefully avoids / reduces unproductive apples-to-oranges debates.

• How? -> How does the protocol solve the problem(s)? Basically, everything else in our list would classify here.

The "How" category can be further grouped into

• Governance (most of the stuff we have under About section)
• Features (Additional Trust Tasks, Relationship Context, Privacy, Security...)
• Use Cases (Mobile Device Use, Web Browser Use, Online/offline...)
• Adoption (Developer Learning Curve, Deployment Complexity, maybe also Deployment Viability although that one will most probably be subjective)

[mathieuglaude]

• perhaps a category of backing/support/community behind protocol (measuring this is a question to be answered)
• Maybe we can give the opportunity for protocol representatives to add new criteria if some if missing ("we're administering this TF, but we're not the SMEs" - messaging)

[mathieuglaude]

@vladevs created a document here: https://docs.google.com/document/d/1U76ShfeQtRci0AvIHwneLAy9c-XnhMPMkS_Qey4J3I4/edit?usp=sharing