Date   

Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Darrel Miller
 

Hi Roger,

Sounds good to me.

Darrel

From: Roger Brown <RBrown@...>
Sent: Thursday, November 10, 2022 11:03 AM
To: Darrel Miller <Darrel.Miller@...>; alf.zugenmaier@... <alf.zugenmaier@...>; Mark Weitzel <markweitzel@...>; marshg@... <marshg@...>; webron@... <webron@...>; Neal Caidin <ncaidin@...>
Cc: tsc@openapi.groups.io <tsc@openapi.groups.io>
Subject: RE: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications
 
You don't often get email from rbrown@.... Learn why this is important

Hi Darrel,

 

Many thanks for this, it’s a very good description of the concern and suggested mitigation. Off the back of this we plan to create an LS to 3GPP using your assessment below as the basis and plan to attribute the OpenAPI Initiative TSC.

 

Can you confirm you are happy for us to go ahead with this plan? We’d be happy to share the LS with you before it is sent.

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

From: Darrel Miller <Darrel.Miller@...>
Sent: 05 November 2022 18:03
To: alf.zugenmaier@...; Roger Brown <RBrown@...>; Mark Weitzel <markweitzel@...>; marshg@...; webron@...; Neal Caidin <ncaidin@...>
Cc: tsc@openapi.groups.io
Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

 

“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”

 

Hi Alf,

 

As one of the members of the OpenAPI Initiative Technical Steering committee, I want to provide you with a written version of the answer I provided to your question raised in this weeks community call.  I have also included Marsh and Ron from the TSC to give them the opportunity share their perspective on this topic also.

 

As I understand it, the 3GPP group use OpenAPI descriptions for the formal definition of APIs in their service based architecture.  While your OpenAPI descriptions describe the set of possible features and capabilities of an API, a specific API deployment may choose different configuration options that might enable or disable certain features.

 

The particular area of concern is with the description of security requirement objects and the relationship between what is described in the OpenAPI definition and what is possible in a specific deployment of an API that implements the OpenAPI definition.

 

An API that implements an OpenAPI definition should provide the capabilities described, however, nothing prevents someone who deploys that API from disabling some of the described capabilities.  It is expected that when a client attempts to use those described capabilities that the HTTP API respond with an appropriate HTTP status code and a error payload explaining why those capabilities do not behave as expected.

 

In order to help client developers be aware that certain capabilities may not be accessible at runtime, the OpenAPI definition could include a custom extension to signal this variability.  For example,

 

{

  "security": [

       {

            x-runtime-configurable: true

    },

       {

           "oAuth2ClientCredentials" : [],

     x-runtime-configurable: true

       }

   ]

}

 

It is necessary to use an "x-" extension to describe this variability as there is currently no native way to describe this.  The x-runtime-configurable name is simply a suggestion, you may find another name that is more descriptive.

 

The majority of usage of OpenAPI is to describe a particular instance of an API, not to describe a standard API shape that could be implemented by multiple providers and deployed many times.  It is a viable use case, just not one we see often.  We welcome additional input from your organization to identify ways in which OpenAPI could be improved in order to address your scenarios. 

 

Please let me know if you have other questions,

 

Regards,

 

Darrel Miller

 

 

 


From: Zugenmaier, Alf <alf.zugenmaier@...>
Sent: Thursday, November 3, 2022 5:15 PM
To: Darrel Miller <Darrel.Miller@...>; RBrown@... <RBrown@...>; Mark Weitzel <markweitzel@...>
Cc: tsc@openapi.groups.io <tsc@openapi.groups.io>
Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

 

You don't often get email from alf.zugenmaier@.... Learn why this is important

Hi Darrel and Mark,

 

also from my side many thanks for the explanations.

 


This link will take you to a set of specifications produced by 3GPP:

In the 29 series, there are a number of specifications that include API specifications:
https://portal.3gpp.org/Specifications.aspx?q=1&series=23&releases=all&draft=False&underCC=False&withACC=False&withBCC=False&numberNYA=False
A good one to start looking at is the specification for the AMF: 29.518
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3339
Looking at the latest version: 
https://www.3gpp.org/ftp/Specs/archive/29_series/29.518/29518-h70.zip
In that zip file, there is a yaml file and a textual description.

That specification doesn't stand alone though, it builds on an
architecture set out in 3GPP TS23.501 and TS23.502, as well as more

