[Openid-specs-ab] Issue #1635: `credential_endpoint ` & `credential_issuer` should be removed from the service metadata (openid/connect)

[Daniel McGrogan]

New issue 1635: `credential_endpoint ` & `credential_issuer` should be removed from the service metadata
https://bitbucket.org/openid/connect/issues/1635/credential_endpoint-credential_issuer

Daniel McGrogan:

It looks like this is a hold over from the earlier OIDC direction.   
The most important difference between the OIDC issuance vs OAuth issuance is that it fundamentally changes the domain to which the Issuer bound . Moving to OAuth issuance implies that the issuance is a function of the Resource Domain, with the Issuer being a property on whatever the resource endpoint is invoked. In the OIDC issuance flow the Issuer is a property of the OP Domain and a single Issuer is bound to that OP \(as scoped by the metadata discovery\). 

‌

Having a single Issuer bound to the auth server is a very restrictive bottle neck. The issuing endpoint & issuer should be as flexible as any resource endpoint & we don't put a single `resource_endpoint` to the auth server service metadata.  Think of a possible Microsoft example where a single IDP may be used to permit the issuance of credentials for multiple Issuers linkedIn, xbox, office365, clippy, msTeams. Google has thousands of resource endpoints for a single OP, having one credential endpoint would make any implementation of the spec extremely centralised.

I also believe the bleeding of the issuance domain is giving rise to issues such as  [https://bitbucket.org/openid/connect/issues/1632/issuer-metadata-clarification-needed](https://bitbucket.org/openid/connect/issues/1632/issuer-metadata-clarification-needed)

Treating the issuing endpoints as a resource endpoints with extended scopes & defined response types should make the spec easier to implement for existing auth/op severs, pushing the complexity into VC aware wallets \(which they will need to be anyway\) & the issuer endpoints.