Policy Versioning Support about guardian HOT 8 CLOSED

The mentality as per @sergmetelin and @danielnorkin is that the history needs to be preserved. The verified credentials need to be given and connected to a specific version of the policy, not just TO the policy. We need to know that when the token is minted, it has been minted according to a certain version of the policy so that we can track it back. Everything needs to be linked to a version. This is not really about the version of the schema but the version of the policy. Next step is @Pyatakov to analyze.

from guardian.

@anvabr We need some assistance flushing this ticket out. We will add to a later Sprint.

from guardian.

@anvabr Can we please update this? This is important to have updated ASAP with a timeline. cc: @danielnorkin @envisionblockchainpm

from guardian.

@anvabr @envisionblockchainpm can we please get an update on this?

from guardian.

Andrey needs to talk more with the Hedera Team as we need additional Discovery after just bringing this up on our Scrum. Sorry for the delay for some reason I hadn't seen this status request from you or Wes.

from guardian.

Step 1: @sergmetelin As discussed today with @anvabr on our call today, the next step is for @Mpinnola to find an example of a version update related to Verra/REDD and present notes in this ticket.

from guardian.

To summarise the main topics of our discussion on this and unanswered questions:

• introducing versioning into the schema/policy syntax is relatively easy, it's just another line in the file.
• the main difficulty is to design how different version of the schema/policy should be used/treated by the system.
  • I feel schemas/policies should be immutable, i.e. each 'version' of the policy is really a new policy self-sufficient artefact (similar to how smart contracts work in the traditional blockchains) referencing the previous artefact with the same name. Otherwise if we really change the policy file (and change its version inside) we would lose the information about the previous version[s]. Unless we somehow record the diffs, but that's probably more difficult to implement. There may be other consideration, @sergmetelin please comment?
  • what is the business logic wrt different version of schemas? does the old version gets obsolete immediately when a new one becomes available? Would the longer running project be assessed on the basis of the schema/policy it was created against, or would it have to comply with the newer version? Are token produced by a different versions of the same schema completely equivalent or should they be distinguishable? @Mpinnola.
  • also please see #85 which raises broader issues of difference and equivalence of versions, schemas and policies. @sergmetelin

from guardian.

@anvabr To provide some context, for the VCS Standard:

• VCS Program editions are labeled with a version number and program documents are correspondingly version controlled
• When a new version is released it's requirements take immediate effect unless specific grace periods are set for specific requirements
• Program documents have a history in the appendix with previous versions, updates, grace periods, etc.
• Example: VCS v4 was released 19 Sep 2019, and updated 9 Mar 2020. Registered projects and projects that complete validation on or before 19 March 2020 remain eligible to apply the crediting period requirements under VCS Version 3.
• Project proponents will be informed of the updates and the updates will also be catalogued on the Verra website
• Project proponents are responsible for using the most up to date versions
• Verified carbon units (VCUs) are not labeled in the Verra registry with a specific version of the VCS Program
• Methodologies, modules, etc. are also periodically updated
• Upon renewing a monitoring period, project descriptions and baseline assessments shall be updated with the latest methodologies
• In general, new requirements go into effect immediately unless otherwise specified.

I think we need to brainstorm the Guardian implications, but here are just some initial thoughts to start the conversion. Let's imagine a Verra REDD project becomes validated and verified under the methodology VM0007 REDD v1.6 and issued VCUs. Then they renew their monitoring period and during the subsequent monitoring period v1.7 is issued and requires a few new data points, effective immediately. A new policy (v1.7) will be created and the project would have to switch to the new policy, which may require slight changes, or no changes at all in certain contexts. Then at the end of the second monitoring period, the updated project description and monitoring report will be submitted to the VVB, in accordance with v1.7. The VCUs will all be the same (not labeled to a specific version). Although the policy and schema may be 99% or even 100% the same in certain contexts, v1.7 will be treated as its own separate policy. A history of all monitoring periods, versions, etc. will be retained. The new policy will also include a history of versions, updates, grace periods, etc.

How does that sound? Just some initial thoughts, interested to hear yours.

from guardian.