1. Purpose and Use

This document provides an optional format for reporting YONA conformance results under yona:ruleset:v1.0.

Use of this template is not required for conformance.

A technical conformance claim under yona:ruleset:v1.0 depends only on:

1. satisfying all applicable normative requirements in YONA Ruleset 1.0;
2. satisfying all applicable normative requirements in the Base Interoperability Profile (BIP); and
3. passing all applicable normative test cases in the YONA Conformance Test Suite.

This template is a suggested format for presenting those results.

2. What This Template Does Not Do

This template does not change protocol requirements, BIP requirements, test cases, or pass/fail criteria.

It also does not define an exclusive issuer, assessor, publication venue, registry, or credential format.

A completed report may be used for internal review, self-asserted claims, bilateral review, procurement review, or third-party attestation, but those uses remain outside the scope of the protocol and BIP.

3. Relationship to Authoritative Documents

For yona:ruleset:v1.0, authority is ordered as follows:

1. YONA Ruleset 1.0
2. Base Interoperability Profile (BIP)
3. YONA Conformance Test Suite
4. this report template

If this template appears to conflict with the YONA Ruleset 1.0, the Base Interoperability Profile (BIP), or the YONA Conformance Test Suite, those documents take precedence and this template must be interpreted accordingly.

4. Minimum Statements a Conformance Report Must Include

A completed conformance report should state, at minimum:

• the tested ruleset_id;
• the tested BIP version or release identifier, if separately published;
• any optional BIP-defined DID service entries advertised during testing; and
• any configuration inputs that materially affect validation, timeout handling, replay handling, caching, or repeated-request behavior.

5. Suggested Report Template

Copy, paste, and complete the following sections.

A. Report Metadata

Report ID:

Date:

Organization making or commissioning this report:

Primary contact:

Contact email:

Report type:

• ☐ Self-asserted conformance report
• ☐ Third-party assessment report
• ☐ Internal validation record
• ☐ Other: __________________

Assessor name (if third-party):

Assessment engagement / reference ID (optional):

Publication URI (optional):

Credential / certificate / VC identifier (optional):

B. Implementation Under Test

Implementation name:

Implementation version / release:

Source revision / commit / build identifier:

Deployment environment identifier:

Baseline BIP coverage exercised:

• ☐ Originator VASP client
• ☐ Beneficiary VASP server
• ☐ Pull-payment retrieval
• ☐ Pull-payment authorization
• ☐ Push-payment authorization
• ☐ YonaPaymentIntentService
• ☐ YonaAuthorizationService

Optional BIP-defined DID service entries advertised during testing:

• ☐ None
• ☐ YonaTravelRuleService
• ☐ YonaAssuranceService

Originator DID(s) used in testing:

Beneficiary DID(s) used in testing:

Service endpoint URL(s) resolved during testing:

YonaPaymentIntentService:

YonaAuthorizationService:

YonaTravelRuleService (if advertised):

YonaAssuranceService (if advertised):

Capability document URL(s) obtained during testing (if applicable):

YonaTravelRuleService capability document:

C. Governing Artifacts

Tested ruleset_id: yona:ruleset:v1.0

Ruleset document identifier / version label:

Ruleset artifact SHA-256 (optional):

BIP document identifier / version label:

BIP artifact SHA-256 (optional):

YONA Conformance Test Suite identifier / version label:

YONA Conformance Test Suite artifact SHA-256 (optional):

Reference Messages and DID Examples identifier / version label (optional):

Reference-messages artifact SHA-256 (optional):

Any local pinned artifact set / manifest identifier (optional):

D. Environment and Material Configuration Inputs

D.1 JOSE and signature validation

Allowed JOSE algorithms:

JOSE library / version:

Key resolution method:

Any local algorithm allowlist notes:

D.2 DID resolution

DID resolver implementation / version:

did:web resolution mode:

Any resolver overrides used during testing:

DID caching behavior (TTL / invalidation / pinning):

D.3 HTTP / TLS

HTTP client stack (if originator role tested):

HTTP server stack (if beneficiary role tested):

Minimum TLS version enforced:

TLS certificate validation policy summary:

Any mTLS / allowlist / network constraints:

D.4 Time and freshness

Clock source / environment:

Clock skew tolerance:

iat / exp enforcement notes:

Authorization timeout handling policy:

Late-response handling policy:

D.5 Replay and repeated-request behavior

Replay window duration:

Replay storage mechanism:

Repeated-request retention window:

Repeated-request state storage mechanism:

Replay scope used for signed-message replay handling:

