proposal to make logistic confirm request stateless (independent of related init request)

[iAmPankajj]

Currently to process a confirm request, LSP would need to read and match the terms agreed upon in the previous related init request with what is sent on the confirm. This dependency of confirm on init will have impact on performance, availability, scalability on LSP side for the confirm requests.

To eliminate the dependency, one possible solution is to make the confirm request stateless or more self-contained yet one that can be trusted by the receiving LSP without having to (store and) fetch the related init request sent previously. To achieve this, the confirm (and oninit) schema can be extended to include the necessary info of the init request that was agreed upon (terms negotiated) by the LSP along with LSP's signature specific for those terms. The LSP upon receiving the subsequent confirm request can validate its own signature and optionally match the signed terms (attributes) with other related attributes in the confirm request (if duplicated) to ensure the terms negotiated in init are intact.

Orchestration details (starting from init) -

1. ONDC logistic buyer (say SellerApp) sends an init request to ONDC logistic seller (LSP) with negotiating terms. These terms could be concentrated as below or be scattered in different parts of init request.

      {
           "context": {...}
            "message":{
                   ...
                   "terms":{
                              "term-attr1":"value1",
                               ...
                               "term-attrN":"valueN"
                   }
             }
       }

   A sample term name-value pair could be "paymentType":"COD"

2. ONDC logistic seller, if it is ok with the terms, generates signature (using its signing private key) for the key (or all) terms (as decided by ONDC) and includes this signature in the /oninit callback response message. It can also copy the terms (in case not implicit) used in generating the signature in the response. A hypothetical portion of /oninit message:

   {"context": {...}
     "message":{...
                             "init-negotiation":{
                                         "signature":<LSP generated signature>
                                          "terms":{
                                                            "term-attr1":"value1",
                                                              ...
                                                              "term-attrN":"valueN"
                                           }
                       }
            }
      }

   NOTE that this signature included in the message payload is different from the signature LSP would add in auth header and is specific to negotiated portions only.

3. ONDC logistic buyer upon receiving the oninit message , ACKs the LSP and extracts out the negotiated portion from it and copies that into the subsequent confirm message to that LSP (in case logistic buyer chooses to place logistic order with that LSP). The logistic buyer can optionally validate the signature in negotiation (although not necessary as it has already validated the signature in the header of oninit) but if it wants can store that negotiated portion for its records (can help solve any non-repudiation issues later with LSP). A hypothetical portion of subsequent confirm message to the LSP

   { "context": {...} "message":{ ... "init-negotiation":{ "signature": "terms":{ "term-attr1":"value1", ... "term-attrN":"valueN" } } ... "term-attr1":"value1" // in case some negotiated terms need to be duplicated at other parts of confirm message for matching or other purposes .... } } NOTE: Logistic buyer also sends its own auth signature in header as it does for any request

4. The LSP upon receiving the confirm request, besides validating the sender's signature in auth header, validates its own signature contained in the "init-negotiation" portion of the confirm payload. If the term information is repeated at other parts of the confirm message (which is expected to be used for creating manifestation order), LSP would match those with the corresponding term value. If the negotiated term/signature validation fails then LSP can reject (NACK) the confirm request with some invalid negotiation error message. Else it would proceed further to create the logistic order/manifestation.

[iAmPankajj]

this can be applied to retail confirm request as well if it has negotiations done in preceding init request

[iAmPankajj]

we may prefer having the terms (being negotiated) concentrated as it gives clarity to buyer and seller on negotiation

[iAmPankajj]

Looks like init requests are also stateful (dependent on data stored in preceding search request)..