Open APIs

Dear Experts,

We were implementing TMF 672 and chosen V5 as it better suites our use-cases: assignment of the application-level roles to the user (employees of the company). 

Our approach is to have business roles modeled as permission set specifications, hence we assign those roles to the users by creating permission set with bunch of permissions representing assigned business roles.

I was originally thinking that each permission (aka assigned business role) should have its own validity period as they are given and withdrawn independently, e.g. one can be retail agent and call center agent simultaneously and then maybe retail agent role assignment should expire independenly of the call center agent role assignment. But instead it is defined as per Open API specification for the whole permission set: 

I've cross checked against SID and indeed there it is set on the Permission level

What would be your view on which source of the information rules in this case?

If that is SID, then we likely need to extend Permission properly on our end, hoping for the new versions of TMF 672 to rectify this issue. Otherwise we will use characteristics object on permission level to model our use-case. 

Hi Denis

As the former lead for this API, I can state that Permission is a very fine-grained item, a technical and atomic representation of a specific right to do or access something. We group these into Permission Sets, which are (shall we say) closer to the business. We envisage that users will acquire Permission Sets automatically (through Party Role) or manually (through explicit granting). It is the Permission Set as a whole, which represents the permissions implied by user's business role, which can optionally expire.

Although we worked closely with the SID team on the entity model for roles and permissions, it seems that in this particular area the SID team decided to give more flexibility.

If your business has a need to assign atomic permissions separately, and with fine-grained expiry date, you can extend the API model in your implementation.

Hope it helps.

------------------------------
Jonathan Goldberg
TM Forum

Original Message:
Sent: Nov 25, 2024 06:37
From: Denis Kozlov
Subject: TMF 672 V5 doesn't match with SID: Valid period of the Permission is absent in TMF 672 and instead defined on the Permission Set level

Dear Experts,

We were implementing TMF 672 and chosen V5 as it better suites our use-cases: assignment of the application-level roles to the user (employees of the company). 

Our approach is to have business roles modeled as permission set specifications, hence we assign those roles to the users by creating permission set with bunch of permissions representing assigned business roles.

I was originally thinking that each permission (aka assigned business role) should have its own validity period as they are given and withdrawn independently, e.g. one can be retail agent and call center agent simultaneously and then maybe retail agent role assignment should expire independenly of the call center agent role assignment. But instead it is defined as per Open API specification for the whole permission set: 

I've cross checked against SID and indeed there it is set on the Permission level

What would be your view on which source of the information rules in this case?

If that is SID, then we likely need to extend Permission properly on our end, hoping for the new versions of TMF 672 to rectify this issue. Otherwise we will use characteristics object on permission level to model our use-case. 

------------------------------
Denis Kozlov
Telefonica Germany GmbH & Co. OHG
------------------------------

Hi Denis

As the former lead for this API, I can state that Permission is a very fine-grained item, a technical and atomic representation of a specific right to do or access something. We group these into Permission Sets, which are (shall we say) closer to the business. We envisage that users will acquire Permission Sets automatically (through Party Role) or manually (through explicit granting). It is the Permission Set as a whole, which represents the permissions implied by user's business role, which can optionally expire.

Although we worked closely with the SID team on the entity model for roles and permissions, it seems that in this particular area the SID team decided to give more flexibility.

If your business has a need to assign atomic permissions separately, and with fine-grained expiry date, you can extend the API model in your implementation.

Hope it helps.

Dear Experts,

We were implementing TMF 672 and chosen V5 as it better suites our use-cases: assignment of the application-level roles to the user (employees of the company). 

Our approach is to have business roles modeled as permission set specifications, hence we assign those roles to the users by creating permission set with bunch of permissions representing assigned business roles.

I was originally thinking that each permission (aka assigned business role) should have its own validity period as they are given and withdrawn independently, e.g. one can be retail agent and call center agent simultaneously and then maybe retail agent role assignment should expire independenly of the call center agent role assignment. But instead it is defined as per Open API specification for the whole permission set: 

I've cross checked against SID and indeed there it is set on the Permission level

What would be your view on which source of the information rules in this case?

If that is SID, then we likely need to extend Permission properly on our end, hoping for the new versions of TMF 672 to rectify this issue. Otherwise we will use characteristics object on permission level to model our use-case. 

you're back! working for TM Forum now?

Hi Denis

As the former lead for this API, I can state that Permission is a very fine-grained item, a technical and atomic representation of a specific right to do or access something. We group these into Permission Sets, which are (shall we say) closer to the business. We envisage that users will acquire Permission Sets automatically (through Party Role) or manually (through explicit granting). It is the Permission Set as a whole, which represents the permissions implied by user's business role, which can optionally expire.

Although we worked closely with the SID team on the entity model for roles and permissions, it seems that in this particular area the SID team decided to give more flexibility.

If your business has a need to assign atomic permissions separately, and with fine-grained expiry date, you can extend the API model in your implementation.

Hope it helps.

Dear Experts,

We were implementing TMF 672 and chosen V5 as it better suites our use-cases: assignment of the application-level roles to the user (employees of the company). 

Our approach is to have business roles modeled as permission set specifications, hence we assign those roles to the users by creating permission set with bunch of permissions representing assigned business roles.

I was originally thinking that each permission (aka assigned business role) should have its own validity period as they are given and withdrawn independently, e.g. one can be retail agent and call center agent simultaneously and then maybe retail agent role assignment should expire independenly of the call center agent role assignment. But instead it is defined as per Open API specification for the whole permission set: 

I've cross checked against SID and indeed there it is set on the Permission level

What would be your view on which source of the information rules in this case?

If that is SID, then we likely need to extend Permission properly on our end, hoping for the new versions of TMF 672 to rectify this issue. Otherwise we will use characteristics object on permission level to model our use-case.