feat(servicemanagement): update the api

#### servicemanagement:v1

The following keys were added:
- schemas.OAuthRequirements.properties.allowAnyScope.type (Total Keys: 1)

Author: yoshi-automation

docs/dyn/servicemanagement_v1.services.configs.html

@@ -172,6 +172,7 @@ <h3>Method Details</h3>
       { # Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It&#x27;s an error to include more than one kind of credential in a single request. If a method doesn&#x27;t have any auth requirements, request credentials will be ignored.
         &quot;allowWithoutCredential&quot;: True or False, # If true, the service accepts API keys without any other credential. This flag only applies to HTTP and gRPC requests.
         &quot;oauth&quot;: { # OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for &quot;Read-only access to Google Calendar&quot; and &quot;Access to Cloud Platform&quot;. Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions. # The requirements for OAuth credentials.
+          &quot;allowAnyScope&quot;: True or False, # UNIMPLEMENTED: If enabled, ESF will allow OAuth credentials with any scope, more details in http://go/esf-oauth-any-scope. WARNING: Enabling this option will bring security risks. Customers enabling this feature accidentally may have the risk of losing authentication enforcement. Please reach out to api-auth@ and esf-team@ for approval and allowlisting before you enable this option.
           &quot;canonicalScopes&quot;: &quot;A String&quot;, # The list of publicly documented OAuth scopes that are allowed access. An OAuth token containing any of these scopes will be accepted. Example: canonical_scopes: https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/calendar.read
         },
         &quot;requirements&quot;: [ # Requirements for additional authentication providers.
@@ -638,6 +639,7 @@ <h3>Method Details</h3>
       { # Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It&#x27;s an error to include more than one kind of credential in a single request. If a method doesn&#x27;t have any auth requirements, request credentials will be ignored.
         &quot;allowWithoutCredential&quot;: True or False, # If true, the service accepts API keys without any other credential. This flag only applies to HTTP and gRPC requests.
         &quot;oauth&quot;: { # OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for &quot;Read-only access to Google Calendar&quot; and &quot;Access to Cloud Platform&quot;. Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions. # The requirements for OAuth credentials.
+          &quot;allowAnyScope&quot;: True or False, # UNIMPLEMENTED: If enabled, ESF will allow OAuth credentials with any scope, more details in http://go/esf-oauth-any-scope. WARNING: Enabling this option will bring security risks. Customers enabling this feature accidentally may have the risk of losing authentication enforcement. Please reach out to api-auth@ and esf-team@ for approval and allowlisting before you enable this option.
           &quot;canonicalScopes&quot;: &quot;A String&quot;, # The list of publicly documented OAuth scopes that are allowed access. An OAuth token containing any of these scopes will be accepted. Example: canonical_scopes: https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/calendar.read
         },
         &quot;requirements&quot;: [ # Requirements for additional authentication providers.
@@ -1116,6 +1118,7 @@ <h3>Method Details</h3>
       { # Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It&#x27;s an error to include more than one kind of credential in a single request. If a method doesn&#x27;t have any auth requirements, request credentials will be ignored.
         &quot;allowWithoutCredential&quot;: True or False, # If true, the service accepts API keys without any other credential. This flag only applies to HTTP and gRPC requests.
         &quot;oauth&quot;: { # OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for &quot;Read-only access to Google Calendar&quot; and &quot;Access to Cloud Platform&quot;. Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions. # The requirements for OAuth credentials.
+          &quot;allowAnyScope&quot;: True or False, # UNIMPLEMENTED: If enabled, ESF will allow OAuth credentials with any scope, more details in http://go/esf-oauth-any-scope. WARNING: Enabling this option will bring security risks. Customers enabling this feature accidentally may have the risk of losing authentication enforcement. Please reach out to api-auth@ and esf-team@ for approval and allowlisting before you enable this option.
           &quot;canonicalScopes&quot;: &quot;A String&quot;, # The list of publicly documented OAuth scopes that are allowed access. An OAuth token containing any of these scopes will be accepted. Example: canonical_scopes: https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/calendar.read
         },
         &quot;requirements&quot;: [ # Requirements for additional authentication providers.
@@ -1594,6 +1597,7 @@ <h3>Method Details</h3>
           { # Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It&#x27;s an error to include more than one kind of credential in a single request. If a method doesn&#x27;t have any auth requirements, request credentials will be ignored.
             &quot;allowWithoutCredential&quot;: True or False, # If true, the service accepts API keys without any other credential. This flag only applies to HTTP and gRPC requests.
             &quot;oauth&quot;: { # OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for &quot;Read-only access to Google Calendar&quot; and &quot;Access to Cloud Platform&quot;. Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions. # The requirements for OAuth credentials.
+              &quot;allowAnyScope&quot;: True or False, # UNIMPLEMENTED: If enabled, ESF will allow OAuth credentials with any scope, more details in http://go/esf-oauth-any-scope. WARNING: Enabling this option will bring security risks. Customers enabling this feature accidentally may have the risk of losing authentication enforcement. Please reach out to api-auth@ and esf-team@ for approval and allowlisting before you enable this option.
               &quot;canonicalScopes&quot;: &quot;A String&quot;, # The list of publicly documented OAuth scopes that are allowed access. An OAuth token containing any of these scopes will be accepted. Example: canonical_scopes: https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/calendar.read
             },
             &quot;requirements&quot;: [ # Requirements for additional authentication providers.

docs/dyn/servicemanagement_v1.services.html

@@ -367,6 +367,7 @@ <h3>Method Details</h3>
       { # Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It&#x27;s an error to include more than one kind of credential in a single request. If a method doesn&#x27;t have any auth requirements, request credentials will be ignored.
         &quot;allowWithoutCredential&quot;: True or False, # If true, the service accepts API keys without any other credential. This flag only applies to HTTP and gRPC requests.
         &quot;oauth&quot;: { # OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for &quot;Read-only access to Google Calendar&quot; and &quot;Access to Cloud Platform&quot;. Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions. # The requirements for OAuth credentials.
+          &quot;allowAnyScope&quot;: True or False, # UNIMPLEMENTED: If enabled, ESF will allow OAuth credentials with any scope, more details in http://go/esf-oauth-any-scope. WARNING: Enabling this option will bring security risks. Customers enabling this feature accidentally may have the risk of losing authentication enforcement. Please reach out to api-auth@ and esf-team@ for approval and allowlisting before you enable this option.
           &quot;canonicalScopes&quot;: &quot;A String&quot;, # The list of publicly documented OAuth scopes that are allowed access. An OAuth token containing any of these scopes will be accepted. Example: canonical_scopes: https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/calendar.read
         },
         &quot;requirements&quot;: [ # Requirements for additional authentication providers.

googleapiclient/discovery_cache/documents/servicemanagement.v1.json

@@ -829,7 +829,7 @@
       }
     }
   },
-  "revision": "20220805",
+  "revision": "20220822",
   "rootUrl": "https://servicemanagement.googleapis.com/",
   "schemas": {
     "Advice": {
@@ -2387,6 +2387,10 @@
       "description": "OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for \"Read-only access to Google Calendar\" and \"Access to Cloud Platform\". Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions.",
       "id": "OAuthRequirements",
       "properties": {
+        "allowAnyScope": {
+          "description": "UNIMPLEMENTED: If enabled, ESF will allow OAuth credentials with any scope, more details in http://go/esf-oauth-any-scope. WARNING: Enabling this option will bring security risks. Customers enabling this feature accidentally may have the risk of losing authentication enforcement. Please reach out to api-auth@ and esf-team@ for approval and allowlisting before you enable this option. ",
+          "type": "boolean"
+        },
         "canonicalScopes": {
           "description": "The list of publicly documented OAuth scopes that are allowed access. An OAuth token containing any of these scopes will be accepted. Example: canonical_scopes: https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/calendar.read",
           "type": "string"