Regression issue : the authorization_server endpoint in the offer is not taken into account anymore

[ThierryThevenet]

That is the first authorization_endpoint to use if it exists

In the following case the authorization_server endpoint is in the offer and the token endpoint is in the authorization server metadata
test with

[hawkbee1]

The offer:
{"credential_issuer":"https://openid-dts-dev-features.dev.adaptivespace.io/issuers/01930812-df79-76d0-889b-3d05cc423889","credential_configuration_ids":["PhotoId-3-with-sd_VC+SD-JWT"],"grants":{"authorization_code":{"issuer_state":"019398bf-9eac-774f-a909-68d8cdab7bdf","authorization_server":"https://authk.dev.adaptivespace.io/realms/pid-issuer-realm"}}}

The url we are launching:
https://authk.dev.adaptivespace.io/realms/pid-issuer-realm/authorize?response_type=code&redirect_uri=https%3A%2F%2Fapp.altme.io%2Fapp%2Fdownload%2Fcallback&state=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb2RlVmVyaWZpZXIiOiJjbVRiT21RdzZ3SnM4RlpqLUluMkFwQk1zbm9kOXlQQkxaUGdsVmlVZk8wIiwiY3JlZGVudGlhbHMiOlsiUGhvdG9JZC0zLXdpdGgtc2RfVkMrU0QtSldUIl0sImlzc3VlciI6Imh0dHBzOi8vb3BlbmlkLWR0cy1kZXYtZmVhdHVyZXMuZGV2LmFkYXB0aXZlc3BhY2UuaW8vaXNzdWVycy8wMTkzMDgxMi1kZjc5LTc2ZDAtODg5Yi0zZDA1Y2M0MjM4ODkiLCJpc0VCU0kiOmZhbHNlLCJwdWJsaWNLZXlGb3JEUG9wIjoie1wiY3J2XCI6XCJQLTI1NlwiLFwiZFwiOlwicEdSMWxZUFNpeDdLLXNmRGRQV3MybG9JRjJXbGxINDR2ci1SeTVORTBfMFwiLFwia3R5XCI6XCJFQ1wiLFwieFwiOlwia3VLeWpjd3Uyclc0aXdLdk55aUltdTV1cUo1ZWZybzY3dktDaC1CUC1Lc1wiLFwieVwiOlwib1hmMHg5ejhBRURHWVN5d1REUVp5MlBDUFdYU3llaGs5NTA2OXBvY0dWRVwifSIsImNsaWVudF9pZCI6ImRpZDprZXk6ejZNa3JZdFlrR3g3ZlNxWVpBeGNTZThINVhTWENkVXRBSFR3YlVwaGNmV1VRcXJFIiwiaWF0IjoxNzMzNTgzNTIzfQ.fb6RsdcafeOXD6Q2QXVpQMskMwb2KJ72jUtBa1COGEU&nonce=1cf35f74-4ecd-4c41-ae60-4e496b51f2a3&code_challenge=gRD9exFLHttbI5M4VC772huLpGseSjz6AbKswg1C3g4&code_challenge_method=S256&issuer_state=019398bf-9eac-774f-a909-68d8cdab7bdf&wallet_issuer=https%3A%2F%2Fapp.altme.io%2Fwallet_issuer&client_id=did%3Akey%3Az6MkrYtYkGx7fSqYZAxcSe8H5XSXCdUtAHTwbUphcfWUQqrE&scope=openid&authorization_details=%5B%7B%22type%22%3A%22openid_credential%22%2C%22format%22%3A%22vc%2Bsd-jwt%22%2C%22vct%22%3A%22PhotoId-3-with-sd%22%7D%5D

[ThierryThevenet]

The url is not the good one, it is probably a fallback if there is no endpoint found.

the wallet should look for the authorization server metadata on the authorization_server of the offer + "/.well-known/oauth-authorization-server" endpoint as it is defined here https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html#name-credential-issuer-metadata-p

[ThierryThevenet]

@hawkbee1
la règle est la suivante :

si l 'url de l'authorization (URL_AS) server est dans la credential offer il faut verifier qu'il est aussi dans la liste des authorization server qui est donnée dans les credential issuer metadata attribut authorization_server.
si c est le cas les metadatas de l'authorization server sont sur URL_AS/.well-known/oauth-authorization-server

si il n'y a pas d'authorization server nommé dans l offer. il faut utiliser l'url de l issuer (URL_ISSUER) pour trouver les metadatas de l authorization server sur URL_ISSUER/.well-known/oauth-authorization-server

Donc en definitive les metadatas de l'authorization server ne sont pas mélangées avec celles de l issuer et ne sont pas sur /.well-known/openid-configuration......sauf pour EBSI V3x

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-p

[hawkbee1]

OPENID4VCI with draft >= 13

[hawkbee1]

