Add OCABundle render method

[PatStLouis]

References #15

• Add new OCABundle render method to specification
• Define OCABundle type with properties: id, type, name, description, digestMultibase, version
• Explain use of JSON paths (RFC6901) in capture base for mapping to credentialSubject
• Include comprehensive OCA v2.0.0-rc1 bundle example with:
  • Capture base with JSON path attributes
  • Meta overlay (name, description)
  • Label overlays (English and French)
  • Information overlay
  • Sensitive overlay
• Update renderMethod property description to include OCABundle type

---

Preview | Diff

[msporny]

We need to spend some time trying to unify the approaches to rendering in the spec and decide what should be in v1.0.

[dlongley]

+1 to figure out if this fits in as an extension or if we can fold it into a unified approach with the other render methods.

We also need to work out where the lines are for extensions, what we can unify, and so on. It seems like minimally unifying on "high-level medium type" to start with would be good (visual, audio, tactile) and then for each of these there might be further breakdowns, e.g., visual => HTML, SVG, etc. Alternatively, maybe visual/audio/tactile just slot in and are just categories for understanding covering accessibility in the spec.

[dmitrizagidulin]

@PatStLouis thank you so much for this PR, this is a great start to the conversation.
As discussed on the call, several of the fields in this PR will likely be useful to ALL the render method classes, so we should consider pulling in common fields into the top level extension spec.

[iherman]

This was discussed during the vcwg meeting on 14 November 2025.

View the transcript

w3c/vc-render-method#25 and w3c/vc-render-method#30

dmitriz: those were discussed previously
… a proposal was to introduce in the core spec itself

brent: do you mean the core data model?

dmitriz: no, the render spec
… that will describe a generic render method, then we would have additional specs for specific methods
… let's look at w3c/vc-render-method#30
… the properties it introduces are general purpose (name, digest multibase, version)
… any method will need those
… So I suggest to wait on this one, as well as PR 25

brent: to clarify: this method is introducing things for a specific render method
… what you propose is to create a separate PR introducing them on the generic render method

dmitriz: correct

phila: reminds me of a discussion I had a long time ago with Mark Nottingham
… about registering a link relation type; Mark pointed out that the link relation type does not give you the media type
… a given VC may have several render method
… having an specific OCA method feels wrong

dmitriz: my understanding of the PR is that it proposes a "super class" of OCABundle

phila: that feels right

manu_: the current way the specification is structured is: we have an extension mechanism, called render method
… we are going to define the generic mechanism, and propose a few concrete ways to use it (PDF, SVG...)
… this is an enormous amount of work
… can we at least prioritize the order in which we go into these things?

manu_: I don't want us to take 2 years to get Render Methods 1.0 published

phila: difference between linking to a render method and embedding

JoeAndrieu: we want to get one, to be able to go to CR
… knowing which one is the 1st one is important

dmitriz: this is a good segway to look at PR 36, which emphasized that the spec is an extension mechanism (as manu_ and JoeAndrieu said)
… I love the idea of "let's take one"; agree with JoeAndrieu that this is going to be a difficult conversation

<dmitriz> we've implemented the HTML template, at MIT DCC. (we started with SVG, but ran into line wrapping probems, and switched to HTML)

dmitriz: SVG and HTML are widely applicable, but maybe not the ones with the most implementations

phila: as GS1, we use SVG and would like SVG to be in there
… any opinion across the room?

dmitriz: dare we bring up the dreaded word "registry"?
… We should not prioritize now, but this discussion is related to deciding what to do with those PRs.
… Let's leave 20 and 35 open for the moment.

---

[PatStLouis]

I've missed the meeting again, my apologies. Here's my intention with this PR and response to some of the comments.

For the added terms, the only thing I've added here is the type (OCABundle) and the version property.

I've observed 3 main patterns to "control" type versioning across w3c / w3c-ccg work items, and I'm open to reconsider this approach.

• Have a specific type tied to a version, ex: MyRenderMethodV2, MyRenderMethod2025
• Have the versioning be inferred by the context used, ex: VerifiableCredential
• Have the versioning be explicitly set as a property on the object (the approach of the PR)

I opted for option 3, since OCA has different versions (v1 and v2.rc-0). When it comes to maintainability, version 3 SEEMS to me like the more convenient solution, since its not entirely reliant on external factor and can allow this spec to evolve without requiring any normative changes. An note can be added for a SHOULD on a specific version (ex: implementers SHOULD use version x).

As far as interop / testing goes, I would only test if A) the bundle resolves B) Each attribute (json pointers) actually points to something in the VC. This is IF we consider testing each individual method necessary, or are only concerned with the DataModel of the renderMethod property.

As for the spec, the only thing that are important is:

• Where to get this bundle
• Explaining that when used as a renderMethod, the attributes are to be interpreted as json pointers on the credential itself.

Now for what model this follows (extension or explicit method) I think this needs more conversation. I could see an extension model that explains each extension and says: here's what to include in your context if you want to use this specific extension. This way we don't need to maintain a context for each method type, only some type definition file that can be linked to but still have a means to test implementations.