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. 

------------------------------
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.

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

Hi Jonathan,

Thanks a lot for the prompt response. 

I believe our approach is aligned to your vision to some extent as we also treat Business Role as Permission Specification Set. 

However, while assigning those Permission Specification Sets (aka Business Roles) we used feature available in the TMF 672 V5 to pass multiple Permission Specification Sets all together with single POST /permissionSet/

However, maybe it is rather a bug (or confusion point) then a feature. 

Current modeling in fact tells us two contraversual things:

1. From Permission Specification definition we shell conclude that Permission should be atomic. 
2. From Permission Set definition we see as one of the possible options for Permission to point to Permission Specification Set that in turn represents multiple Permissions, so kind of a circular dependency if you think about it. 

The second one case is btw. perhaps rightfully not present in the SID (added in red):

So having this Permission Set -> Permission(s) -> Permission Specification Set -> Permission Specification(s) -> Permission - is it indeed an issue or there was some thought behind?

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

Original Message:
Sent: Nov 25, 2024 07:52
From: Jonathan Goldberg
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

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
------------------------------

you're back! working for TM Forum now?

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform
------------------------------

Original Message:
Sent: Nov 25, 2024 07:52
From: Jonathan Goldberg
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

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
------------------------------

I'm back, but working part-time for TMF, so I don't know how much time I'll have to interact with the community.

------------------------------
Jonathan Goldberg API Architect
Jonathan Goldberg
Although I am a contractor for TM Forum, the views and information I express in this community are mine, and do not necessarily reflect TM Forum official position.
------------------------------

Original Message:
Sent: Nov 26, 2024 08:59
From: Matthieu Hattab
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

you're back! working for TM Forum now?

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform
------------------------------


Original Message:
Sent: Nov 25, 2024 07:52
From: Jonathan Goldberg
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

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