attribute authorization_servers in the issuer metadata for Draft 13 is now an array and ends with an s

[ThierryThevenet]

For draft 13 and above

If authorization server is given in the offer, take it to look for the authorize endpoint, token endpoint, PAR, etc. It means that the issuer server and the authorization server are 2 different servers.

Example of an offer for pre authorized code flow with an authorization_server attribute

 {
      "credential_offer": {
            "credential_issuer": "http://192.168.1.156:3000/issuer/npwsshblrm",
            "credential_configuration_ids": [
                  "Pid"
            ],
            "grants": {
                  "urn:ietf:params:oauth:grant-type:pre-authorized_code": {
                        "pre-authorized_code": "24b82a4d-27fd-11ef-9b72-0b0c8fc8184c",
                          "authorization_server": "http://192.168.1.156:3000/issuer/kwcdgsspng"
                  }
            }
      }
}

or Example of an offer authorization code flow with the authorization_server attribute

{
      "credential_offer": {
            "credential_issuer": "http://192.168.1.156:3000/issuer/kwcdgsspng",
            "credential_configuration_ids": [
                  "Pid"
            ],
            "grants": {
                  "authorization_code": {
                        "issuer_state": "test11",
                        "authorization_server": "http://192.168.1.156:3000/issuer/kwcdgsspng"
                  }
            }
      }
}

if the authorization server is not given in the offer :

1) if the attribute authorization_servers : [ "https://....", "https://....", ...] exist in the issuer metadata take the first value of the array as the authorization server endpoint. It means that the issuer server and authorization server are 2 different servers

2) if he attribute authorization_servers does not exist, it means that the issuer and the authorization server are the same server

Be careful the new attribute authorization_servers(with 's' at the end) is now an array, it was previously a string

issuer metadata are in <issuer URL>/well-known/openid-credential-issuer authorization server metadata are in <authorization server URL >/.well-known/openid-configuration

[ThierryThevenet]

specs of theauthorization_serversattribute in the issuer metadata

authorization_servers: OPTIONAL. Array of strings, where each string is an identifier of the OAuth 2.0 Authorization Server (as defined in [[RFC8414](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#RFC8414)]) the Credential Issuer relies on for authorization. If this parameter is omitted, the entity providing the Credential Issuer is also acting as the Authorization Server, i.e., the Credential Issuer's identifier is used to obtain the Authorization Server metadata. The actual OAuth 2.0 Authorization Server metadata is obtained from the oauth-authorization-server well-known location as defined in Section 3 of [[RFC8414](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#RFC8414)]. When there are multiple entries in the array, the Wallet may be able to determine which Authorization Server to use by querying the metadata; for example, by examining the grant_types_supported values, the Wallet can filter the server to use based on the grant type it plans to use. When the Wallet is using authorization_server parameter in the Credential Offer as a hint to determine which Authorization Server to use out of multiple, the Wallet MUST NOT proceed with the flow if the authorization_server Credential Offer parameter value does not match any of the entries in the authorization_servers array.

[ThierryThevenet]

OIDC4VCI test 8, 10 , 11