Registry apis implementations

[venkatramanm]

My thoughts on the registry api rationalizations after the discussions on Dec - 1 2021
registry.pdf
reg_api.pdf

[techframewirk]

Will participant_id and subscriber_id be the same? I don't see participant_id anywhere in the API request or response bodies. Will it be something that is used by the registry internally that a network participant need not be aware of?

[venkatramanm]

YEs

[venkatramanm]

Actually, after the 3 Dec discussion, it was recommended by Paul to use a subscriber_id different from participant_id
subscriber_id = ${participant_id}.${domain}.${type) , e.g humbhionline.in.nic2004:52110.BPP, humbhionline.in.nic2004:55204.BAP
This way, the signing headers would give more detail and be useful in locating the the subscription record of the network participant.

[ravi-prakash-v]

Can we break down the Open questions and move it as a separate thread?

[techframewirk]

You mean the open questions in the open questions document? Most of the answers are refer to the document attached here. Won't it be better to have all the questions regarding the document here itself in this discussion?

[venkatramanm]

Updated registry.pdf based on recommendation on Dec-3 call .

[chainhead]

There is no markdown version for community to edit, comment, PR, etc.?

[techframewirk]

One thing I want to highlight in this implementation is ParticipantKey is linked to the NetworkParticipant and does not have a 1-1 relationship with Subscription. Hence there will not be a 1-1 relationship between the public keys and the subscriber_url which could be an issue during the subscribe, on_subscribe flow as the key is not linked to any one subscriber_url.

[venkatramanm]

• /subscribe is an authorized call using Authorization Header.
• It is signed using a key_id of the subscriber's choice within the participant's ownership. It is therefore verifiable by the registry.
• In /on_subscribe (if the subscription url is in "SUBSCRIBED" status), New keys in "unverified" status can be verified. and if not in "SUBSCRIBED" status, a verified key_id can be used to verify the url to mark the subscription as "SUBSCRIBED"
• Yes, If you need tight coupling of subscriber_id and key_id, you can create each subscriber as a different participant who has only one key and one subscription (domain.type combination).

[techframewirk]

In the document /subscribe is used for the following use cases :

• Retrigger on_subscribe in case initial call fails.
• Add a new key to the registry.
• Add new service domain for a domain.
• Updating subscriber_url.
• Invalidating a key.

I think some of these use cases can be implemented using another endpoint which might make the implementation less complicated and documenting the same will become easier as well.

[venkatramanm]

Most of beckn apis even in transaction-apis have many attributes which by each usecase, can be trimmed. Creating new apis for each usecase may become impractical. It is a trade off. I am ok with your suggestion. Let's see what others have to say?

[venkatramanm]

I have updated the documents and the model diagram.
Document as Markdown
Data model updated
Date model in dia format

[ravi-prakash-v]

Unable to click the links

[pkapustin]

We had a discussion recently on this topic. Trying to summarize that here.

Background

We distinguish between participants, subscribers and keys. Participant is a company that needs to register offline with the registry. Each subscriber is essentially a role the participant plays (for example, a BAP in public transport domain, a BAP in taxi domain, a BAP in parking domain are all different roles).
Each subscriber defines a subscriber_url (set of Beckn endpoints).
A participant may want to reuse the same keys for different subscribers. Also, different keys may be used at the same by the same subscriber during key rotation.

Proposed changes

1. participant_id corresponds to a company, offline registration with a registry.
2. subscriber_id corresponds to a role a participant plays (combination of type and domain), maps 1 to 1 with bap_id / bpp_id, subscriber_url and bap_url / bpp_url. Different urls, different domains or different types of participation (BAP, BPP, BG) should have different subscriber_ids.
3. We rename unique_key_id to key_id. key_id identifies the public key (or a set of encryption / signing public keys).
4. In signature data, we use subscriberData instead of currently used keyId:
   Signature keyId= "{subscriber_id}|{unique_key_id}|{algorithm}
5. We distinguish between subscriberLookup and keyLookup as these are conceptually different lookups and create two different endpoints for that.

[venkatramanm]

Key_id may be named pub_key_id to avoid confusion

[dhirajp-protean]

@venkatramanm We would need to define different APIs instead of keeping on /subscribe API.

1. For adding new services region for a domain
2. update subscriber URL
3. Invalidating Keys
4. Lookup based on key and subscriber lookup.

What is your thought on this?

[venkatramanm]

I don't have strong opinions on multiple or single api. I want the usecases to be handled.