Dynamic update-ability of Render Methods.

One of the common use cases and expectations for remotely referenced render methods is that they could be updated dynamically if/when branding or designs changed. However, that does not seem possible--even if remotely referenced--as the specific Render Method template resource is always bound to the credential at issuance time. This is certainly true if the template is stored "statically" within the credential, but it is also true for remote resources if/when a digestMultibase is included for stability or security.

So, if a render method includes both a remote URL and a digest, that credential MUST be reissued if/when the Render Method for it needs to be altered.

First, we should call out that requirement--and the risks of not including a digestMultibase value.

Second, we may also want to consider an alternative architecture where Render Methods are provided relative to credential types and context URLs vs. directly "within" the credential. Such an architecture would give more control over render method distribution--tying it to context publication (most likely)--and could lean on our other work such as VC Recognized Entities for the "authority" (and provenance and security) of those renderers.

This feels like an essential point that we've overlooked during our other conversations.

Cheers!
🎩

No files, tests, or entry points are named. Start by reviewing the Render Method specification and the existing discussions about remote resources and digestMultibase, then define the documentation requirement and architecture decision before implementation.