Closed georgepadayatti closed 7 months ago
ok, no problem in the OIDC spec is the other way around ... I assume this has to do with the fact that the OIDC spec provisions for mutiple AS server if I am not mistaken. So, you would fetch the openid-configuration after selecting which AS you want to used.. but I guess the ARF doesn't consider this case? If this is so lets close this @georgepadayatti plz :)
ok, no problem in the OIDC spec is the other way around ... I assume this has to do with the fact that the OIDC spec provisions for mutiple AS server if I am not mistaken. So, you would fetch the openid-configuration after selecting which AS you want to used.. but I guess the ARF doesn't consider this case? If this is so lets close this @georgepadayatti plz :)
Your earlier observation is correct. First credential issuer well-known endpoint is resolved as its present in credential offer and then AS well-known endpoint.
At present the RFC mentions the holder wallet performs discovery in the following order:
/.well-known/openid-configuration
)/.well-known/openid-credential-issuer
)Reference is given below:
https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/3a093511e9c735319ab0b3285e92fc7a75896872/ewc-rfc001-issue-verifiable-credential.md?plain=1#L140-L152
The above is wrong and propose the following order:
credential_issuer
endpoint from the credential offer and then resolves the credential issuer well-known endpoint.