Protocol feedback

Large-Scale Telemetry: Beckn Should Coordinate the Exchange

IES over Beckn works well for consent, discovery, contracts, signatures, callbacks, and delivery state. The actual data transfer method is domain-defined: inline for small payloads, or webhook notifications, polling, signed URLs, APIs, streams, or data rooms for larger production telemetry.

Recommended Production Pattern

Beckn coordination: discover → select → init → confirm → status/on_status

Domain delivery: inline payload, signed URL, API job, polling, stream, data room, or SFTP

IES payload: JSONL / Parquet / Arrow with manifest, checksum, and partitions

Inline payloads do not scale

Embedding full IES_Report data in dataset:dataPayload works for demos, but large meter exports should usually move through a domain-defined delivery mechanism.

Beckn coordinates; the domain delivers

Webhooks, polling, signed URLs, APIs, streams, and data rooms are delivery choices defined by the domain/application, not by Beckn core transport.

Chunking needs a convention

Large reports need sequence numbers, checksums, idempotency keys, and retry handling so receivers can detect duplicates, gaps, and partial delivery.

Validation cost grows quickly

If huge interval payloads are embedded inline, full JSON schema validation adds CPU and memory pressure inside ONIX and application webhooks.

Delivery Method Guidance

Use case	Method	Why
Demo or one meter/day	INLINE	Best for visibility and simple walkthroughs.
Large daily exports	DOWNLOAD	Return a signed URL, checksum, expiry, and format metadata.
Queryable history	API	Use pagination or async export jobs.
Near real-time telemetry	STREAM / POLL	Coordinate access through Beckn, then stream or poll through the application data plane.
Sensitive raw meter data	DATA_ROOM / DATA_ENCLAVE	Keep data governed without unrestricted raw export.

Short Feedback

Keep INLINE delivery for demos and small telemetry samples because it makes the protocol story easy to see.

For production, use Beckn for identity, authorization, callbacks, and delivery state. The application/domain should choose the actual transfer path: inline payload, polling, signed URL, API, stream, or governed data room.

BAP / BPP Interoperability Feedback

The BAP/BPP model is sound, but cross-party integration needs sharper tooling around registry resolution, callback completion, and diagnostics.

Registry discovery needs a standard path

Signature validation works only when the receiver can resolve the partner's subscriber ID, registry namespace, and key ID. Cross-team setup still required manual registryName and recordId exchange.

ACK is not completion

A select/init/confirm/status ACK proves request acceptance. Completion requires the matching on_* callback, signature verification, correlation by transactionId, and payload or fulfillment processing.

BPP callback generation must be explicit

A BPP is not done after returning ACK. It must route to business logic, build on_select/on_init/on_confirm/on_status, sign the callback, and send it to the BAP receiver.

Identity strings must match exactly

context.bppId, DeDi subscriber_id, signature keyId, and callback context must align. A small typo in subscriber ID causes lookup or signature validation failure.

Error messages should be more actionable

Adapter errors should include subscriberId, registryName, keyId, and whether the failure was missing signature, record not found, digest mismatch, or schema validation.

Round-trip conformance matters

Conformance should test request ACK plus callback receipt and verification. Testing only POST select -> ACK misses the most common interop failures.

Double Verification for Demos

Do not treat an ACK as success by itself. For every cross-team demo, verify both layers.

1. Protocol layer: request returned ACK and was signed by the expected BAP/BPP identity.

2. Callback layer: matching on_* callback reached the receiver, signature verified, and payload or fulfillment metadata was processed.