Non-Issuer provided Render Methods.

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?

No file or test is named. Start by reviewing the current issuer-provided render-method model and the proposed appendix about render methods supplied by credential type creators; done would require a decided specification approach for non-issuer-provided methods and its treatment in the project documentation.