Subject: [scim] Proposed Detail Errors

From: Phil Hunt <[email-masked]>
Date: Fri, 27 Jun 2014 11:47:17 -0700

After reviewing the API and Schema docs, here is a first cut of the detailed error codes.

For HTTP Status 400 (Bad Request) responses, the following detail
   error types are defined:

+--------------+------------------------------+---------------------+
| scimType     | Description                  | Applicability       |
+--------------+------------------------------+---------------------+
| invalidFilte | The specified filter syntax  | GET(Section 3.2.2), |
| r            | was invalid (does not comply | POST (Search -      |
|              | with Figure 1) or the        | Section 3.2.3),     |
|              | specified attribute and      | PATCH (Path Filter  |
|              | filter comparison            | - Section 3.3.2)    |
|              | combination is not           |                     |
|              | supported.                   |                     |
| uniqueness   | One or more of attribute     | POST (Create -      |
|              | values is already in use or  | Section 3.1), PUT   |
|              | is reserved.                 | (Section 3.3.1),    |
|              |                              | PATCH (Section      |
|              |                              | 3.3.2)              |
| mutability   | The attempted modification   | PUT (Section        |
|              | is not compatible with the   | 3.3.1), PATCH       |
|              | target attributes mutability | (Section 3.3.2)     |
|              | or current state (e.g.       |                     |
|              | modification of an immutable |                     |
|              | attribute with an existing   |                     |
|              | value).                      |                     |
| invalidSynta | The request body message     | POST (Search -      |
| x            | structure was invalid or did | Section 3.2.2,      |
|              | not conform to the request   | Create - Section    |
|              | schema.                      | 3.1, Bulk - Section |
|              |                              | 3.5), PUT (Section  |
|              |                              | 3.3.1)              |
| invalidPath  | The path attribute was       | PATCH (Section      |
|              | invalid or malformed (see    | 3.3.2)              |
|              | Figure 4).                   |                     |
| noTarget     | The specified "path" did not | PATCH (Section      |
|              | yield an attribute or        | 3.3.2)              |
|              | attribute value that could   |                     |
|              | be operated on. This occurs  |                     |
|              | when the specified "path"    |                     |
|              | value contains a filter that |                     |
|              | yields no match.             |                     |
| invalidValue | A required value was         | GET (Section        |
|              | missing, or the value        | 3.2.2), POST        |
|              | specified was not compatible | (Create - Section   |
|              | with the operation or        | 3.1, Search -       |
|              | attribute type (see Section  | Section 3.2.2), PUT |
|              | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),    |
|              | ma]).                        | PATCH (Section      |
|              |                              | 3.3.2)              |
| invalidVers  | The specified API version is | GET (Section        |
|              | not supported (see Section   | 3.2.2), POST (ALL), |
|              | 3.11).                       | PUT (Section        |
|              |                              | 3.3.1), PATCH       |
|              |                              | (Section 3.3.2),    |
|              |                              | DELETE (Section     |
|              |                              | 3.4)                |
+--------------+------------------------------+---------------------+
I plan to put these into draft 07 of the API and will publish over the weekend.

As always, feedback welcome!

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Sun, 29 Jun 2014 20:09:49 +0000

I like these, Phil.  Should this list of error codes be extensible?

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, June 27, 2014 1:47 PM
To: Scim WG
Subject: [scim] Proposed Detail Errors

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Sun, 29 Jun 2014 13:27:13 -0700

Could be if we use URIs for codes 

Phil

> On Jun 29, 2014, at 13:09, Kelly Grizzle <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 30 Jun 2014 14:46:52 +0000

I remember that one of the initial drivers for this ticket was the ability for service providers to send back error codes that are specific to the service provider.

An example on a user creation might be “error 28738” … “client has exceeded the maximum number of users in their organization”.  Ideally the SP would be able to communicate back the general HTTP error code, a provider-specific error code, and a human readable description.

I think that scimType would allow for this if the list were extensible.

--Kelly

From: Phil Hunt [mailto:[email-masked]]
Sent: Sunday, June 29, 2014 3:27 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

