❓ Clarification: Handling multiple renderMethod entries from multiple issuers

[amir-hameed-mir]

---

❓ Clarification: Handling multiple renderMethod entries from multiple issuers

I'm reviewing the current draft and trying to understand how to implement renderMethod for credentials with multiple issuers. The specification seems to have a gap when issuers provide conflicting render instructions.

---

Section 2.1

The spec says in Section 2.1:

"The value of the renderMethod property MUST specify one or more rendering methods..."

If I have a credential with multiple issuers, like this:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc/render-method/v1"
  ],
  "id": "http://example.com/credentials/123",
  "type": ["VerifiableCredential", "CrossBorderTravelPass"],
  "issuer": [
    "did:gov:usa",
    "did:gov:canada",
    "did:gov:mexico"
  ],
  "renderMethod": [
    {
      "type": "TemplateRenderMethod",
      "renderSuite": "svg-mustache",
      "template": {
        "id": "https://usa.gov/templates/travel-pass.svg"
      },
      "renderProperty": [
        "/credentialSubject/name",
        "/credentialSubject/passportNumber",
        "/credentialSubject/nationality"
      ]
    },
    {
      "type": "TemplateRenderMethod",
      "renderSuite": "svg-mustache",
      "template": {
        "id": "https://canada.ca/templates/travel-doc.svg"
      },
      "renderProperty": [
        "/credentialSubject/name",
        "/credentialSubject/nationality"
      ]
    }
  ],
  "credentialSubject": {
    "id": "did:example:traveler123",
    "name": "Jane Doe",
    "passportNumber": "P12345678",
    "nationality": "Dual Citizen"
  }
}

---

The Implementation Dilemma

1. USA's template shows passportNumber (for verification)
2. Canada's template hides passportNumber (for privacy)
3. Mexico has no renderMethod
4. All three are equal co-issuers

---

Questions Needing Clarification

1. Priority
   Should a wallet use the first renderMethod in the array? Last? All of them?

2. Consensus
   Do all issuers need to agree on presentation? If Mexico adds a third conflicting template later, what happens?

3. Completeness
   If issuers disagree on what fields to show (renderProperty), whose preference wins?

4. Liability
   If a wallet chooses USA's template (showing passport number) in Canada, who is responsible for the privacy violation?

---

What I Can't Find in the Spec

I've reviewed Sections 2.1 and 2.2, but can't find guidance on:

• How to handle multiple renderMethod entries (priority, conflict resolution)
• Whether renderMethod should be considered per issuer or per credential
• What happens when renderProperty arrays conflict between issuers
• Whether all issuers must sign or approve the render method

---

Minimal Request

Could the editors please clarify:

1. Is handling multiple issuers with potentially conflicting renderMethod entries in scope for v1.0?
2. If yes, what normative text should implementers follow?
3. If no, should we add a note about this limitation in Security Considerations or elsewhere?

This clarification would help avoid inconsistent implementations and potential privacy/security issues.

Thank you for your guidance!

---

[dlongley]

If I have a credential with multiple issuers, like this...

The VCDM only supports a single issuer. If a group of entities wants to issue a VC collectively, they can do so with a DID that represents their group -- and key management is an internal affair that can be done however that group desires without external exposure.

Does that avoid the above problem entirely without further need for analysis?

[aamirmir001]

@dlongley Thanks for the clarification. Understood that the VCDM’s single-issuer constraint avoids this scenario by design, since any collective issuance would be represented by a single issuer DID.

It may still be helpful to add a brief note in this specification explicitly stating that handling of rendering conflicts arising from multiple independent issuers is out of scope due to the single-issuer model, to avoid confusion for readers considering federated or joint-issuance use cases.