protocol related, but still general TS29.500 and TS29.501.

 

Cheers,

   Alf

 

Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:

Hi Darrel, Mark,

 

Many thanks for the very useful call just now. Please see below the questions we discussed. For context here is some detail on the GSMA’s Coordinated Vulnerability Disclosure programme. @alf.zugenmaier@... if you could kindly add the links to the 3GPP Specs.

 

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.

.


Re: Event: OpenAPI Initiative - TSC Meeting - Thursday, November 10, 2022 #cal-reminder

Neal Caidin
 

Hi All,

Today's meeting is cancelled. Not sure what triggered this notification. Please ignore.

Thanks,
Neal

Neal Caidin
Program Manager 
The Linux Foundation
Durham, NC, U.S.A. - Eastern time zone
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)




On Thu, Nov 10, 2022 at 11:55 AM Group Notification <noreply@...> wrote:

Reminder: OpenAPI Initiative - TSC Meeting

When:
Thursday, November 10, 2022
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - Thursday, November 10, 2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
Thursday, November 10, 2022
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Roger Brown <RBrown@...>
 

Hi Darrel,

 

Many thanks for this, it’s a very good description of the concern and suggested mitigation. Off the back of this we plan to create an LS to 3GPP using your assessment below as the basis and plan to attribute the OpenAPI Initiative TSC.

 

Can you confirm you are happy for us to go ahead with this plan? We’d be happy to share the LS with you before it is sent.

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

From: Darrel Miller <Darrel.Miller@...>
Sent: 05 November 2022 18:03
To: alf.zugenmaier@...; Roger Brown <RBrown@...>; Mark Weitzel <markweitzel@...>; marshg@...; webron@...; Neal Caidin <ncaidin@...>
Cc: tsc@openapi.groups.io
Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

 

“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”

 

Hi Alf,

 

As one of the members of the OpenAPI Initiative Technical Steering committee, I want to provide you with a written version of the answer I provided to your question raised in this weeks community call.  I have also included Marsh and Ron from the TSC to give them the opportunity share their perspective on this topic also.

 

As I understand it, the 3GPP group use OpenAPI descriptions for the formal definition of APIs in their service based architecture.  While your OpenAPI descriptions describe the set of possible features and capabilities of an API, a specific API deployment may choose different configuration options that might enable or disable certain features.

 

The particular area of concern is with the description of security requirement objects and the relationship between what is described in the OpenAPI definition and what is possible in a specific deployment of an API that implements the OpenAPI definition.

 

An API that implements an OpenAPI definition should provide the capabilities described, however, nothing prevents someone who deploys that API from disabling some of the described capabilities.  It is expected that when a client attempts to use those described capabilities that the HTTP API respond with an appropriate HTTP status code and a error payload explaining why those capabilities do not behave as expected.

 

In order to help client developers be aware that certain capabilities may not be accessible at runtime, the OpenAPI definition could include a custom extension to signal this variability.  For example,

 

{

  "security": [

       {

            x-runtime-configurable: true

    },

       {

           "oAuth2ClientCredentials" : [],

     x-runtime-configurable: true

       }

   ]

}

 

It is necessary to use an "x-" extension to describe this variability as there is currently no native way to describe this.  The x-runtime-configurable name is simply a suggestion, you may find another name that is more descriptive.

 

The majority of usage of OpenAPI is to describe a particular instance of an API, not to describe a standard API shape that could be implemented by multiple providers and deployed many times.  It is a viable use case, just not one we see often.  We welcome additional input from your organization to identify ways in which OpenAPI could be improved in order to address your scenarios. 

 

Please let me know if you have other questions,

 

Regards,

 

Darrel Miller

 

 

 


From: Zugenmaier, Alf <alf.zugenmaier@...>
Sent: Thursday, November 3, 2022 5:15 PM
To: Darrel Miller <Darrel.Miller@...>; RBrown@... <RBrown@...>; Mark Weitzel <markweitzel@...>
Cc: tsc@openapi.groups.io <tsc@openapi.groups.io>
Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

 

You don't often get email from alf.zugenmaier@.... Learn why this is important

Hi Darrel and Mark,

 

also from my side many thanks for the explanations.

 


This link will take you to a set of specifications produced by 3GPP:

