Registration of Network Participants:
Software in registry mode should allow Network Participants to register themselves with a Subscriber ID and Subscriber URL.
Approval: Software in registry mode may have approval criteria for registrants. Once the criteria are met, the registrants may be considered as subscribers.
Ownership: Software in registry mode must allow organizations/users that register Network Participants to own and have rights to modify their network roles and participant keys. It must not allow a user to change other users’ network participant details.
Subscription of Network Participants:
Software in registry mode must allow subscribers to create and alter their details including domain, role, location, etc., as described in Subscription and Subscriber objects through the subscribe endpoint described below.
Network Participant - Keys:
Software in registry mode must allow public keys associated with network participants to be changed through the subscribe endpoint described below.
Subscribe (Registry API):
Software in registry mode must support the modification of subscriber information through the subscribe endpoint as described in Beckn Protocol Registry Infrastructure API. It must support automatic verification of changed information through the call to on_subscribe as described in the API document.
Lookup (Registry API):
Software in registry mode must support the lookup of Subscriber information through the lookup endpoint as described in Beckn Protocol Registry Infrastructure API. The lookup is a synchronous API call and must return its result in the response. It must support the following while it may support filtering by the rest of the parameters in subscriber and subscription objects:
lookup by subscriber_id and key_id
lookup by domain and type
Logging - Public Key Changes:
All public key changes of the network participants must be logged and stored for extended duration. This is required for dispute resolutions at the trust layer.
Merging Two Networks:
It must be possible to copy the network participant information present in the registry in bulk from one registry to another.
UI & Backend Requirements:
The UI for the Registry Mode should utilize the existing Registry available at: https://registry.becknprotocol.io/login
For the backend, Strapi should be used. The Registry itself should be developed as a Strapi Plugin that supports CRUD operations.
The Beckn-ONIX-Stack:v0.1 version document is here.
Goals
[ ] Apply all common requirements from “Requirements for all modes” to Registry mode.
[ ] Implement registration functionality for Network Participants with Subscriber ID and URL.
[ ] Define and implement approval criteria for registrants.
[ ] Ensure organizations/users have ownership rights over their network roles and participant keys.
[ ] Prevent users from modifying other users’ network participant details.
[ ] Allow subscribers to create and update their details (domain, role, location, etc.) through the subscribe endpoint.
[ ] Enable public key changes for network participants via the subscribe endpoint.
[ ] Implement the subscribe API for modifying subscriber information with automatic verification.
[ ] Implement lookup API to retrieve subscriber information by subscriber_id, key_id, domain, and type.
[ ] Log and store public key changes for extended duration.
[ ] Implement functionality to merge network participant data between registries.
Description
Common Requirements:
Registration of Network Participants:
Software in registry mode should allow Network Participants to register themselves with a Subscriber ID and Subscriber URL.
Approval: Software in registry mode may have approval criteria for registrants. Once the criteria are met, the registrants may be considered as subscribers.
Ownership: Software in registry mode must allow organizations/users that register Network Participants to own and have rights to modify their network roles and participant keys. It must not allow a user to change other users’ network participant details.
Subscription of Network Participants:
Software in registry mode must allow subscribers to create and alter their details including domain, role, location, etc., as described in Subscription and Subscriber objects through the subscribe endpoint described below.
Network Participant - Keys:
Software in registry mode must allow public keys associated with network participants to be changed through the subscribe endpoint described below.
Subscribe (Registry API):
Software in registry mode must support the modification of subscriber information through the subscribe endpoint as described in Beckn Protocol Registry Infrastructure API. It must support automatic verification of changed information through the call to on_subscribe as described in the API document.
Lookup (Registry API):
Software in registry mode must support the lookup of Subscriber information through the lookup endpoint as described in Beckn Protocol Registry Infrastructure API. The lookup is a synchronous API call and must return its result in the response. It must support the following while it may support filtering by the rest of the parameters in subscriber and subscription objects:
Logging - Public Key Changes:
All public key changes of the network participants must be logged and stored for extended duration. This is required for dispute resolutions at the trust layer.
Merging Two Networks:
It must be possible to copy the network participant information present in the registry in bulk from one registry to another.
UI & Backend Requirements:
The UI for the Registry Mode should utilize the existing Registry available at:
https://registry.becknprotocol.io/login
For the backend, Strapi should be used. The Registry itself should be developed as a Strapi Plugin that supports CRUD operations.
The Beckn-ONIX-Stack:v0.1 version document is here.
Goals
Expected Outcome
Acceptance Criteria
Mockups / Wireframes
NA
Product Name
Beckn
Domain
NA
Tech Skills Needed
Complexity
Medium
Category
API Development
Sub Category
Registry Mode