RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (4)

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".

Report New Errata