token_error_response.json

[garethsb]

Is there a reason token_error_response.json isn't identical to the error.json schema used in other specs? Or if OAuth 2.0 spec requires more info, could it extend error.json with additional properties?

Thanks!

[dannymeloy]

I based the error responses on the OAuth2 spec (RFC6749) in https://tools.ietf.org/html/rfc6749#page-45. The error and error_description could happily be combined into the error field of the standard NMOS error message though 👍

[NEOAdvancedTechnology]

Danny will work with Gareth on this.

[garethsb]

OK, I see, RFC 6749 defines the OAuth 2.0 access token response for the error case (another explanation), though it doesn't do so in terms of JSON Schema as far as I can see.

It looks like we could have a response that was both valid according to RFC 6749 Section 5.2, and valid according to the common NMOS error.json schema, but unfortunately "error" in RFC 6749 must be a string enum, and "error_description" is user-friendly, whereas in NMOS error.json, "error" is the user-friendly message.

So, although the following is valid according to both specs, I'm not sure it's a good idea. :-(

{
    "error": "invalid_request",
    "error_description": "something went really wrong, I blame Gareth",
    "error_uri": "https://amwa-tv.github.io/nmos-api-security/best-practice-authorisation.html",
    "code": 400,
    "debug": "the thing that went wrong was oh-this-is-bad/really-bad returned 42"
}

[andrewbonney]

Given the desire to bring in RFC 8414 to enable the use of more generic existing Authorization Server implementations, we can't really mandate the use of NMOS-specific conventions for this API (although individual implementations could still add them if they wish). As such I've brought the error response back into line with RFC 6749's expectations in https://github.com/AMWA-TV/nmos-authorization/pull/5

[NEOAdvancedTechnology]

agreed