Token endpoint resolution
ejossev opened this issue · 4 comments
Hi,
I believe this is a bug in the logic. The latest draft of OIDC4VCI states
authorization_server: OPTIONAL. Identifier of the OAuth 2.0 Authorization Server (as defined in [[RFC8414](https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#RFC8414)]) the Credential Issuer relies on for authorization. If this element is omitted, the entity providing the Credential Issuer is also acting as the AS, i.e., the Credential Issuer's identifier is used as the OAuth 2.0 Issuer value to obtain the Authorization Server metadata as per [[RFC8414](https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#RFC8414)].
The second sentence states, that if authorization_server param is missing, then the credential_issuer value shall be used as AS, ie the metadata shall be retrieved from credential_issuer endpont .well-known/openid-configuration.
Hi @ejossev Thanks for the bugreport.
Not entirely sure if I get it right, because IMO the current resolution logic does not contradict the spec. Your remark seems to be addressed in the else branch of the expression.
The if branch will only be triggered if we do get the OID4VCI metadata and only if it does not have a token_endpoint in it (something which isn't in the spec but seen in the wild) but does have the optional authorization_server value in it. This means it If that is the case we use the AS value to retrieve AS metadata and that should also provide the token endpoint. If we cannot resolve that well-known we raise an error, because now we have an OIDVCI issuer stating it has a separate AS at a specific location, but we could not retrieve its well-known metadata.
In all other cases we start fetching the OIDC and OAuth2 well-known metadata, see line 68. Then as a last step we double check whether we did find a token_endpoint, so first via OIDV4CI, then OIDC and then OAuth2. If that fails we throw an error, because we cannot find it.
I do believe we should also check for OIDC in case a separate AS is provided, and at one point it would be wise to stop support for a token_endpoint in the OID4VCI issuer metadata altogether. I also believe we need to change the logic a bit for Authorized code flows, because right now we are only interested in the token_endpoint and for the Authorized Flow we would also require either OAuth or OIDC metadata
edit:
Oh %$#%$#, sorry the else branch is at a different scope. Yeah that for sure isn't correct it seems. We will have a look at it
We will also split the OAuth2/OIDC metadata from the OID4VCI metadata, as that was fine and handy initially but will need to be done anyway for Authorized code flows
Thanks for reporting. The logic has been overhauled and now is both more flexible as wall as better in line with the spec. Will be released in the new version momentarily
Thanks, seems better now.
Have a nice day ;)