In the 29 series, there are a number of specifications that include API specifications:
https://portal.3gpp.org/Specifications.aspx?q=1&series=23&releases=all&draft=False&underCC=False&withACC=False&withBCC=False&numberNYA=False
A good one to start looking at is the specification for the AMF: 29.518
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3339
Looking at the latest version: 
https://www.3gpp.org/ftp/Specs/archive/29_series/29.518/29518-h70.zip
In that zip file, there is a yaml file and a textual description.

That specification doesn't stand alone though, it builds on an
architecture set out in 3GPP TS23.501 and TS23.502, as well as more

protocol related, but still general TS29.500 and TS29.501.

 

Cheers,

   Alf

 

Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:

Hi Darrel, Mark,

 

Many thanks for the very useful call just now. Please see below the questions we discussed. For context here is some detail on the GSMA’s Coordinated Vulnerability Disclosure programme. @alf.zugenmaier@... if you could kindly add the links to the 3GPP Specs.

 

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.

.


Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Darrel Miller
 

Hi Alf,

As one of the members of the OpenAPI Initiative Technical Steering committee, I want to provide you with a written version of the answer I provided to your question raised in this weeks community call.  I have also included Marsh and Ron from the TSC to give them the opportunity share their perspective on this topic also.

As I understand it, the 3GPP group use OpenAPI descriptions for the formal definition of APIs in their service based architecture.  While your OpenAPI descriptions describe the set of possible features and capabilities of an API, a specific API deployment may choose different configuration options that might enable or disable certain features.

The particular area of concern is with the description of security requirement objects and the relationship between what is described in the OpenAPI definition and what is possible in a specific deployment of an API that implements the OpenAPI definition.

An API that implements an OpenAPI definition should provide the capabilities described, however, nothing prevents someone who deploys that API from disabling some of the described capabilities.  It is expected that when a client attempts to use those described capabilities that the HTTP API respond with an appropriate HTTP status code and a error payload explaining why those capabilities do not behave as expected.

In order to help client developers be aware that certain capabilities may not be accessible at runtime, the OpenAPI definition could include a custom extension to signal this variability.  For example,

{
  "security": [
       {
            x-runtime-configurable: true
    },
       {
           "oAuth2ClientCredentials" : [],
     x-runtime-configurable: true
       }
   ]
}
 
It is necessary to use an "x-" extension to describe this variability as there is currently no native way to describe this.  The x-runtime-configurable name is simply a suggestion, you may find another name that is more descriptive.

The majority of usage of OpenAPI is to describe a particular instance of an API, not to describe a standard API shape that could be implemented by multiple providers and deployed many times.  It is a viable use case, just not one we see often.  We welcome additional input from your organization to identify ways in which OpenAPI could be improved in order to address your scenarios. 

Please let me know if you have other questions,

Regards,

Darrel Miller
 

 

From: Zugenmaier, Alf <alf.zugenmaier@...>
Sent: Thursday, November 3, 2022 5:15 PM
To: Darrel Miller <Darrel.Miller@...>; RBrown@... <RBrown@...>; Mark Weitzel <markweitzel@...>
Cc: tsc@openapi.groups.io <tsc@openapi.groups.io>
Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications
 
You don't often get email from alf.zugenmaier@.... Learn why this is important
Hi Darrel and Mark,

also from my side many thanks for the explanations.


This link will take you to a set of specifications produced by 3GPP:
In the 29 series, there are a number of specifications that include API specifications:
https://portal.3gpp.org/Specifications.aspx?q=1&series=23&releases=all&draft=False&underCC=False&withACC=False&withBCC=False&numberNYA=False
A good one to start looking at is the specification for the AMF: 29.518
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3339
Looking at the latest version: 
https://www.3gpp.org/ftp/Specs/archive/29_series/29.518/29518-h70.zip
In that zip file, there is a yaml file and a textual description.

That specification doesn't stand alone though, it builds on an
architecture set out in 3GPP TS23.501 and TS23.502, as well as more
protocol related, but still general TS29.500 and TS29.501.

Cheers,
   Alf

Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:

Hi Darrel, Mark,

 

Many thanks for the very useful call just now. Please see below the questions we discussed. For context here is some detail on the GSMA’s Coordinated Vulnerability Disclosure programme. @alf.zugenmaier@... if you could kindly add the links to the 3GPP Specs.

 

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.


Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Roger Brown <RBrown@...>
 

Hi Darrel, Mark,

 

