anchor.diff:      id: "<provider id>",
       identityProvider: {
         metadata: {
  -        url: "https://myssoprovider.com/meta-data/..."
  -      }
  -    }
  -  }) {
  -    ssoProvider {
  -      state
  -      url
  +        url: "https://myssoprovider.com/metadata/..."
  +      }
  +    }
  +  }) {
  +    ssoProvider {
  +      state
  +      url
  +      ... on SSOProviderSAML {
  +        serviceProvider {
  +          ssoURL
  +          issuer
  +        }
  +      }
       }
     }
   }
   ```
         
  -If your SSO provider doesn't provide a metadata URL, you can manually specify the SSO URL, Issuer (also known as Entity ID), and Certificate to the `ssoProviderUpdate` mutation:
  +If your SSO provider didn't provide a metadata URL, then copy SSO URL, Issuer (also known as Entity ID), and Certificate into the `ssoProviderUpdate` mutation:
         
   ```graphql
   mutation UpdateProviderMetaData {
  
positive.code: 
  ### Step 2
  
  The next step is to log into your SSO provider’s system and setup Buildkite using the `issuer`, `ssoURL` and `metadata` returned above. Once setup, your SSO provider should provide a meta-data URL, or a set of URLs and a certificate, that you can use in the next step.
  
  ### Step 3
  
  If your provider provided a metadata URL, use the `ssoProviderUpdate` mutation to have Buildkite automatically retrieve the details and set it up, ready for a test login. This will not yet affect any of your Buildkite users.
  
  ```graphql
  mutation UpdateProviderMetaData {
  
negative.code:     ssoProvider {
        state
        url
        ... on SSOProviderSAML {
          serviceProvider {
            ssoURL
            issuer
          }
        }
      }
    }
  }
  ```
  
  If your SSO provider requests additional info, use the `ssoURL` property for the ACS URL or SSO URL, and the `issuer` property for the Issuer or Entity ID.
  
  ### Step 4
  
  