Add support for non-SDK annotators in config

[tsconn23]

A use case has been articulated whereby a customer utilizing the DCF wants to define an annotator and not have it included in the SDK. This could be for a few reasons:

• The logic in the annotator is proprietary
• The purpose of the annotator isn't widely generalizable
• The developer doesn't utilize any other language implementation of the SDK and doesn't want to port the annotator

During the Alvarium TSC call os 25-Mar-2024, an approach was demonstrated whereby the sdk/annotators portion of the config was separated into two arrays -- basic and extended.

• basic is an array containing keys to annotators implemented in the SDK
• extended allows a developer to define an array of keys for custom annotators

basic would facilitate the current method of looping through the annotator keys and instantiating each one at application startup through the normal factory pattern. extended could be used in a similar fashion if the developer needs to instantiate multiple custom annotators. Alternatively, if there is only one custom annotator, the developer could ignore this property and inline the instantiation. For example:

        // List of annotators driven from config. Initialize basic SDK annotators first, followed by custom/extended.
	var annotators []interfaces.Annotator
	for _, t := range cfg.Sdk.Annotators.Basic {
		instance, err := factories.NewAnnotator(t, cfg.Sdk)
		if err != nil {
			logger.Error(err.Error())
			os.Exit(1)
		}
		annotators = append(annotators, instance)
	}
	// The custom annotators implemented in this app follow. This could be a loop as well.
	bootAnnotator := local.NewSecureBootAnnotator(cfg.Sdk)
	// Add custom annotator to list of annotators passed to SDK
	annotators = append(annotators, bootAnnotator)

An example of the new config definition in JSON follows:

"sdk": {
    "annotators": {
      "basic": ["tpm", "tls"],
      "extended": ["secboot"]
    }
    ...
}

In addition, standardized functionality provided by the SDK to support hashing and signing needs to be exported somehow for developers writing custom annotators. It's possible this could be done by adding respective support in our factories.

[tsconn23]

Tagging @DyrellC and @Ali-Amin for any subsequent comment. If none is received, I'll contribute the code for this issue as it's already written locally.

[Ali-Amin]

@tsconn23 Not sure why we need to have the 'extended' annotator keys in the config, is it to add support for runtime config of these annotators or is there another reason ?

[tsconn23]

@tsconn23 Not sure why we need to have the 'extended' annotator keys in the config, is it to add support for runtime config of these annotators or is there another reason ?

It wouldn't be runtime support b/c if you change the config after the app is running, the change isn't detected until a restart. The two reasons I was thinking are

• If there are multiple custom annotators, allow the developer to instantiate them in a loop through a factory abstraction similar to how the basic types are done rather than in-lined one by one.
• To provide a declarative way of seeing first of all that the app runs more annotators than those included in the SDK, and secondarily which annotators they are.

[Ali-Amin]

@tsconn23 Not sure why we need to have the 'extended' annotator keys in the config, is it to add support for runtime config of these annotators or is there another reason ?

It wouldn't be runtime support b/c if you change the config after the app is running, the change isn't detected until a restart. The two reasons I was thinking are

• If there are multiple custom annotators, allow the developer to instantiate them in a loop through a factory abstraction similar to how the basic types are done rather than in-lined one by one.
• To provide a declarative way of seeing first of all that the app runs more annotators than those included in the SDK, and secondarily which annotators they are.

Got it, no comments from my side then.

[tsconn23]

I have edited the title of this issue to reflect a descoping. I am going to move the changes to support the following logic into another issue.

In addition, standardized functionality provided by the SDK to support hashing and signing needs to be exported somehow for developers writing custom annotators. It's possible this could be done by adding respective support in our factories.

Externalizing new factories to allow SDK consumers to leverage hashing and signature implementations in their own annotators can be done independently of the above configuration changes.