`credential_endpoint ` & `credential_issuer` should be removed from the service metadata

[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

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.

[Torsten Lodderstedt]

Hi Daniel,

you are raising a very interesting question! I think the answer depends on whether one sees the AS and the RS as part if the same entity. If so just using the existing OAuth AS issuer value and metadata might be fine and simple. If the same AS shall authorize issuance of credentials at different endpoints, there would be clearly be the need to differentiate. That would also require the wallet to identify the issuer resource in the authorization request. I have rarely come across such setups (but built one for electronic signatures myself).

I’m not sure how many of the use cases you listed really require a single AS, multiple credential issuance endpoint setup. I guess some of the are rather multi tenant setups, where an AS tenant corresponds to a single RS tenant. Just a guess.

[Daniel McGrogan]

Thanks for the reply @tlodderstedt.
Can you expand on what you mean by "entity"? I think the delineation between AS and RS is an important one - it is a loose coupling that it allows them to be the same instance/server/entity with out forcing them to be. If you have a large number of services and service endpoints, then the AS RS separation becomes critical. A credential issuance endpoint treated as an RS endpoint with known resource type (VC) is a powerful tool. That ability to horizontally scale resources with out forcing updates on AS should not be lost for issuance.

Yes it would be useful for multi-tenanted solutions and I don't think it's correct to imply a 1:1 DID binding to an identity or domain. There can be any number of reasons an organisation may wish to have multiple issuing identities such as regionalisation, security bulkheading, peer-relationships, non-public relationships, conglomerations, etc.

The current spec does not demand that the Issuer DID be the same identity as the AS (nor do I think it should). The mapping of the Issuer DID(s) to "an identity" is a problem which also exists in the verification flow and can be addressed with a DID specific solution such as Well Known DID. For issuance, if the AS only supports one identity then it should prob have a DID field in the credential_issuer object too.

The problem of the wallet identifying the the credential endpoint is similar to the existing problem for clients discovering resource endpoints today. But in this case, there's a built-in solution at the Issuance Initiation Request.

We have the exact use case requirement as described above (obv. for Workday subsidiaries not MSFT) as well as multi-tenant use cases. If we bind a single issuing identity to an AS we need to start creating logical/virtual OPs for no obvious advantage. I would suggest that building a specification in this way is unnecessarily limiting and will inhibit VCI uptake in the immediate term.

[David W Chadwick]

If you look at issue #1632 you will see that I have proposed a solution that allows an implementation to have either one metadata file for both the RS and AS or separate metadata files for them. (But I also highlight a security issue with a single metadata file, in that the JWKS contains keys for signing both access tokens and VCs.)

[Daniel McGrogan]

#1632 is interesting because its addressing the same problem ( which we also ran into during implementation :D) by introducing a more sophisticated metadata solution for the RS. Which seems like trying to address a domain config problem with more config.

I think we can side step the whole problem by removing the issuer metadata from the AS metadata and treating the issuing endpoint as a resource endpoint which produces typed information (VCs). The discovery of the resource endpoint and any additional metadata can be moved to the initiate issuance request. Other than the credential_endpoint all the other metadata seems like a nice to have rather than a requirement for the issuance to work.
I might be missing some reason this metadata is required at all.

‌

[David W Chadwick]

@Daniel. But isnt what you suggest provided by having two separate metadata files, one for the authz server and one for the resource server? If not, I am not clear at what you are actually proposing.

[Daniel McGrogan]

Ah I see I didn't get that domain separation from the solution description. Having a clearly defined metadata for the RS, which contains VC Issuing info, would do the trick . It removes the issue and provides a nice decoupling. + it seems like a useful idea to feedback for OAuth 2.x.

[Daniel McGrogan]

closing as resolved. issue is being addressed in https://bitbucket.org/openid/connect/issues/1632/issuer-metadata-clarification-needed

[Torsten Lodderstedt]

Can you expand on what you mean by "entity"?

Sure. AS and RS live in the same security domain, typically belonging to the same legal entity. That’s the default model for OAuth, where the AS of a certain security domain protects the RSs of that domain. They are clearly different technical services. And yes, that the key to scalability (that differentiate OAuth 2 from OAuth 1).