Open APIs

 View Only
  • 1.  Difference between TMF672 and TMF691

    TM Forum Member
    Posted Mar 11, 2020 00:35
    Hi All,
    What's the main difference between the TMF691 Federated ID API and TMF672 User Roles and Permissions API?. The first one seems to wrap the open id connect api. But both talk about assets users are able to manage and the permissions and actions they can perform on that asset.

    ------------------------------
    Shibin CK
    Tecnotree
    ------------------------------


  • 2.  RE: Difference between TMF672 and TMF691

    TM Forum Member
    Posted Mar 12, 2020 05:04
    Hi Shibin
    The best I can do is to refer you to the leaders of the APIs @Joel Burgess (691) and @Gregoire Laurent (672), hopefully they can clarify this question.
    Hope it helps​​

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



  • 3.  RE: Difference between TMF672 and TMF691

    Posted Mar 12, 2020 10:21

    Hi all, I got to this same question while designing an user login system for our self-care applications.
    If the issue gets clarified, please post the conclusions here, as I still don't have it clear. 
    Thanks!

    Best regards,



    ------------------------------
    Glaucio Vaz de Mello
    Solutions Architect
    Wom Mobile
    ------------------------------



  • 4.  RE: Difference between TMF672 and TMF691

    TM Forum Member
    Posted Mar 13, 2020 05:38
    Hello Shibin, 

    the API  TMF672 (User Roles and Permissions) is used to manage roles and permissions given by a party (identified as a granter) to another party (the grantee) over a specific entity that he owns (the manageableAsset defined in the userRole resource).

    This API could for example be used to give to the owner of a VOD account the right to create subaccounts for his family members. In this case, the granter and the grantee are not logged in. We just handle data related to those parties.

    I let @Joel Burgess complete for TMF691.

    Best regards,


    ------------------------------
    Gregoire Laurent
    Orange
    My answer are my own & don't represent necessarily my company or the TMF.
    ------------------------------



  • 5.  RE: Difference between TMF672 and TMF691

    TM Forum Member
    Posted Jan 27, 2023 17:01
    Hi @Gregoire Laurent, in you example "This API could for example be used to give to the owner of a VOD account the right to create subaccounts for his family members. In this case, the granter and the grantee are not logged in. We just handle data related to those parties"

    how is a grantee not referred to the logged in user?, as per TMF672 documentation, grantee is the receiver of the permission. 
    can you basically clarify on the definition of grantee?

    ------------------------------
    Narendra Kumar
    Saudi Telecom Company
    ------------------------------



  • 6.  RE: Difference between TMF672 and TMF691

    TM Forum Member
    Posted Mar 13, 2020 08:10
    Hi Shibin & all, 

    To me this difference is clearly stated in the use cases of the APIs.

    Federated Identity API is about Identity management "The management of principals of any kind (persons, objects, …)". The can be identities of Parties or Resources (Device).

    User Roles and Permissions is about Access Management ie. the API you would use to Create and Update Roles and Permissions of Identities defined by the previous API. 

    Both are in the domain of Identity and Access management and these services are usually in the same system/platform. The do need to reference each others data.

    It is obvious that those APIs are defined by different teams and some of their terminology and use cases don't match. For example TMF672 is scoped only for Party(type=Individual), but you do need to manage permissions of Identities of Resources as well. 

    But that is seen across the TMForum API spectrum. And they will evolve.

    ------------------------------
    Niko Kolari
    DNA Plc
    ------------------------------



  • 7.  RE: Difference between TMF672 and TMF691

    Posted Oct 02, 2020 10:22
    Hi all,

    I just started to look at the mentioned APIs and I'm with Niko, that those APIs are strongly related to each other but do not fit together not only because of the scope, but also from a resource model point of.

    Actually we have a need to implement those APIs or at least provide similar  functionalities for our APIs. If I look at TMF672 User Roles and Permissions I found that the last Update is back in 2017 and since then there is not reference implementation. Is there any reason behind this?
    It seems that TMF691 has been designed without looking into TMF672, too much and is kind of a "read only" API enhancing OIDC. Basically a good idea, but which API is then managing the data provided through TMF672 Federated Identity? Maybe the idea is to use an Identity Management System for this. Don't know that.

    Maybe I can ask for some feedback and opinion about whether or not to implement those APIs or if it is better to wait until further development happend.  ​

    Thanks for your feedback.

    BR

    ------------------------------
    Reiner Mertens
    IAM Architect - Deutsche Telekom IT
    ------------------------------

    ------------------------------
    Reiner Mertens
    Deutsche Telekom AG
    ------------------------------



  • 8.  RE: Difference between TMF672 and TMF691

    TM Forum Member
    Posted Oct 11, 2020 09:50
    Please note that user roles and permissions TMF672 was refreshed recently for v4.0, I advise you to look at the early access table here as well as the published table, to verify that you can see the most up-to-date materials.
    Hope it helps

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