Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes

[Phil Hunt <[e-mail]>]

1. scimType is intended to indicate many of these details. Like a unique index conflict (e.g. “uniqueness”).  That said, I’m not sure it would indicate which attribute caused the failure.  Should we indicate which attribute is not unique or which attribute has a mutability error through another response element?

2. Why isn’t the standard accept-langauge headers not appropriate to localize the detail message? 

There are also some security considerations here in cross-domain scenarios. It is very likely that even if we mandate detail errors that many SPs will return generic Status 400 errors to non-privledged clients.

Phil

@independentid
www.independentid.com
[e-mail]



On Jun 26, 2014, at 2:09 AM, David Möbius <[e-mail]> wrote:

> Hello,
> 
> I would like to adjust to add a "error group" type to the error object.
> 
> Example:
> 
> {
>  “schema”: "urn:scim:api:messages:2.0:Error”
>  "scimGroupType" - "saving user"
>  "scimDetailType" - "username allready taken"
>  "status" - the HTTP status (should correspond to the response header)
>  "detail" - "The username 'marissa' is already taken"
> }
> 
> 
> The scimGroupType and the scimDetailType should never change if you do
> the same mistage to make it machine readable.
> 
> Example and Reason:
> I have a mask where the user can create an account. I have created my
> html page the way that the user can't do "anything" wrong. The only
> think the could do wrong is to use a existing username.
> 
> After I send the new user to the backend I get an exception. Since I
> wan't to display the exception message in german or an other language I
> need to know what type of exception was the problem.
> 
> I would like to give the User kind of messages:
> 
> 1. The user used a given username: If this is the problem I can see it
> with the help of the scimDetailType which will always be "username
> already taken".
> 
> 2. It is somethink wrong with the userdata (for example a email without
> @ which I forget to check in my frontend). That something is wrong with
> the userdata in generall I can see with the "scimGroupType"
> 
> 3. Something else happens and I want to log the exception in my logs and
> give an general message to the user
> 
> In my front end it could look like
> 
> if(scimException.getScimDetailType.equals("username allready taken")){
> 
> errorMessage = "in german: Your username is already taken. Plase use a
> other one."
> }else if(scimException.getScimGroupType.equals("saving user")){
> 
> errorMessage = "in german: Could not save your data. Please check your
> given data.";
> }else{
> 
> log.Error(scimException);
> errorMessage= "in german: an error happen. Please try again later."
> }
> 
> For this reason it would be good if we have 2 error codings in our error
> json object. What do you think about this?
> 
> by David
> 
> Am 25.06.2014 21:07, schrieb Phil Hunt:
>> On the call today (Erik, Bjorn, Morteza, and myself), we discussed the
>> error issue.
>> 
>> The major concern with the draft suggested by Julian is really one of
>> timing - we would prefer not to hold SCIM up. A good middle-ground
>> approach is to align with the draft, but define the error fully within
>> SCIM (using the SCIM mime type and schema namespace).
>> 
>> The proposal on the call is to SCIM mime/type of application/scim+json
>> in error responses and include the SCIM error message schema declaration.  
>> 
>> {
>> “schema”: "urn:scim:api:messages:2.0:Error” (indicates the SCIM message
>> type)
>> "scimType" - a keyword indicating the detail error (e.g.  “mutability”)
>> "status" - the HTTP status (should correspond to the response header)
>> "detail" - a detailed, human-readable message
>> }
>> 
>> Servers MAY return additional attributes (e.g. ones from http-problem
>> draft).  The only mandatory attributes are “schema” and “status”.  For
>> example on anonymous self-registration scenarios, servers may be
>> unwilling to give detail error responses for security reasons.
>> 
>> The reason for using scimType (instead of type) is to avoid any
>> confusion with “type” from draft-nottingham-http-problem and its
>> eventual use of “type”.
>> 
>> In a future update to SCIM we can then transition to align with the HTTP
>> Problem draft by simply adding “type” in the way it defines. 
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com <http://www.independentid.com>
>> [e-mail] <mailto:[e-mail]>
>> 
>> 
>> 
>> On Jun 25, 2014, at 12:25 AM, Erik Wahlström
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>> 
>>> So that would make it look like the following right?
>>> 
>>> {
>>>  "schemas": ["urn:scim:api:messages:2.0:Error"],
>>>  "Error":
>>>    {
>>>      "type": "urn:scim:api:error:2.0:mutability",
>>>      "title": “Attribute is readOnly.",
>>>      "detail": “Attribute 'id' is readOnly and can’t be changed in a
>>> PATCH request.",
>>>      “status": 400  
>>>    }
>>> }
>>> 
>>> I replaced Errors with Error.
>>> Also replaced urn:scim:error:api:2.0:mutability with
>>> urn:scim:api:error:2.0:mutability
>>> 
>>> That works for me.
>>> / Erik
>>> 
>>> 
>>> 
>>> On 25 Jun 2014, at 01:30, Phil Hunt <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>> 
>>>> Note: July 04 is the LAST day for us to potentially submit updates
>>>> for the IETF90 meeting.  This gives us about 1.5 weeks to close off
>>>> the error issues and update the drafts.  If you have a moment please
>>>> take a look and comment as soon as possible...
>>>> 
>>>> Julian thanks for the suggestion.  For the rest of the group’s
>>>> benefit, the draft Julian referenced suggests the following
>>>> attributes be returned in a standardized detailed error JSON body…
>>>> 
>>>>>   A problem details object MAY have the following members:
>>>>> 
>>>>>   o  "type" (string) - An absolute URI [RFC3986 <http://tools.ietf.org/html/rfc3986>] that identifies the
>>>>>      problem type.  When dereferenced, it SHOULD provide human-readable
>>>>>      documentation for the problem type (e.g., using HTML
>>>>>      [W3C.REC-html401-19991224 <http://tools.ietf.org/html/draft-nottingham-http-problem-06#ref-W3C.REC-html401-19991224>]).  When this member is not present, its
>>>>>      value is assumed to be "about:blank".
>>>>>   o  "title" (string) - A short, human-readable summary of the problem
>>>>>      type.  It SHOULD NOT change from occurrence to occurrence of the
>>>>>      problem, except for purposes of localisation.
>>>>>   o  "status" (number) - The HTTP status code ([RFC2616], Section 6 <http://tools.ietf.org/html/rfc2616#section-6>)
>>>>>      generated by the origin server for this occurrence of the problem.
>>>>>   o  "detail" (string) - An human readable explanation specific to this
>>>>>      occurrence of the problem.
>>>>>   o  "instance" (string) - An absolute URI that identifies the specific
>>>>>      occurrence of the problem.  It may or may not yield further
>>>>>      information if dereferenced.
>>>> 
>>>> Here is the corresponding example error response:
>>>>>   HTTP/1.1 403 Forbidden
>>>>>   Content-Type: application/problem+json
>>>>>   Content-Language: en
>>>>> 
>>>>>   {
>>>>>    "type": "http://example.com/probs/out-of-credit",
>>>>>    "title": "You do not have enough credit.",
>>>>>    "detail": "Your current balance is 30, but that costs 50.",
>>>>>    "instance": "http://example.net/account/12345/msgs/abc",
>>>>>    "balance": 30,
>>>>>    "accounts": ["http://example.net/account/12345",
>>>>>                 "http://example.net/account/67890"]
>>>>>   }
>>>> 
>>>> Julian, what is the value of having “type” be a URI?  Why not just
>>>> have a SCIM specific attribute (scimType) and use simple keywords?
>>>> (asking mainly for the WG’s benefit). I guess the strong case is that
>>>> by standardizing HTTP responses, client code gets simplified.
>>>> However, using standard attributes creates the namespace conflict
>>>> issue.  So we need URI based error codes.
>>>> 
>>>> The SCIM specs could adopt the “type”, “detail”, and “status”. We
>>>> would register a namespace of urn:scim:error:apil:2.0 in the SCIM
>>>> IANA section in addition to api:messages, schema:core, etc.  This
>>>> would give detail error types of:
>>>>  urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc.
>>>> 
>>>> The other items, like title, instance, etc could be optional or just
>>>> omitted from SCIM spec. —> we would just indicate that clients should
>>>> expect attributes within the JSON message other than those defined by
>>>> the SCIM drafts.
>>>> 
>>>> IMPORTANT NOTE:  the format suggested by Julian allows for only one
>>>> error at a time.  Erik had commented he prefers to return only one. I
>>>> tend to agree. In the case of BULK requests, this is not really an
>>>> issue since each BULK operation gets its own response block.
>>>> 
>>>> *_In the interests of time, any objections to using type (with URI
>>>> based error codes), detail, status, per above and limiting to ONE per
>>>> response?  _*
>>>> 
>>>> I know these are normative changes….however I’m pretty sure we can’t
>>>> avoid changes in the final document clean up whether or not we adopt
>>>> the proposed standardized error response.
>>>> 
>>>> Cheers,
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com <http://www.independentid.com/>
>>>> [e-mail] <mailto:[e-mail]>
>>>> 
>>>> 
>>>> 
>>>> On Jun 24, 2014, at 12:23 PM, Julian Reschke <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>>> On 2014-06-24 21:01, Phil Hunt wrote:
>>>>>> With regards to tickets 37, 46, 67, it looks like we will have some
>>>>>> normative changes required.  I am also expecting new SCIM error
>>>>>> codes as
>>>>>> we look at the possible reasons a server might return Bad Request or
>>>>>> other HTTP status codes.
>>>>>> 
>>>>>> Currently, the example response from PATCH, we use “error” to
>>>>>> indicate a
>>>>>> detailed error.
>>>>>> 
>>>>>> * "error":"mutability"*
>>>>>> 
>>>>>> From Response Codes Section, no detail error is defined:
>>>>>> 
>>>>>> *HTTP/1.1 404 NOT FOUND*
>>>>>> 
>>>>>> {
>>>>>>  "schemas": ["urn:scim:api:messages:2.0:Error"],
>>>>>>  "Errors":[
>>>>>>    {
>>>>>>      *"description":"Resource 2819c223-7f76-453a-919d-413861904646
>>>>>> not found",
>>>>>>      "code":"404"*
>>>>>>    }
>>>>>>  ]
>>>>>> }
>>>>>> 
>>>>>> 
>>>>>> Doing a search around Twitter, AWS, and many others, I see that “code”
>>>>>> is often used to indicate a detailed error message (“mutability”) and
>>>>>> status is used to indicate HTTP status.
>>>>>> 
>>>>>> In an attempt to bring consistency across the API document, I am
>>>>>> proposing we use http_status and scim_code. This will help make clear
>>>>>> what we are referring to and allow existing implementations to co-exist
>>>>>> for a while (by having different names).
>>>>>> 
>>>>>> _Are there any objections to normalizing the spec around following
>>>>>> format and attributes?_
>>>>>> 
>>>>>> Proposed example:
>>>>>> 
>>>>>> *HTTP/1.1 400 Bad Request*
>>>>>> 
>>>>>>   Content-Type: application/scim+json;charset=UTF-8
>>>>>>   Cache-Control: no-store
>>>>>>   Pragma: no-cache
>>>>>> 
>>>>>>   {
>>>>>>     "schemas": ["urn:scim:api:messages:2.0:Error"],
>>>>>>     "Errors":[
>>>>>>       {
>>>>>>         *“scim_code":"mutability”,*
>>>>>> 
>>>>>> *          “http_status”:400,*
>>>>>>         "error_description":"Attribute 'id' is readOnly."
>>>>>>       },
>>>>>> 
>>>>>>        . . .
>>>>>> 
>>>>>>     ]
>>>>>> 
>>>>>>   }
>>>>>> ...
>>>>> 
>>>>> You may want to read
>>>>> <http://tools.ietf.org/html/draft-nottingham-http-problem-06>...
>>>>> 
>>>>> Best regards, Julian
>>>>> 
>>>>> _______________________________________________
>>>>> scim mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/scim
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/scim
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim
>> 
> 
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim