Specification WG (SPEC-WG)

Agenda

1. Merge sequence for the open pull requests (economic model PR, v5 PR)
2. New credential schema attributes in the v5 spec (subject kind, presentation mode, credential format, digest requirement, verification session, presentation validity period)
3. Debate on presentation modes and attribute naming
4. Presentation digest anchoring and payment flow
5. Changes in v4, fee calculation and trust-resolution clarifications
6. Feature removed from v5; onboarding / trigger-resolver timing
7. Duplication between the Verifiable Trust and VPR specs
8. Work in progress: corporation sponsorship and gas cap
9. Short update on Martín's post-quantum work

Discussion

Merge sequence. Fabrice Rochette explained that he had commented on and opened a PR against the economic model PR authored by Pratik, answering the questions he could. The plan was to merge PR 183 into 177, bring the package into main, and then rebase the remaining PR.

New credential schema attributes. Fabrice walked through the additions to the credential schema in the v5 data model: a subject kind indicating whether a credential may be issued to a service or to a person; a presentation mode with three values for service subjects — public (presented in the DID document), accredited automatic (the agent must present on request from an accredited verifier) and accredited approval (the service controller must approve each presentation); a restriction on credential formats/containers per schema; a flag for whether a digest must be anchored on chain (needed for AnonCreds, optional for SD-JWT, which can rely on a separate revocation list, and relevant later for mDoc); a verification session flag stating whether the create/update session call is mandatory when fees are zero; and a presentation validity period allowing a governance framework to require re-requesting (and re-paying for) a credential after a set time, with the presentation digest anchored on chain as legal proof.

Debate on presentation modes. Ariel Gentile questioned why the automatic/approval distinction belongs on chain rather than being internal service configuration, arguing it cannot be proven whether an agent answered automatically or asked its controller, and that the names "accredited automatic" and "accredited approval" were poor. Fabrice argued the rule must be enforceable by the ecosystem and defined immutably in the schema, since some credentials are legally mandatory to present while others should remain at the holder's discretion, like a personal wallet. He compared non-compliance to not publishing mandatory public credentials — a slashing risk. Fabrice said he had no objection to renaming the attributes and asked Ariel to reflect and come back the following week with concrete proposals. Ariel also warned that the credential schema object is accumulating too many parameters and that overlapping terminology (credential schema, JSON schema) makes the spec hard to read.

Presentation digest anchoring. Fabrice described the flow: the presenter computes and shares the digest of the presentation so the verifier can anchor it when creating the session and paying, after which the presenter releases the credential. The verifier cannot be asked to pay after receiving the credential. The open edge case is a presenter computing the digest incorrectly; an escrow-based solution was considered but judged too complex. Ariel noted that a presentation may contain more than one credential, which is not used today but will matter later; Fabrice said it would be limited to one credential per presentation for now, and that reducing the number of transactions per service remains to be optimised.

v4 and other changes. v4 contains bug fixes only. Other items: digest holder and participant ID added so revocation can be limited to the issuing service; slashed ecosystem participants no longer receive fees, reducing the verifier's price; an indexer issue clarifying that an anchored digest keeps a credential valid after the issuer entry becomes inactive, whereas AnonCreds credentials do not; and matching updates in the Verifiable Trust spec, for which Fabrice asked Ariel to verify the container/format explanations.

Removed feature and onboarding. The mechanism defining who may request which credential attributes was removed from v5 as too complex for current needs. Both noted that the holder permission is created before credential issuance, requiring the receiving agent to call the trigger resolver, and agreed this needs rethinking later.

Spec duplication. Ariel observed that anchoring rules are defined both in the Verifiable Trust spec and in the VPR data model, and proposed defining them once (in VT) with the other referencing it, keeping only the checks in the VPR spec. Fabrice agreed and said he would remove the duplicated credential schema section; he mentioned a single repository as an option but noted it has implications.

Work in progress. Fabrice is working on corporation sponsorship, so public entities never handle or see the token, and on a per-transaction gas cap to prevent a compromised service from draining a corporation's wallet. These PRs stay in draft.

Martín. Fabrice met Martín and settled the monthly payment arrangement; Martín was encouraged to gain autonomy and join the working groups. Ariel reported his comments were well received by the Askar maintainers, who updated dependencies to enable the post-quantum work, and that Credo is also involved.

Decisions

• Merge order agreed: PR 183 into 177, then into main, then rebase the remaining PR.
• Attribute names in the credential schema are open to change; the logic is what Fabrice asked to be reviewed first.
• Presentations will be limited to one credential for now.
• The attribute-level request permission feature is removed from v5.
• Rules will be defined in a single spec and referenced from the other; the duplicated credential schema section will be removed from the VPR spec.

