1. Purpose and Use

This document provides an optional format for reporting BIP 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 BIP 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. BIP 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 BIP 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:

• which role or roles were tested;
• the tested interaction scope (pull, push, or both);
• the tested ruleset_id;
• the tested BIP version or release identifier, if separately published; 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:

Role(s) tested:

• ☐ Originator VASP client
• ☐ Beneficiary VASP server

Interaction scope claimed:

• ☐ pull
• ☐ push
• ☐ both

Flows exercised:

• ☐ Pull-payment retrieval
• ☐ Pull-payment authorization
• ☐ Push-payment authorization

Endpoint(s) exercised:

• ☐ YonaPaymentIntentService
• ☐ YonaAuthorizationService

Originator DID(s) used in testing:

Beneficiary DID(s) used in testing:

Service endpoint URL(s) resolved during testing:

YonaPaymentIntentService:

YonaAuthorizationService:

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):

BIP Conformance Test Suite identifier / version label:

BIP 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. Scope of Test Execution

E.1 Role Coverage

E.2 Endpoint Coverage

E.3 Flow Coverage

E.4 Not-Applicable Cases

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

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 for the roles and scope described herein against yona:ruleset:v1.0, the corresponding Base Interoperability Profile, and the identified BIP Conformance Test Suite release, and produced the results recorded in this report.

L.2 Third-party assessment form

[Assessor name] assessed the implementation identified in this report for the roles and scope described herein against yona:ruleset:v1.0, the corresponding Base Interoperability Profile, and the identified BIP Conformance Test Suite release, and recorded the results in this report.

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. BIP conformance concerns deterministic interoperability across independent implementations.

A useful conformance report allows a counterparty, assessor, or internal reviewer to understand what was tested, under what scope and configuration, and with what result.

For that reason, the report should make role, interaction scope, 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 BIP Conformance Test Suite.

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