authorization_servers: OPTIONAL. Array of strings, where each string is an identifier of the OAuth 2.0 Authorization Server (as defined in [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]. 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.

[hawkbee1]

3. Obtaining Authorization Server Metadata

Authorization servers supporting metadata MUST make a JSON document
containing metadata as specified in Section 2 available at a path
formed by inserting a well-known URI string into the authorization
server's issuer identifier between the host component and the path
component, if any. By default, the well-known URI string used is
"/.well-known/oauth-authorization-server". This path MUST use the
"https" scheme. The syntax and semantics of ".well-known" are
defined in RFC 5785 [RFC5785]. The well-known URI suffix used MUST
be registered in the IANA "Well-Known URIs" registry
[IANA.well-known].

Different applications utilizing OAuth authorization servers in
application-specific ways may define and register different well-
known URI suffixes used to publish authorization server metadata as
used by those applications. For instance, if the example application
uses an OAuth authorization server in an example-specific way, and
there are example-specific metadata values that it needs to publish,
then it might register and use the "example-configuration" URI suffix
and publish the metadata document at the path formed by inserting
"/.well-known/example-configuration" between the host and path
components of the authorization server's issuer identifier.
Alternatively, many such applications will use the default well-known

Jones, et al. Standards Track [Page 8]

RFC 8414 OAuth 2.0 Authorization Server Metadata June 2018

URI string "/.well-known/oauth-authorization-server", which is the
right choice for general-purpose OAuth authorization servers, and not
register an application-specific one.

An OAuth 2.0 application using this specification MUST specify what
well-known URI suffix it will use for this purpose. The same
authorization server MAY choose to publish its metadata at multiple
well-known locations derived from its issuer identifier, for example,
publishing metadata at both "/.well-known/example-configuration" and
"/.well-known/oauth-authorization-server".

Some OAuth applications will choose to use the well-known URI suffix
"openid-configuration". As described in Section 5, despite the
identifier "/.well-known/openid-configuration", appearing to be
OpenID specific, its usage in this specification is actually
referring to a general OAuth 2.0 feature that is not specific to
OpenID Connect.

3.1. Authorization Server Metadata Request

An authorization server metadata document MUST be queried using an
HTTP "GET" request at the previously specified path.

The client would make the following request when the issuer
identifier is "https://example.com" and the well-known URI suffix is
"oauth-authorization-server" to obtain the metadata, since the issuer
identifier contains no path component:

 GET /.well-known/oauth-authorization-server HTTP/1.1
 Host: example.com

If the issuer identifier value contains a path component, any
terminating "/" MUST be removed before inserting "/.well-known/" and
the well-known URI suffix between the host component and the path
component. The client would make the following request when the
issuer identifier is "https://example.com/issuer1" and the well-known
URI suffix is "oauth-authorization-server" to obtain the metadata,
since the issuer identifier contains a path component:

 GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
 Host: example.com

Using path components enables supporting multiple issuers per host.
This is required in some multi-tenant hosting configurations. This
use of ".well-known" is for supporting multiple issuers per host;
unlike its use in RFC 5785 [RFC5785], it does not provide general
information about the host.

Jones, et al. Standards Track [Page 9]

RFC 8414 OAuth 2.0 Authorization Server Metadata June 2018

3.2. Authorization Server Metadata Response

The response is a set of claims about the authorization server's
configuration, including all necessary endpoints and public key
location information. A successful response MUST use the 200 OK HTTP
status code and return a JSON object using the "application/json"
content type that contains a set of claims as its members that are a
subset of the metadata values defined in Section 2. Other claims MAY
also be returned.

Claims that return multiple values are represented as JSON arrays.
Claims with zero elements MUST be omitted from the response.

An error response uses the applicable HTTP status code value.

The following is a non-normative example response:

 HTTP/1.1 200 OK
 Content-Type: application/json

 {
  "issuer":
    "https://server.example.com",
  "authorization_endpoint":
    "https://server.example.com/authorize",
  "token_endpoint":
    "https://server.example.com/token",
  "token_endpoint_auth_methods_supported":
    ["client_secret_basic", "private_key_jwt"],
  "token_endpoint_auth_signing_alg_values_supported":
    ["RS256", "ES256"],
  "userinfo_endpoint":
    "https://server.example.com/userinfo",
  "jwks_uri":
    "https://server.example.com/jwks.json",
  "registration_endpoint":
    "https://server.example.com/register",
  "scopes_supported":
    ["openid", "profile", "email", "address",
     "phone", "offline_access"],
  "response_types_supported":
    ["code", "code token"],
  "service_documentation":
    "http://server.example.com/service_documentation.html",
  "ui_locales_supported":
    ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
 }

Jones, et al. Standards Track [Page 10]

RFC 8414 OAuth 2.0 Authorization Server Metadata June 2018

3.3. Authorization Server Metadata Validation

The "issuer" value returned MUST be identical to the authorization
server's issuer identifier value into which the well-known URI string
was inserted to create the URL used to retrieve the metadata. If
these values are not identical, the data contained in the response
MUST NOT be used.

4. String Operations

Processing some OAuth 2.0 messages requires comparing values in the
messages to known values. For example, the member names in the
metadata response might be compared to specific member names such as
"issuer". Comparing Unicode [UNICODE] strings, however, has
significant security implications.

Therefore, comparisons between JSON strings and other Unicode strings
MUST be performed as specified below:

1. Remove any JSON-applied escaping to produce an array of Unicode
   code points.

2. Unicode Normalization [USA15] MUST NOT be applied at any point to
   either the JSON string or the string it is to be compared
   against.

3. Comparisons between the two strings MUST be performed as a
   Unicode code-point-to-code-point equality comparison.

Note that this is the same equality comparison procedure described in
Section 8.3 of [RFC8259].

5. Compatibility Notes

The identifiers "/.well-known/openid-configuration", "op_policy_uri",
and "op_tos_uri" contain strings referring to the OpenID Connect
[OpenID.Core] family of specifications that were originally defined
by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the
reuse of these identifiers that appear to be OpenID specific, their
usage in this specification is actually referring to general OAuth
2.0 features that are not specific to OpenID Connect.

The algorithm for transforming the issuer identifier to an
authorization server metadata location defined in Section 3 is
equivalent to the corresponding transformation defined in Section 4
of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that
the issuer identifier contains no path component. However, they are
different when there is a path component, because OpenID Connect

[ThierryThevenet]

it fauils with Sicpa test
https://sicpaspace.slack.com/archives/D07F318332T/p1734949996620349