Clarification about format of Credential Request Errors

[edouardhue]

I find section 7.3.1. Credential Error Response confusing about the format of these errors.

For Authorization Errors, it is quite clear that error responses should follow 3.1. Error Codes from RFC 6750, which requires the use of the WWW-Authenticate header with error and error_description attributes.

For Credential Request Errors, it is unclear wether RFC 6749 or 6750 errors should be used.

For errors related to the Credential Request's payload […] the specific error codes from this section MUST be used instead of the generic invalid_request parameter defined in Section 3.1 of [RFC6750]
HTTP response MUST use the HTTP status code 400 (Bad Request) and set the content type to application/json with the following parameters in the JSON-encoded response body :

• error: […]
• error_description: […]

This looks much like errors defined in 5.2. Error Response from RFC 6749, but the text only points to RFC 6750.

It is not obvious that RFC 6749 should be used here, as its 5.2 section is about errors by the authorization server, while we are here talking about the Credential endpoint, which rather acts like a resource server. From this point of view, following RFC 6750 looks more appropriate.

[Sakurann]

I think the intent was to use rfc6750 for credential endpoint errors which means using WWW-Authenticate response header as defined in https://www.rfc-editor.org/rfc/rfc6750.html#section-3, so the text is correct but the example here is wrong? @bc-pi can you confirm?

[bc-pi]

The intent is/was to use rfc6750 for authorization errors regrading the access token, as @edouardhue points out.

For credential request errors, neither RFC 6749 or 6750 errors are applicable. They are just credential request errors as defined in https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-request-errors - they look similar to RFC 6749 errors, json with mostly the same member names, but are otherwise not RFC 6749 authorization server errors in any way. They are application layer errors from the credential issuing application.

I believe the text and example are correct as is. Though could clearly stand some improvements/clarifications. I just don't know what such improvements/clarifications would actually look like.

[bc-pi]

In other words for credential request errors, it is neither RFC 6749 or 6750 errors. It looks like 6749 for better or worse but it is not. It's a credential request error that says what the error code should be and what the body looks like.

[edouardhue]

Thanks @bc-pi for clarifying this. What about using rfc9457 (Problem Details) instead to represent those application errors? It seems a natural fit to me:

• the error parameter could map to the type member;
• the optional error_description parameter could map to the detail member;
• status would be 400;
• title and instance would be left to implementors.

As we already have a well-defined list of error types, these could be registered to the Problem Types registry, maybe with a prefix like urn:ietf:params:oauth:http-problem-types:.

[bc-pi]

I suppose that could be done but I don't personally see sufficient utility in doing to to warrant an arguably breaking change to the credential issuance API.

[edouardhue]

That's right if we consider changing this after 1.0 goes final. Could it still be considered for inclusion into 1.0?

[bc-pi]

That's right if we consider changing this after 1.0 goes final. Could it still be considered for inclusion into 1.0?

That would be a question for the larger WG and chairs. But my intuition is that there's not the appetite for it.

[Sakurann]

what is the benefit of using rfc9457 (Problem Details) instead of our current error codes?

[edouardhue]

First of all, error formats from rfc6749 or rfc6750 are not really fit to the purpose. rfc6750 covers authorization errors on the application side, which is fine. rfc6749 defines an error format for Authorization Servers. But, as @bc-pi pointed out, Credential Endpoint errors are application errors. Using rfc6750 for application errors would be wrong, and using rfc6759 outside of an Authorization Server is unexpected. Although, it is unlikely that some library provides a standalone implementation support for rfc6749 without pulling a whole Authz Server framework.

I see several advantages in using rfc9457. It provides a general purpose error format for application errors with well-defined semantics, a IANA registry for well-known error types, and a potential for large adoption. Implementation support (at least in the Java/Spring world) comes out-of-the-box.

I'd rather turn the question inside-out: what is the benefit of using mimicking rfc6749 when a well-established format already exists?

[bc-pi]

I'd rather turn the question inside-out: what is the benefit of using rfc6749 out of purpose when a well-established format already exists?

But rfc6749 is not being used here.