Re: [Anima] Use of problem details in BRSKI (and other ANIMA) documents (rfc9457)

["Fries, Steffen" <[e-mail]>]

Hi Toerless,

Providing errors with more detailed information is certainly helpful. My gut feeling would be to have this as SHOULD and not as MUST. Reasoning is that for instance in BRSKI-PRM, we have different error codes for different states in the verification as discussed in the design Team meetings (see https://github.com/anima-wg/anima-brski-prm/issues/103). This allows to easily deduce in which state the pledge currently is and allows appropriate reaction in that specific state. Having more detailed information may lead to a more specific handling in that state. Based that the current approach allows for proper reaction, I would consider it as optional.

Best regards
Steffen

> -----Original Message-----
> From: Toerless Eckert <[e-mail]>
> Sent: Wednesday, September 6, 2023 8:31 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Use of problem details in BRSKI (and other ANIMA) documents (rfc9457)
>
> Dear ANIMA-WG
>
> In the weekly BRSKI  calls we did discuss on and off the issue of limited HTTP error
> codes returned when calling BRSKI endpoint URIs. Especially the point that it's
> difficult to map all error conditions to unique HTTP status codes.
>
> So, i would hereby like to suggest that we revisit error codes returned by new
> BRSKI work to follow what the IETF has specified and follow what seems to be
> like a very simple way to apply that method, as found in ACME (which is kinda
> related to our BRSKI work).
>
> -- Reference:
>
> RFC7807 defines how to signal problem details for HTTP APIs. It was superceeded
> by RFC9457, but of course, there are more RFC already using/referencing
> RFC7807 than RFC9457.
>
> --- Simple example:
>
> ACME, RFC9115 seems like a good, minimum complexity way to apply this
> problem report method. It specifies for example:
>
>    ... MUST return an error response with status code 403
>    (Forbidden), providing a problem document [RFC7807] with type
>    "urn:ietf:params:acme:error:unknownDelegation".
>
> And then there is an IANA section asking to register this "unknownDelegation".
> Aka: minimum text work.
>
> --- Longer example reference:
>
> Of course, one of our RFC, maybe rfc8366bis needs to ask for creation of a registry
> for "urn:ietf:params:brski", and the error registry, but that's easily written,
> especially when it follows the ACME approach.
>
> RFC8555 , the main  ACME does of course introduce a long list of error codes,
> They can also all be found in the registry:
>
> https://www.iana/.
> org%2Fassignments%2Facme%2Facme.xhtml%23acme-error-
> types&data=05%7C01%7Csteffen.fries%40siemens.com%7C96d0c9691fa94b1c6
> 62e08dbaf0779f0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
> 296218869389810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=
> aFb8goeUiPdCq2xCiZ5bRJPiZhtzmu6ws4jGuGUczBk%3D&reserved=0
>
> --- Example of how to apply:
>
> Lets take an example with BRSKI-PRM, which currently specifies:
>
>   400 Bad Request: if the pledge detected an error in the format
>   of the request or detected invalid JSON even though the PER media type was set
> to application/json.
>
> Instead of just returning 400, we could change this to MUST/SHOULD also
> indicate an appropriate problem report.
>
> --- How to apply to BRSKI:
>
> Technically, the eror transaction would look like this
>
> GET /.well-known/brski/tpvr HTTP/1.1
> Host: brski-registrar.example.com
> Content-Type: application/json
> Accept: application/json, application/problem+json {
>   ... existing BRSKI PRM PVR data
> }
>
> Aka: in the request, the initiator would indicate that it supports problem+json
>
> HTTP/1.1 400 Bad Request
> Content-Type: application/problem+json
> Content-Language: en
>
> {
>  "type": "urn:ietf:params:brski:error:ErrorNameNNN",
>  "title": "...",
>  "detail": "...",
>  "blablabla": "...",
> }
>
> In the reply, we would be able to have a combination of specific ErrorNameNNN
> and other fields.
>
> I think the logic of applying ErrorNameNNN and the other fields would be based
> on the following considerations:
>
> Whenever an initiator should or could have two different reactions to two
> different errors, such as different retries, then there MUST be two different
> ErrorNameNNN. Aka: automated reactions must be possible by only examining
> the ErrorNameNNN.
>
> Whenever it is easy to distinguish two different Errors by name, then we should
> also introduce those different ErrorNameNNN. The list of ACME error codes
> might be a good help.
>
> Whenever there must be a human in the loop anyhow to resolve the issue, it is
> sufficient to describe the problem differences in the "detail" and potentially other
> fields, which can be custom, such as indicated via "blablabla".
>
> So, for the example of this "Bad Request", the problem of course is that some
> plege or agent developer (or even worse customer/operator) needs to figure out
> what the registrar did not like.
>
> --- Bad ? Example what to do:
>
> What i have seen in other protocols, and what is quite ugly, but the minimum, is,
> translated to this registrar example, that the developer of the code that is parsing
> the request message/data-structure simply emits a different numeric error code
> on every code line where an error is encountered.
>
> This would translate to:
>
> {
>  "type": "urn:ietf:params:brski:error:CrypticVendorError",
>  "detail": "ExampleCorpMegaRegistrar, v0.97b, code: 0x10057"
> }
>
> Aka: some crap where the operator needs to call support of that Registrar, but at
> least then it just needs to tell the software version v0.97b and the code 0x10057
> and then 3rd level support may be able to tell the operator whats "wrong" on the
> othrer side (agent/pledge).
>
> But - this is least amount of spec effort on our side (as in: we don't specify
> anything beyond CrypticVendorError.
>
> And of course, this is not what ACME did, they tried to break down the errors
> more by analyzing what errors could exist and come up with better Error codes for
> them.
> Which of course is more work.
>
> Cheers
>     toerless
>
> ==============
>
> https://www.rfc-/
> editor.org%2Frfc%2Frfc8075.txt&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C96d0c9691fa94b1c662e08dbaf0779f0%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638296218869389810%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=37o%2Fj9xAL9Mtf3lazwZogLGAGJ1Bzo60E%2BuSXBx
> rX5k%3D&reserved=0
> section 5.5.1
> --
> ---
> [e-mail]