[Openid-specs-ab] Issue #1376: Credential Issuance: Remove the reliance on OIDC4VP (openid/connect)

[Thomas Bellebaum]

New issue 1376: Credential Issuance: Remove the reliance on OIDC4VP
https://bitbucket.org/openid/connect/issues/1376/credential-issuance-remove-the-reliance-on

Thomas Bellebaum:

Moved to here from Github.  
  
Currently, the draft relies on OIDC4VP \(and, realistically, SIOP\), which may be a high bar to clear for some OPs and clients,  
as it requires the OP to act as a client as well, and the client to act as an OP.  
For clients, this is probably not much of a concern to a wallet which want to utilize OIDC4VP anyway to present their VCs,  
but if other means for exchanging VPs are used, this may become a burden.

**TODO** maybe there are even some security policies against this? I am unsure.

Therefore I propose an alternative for discussion:

If the Issuer is not given enough attestations for the user,  
it could return a special error containing machine readable instructions for what additional credentials are required by the user.  
A wallet would then ask the user to select the additional credentials to send along and subsequently start the AuthZ over using the `static` credential input approach including all relevant credentials.

Pros:

* No direct reliance on OIDC4VP
* The OP needs to keep less state \(like accepted VPs\), as every auth request contains either all necessary credentials, or can be rejected.
* If a client already knows it belongs to a subset of users for which additional credentials are required, it can send them along in the first request, thus reducing the number of round trips.

    * This would however need to be mentioned in the privacy considerations, as by the principle of data minimization the client needs to be reasonably sure that all sent credentials are required.
    
* ...

Cons:

* Hard to make error responses as expressive as OIDC4VP
* Strictly speaking this would extend the capabilities of error responses
* ...

‌