Steve
I think this addition to the thread is a bit of a non-sequitur to the previous one?
Prior to this you were discussing information models for an envisaged API?
This latest message in part now attempts to deal with with Integrity/Non-Repudiation requirements for an API together with the reliable asynchronous delivery of information.
On the second of these I would caution trying to extemporise on how to realise these risk mitigations on a single API. But I note that the Open API team seem to have left these wider concerns open for implementers to resolve for themselves?
Trying to select technologies, and define their usage, to cover the whole of the C.I.A security requirements for both information in motion and at rest and achieve idempotency of asynch messaging and ensure that is compatible with the security standards supported in the OpenAPI specification standards could become a tall order.
Moreover these features will then become an issue for achieving interoperability with other partners in a B2B model.
Ideally you would want to solve these issues once for a variety of APIs and in concert with others implementing similar solutions.
For example I get the impression that you have chosen to regard digital signing as a means of dealing with authentication of the origin? Infact technologies like XMLDSIG, JWS, HMAC and the like are as much about message integrity as anything else. Moreover these technologies have to be clear on issues like the relationship between encryption and signing, and which bits of a message are signed (due to issues of transformation of http headers and the like in flight), and the PKI infrastructure (or not) behind them.
You mention ebXML. Well the approach taken there was to conduct an initial risk assessment and look at compatible technologies to address those risks (url below)
http://www.ebxml.org/specs/secRISK_print.pdf Moreover the technologies were chosen to be compatible with one another. And great pain was taken to ensure be clear what it was about a message which was signed (whether it would include timestamps for example) and also to be clear that it was a signature of the message as created, sent, received and persisted in a message store without being transformed and /or stored in a business system of record.
Oh and not only was it standardised and tested for interoperability of various implementations, it was also defined to be configurable on a partner by partner basis and not baked into the API of the internal systems.
------------------------------
Derrick Evans
------------------------------
Original Message:
Sent: Jan 26, 2022 06:52
From: Steve Ranford-Bragg
Subject: APIs for allocating work request to partners supplying engineering services
Having given this some more thought, there was a danger of trying to overcomplicate it and end up trying to replicate the level of the OASIS standards for ebXML which I think goes too far. However, there is value I think in providing a method of managing work orders with another party that gives the important parts of ebXML for reliability and non-repudiation until there is a decision on how it should be managed and included in the TMF standards.
What I'm considering uses existing APIs and consists of:
- The work specifications are published by the entity catalogue management API which defines a set of work items with units, characteristics, prices etc so they are machine readable for publication of new contracts and versions etc.
- The work order API will be exposed by the work originator (in this case Openreach) to manage the tasks. Openreach applications will be able to create a work order and then both Openreach and the third party will be able to use the GET/PUT/PATCH/DELETE operations to manage updates and transition the work order as it progresses.
- The event management API will be used to allow third parties to be notified of work being allocated to them by subscribing to a topic and then Openreach creating an event for that topic. Work order details will be sent in the work order create event.
- The delivery receipts in ebXML will be replaced with an HTTP header with a correlation id that denotes that the message has been received and persisted for processing. For example on receiving the work order create event, the third party will update call the API to update the state to "acknowledged" and pass an input header with their correlation id that signifies it has been persisted on arrival. The response to the update will contain a correlation id that the request has been persisted before being actioned.
- To add the non-repudiation offered by ebXML, key pairs will be generated and the private key used to sign part or all of the message payload. The public key will be shared with the other party who can then decrypt the payload to authenticate that the incoming message is from the expected origin.
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: Jan 23, 2022 06:24
From: Steve Ranford-Bragg
Subject: APIs for allocating work request to partners supplying engineering services
Yes, this is a bit of a different case to a standard procurement process where you're buying from a supplier. In this use case the work orders are being placed on the basis of a defined contract with our partners and prices so we actually dictate the catalogue and the specification of what is being provided by the supplier.
We also place work requests to third parties based on contracts to do things like provision of orders to give us more flex in our field engineering resources so there would feel like several possible use cases for this - I'd imagine other large network and service providers may also have a similar requirement? I'm going to involve
@Tony Shepherd to help with the process view of this too when he returns from leave.
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: Jan 23, 2022 04:54
From: Jonathan Goldberg
Subject: APIs for allocating work request to partners supplying engineering services
Hi Steve
Some of the ODA use cases are looking at soliciting services from third parties, and have been discussions around a purchase order component to mediate this. @Ludovic Robert and @Sylvie Demarest could probably give more information.
Specifically regarding work order - there is a suite of work-related APIs in early development in the Open API project. I think that a main challenge here will be - for the consumer of (say) a Work Order API (e.g. BT), how do you "know" what is in your suppliers' "work catalog" so that you can correctly construct the work order.
Very interesting discussion point that you have raised here.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Jan 21, 2022 07:00
From: Steve Ranford-Bragg
Subject: APIs for allocating work request to partners supplying engineering services
Looking into the ABE's which might be used here, there seem to be two related ones. We are procuring a service from a supplier and so there are elements on issuing an order, invoicing and bill payment but what we're issuing is more akin to a work order as it is requesting stuff to be done rather than the delivery of a service or asset. Possibly there could be an association between the two to allow for the procurement of either goods and also completion of work orders by a supplier?
------------------------------
Steve Ranford-Bragg
BT Group plc
Original Message:
Sent: Jan 21, 2022 05:54
From: Steve Ranford-Bragg
Subject: APIs for allocating work request to partners supplying engineering services
Hi,
We are investigating the modernisation of our existing IT used to send work requests to partners who we have contracts with to supply resource to complete civil engineering work (network build, roadworks, tree cutting services etc) and at the moment the emphasis seems to be on B2C/B2B - which is completely reasonable - but has there been any thought about these kind of services? If we are ahead of some others I'd be happy to share our work and collaborate with others on the definition of the APIs.
------------------------------
Steve Ranford-Bragg
BT Group plc
------------------------------