Action items

• Review the v5 PR and come back with a concept and naming proposals (Ariel Gentile, next week)
• Verify the container and credential-format explanations in the Verifiable Trust spec (Ariel Gentile)
• Remove the duplicated credential schema definitions from the VPR spec and reference the VT spec instead (Fabrice Rochette)
• Check and fix the cross-version links between the VPR and VT specs raised in Ariel's earlier comment (Fabrice Rochette)
• Continue the corporation sponsorship and gas cap work, kept as drafts (Fabrice Rochette)
• Send Ariel the scope of the CCM / chamber of commerce engagement (Fabrice Rochette, next morning)

Agenda

1. Documentation pull request and build/navigation rework
2. New implementation/demos working group, certification programme
3. Testnet v4 migration: wipe, playground use cases, cluster split and DNS mapping
4. Onboarding flows and known VS Agent / timing issues
5. Specification work: v5 writing approach and spec publication tooling
6. Team updates: Credo, post-quantum work, contributor status

Discussion

Documentation pull request. Fabrice Rochette said he had reviewed the PR: the "Understand" section was well written, but the "Build" part would need rework because it is hard to find the right information in it. He intended to redo it only after the testnet migration to v4, and to add step-by-step screenshots (ecosystem creation, creating a corporation, joining an ecosystem) generated through an existing pipeline. He asked Ariel Gentile to approve the PR before the migration. Fabrice had used the documentation for local tests; the VS Agent appeared to work on version 0.9.1, though he lacked the ecosystem mnemonic to test his request. Ariel mentioned an upcoming 2.0.0 release.

New working group, certification. Fabrice announced a new working group launching Thursday at 8, with Bernard (French) and other folks. Its scope: demos and how to build them (playground-style), training workshops and certification. A certification programme is being prepared and partly published in a repository, with a free tier and a paid tier; a temporary link exists on the Verana Foundation site. The aim is to certify companies whose technical teams can implement Verana services. Fabrice wants testnet on v4 first so documentation and certification align. He also asked Bernard to look at deployment on AWS and Google Cloud, with everything to be verified against the documentation.

Testnet migration and clusters. Ariel reported devnet had been restarted and tested; Maxime validated the use cases, personal wallet worked, and Hologram is ready for publication pending an Android production test. Andrés would run the testnet migration. A full wipe of testnet is required for v4, and playground elements will be recreated — the four basic web use cases (Vesta, BH, Verandia/Crypto Exchange, personal wallet), estimated at about three to four hours. Fabrice asked that the wipe be announced on Discord announcements. On clusters: *.playground.testnet.network stays on the current cluster; everything else (indexer, graph, app, search, visualiser, faucet, explorer, SS ecosystem, org issuer, API/RPC proxy) moves to the new cluster, which will be testnet-only. Ariel had understood it the other way round but accepted. They mapped DNS entries live; Ariel would ask Andrés to confirm which services are actually used, noting many leftover test entries. Fabrice also asked that mnemonics created for testnet corporations be kept secret, and reminded that credentials should not be sent over Discord as it is not encrypted. Resource sizing was discussed: graph ~90–100 MB, indexer around 1 GB, VS Agent running on 256 MB.

Onboarding flows. Ariel confirmed onboarding is implemented, with a connection between the frontend and the associated VS Agent to track onboarding states and external OOB links. He warned of known issues: duplicate connections in VS Agent (being fixed by Tarun in v2), and timing problems where the trigger resolver fires before the final state is available, requiring retries. Both agreed the ordering of indexer notifications to agents needs to be made robust.

Specifications. Nothing had been decided on how to write the v5 specs. Ariel described using an IEEE/ISO-style template ("ASD 100" in transcript) on a side project, with a high-level requirements spec plus a more detailed design spec, and proposed trying it for v5. Fabrice shared a link to "spec-up T" from Trust over IP, similar to Docusaurus in appearance and navigable, and asked whether Docusaurus (already versioned v3, v4) could host a spec tab instead. Both agreed the current GitHub files are not navigable or human-readable enough.

Other updates. Ariel reported Credo progress with Robert's involvement, Tarun's pull requests fixing KMS bugs, Maxim's OpenID4VC fixes, and Martin's post-quantum work: the plan is an experimental Credo integration using the Noble pure-JavaScript library (Node and React Native) rather than native Askar support, since ML-DSA in RustCrypto is experimental. Fabrice suggested inviting Martin to the Implementation working group. Tarun's availability after his new job is still unconfirmed.

Decisions