Repeated-request scope used for yona.authorization_request handling:

Material inputs used for repeated-request comparison:

Non-material request differences tolerated without changing decision:

D.6 Parsing and validation limits

Maximum request size:

Maximum response size:

Duplicate-member-name handling:

Unknown/additional-field handling:

Any local validation reason mapping (optional):

E. Coverage of Test Execution

E.1 Baseline BIP Coverage

E.2 Optional Advertised Service-Entry Coverage

E.3 Not-Applicable Cases

List any suite cases treated as not applicable, and explain why.

For a full YONA conformance claim, baseline BIP cases should not be treated as not applicable. Use this section for optional-service cases that were not applicable because the corresponding service entry was not advertised, or for other suite-defined applicability rules.

F. Results Summary

Overall result:

• ☐ PASS
• ☐ FAIL

Determinism statement:

Repeated executions of the same applicable test vectors under the same configuration produced deterministic outcomes.

• ☐ Yes
• ☐ No

If FAIL, list the failing cases and reasons:

If PASS, confirm there are no open deviations that would change deterministic behavior:

• ☐ Confirmed

General notes / deviations / observations:

G. Case-by-Case Results

Fill one row per applicable test case executed.

For repeated-request or binding-sensitive cases, also record the exact request/response hash evidence below or in attachments.

H. Evidence Inventory

Record evidence over exact bytes used on the wire.

H.1 DID Document Hashes

Resolved originator DID document SHA-256 (exact bytes):

Resolved beneficiary DID document SHA-256 (exact bytes):

H.2 Request / Response Hashes

For each applicable executed case:

H.3 Binding Evidence

For each accepted terminal response, record:

• the exact request bytes used for recomputation
• the recomputed request_jws_sha256 value
• whether the response value matched exactly

H.4 Timeout and no-response evidence

For each no-response classification, record:

• request send timestamp
• cutoff timestamp
• observed outcome
• evidence that no eligible terminal response was obtained by cutoff
• evidence that any late response was ignored, if applicable

I. Negative Coverage Results

Record one row per negative condition demonstrated.

J. Repeated-Request Results

Complete this section if repeated yona.authorization_request cases were executed.

Record the repeated-request rule applied during testing:

Repeated-request scope:

Retention window:

Material input set:

Non-material request differences:

K. Attachments / Evidence Pointers

Attach or link to supporting evidence, where available, such as:

• exact request and response JWS samples
• relevant DID documents or exact-byte captures
• HTTP logs
• JOSE parsing and signature-verification logs
• binding recomputation logs
• timeout or cutoff logs
• replay or repeated-request logs
• relevant environment configuration excerpts

L. Optional suggested claim language

L.1 Self-asserted form

[Organization / implementation name] states that the implementation identified in this report was tested against yona:ruleset:v1.0, the corresponding Base Interoperability Profile (BIP), and the identified YONA Conformance Test Suite release, and produced the results recorded in this report. This report identifies the baseline BIP coverage exercised, any optional BIP-defined DID service entries advertised during testing, and the material configuration inputs used.

L.2 Third-party assessment form

[Assessor name] assessed the implementation identified in this report against yona:ruleset:v1.0, the corresponding Base Interoperability Profile (BIP), and the identified YONA Conformance Test Suite release, and recorded the results in this report. This report identifies the baseline BIP coverage exercised, any optional BIP-defined DID service entries advertised during testing, and the material configuration inputs used.

Do not state or imply that YONA LLC, any future YONA successor body, or any other party reviewed, approved, issued, or published the claim unless that actually occurred.

M. Sign-off

Prepared by:

Title / role:

Date:

Signature / approval record (optional):

Reviewed by (optional):

Title / role:

Date:

Signature / approval record (optional):

6. Interpretation Notes

This template is intentionally evidence-oriented. YONA conformance concerns deterministic interoperability across independent implementations.

A useful conformance report allows a counterparty, assessor, or internal reviewer to understand what baseline BIP coverage was exercised, which optional BIP-defined DID service entries were advertised during testing, under what material configuration the testing occurred, and with what result.

For that reason, the report should make baseline coverage, advertised optional service entries, material configuration inputs, applicable-case coverage, and exact-byte evidence explicit.

7. Non-Normative Reminder

This template is optional.

Conformance under yona:ruleset:v1.0 is determined by:

1. YONA Ruleset 1.0,
2. the Base Interoperability Profile (BIP), and
3. the YONA Conformance Test Suite.

Use of this template, publication venue, or any particular credential or issuer is not required for a conformance claim under YONA.