Many thanks for the very useful call just now. Please see below the questions we discussed. For context here is some detail on the GSMA’s Coordinated Vulnerability Disclosure programme. @alf.zugenmaier@... if you could kindly add the links to the 3GPP Specs.

 

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.


Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Zugenmaier, Alf <alf.zugenmaier@...>
 

Hi Darrel and Mark,

also from my side many thanks for the explanations.


This link will take you to a set of specifications produced by 3GPP:
In the 29 series, there are a number of specifications that include API specifications:
https://portal.3gpp.org/Specifications.aspx?q=1&series=23&releases=all&draft=False&underCC=False&withACC=False&withBCC=False&numberNYA=False
A good one to start looking at is the specification for the AMF: 29.518
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3339
Looking at the latest version: 
https://www.3gpp.org/ftp/Specs/archive/29_series/29.518/29518-h70.zip
In that zip file, there is a yaml file and a textual description.

That specification doesn't stand alone though, it builds on an
architecture set out in 3GPP TS23.501 and TS23.502, as well as more
protocol related, but still general TS29.500 and TS29.501.

Cheers,
   Alf

Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:

Hi Darrel, Mark,

 

Many thanks for the very useful call just now. Please see below the questions we discussed. For context here is some detail on the GSMA’s Coordinated Vulnerability Disclosure programme. @alf.zugenmaier@... if you could kindly add the links to the 3GPP Specs.

 

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.


Event: OpenAPI Initiative - TSC Meeting - 11/03/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
11/03/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 10/27/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
10/27/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 10/20/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
10/20/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 10/13/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
10/13/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 10/06/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
10/06/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 09/29/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
09/29/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Neal Caidin
 

Hi Roger,

Sorry for the delay in response. The best place to go for answers is probably the #spec channel on Slack. To join Slack please use:

If you run into any issues, please let me know, ncaidin@... .

We also have a Discord space for discussions:

Best regards,
Neal

Neal Caidin
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)




On Wed, Sep 28, 2022 at 7:56 AM Roger Brown <RBrown@...> wrote:

Hello,

 

Please let me introduce myself. I am Roger Brown and I manage the Coordinated Vulnerability Disclosure programme within the GSMA. The programme offers an avenue for researchers to disclose Telco industry vulnerabilities. We then work with the industry to develop fixes and mitigations to protect the industry and its customers. We have recently received an OAuth2.0 vulnerability and we hoped someone at OpenApi might be able to assist with a couple of questions regarding your specifications:

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

Many thanks for any assistance you can offer. If this has been sent to the wrong email account, please could you advise who would be best to contact.

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.


Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications

Roger Brown <RBrown@...>
 

Hello,

 

Please let me introduce myself. I am Roger Brown and I manage the Coordinated Vulnerability Disclosure programme within the GSMA. The programme offers an avenue for researchers to disclose Telco industry vulnerabilities. We then work with the industry to develop fixes and mitigations to protect the industry and its customers. We have recently received an OAuth2.0 vulnerability and we hoped someone at OpenApi might be able to assist with a couple of questions regarding your specifications:

 

The openAPI specification contains the following statements:

1) "To make security optional, an empty security requirement ({}) can be included in the array.", and

2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."

 

We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.

 

So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?

 

Many thanks for any assistance you can offer. If this has been sent to the wrong email account, please could you advise who would be best to contact.

 

 

Kind Regards,

Roger Brown

 

signature_985842233

 

Roger Brown

Security Services Manager

+447740433437

 

gsma.com

 

.


Event: OpenAPI Initiative - TSC Meeting - 09/22/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
09/22/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 09/15/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
09/15/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 09/08/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
09/08/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 09/01/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
09/01/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY


Event: OpenAPI Initiative - TSC Meeting - 08/25/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: OpenAPI Initiative - TSC Meeting

When:
08/25/2022
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Organizer: ncaidin@... 5105931367

View Event

Description:

https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09

 

Or iPhone one-tap :

    US: +16699006833,,975841675#  or +16465588656,,975841675#

Or Telephone:

    Dial(for higher quality, dial a number based on your current location):

        US: +1 669 900 6833  or +1 646 558 8656  or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)

        Canada: +1 647 558 0588  or +1 855 703 8985 (Toll Free)

    Meeting ID: 975 841 675
    Passcode: 763054

    International numbers available: https://zoom.us/zoomconference?m=O5GTXe8YQd3NYbDa8zH3wow0vl20oFrY

1 - 20 of 467