[has-PR] Requesting multiple credentials

[David W Chadwick]

An issuer may issue multiple credentials to its users e.g. a bank issues Visa and Mastercards, a university issues multiple types of degree certificates to students. The current spec allows the issuer to publish these different types in its metadata, but the protocol requires the client to make multiple round trips in order to retrieve the credentials.

It is more efficient for the wallet to make a request for multiple credentials in one request to the credential endpoint rather than multiple requests. This can be achieved by allowing the request argument to be a set of the current set of parameters.

[David W Chadwick]

Note. Implementing the retrieval of multiple credentials in one round trip or in several round trips will be at the choice of the wallet, since it sends the credential request. Thus support for this feature is optional for wallets. Support for returning multiple credentials in one reply should be required for issuers that return credentials immediately, but optional for issuers that use the delayed response. It is relatively easy for issuers that perform immediate issuing to perform it multiple times since it is simply looping around the same procedure again. However, efficiency is not an issue for delayed responses since the wallets are polling and there could be many polling round trips before the credential is ready. The delayed response is inefficient by design. So getting the credentials one by one rather than all at once is not seen to be a significant impediment.

‌

[Michael Jones]

Per the discussion on the 7-Jul-22 call, there is substantial opposition among working group members to modifying the specification to enable requesting and returning multiple credentials in a single protocol interaction. Doing so would complicate the simple common cases. One significant source of complication would be handling partially successful results, where some of the requested credentials are successfully provided and some result in errors.

Just like OAuth 2.0 only enables returning a single access token per request, we should likewise maintain the simplicity of the current approach by only enabling returning a single credential per request.

On the call, David Chadwick agreed to point any places he finds where the language currently appears to be ambiguous, implying that returning multiple credentials is a possibility, so that we can correct them.

[David W Chadwick]

Mike can you explain how this would complicate the simple common cases in which the wallet asks for a single credential. Thanks

[David W Chadwick]

Asking for multiple credentials is not the simple case and is only optional for the wallet to support. So simple wallets wont support it.

‌

[Kristina Yasuda]

I heard about a use case where the issuer wants to issuer 100s/1000s credentials to enable pairwise identifiers. We may want to reconsider an option to issue multiple credentials in one req/res

[Torsten Lodderstedt]

What would that mean from a technical standpoint? Requesting the same credential type with an array of identifiers/ proofs of possession for the different pairwise identifiers?

[David W Chadwick]

As was discussed at the meeting on 7 July 22, requesting multiple credentials introduces complexity into the response for multiple credentials, because partial results are now possible i.e. some of the credentials have been issued and some have not been. (For the single credential case the result is either success or failure, and this is what we currently have.) The conclusion of the meeting is that this needs further thought.

If we introduce requesting multiple credentials in one message (which could be different credentials with the same crypto e.g. Amex and Visa cards from a bank, or the same credential with different cryptos) then the partial result will need to provide the wallet with the issued credentials plus ideally a reason for each failed credential (e.g. a list of failed credential IDs with reasons).

[Oliver Terbu]

I can see that having multiple roundtrips for issuing credentials is something that could cause some troubles in certain environments. In contrast to issuing access_tokens, issuing credentials can require more than creating an entry in a database (+ optionally signing it with the OP’s key). In our case, we are working on a project with a customer where they specifically asked for eliminating multiple roundtrips since it would make the integration hard in terms of costs (case management, connectors with multiple vendor APIs).

IMO, the following cases have to be distinguished:

1. multiple credentials, same credential_type but different format
2. multiple credentials, different credential_type but same format
3. multiple credentials, different credential_type and different format

I also want to clarify things that are related to this issue:

Q1. Is the authorization grant about issuing a credential_type and not about a particular format?

Q2. Does the authorization grant only allow to issue one instance of the credential, or is the expectation that wallets can hit /credentials with the same access_token multiple times? would it result in a new credential (i.e. id), or would the prior credential be returned, or is it up to the issuer? Latter case would be fine by me but it would help to be documented.

Q3. Does the c_nonce have a specific security function in addition to proving control over the private key material that will be bound to the credential? I'm asking if it would be save to allow the same c_nonce in multiple /credential requests. I'm asking because this would then allow us a database-less (stateless) implementation of that specification. I guess it is replay protection but an attacker won’t be able to use the credential with the private key anyways. So, I think this this mostly about the concern that attackers should not read the PII of the wallet but isn’t that prevented by the access_token. In OIDC, userinfo is only protected by an access_token as well.

Some observations on supporting multiple credential types and formats after reading the current spec …

Initiate Issuance Request:

• multiple use of credential_type is already supported

Authorization Request:

• authorization_details has to become an array. I guess this is just underspecified atm because the example in 6.5.2 uses an array already. Also note, it would be inconsistent with Initiate Issuance Request credential_type that supports multiple credential types.
• openid_credential:<credential-type> already supports multiple credential types.

Credential Request:

• type should be fixed, and should rather be credential_type (so it doesn’t get conflated with the type in the authorization_details). I might open a separate issue for this.
• current credential request payload (including proof, type and format) would need to become an array to support multiple credential types and/or formats.

Credential Response:

• current credential response payload would need to become an array.

Since we have two projects using either multiple credential types, or one credential type but in different formats, I’m supportive of this.

The question is what happens if one of those credentials in potentially different formats results in an error? Case 1 seems to be the easiest one since it could be either return all formats, or return an error?

[Jeremie Miller]

I’m late to this conversation, but my initial impression reading up on it is that this is best solved by using HTTP/2 or 3 where the overhead for multiple requests, even hundreds of them in parallel, is extremely efficient.

