You are correct that in the current published scope of TMF672 the focus was mainly on family situations, parental controls, etc.
Due to this limited scope, we decided to create a complete overhaul of the API, removing some constraints and adding a more flexible model of rights and permissions, basically allowing representation of RBAC and ABAC. In parallel, the corresponding Information Framework (SID) was updated. I'm the lead for this API, and it was done in cooperation with an architect from Verizon (who unfortunately has since moved on career-wise and is no longer involved in TMF activities).
Unfortunately, the publication of the new API has been delayed due to higher priorities for version 5 publication in other areas of the Open API model.
I can perhaps share with you the user guide as-is, with a strong warning that details might change as a part of the revised version 5 publication tools and procedures. I don't have a date for when we'll be publishing the "official" beta.
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.
Sent: Sep 26, 2022 08:06
From: David Whitfield
Subject: Application permissions to Entities
I began looking at the TMF672 user Role and Permission management API as i'd initially thought this might be the correct choice. However i see that in here all of the examples seem to suggest use cases where a particular product has some kind of digital access platform and giving a root user (service/product account holder) access, It then goes on to allow them to manage this by adding addional people to it. I can see how this fits nicely into a use case like a VOD streaming platform where service users wish to create and manage their household profiles.
I however had a different use case and this is internal to the organisation. The following are true
- There are multiple COM platforms
- There is a single SOM platform
- Orders will be 'owned' by a division of the organisation
- Entries in the service inventory will be 'owned' by a division of the organisation
- Multiple platforms will need to access these orders/services (such as product/service management systems, COMs, ticketing, diagnostics systems.
These kind of permissions are at application level and not at user (customer or employee). So it didnt feel natural to me that the use case documented in API really fitted this use case as the permissions would not be continually managed and new permissions continually be created.
Even if the feeling is that this API could be be used im not sure if it would be efficient. Its appears like every time an entity (an order or a service) is created then a new permission must be created and assigned. This would mean that.
I'm not sure if ive just picked on the wrong document here or just that this is a use case that hasnt been addressed/seen as needed.
- the "user" would be actually a system (i.e. COM1)
- the granter would be a system (SOM)
- when the SOM API was called (especially in a 'LIST' operation) it would need to take identity of the caller and then call this 672 API and the payload would be quite lengthy given the number of order references that it might return.
@Gregoire Laurent I noticed you were the lead on this 672 from another post so perhaps you might be one of the people able to help?
As always, appreciate any help on this