remove use of the `authorization_pending` and `slow_down` error codes

[bc-pi]

per issue #60

[awoie]

I was wondering how we would support the following use case if we remove authorization_pending. In some cases, the AS cannot make an immediate decision on the authz request because some human intervention is needed for a final decision even though the initial credentials the user provided were successfully verified. I assume we could do that via deferred issuance, right? In that case, I was wondering what would be the error code in the credential response in case the issuer made a negative decision? Currently, I cannot see a error code that would fit. Should we add a new one?

[jogu]

@awoie

I was wondering how we would support the following use case if we remove authorization_pending. In some cases, the AS cannot make an immediate decision on the authz request because some human intervention is needed for a final decision even though the initial credentials the user provided were successfully verified. I assume we could do that via deferred issuance, right? In that case, I was wondering what would be the error code in the credential response in case the issuer made a negative decision? Currently, I cannot see an error code that would fit. Should we add a new one?

That's all correct, yes. I think the new error code defined here might cover it: https://github.com/openid/OpenID4VCI/pull/321 ?

[jogu]

I think we're ready to merge this now - it's been discussed on several working group calls and there were no objections raised based on the notification send to the mailing list a month ago: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20240415/000278.html

@bc-pi would you mind resolving the trivial conflict please?

[awoie]

@awoie

I was wondering how we would support the following use case if we remove authorization_pending. In some cases, the AS cannot make an immediate decision on the authz request because some human intervention is needed for a final decision even though the initial credentials the user provided were successfully verified. I assume we could do that via deferred issuance, right? In that case, I was wondering what would be the error code in the credential response in case the issuer made a negative decision? Currently, I cannot see an error code that would fit. Should we add a new one?

That's all correct, yes. I think the new error code defined here might cover it: #321 ?

Yes, that would cover it. Thanks.

[bc-pi]

@bc-pi would you mind resolving the trivial conflict please?

done!

[jogu]

Thanks Brian! I'll merge this then as per my previous comment.