IMO it’s too much complexity to justify adding to the issuance protocol when the problem can be solved at the HTTP layer.

[Oliver Terbu]

@Jeremie Miller: My concern was that the downstream business logic of the /credentials request is cost intensive, e.g., when connected with a case management. In our case, there is a big difference between telling the downstream process to issue one credential or multiple credentials at once. I don’t see how HTTP2/3 multiplexing could solve that issue although connections are reused and requests are sent alongside each other. The web service would still handle each /credentials request individually and execute the downstream process for each of them. IMO, the /credentials endpoint would still don’t know many and what credentials are being requested in total. Would you agree with that?

[Kristina Yasuda]

I think there are more cases than listed above… It can be same/different proof_of_possession, same/different format and same/different credential_type. With potentially 8 combinations, against what I was originally thinking, we enable none or all.

Q1: depends on the authz request parameters - credential_type is required but format is optional - I would not expect a wallet that did not bother to specify format in the authz req to specify it in the cred req. (spec text: authz req params)

Q2: Assumption was wallets can hit Credential Endpoint multiple times. (Access Token can be the same or refreshed using Refresh Token). Assumption also was that subsequent credential request results in a new credential - we might need to clarify in the spec text. why would an issuer return the same credential multiple times..?

Q3: there is a separate issue #1577. but no, I do not think there is any additional feature to c_nonce that binding jwk proof to the transaction.

[Torsten Lodderstedt]

@oliver, @david

1) Would you expect the multiple issuance request to support deferred issuance as well?

2) What is the expected failure behavior? I could envision either (a) fails completely in case of any error (b) partial failure possible, i.e. provides partial results and error information for credentials it cannot provide (+ request fails due to request, not credential specific, conditions)

Any of (1) or (2b) may result in partial results, whereas (1) would also result in incremental results.

[Tobias Looker]

I’m late to this conversation, but my initial impression reading up on it is that this is best solved by using HTTP/2 or 3 where the overhead for multiple requests, even hundreds of them in parallel, is extremely efficient.

IMO it’s too much complexity to justify adding to the issuance protocol when the problem can be solved at the HTTP layer.

At a high level I agree with this perspective, multi-request style batch API’s creates maintainability challenges, forces more consideration around request/response size, how many elements can be received, pagination (potentially) and error handling.

R.e your questions Oliver

1. Yes credential type refers to group of claims or set of information NOT the format it will be issued in, just like an OAuth2 scope entirely decoupled from the form the access token will take that is issued from the token endpoint
2. The wallet is free to hit the credential endpoint for however long the access token is considered valid by the issuer, one issuer may decide that an access token is only good for a single request and enforce in that manner.
3. There is another good issue discussing some of the proposals we have at the moment for nonce management within the protocol. TL;DR if we go in the direction of DPoP, nonce could actually be optional if an issuer so chooses

‌

[David W Chadwick]

@Torsten Lodderstedt Good questions. I will answer 2) first. I would prefer partial results where the issuer returns the subset of successful credentials plus an error reason for each failed one. In another thread we are already discussing having an ID for each credential so that the wallet and issuer have unique handles for identifying the credentials so that the partial result is unambiguous.

Turning to 1). Delayed issuing potentially complicates the model. But recognising that delayed issuing is a valid use case e.g. using an offline hardware signing key, then I would suggest that the entire set of requested credentials is processed at once i.e. all are issued later or all are issued immediately. Unless you have a good use case as to why the issuer might issue some credentials immediately and some later (given that the issuing has already been authorised - this is not an application process for a credential but an issuing process!) then I would suggest that this be a restriction to delayed issuing in the multiple request case.

[Torsten Lodderstedt]

I think the multiple credentials issuance will be significantly more complex than the current credential endpoint. Nevertheless, I think there are enough good arguments to add this feature to the spec.

In order to keep things simple for implementers that are satisfied with the current endpoint, I suggest to add a new endpoint with the capability for multiple credential issuance. We can use this new endpoint to experiment and evolve the design.

Issuers that support the new endpoint would publish the endpoint URL in its metadata.

[Kristina Yasuda]

SIOP call: agreed that we want to go in the direction of separating simple and complicated credential endpoints.

Few questions:

• are both simple and complicated endpoints conditional or is simple endpoint is mandatory? If Client can send a simple issuance request to the complicated endpoint and still get a valid credential, what’s the point of separating endpoints..?
• does one complicated endpoint handle all of the combinations - multiple proofs, types, formats?

Next steps: Oliver to suggest concrete request syntax for a complicated endpoint + Kristina to suggest how issuer can advertise which issuance it supports in the metadata

[Kristina Yasuda]

If Client can send a simple issuance request to the complicated endpoint and still get a valid credential, what’s the point of separating endpoints..?

I think the normative statement should be complicated endpoint MUST throw an error if it receives a simple request. so it’s only simple endpoint that can handle simple request.

‌

[Oliver Terbu]

I created https://bitbucket.org/openid/connect/pull-requests/267 that adds batch credentialing based on the single credential request endpoint.

[Oliver Terbu]

I created a new PR here: https://bitbucket.org/openid/connect/pull-requests/285

[Kristina Yasuda]

fix: fixes #1544

→ <<cset f6b06ac76988>>

[Kristina Yasuda]

4 approvals, no objections, agreed to merge in a Oct-27-2022 SIOP call. merging

Merged in oterbu/fix-1544-new (pull request #285)

Adding batch credential endpoint: fixes #1544

Approved-by: Jeremie Miller Approved-by: Kristina Yasuda Approved-by: Torsten Lodderstedt Approved-by: Michael Jones

→ <<cset af6952791d21>>