Repository navigation
Non-Issuer provided Render Methods. #78
Description
Activity
+1 to use cases where other entities author render methods and that these are published and delivered to renderers outside the credential content itself.
Being able to match up credentials (e.g. by Type) to standard-format templates could help renderers support a broader range of credential types over time.
Reacted by BigBlueHatExpressing a render method as an externally linked VC (but including the necessary dispatch/selection info and the expected issuer that will sign that external VC) could be part of the solution here.
The conversations thus far have expected issuer to be the prime operators in the creation of Render Methods. However, many/most Issuers actually lean on standards bodies (consortiums, governments, etc.) to determine the credential types and those same groups (or connected ones) frequently define design (and even material shape/size) of how a credential is displayed.
Consequently, we should consider adding (at least) an appendix that explores non-issuer provided render methods to provide a means for credential type creators to provide render methods relative to the type rather than relative to (i.e. embedded or references from) a single credential (provided by the Issuer).
One scenario, imagine a Credit Card credential type + one or more Render Methods provided by Visa/Mastercard/etc. vs. by every bank that issues Credit Cards.
Considering this possibility may also help us avoid redundant information being pushed around and reprocessed if/when/as the same credential type gets used frequently (or when render methods are themselves large).
Thoughts?