merge credential endpoint with the batch credential endpoint

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1759

Original Reporter: danielfyes

The normal credential endpoint is really a specialized instance of the batch endpoint. I think the spec and implementations can be simplified by removing what today is the regular credential endpoint and only keeping the batch endpoint. As far as I can see, the overhead is very small and the functionality of the batch endpoint is a superset of the one of the regular credential endpoint.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I think it is the other way around: The batch endpoint is a specialized, extended instance of the normal credential endpoint.

Most of the implementations only need normal credential endpoint for their use cases. So for the interoperability, the spec mandates the support for the normal credential endpoint for the supporting implementations, while if the architecture requires, batch endpoint can also be supported.

We need more implementation experience, but batch endpoint has been seen as adding a certain amount of complexity (more than “small”) to the normal credential endpoint.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

I agree that requiring the credential endpoint is appropriate, since it’s the normal simple case, whereas having an optional batch credential endpoint is also appropriate.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

SIOP 2023-04-07 call
current direction is to keep both endpoints and wait for implementation experience if we want to remove either.
Here is the original issue that led to a batch credential endpoint (I think)
https://bitbucket.org/openid/connect/issues/1544/has-pr-requesting-multiple-credentials

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

pending close. @{557058:cd7888c3-ecf3-47c0-92ec-168b48519672}

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: danielfett

Following offline conversations, I’d like to re-open this issue.

Besides the points raised above - one endpoint less to protect and maintain - there is another issue in the spec right now.

How is deferred batch issuance supposed to work?

As far as I can tell, the idea is that in case the batch endpoint cannot issue all credentials immediately, it will issue a transaction_id (or many?) and the wallet is supposed to hit the deferred endpoint with that transaction_id. The deferred credential endpoint is defined as returning one credential only. So is the wallet supposed to hit the endpoint 100 times for 100 credentials? It doesn’t seem that this is the intended solution.

So my proposal is to do away with the specialized one-credential case alltogether, for all endpoints. It introduces complexity and corner cases that are just not needed.

The credential endpoint should be removed, the batch credential endpoint becomes the new default, and the deferred endpoint is enabled for batch deferred issuance.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: danielfett

See comment.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: danielfett

In the SIOP call, a case was discussed where the Wallet might not know how many credentials are to be issued. The Wallet would not know which endpoint to hit. This issue would go away with this proposal.

[paulbastian]

I agree with @danielfett that it should be possible to merge credential and batch credential endpoint, see #93 (comment)

[Sakurann]

I think requirements are:

• there are implementations that do not need batch issuance
• there should be a de facto interoperability between implementations via at least one mandatory to implement endpoint

I think we could achieve this by having one endpoint that is mandatory to support issuance of one credential per request, but can also be used with more than one credential per request (though the same endpoint will handle differing error conditions) and issuer metadata will include a parameter that indicates whether this endpoint supports batch issuance capability or not.

[tlodderstedt]

I think we need a understanding of what is implemented today. My assumption would be most implementations support "normal" issuance but not batch issuance so removing the "normal" issuance from the spec would be a big breaking change. Also I would like to learn from implementers whether a removal of the "normal" issuance endpoint would make their life easier or harder.
I also think we need to come to a conclusion around support for issuing multiple instances of the same credential before deciding on that matter.