In 3.0 there will be well defined string names used for various purposes. The design document has this to say about it:

Names are required for algorithms, parameters, and properties. In order to ensure consistency and to enable external Provider implementers to define new names in a consistent way there will be a registry of recommended or used names. It will be maintained separately from the sources.

So far not much thought has been given to what that registry will look like. IMO there should be:

• A well defined format that can be made human readable and machine readable (see below)
• For each name a clear definition of what it is to be used for (e.g. algorithm name, property name, parameter name)
• For parameters we should be defining
  • The algorithm the parameter is associated with and what it is to be used for (e.g. is it associated with the private key? the public key? other agreed parameters?) etc
  • The expected type and (where appropriate) the width of the parameter (e.g. if it is an integer is it 32-bit/64-bit/multi-precision?)
• For properties we should be defining
  • Valid values
• Parameter names probably need to be unique within the scope of an algorithm but not beyond that, e.g. DSA has a "p" parameter, and so does DH; but they should be considered as different to each other.

The format should either be directly human readable or be able to be transformed into some human readable format so that it acts as documentation for Provider developers.

The format should also be machine readable so that we automate checking that OSSL_PARAM instances meet the requirements (possibly we could choose to just do such checking only in debug builds for performance reasons). We'd also have to be able to cope with scenarios where there is no well defined format (e.g. where an external provider is developed using parameters unknown to libcrypto).