Open APIs

 View Only
  • 1.  Cleint sensitive data in request URL's

    TM Forum Member
    Posted Feb 19, 2020 13:09
    Hi All

    I was wondering if there are any standard guidelines available on this portal to pass the client sensitive data like MSISDN's or Directory numbers in the Product qualification request API. I presume that this would be a common concern for all the companies operating under GDPR regulations and since most of the API gateways have logging enabled for the requests that pass through, I was wondering if there have been any guidelines or standard procedures established to pass such information in the API request securely.

    Appreciate your thoughts on this.

    Cheers!

    ------------------------------
    Vishal Thakur
    BT Group plc
    ------------------------------


  • 2.  RE: Cleint sensitive data in request URL's

    TM Forum Member
    Posted Feb 19, 2020 13:49
    Hi Vishal

    To date the Open API specifications have not made prescriptions regarding transmission of personal data (I prefer that term rather than Sensitive data, since GDPR covers all data owned by a data subject, not just sensitive data).

    My personal view is that this is beyond the scope of an API specification. For example you raise the issue of logging, that's surely an issue that needs to be addressed in the implementation of an API (for logging from within the business layer), or in the API gateway (for logging of API payloads).

    It might be possible to "decorate" the Open API data model (the schema) with additional metadata indicating which data is considered personal, PII, sensitive, etc. But I don't know how this could be done technically within the current format (JSON Schema and Swagger), maybe other forum members have ideas.

    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: Cleint sensitive data in request URL's

    TM Forum Member
    Posted Feb 20, 2020 05:48
    VIshal
    The topics of Security and privacy has been partially addressed in the ODA project u the specific point you raise is an active current discussion.  The work so far is  in two documents
    The later gives a structured approach to assessing risk and mitigation requirement on entities within ODA including those described in SID.
    In the main GDPR impact entities related to Parties around PII and lawful processing. ( Note there are uncertainties about what is lawful processing in a network / 5G context) 
    Your question about control of this PII data in interfaces has multiple levels:
    •  A  role based and or attribute access control mechanism established outside the specific API but affecting the behaviour of the API, and following guidelines such as those in IG1187
    • A security privacy  framework for managing access and access control lists and auditing requirements
    • This later point came up at AW as part of the discussion on Model driven approaches to implementing ODA Components ( that use TM Forum Open APIs in a specific pattern) as described in: 
      IG1171 ODA Component Definition R19.0.1    see
       
      2020-02-04 Tue Q4: ODA-RI workshop: ODA Technical Architecture( WIP to be completed)
    • The key point is that security /privacy mechanisms have to be associated with a deployable unit of software of which an API is one part. ODA Components are the natural fit for this requirement.
    • The discussion at Action Week above and the following ODA Security  Privacy  team calls was to develop a machine readable metadata for defining Security / Privacy of an ODA Component and hence a specific OPEN API in a specific context.
    happy to include you in such discussions if you drop me a message with your email  Note there is a BT person involved in these discussions.


    ------------------------------
    Dave Milham
    TM Forum chief architect
    ------------------------------