Phil

On Jun 29, 2014, at 13:09, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
I like these, Phil.  Should this list of error codes be extensible?

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Mon, 30 Jun 2014 08:56:27 -0700

David had a similar comment. 

What if there was a separate attribute: spCode that allows the service provider to indicate non-protocol errors?

Phil

> On Jun 30, 2014, at 7:46, Kelly Grizzle <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 30 Jun 2014 11:14:03 -0700

After thinking about this a bit, I think URIs for scimType is the best way to go. While having a URI means a new IANA registry, it is probably simpler to implement and allows for the capability for SPs to extend errors as Kelly and David have requested.  It is also in line with: http://tools.ietf.org/html/draft-nottingham-http-problem-06

As many are off-line much of the week due to Canadian and US holidays, and the window for submissions for IETF90 closes Friday, I will start work amending the API draft to include the error codes listed at the start of this thread but with URIs and will add the IANA registry for errors.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 30 Jun 2014 19:24:14 +0000

Isn't this going to be a continued problems with IANA updates ?

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, June 30, 2014 11:14 AM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

Phil

@independentid

On Jun 30, 2014, at 8:56 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Jun 30, 2014, at 7:46, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
I remember that one of the initial drivers for this ticket was the ability for service providers to send back error codes that are specific to the service provider.

An example on a user creation might be "error 28738" ... "client has exceeded the maximum number of users in their organization".  Ideally the SP would be able to communicate back the general HTTP error code, a provider-specific error code, and a human readable description.

--Kelly

Phil

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 30 Jun 2014 12:35:01 -0700

How so?

Phil

> On Jun 30, 2014, at 12:24, Anthony Nadalin <[email-masked]> wrote:
> 
> Isn’t this going to be a continued problems with IANA updates ?
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 30 Jun 2014 21:43:52 +0000

Concern is that this can cause continuous code changes in different codes being registered, ideally there would only be a couple and they would be from the start but this could grow and cause interoperability issues with folks registering error codes

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, June 30, 2014 12:35 PM
To: Anthony Nadalin
Cc: Kelly Grizzle; Scim WG
Subject: Re: [scim] Proposed Detail Errors

How so?

Phil

On Jun 30, 2014, at 12:24, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
Isn’t this going to be a continued problems with IANA updates ?

Phil

@independentid

Phil

--Kelly

Phil

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid

---

From: Leif Johansson <[email-masked]>
Date: Tue, 01 Jul 2014 00:54:22 +0200

On 2014-06-30 23:43, Anthony Nadalin wrote:
> Concern is that this can cause continuous code changes in different
> codes being registered, ideally there would only be a couple and they
> would be from the start but this could grow and cause interoperability
> issues with folks registering error codes

Thats going to be true for any extension though, right? Errors are no
worse in this respect.

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 30 Jun 2014 23:13:52 +0000

I don't know that service providers should have to register codes that are specific to their implementation ... that kind of seems like overkill to me.  What benefit does that provide other than possibly preventing collisions?

As long as the SP can provide information to the client about what error occurred, it feels like that is enough.  The error code sent in the response could either be one of the SCIM-defined errors (mutability, etc...) or a provider-defined error (eg - an error code number, etc...).

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Monday, June 30, 2014 5:54 PM
To: [email-masked]
Subject: Re: [scim] Proposed Detail Errors

> issues with folks registering error codes

Thats going to be true for any extension though, right? Errors are no worse in this respect.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 30 Jun 2014 20:50:30 -0700

My worry is that if service providers implement non-standard codes and than do not register them, then they can expect that clients shall ignore their proprietary custom codes.

Still, service providers should also expect that not every client will implement registered codes either.

Clients will need to keep in mind that many service providers will likely only return a general 400 bad request for *any* error as they may be cautious about proving attacks.

I recommend we limit error codes to protocol and schema issues only in order to get to a final draft in Toronto.

I understand the value of detailed error codes to coding smart UIs. But I would prefer to deal with these fine-grained errors in a future charter.

Phil

@independentid
www.independentid.com
[email-masked]