RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Reported (5)

RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015

Source of RFC: scim (art)

Errata ID: 4670
Status: Reported
Type: Technical

Reported By: Vassilis Michalitsis
Date Reported: 2016-04-15

Section 3.4.2.2 says:

Filters MUST be evaluated using the following order of operations, in
   order of precedence:

   1.  Grouping operators

   2.  Logical operators - where "not" takes precedence over "and",
       which takes precedence over "or"

   3.  Attribute operators

It should say:

Filters MUST be evaluated using the following order of operations, in
   order of precedence:

   1.  Grouping operators

   2.  Attribute operators

   3.  Logical operators - where "not" takes precedence over "and",
       which takes precedence over "or"

Notes:

It seems that the precedence of logical and attribute precedence is reversed? The filter filter=title sw "M" and userType eq "Employee" is meant to be interpreted as filter=(title sw "M") and (userType eq "Employee").
This is also the "expected" behaviour consistent with most other languages - with the notable exception of unary "or" which in SCIM is disambiguated as it can only apply to a parenthesized filter expression.

Errata ID: 4690
Status: Reported
Type: Technical

Reported By: Phil Hunt
Date Reported: 2016-05-10

Section 3.4.2.2 says:

valFilter = attrExp / logExp / *1"not" "(" valFilter ")"

It should say:

valFilter = attrExp / valLogExp / *1"not" "(" valFilter ")"

valLogExp = attrExp SP ("and" / "or") SP attrExp

Notes:

Figure 1 contains the ABNF for SCIM filters. The term "logExp" specifies "FILTER" as an option which unintentionally allows recursion. A valFilter should only allow simple sub-attribute expressions and simple logic. Nesting of valuePath (e.g. attr[a eq b and attr[c eq d]]) should not be possible.

Errata ID: 4978
Status: Reported
Type: Technical

Reported By: asgs
Date Reported: 2017-03-24

Section 4 says:

/ServiceProviderConfig

It should say:

/ServiceProviderConfigs

Notes:

Per the details provided on the SCIM website http://www.simplecloud.info/#overview, the endpoint should be /ServiceProviderConfigs. A trailing "s" is missing. The SCIM implementations of major service providers like Facebook, Salesforce, Slack implement /ServiceProviderConfigs

Errata ID: 5050
Status: Reported
Type: Technical

Reported By: Phil Hunt
Date Reported: 2017-06-23

Section 3.7.3 says:

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {[
           {
               "op": "remove",
               "path": "nickName"
           },
           {
               "op": "add",
               "path": "userName",
               "value": "Dave"
           }
         ]}
       },

It should say:

       {
         "method": "PATCH",
         "path": "/Users/5d8d29d3-342c-4b5f-8683-a3cb6763ffcc",
         "version": "W/\"edac3253e2c0ef2\"",
         "data": {
           "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
           "Operations": [
               {
                  “schemas”:["
                  "op": "remove",
                  "path": "nickName"
               },
               {
                  "op": "add",
                  "path": "userName",
                  "value": "Dave"
               }
           ]
         }
       },

Notes:

The example figure is incorrect. It should show the actual patch operation request body in the JSON attribute "data" as it would be expressed in its own HTTP request payload. Instead it shows the values of the "operations" attribute. See sec 3.7 definition of "data".

Errata ID: 5295
Status: Reported
Type: Technical

Reported By: Marcel van den Dungen
Date Reported: 2018-03-22

Section 3.5.2.1 says:

If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:

   HTTP/1.1 204 No Content
   Authorization: Bearer h480djs93hd8
   ETag: W/"b431af54f0671a2"
   Location:
   "https://example.com/Groups/acbf3ae7-8463-...-9b4da3f908ce"

It should say:

If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:

   HTTP/1.1 204 No Content
   ETag: W/"b431af54f0671a2"

Notes:

The Authorization header is a request header and should not be included in a response.
The Location header is used to redirect a client to a new location or indicate the location of a new resource. Neither is the case here, so the header should be omitted.

Also, it's unclear from the text whether it's valid to respond with 204 No Content if the user was successfully added to the group.

Report New Errata