search

uncefact / spec-untp

UN Transparency Protocol
https://uncefact.github.io/spec-untp/
GNU General Public License v3.0
10 stars 9 forks source link

MAY rendering method #111

Closed nissimsan closed 1 week ago

nissimsan commented 2 weeks ago

Recommendations are fine, but demanding a particular rendering method is beyond what we are here to do.

nissimsan commented 2 weeks ago

I don't think it's essential at all. Data will be flowing into a relevant operational systems in most cases anyway. Who are we to say how that is presented?

PatStLouis commented 2 weeks ago

I was referencing the sentence above:

To support uptake across supply chain actors with varying levels of technical maturity, human rendering of digital credentials is essential.

Maybe encouraged or valuable are better words here?

We are also providing means to render the credential, not mandating how to present it. This is for supply chain actors with varying levels of technical maturity which could find such a feature valuable.

onthebreeze commented 1 week ago

I do fee quite strongly that this is at least a SHOULD. An issuer of a DPP cannot know the technical maturity of the verifier and if there is no rendering template then the issuer faces a world of complexity where they publish different artefacts for different consumers - eg PDFs for humans and quite separate VCs for machines. Then they face the challenge of having to know a-priori which format to issue for which consumer. Rendering templates in VCs fix that problem - issuers just issue without concern about technical maturity of verifiers. It's a fundamental part of the UNTP scalability architecture and so we cannot just drop this to a MAY.

nissimsan commented 1 week ago

OK, I'm convinced that rendering is essential. I still reject forcing a particular method for doing so. I hope my updated wording makes us all happy?

zachzeus commented 1 week ago

There are 2 questions: How important is a consumable rendering method to UNTP compliance? Which method?

Recommendation from the call:

nissimsan commented 1 week ago

@zachzeus, I don't understand your comment and why this did not get merged?

Was the suggestion to change the wording to There SHOULD be a rendering method and if you have a rendering method it MUST be HTML and it can also be others.? Seems a little clunky, but okay...

PatStLouis commented 1 week ago

@nissimsan What was discussed in the meeting was that an implementer SHOULD use the renderMethod property as defined in the VC data model. If renderMethod if used, it MUST include an entry of type HTMLRenderMethod. It MAY additionally include other renderMethod entries.

The logic discussed behind this was that: A) we want to strongly incentivize implementers to use renderMethod B) If the implementer chooses to do so, they must include at least 1 testable method, currently the HTMLRenderMethod is the only demonstrable-ish renderMethod we have in the specification C) Implementers can additionally include other renderMethod relative to their use cases but won't be tested

Does this help clarify?

nissimsan commented 1 week ago

@PatStLouis, okay I copied your wording.