• The current cluster keeps *.playground.testnet.network; all other testnet services move to the new, testnet-only cluster.
• Testnet will be wiped and migrated to v4 today, with the four basic playground use cases redeployed and an announcement posted on Discord.
• Post-quantum support in Credo will start as an experimental integration using the Noble JavaScript library rather than native Askar support.

Action items

• Review and approve the documentation pull request before the v4 migration (Ariel Gentile)
• Rework the "Build" documentation section and add generated screenshots after the testnet migration (Fabrice Rochette)
• Announce the testnet wipe in Discord announcements and warn David about playground downtime (Fabrice Rochette / Ariel Gentile)
• Ask Andrés to confirm the definitive list of services and subdomains for the new cluster (Ariel Gentile)
• Invite Martin to the Implementation working group regarding post-quantum verifiable credentials (Ariel Gentile)
• Confirm Tarun's availability and continued involvement after his new job (Ariel Gentile)

Agenda

1. New working-group features on veranafoundation.org (meeting editing, automatic transcripts and minutes)
2. Private groups, GitHub backup repositories and MCP access
3. Onboarding of a new contributor ("Lin") and playground use cases
4. Prerequisites before giving external people deployment access

Discussion

Working-group features on veranafoundation.org. Fabrice Rochette demonstrated changes he made to the foundation website. Individual meetings in a series can now be moved or cancelled without affecting the rest of the series, which was the change Ariel Gentile had requested. Automatic transcription and AI-generated minutes have been added: roughly ten minutes after a session ends, group leads receive an email pointing to a "past session minutes" page containing an editable Markdown draft, which leads can approve, change or reject. For public groups, approved minutes are published to GitHub; publishing the raw transcript is optional. An executive summary is shown on the group page, with the full detail available behind it. The feature can be disabled per group.

Fabrice noted a current limitation: Google Meet transcription cannot detect the meeting language automatically, and because the account used is configured in English, Spanish meetings are transcribed in English by default. The workaround is to stop the transcript manually and restart it in Spanish. He also noted that Spanish transcription is only alpha-level support and may not work well. Ariel said the mechanism should simply be tried out.

Private groups and MCP. Groups can now be created as private: the group is visible, but sessions and minutes are restricted to members, and join requests must be approved by the leads. Fabrice gave the internal meeting with the France team as a candidate use case, to keep a record of what was discussed. He also described an MCP endpoint with a per-user token, allowing an AI assistant to search minutes and transcripts, and his intention to combine it with the MCP of the CRM in use so that actions mentioned in a meeting can be reflected in the CRM. He added that token-based configuration works with Claude Code but not with Claude, so he implemented an OAuth redirect flow (sign-in to the Verana Foundation, then return with a token); this was not yet merged. Content is also backed up to two GitHub repositories, one public for public groups and one private ("Private Working Groups") for private groups.

Onboarding "Lin" and playground use cases. Fabrice said he could not attend the scheduled meeting with Lin because of a conflicting appointment with Julian Bonilla of an integrator named Grow Data, and asked whether Ariel could take it. Ariel replied he was not in a position to, as he had no prepared material and already had a session with another contributor ("Martin"), whom he wanted to support properly.

Fabrice forwarded Ariel an example of an incoming request and argued that demand for short-lived playground demos and use cases is growing, that he currently builds them himself, and that someone else could take this over. He proposed Lin start by deploying services, reproducing existing use cases and then creating new ones (for example testing credentials with a wallet), which would also teach him how Verana works.

Ariel agreed with the direction but objected that an unknown person doing deployments requires the groundwork to be in place first: the separate cluster for the playground discussed previously, so that the indexer and current infrastructure are not affected, and a reasonably organised playground repository. Fabrice suggested devnet or a test cluster as a possible environment. Ariel also raised the practical difficulty of the time-zone gap, suggesting that in the meantime Lin ask questions on Discord. Fabrice proposed inviting him to the Implementation Working Group so he could listen in; Ariel had no objection but was unsure how much value it would add.

Decisions

• The meeting with Lin will be postponed to the following week (next Monday was mentioned), as the material he is meant to investigate is not yet prepared.
• Lin will be asked to register on the Verana Foundation site and join the working group; inviting him to the Implementation Working Group as a listener was accepted without objection.
• Before giving Lin deployment access, the playground must run on a separate cluster and the playground repository must be organised.

Action items

• Tell Lin the meeting is moved to next week and ask him to register on the Verana Foundation site and join the group (Fabrice Rochette)
• Prepare and organise the playground repository and the separate playground cluster before onboarding external contributors (Ariel Gentile)
• Merge the OAuth redirect flow for MCP access from Claude (Fabrice Rochette)