RFC Errata
Found 11 records.
Status: Verified (2)
RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015
Source of RFC: scim (sec)
Errata ID: 6893
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Phil Hunt
Date Reported: 2022-03-24
Verifier Name: RFC Editor
Date Verified: 2022-03-25
Section 7.5.2 says:
HTTP/1.1 403 Forbidden
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":
"Query filter involving 'name' is restricted or confidential",
"scimType": "sensitive",
"status": "404"
}
It should say:
HTTP/1.1 403 Forbidden
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":
"Query filter involving 'name' is restricted or confidential",
"scimType": "sensitive",
"status": "403"
}
Notes:
The error "status" value in the figure is wrong. It should be "403", consistent with the normative text and the HTTP Status at the start of the figure.
Errata ID: 7898
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Osman Merghani Osman Elsayed
Date Reported: 2024-04-17
Verifier Name: RFC Editor
Date Verified: 2024-04-17
Section 3.12 says:
Example of an error in response to a PUT request:
HTTP/1.1 400 Bad Request
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"mutability"
"detail":"Attribute 'id' is readOnly",
"status": "400"
}
It should say:
Example of an error in response to a PUT request:
HTTP/1.1 400 Bad Request
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"mutability",
"detail":"Attribute 'id' is readOnly",
"status": "400"
}
Notes:
The response body is invalid JSON due to the missing comma after "mutability".
Status: Reported (8)
RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015
Source of RFC: scim (sec)
Errata ID: 4670
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 6010
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shelley Baker
Date Reported: 2020-03-09
Section 4 says:
"totalResults":2, "itemsPerPage":10,
It should say:
"totalResults":2, "itemsPerPage":2,
Notes:
Per Section 3.4.2.4, "itemsPerPage" specifies the number of query results returned in a page. In Section 4 Figure 9, the page contains only 2 items, so the "itemsPerPage" should be 2 not 10.
Errata ID: 7319
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: James Linnell
Date Reported: 2023-01-25
Section 3.4.2.2 says:
FILTER = attrExp / logExp / valuePath / *1"not" "(" FILTER ")"
valuePath = attrPath "[" valFilter "]"
; FILTER uses sub-attributes of a parent attrPath
valFilter = attrExp / logExp / *1"not" "(" valFilter ")"
It should say:
FILTER = attrExp / logExp / valuePath / *1("not" SP) "(" FILTER ")"
valuePath = attrPath "[" valFilter "]"
; FILTER uses sub-attributes of a parent attrPath
valFilter = attrExp / logExp / *1("not" SP) "(" valFilter ")"
Notes:
Note the following example filter listed further down in section 3.4.2.2:
filter=userType ne "Employee" and not (emails co "example.com" or
emails.value co "example.org")
There is a space between the "not" and the opening parenthesis, which is not allowed in the listed ABNF grammar. The corrected text includes a mandatory space between these two tokens.
It may be desired to use `*1("not" *1SP) "("` instead, for backwards compatibility reasons. This would allow for an optional space after a "not" keyword. Or, it may be desired to instead edit the example to remove the space, preserving the original intent of the listed grammar.
Errata ID: 7322
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: James Linnell
Date Reported: 2023-01-26
Section 3.4.2.2 says:
valFilter = attrExp / logExp / *1"not" "(" valFilter ")"
It should say:
valFilter = attrExp / valLogExp / *1"not" "(" valFilter ")"
valLogExp = valFilter SP ("and" / "or") SP valFilter
Notes:
This is a correction to Errata 4690 for this RFC. Errata 4690 introduced the following `valLogExp`:
valLogExp = attrExp SP ("and" / "or") SP attrExp
However, this fails to allow the following filter expression:
emails[type eq "work" or (type eq "home" and value ew "@example.com")]
because 4690's `valLogExp`'s recursion into `attrExp` would not allow for the parenthetical expression. The fixed `valLogExp` correctly recurs back into `valFilter` to allow for an `attrExp`, or a joined `logExp`, or a parenthtical.
While this example is not in the list of other exceptions in Section 3.4.2.2, the original use of `logExp` and the recurred `FILTER` would suggest that this example is within the original intent of the document.
Status: Held for Document Update (1)
RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015
Source of RFC: scim (sec)
Errata ID: 7122
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Egil Hansen
Date Reported: 2022-09-08
Held for Document Update by: Murray Kucherawy
Date Held: 2022-09-12
Section 3.5.2 says:
The "path" attribute is described by the following ABNF syntax rule:
PATH = attrPath / valuePath [subAttr]
Figure 7: SCIM PATCH PATH Rule
The ABNF rules "attrPath", "valuePath", and "subAttr" are defined in
Section 3.4.2.2. The "valuePath" rule allows specific values of a
complex multi-valued attribute to be selected.
It should say:
The "path" attribute is described by the following ABNF syntax rule:
PATH = attrPath / valuePath [subAttr] / attrExp
Figure 7: SCIM PATCH PATH Rule
The ABNF rules "attrPath", "valuePath", "subAttr", and "attrExp" are
defined in Section 3.4.2.2. The "valuePath" rule allows specific
values of a complex multi-valued attribute to be selected.
Notes:
In section 3.5.2.2. (Remove Operation), states:
"If the target location is a multi-valued attribute and a complex
filter is specified comparing a "value", the values matched by the
filter are removed. If no other values remain after removal of
the selected values, the multi-valued attribute SHALL be
considered unassigned."
This means it should be possible to create a filter that selects a value from a multi-valued attribute that is not complex. Writing such a filter seems impossible without having "attrExp" as a possible legal PATH.
In section 3.4.2.2. (Filtering) there is an example that shows how such a filter could look for a multi-valued attribute, i.e.:
filter=
schemas eq "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
This would also work for a path filter, e.g.:
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"remove",
"path":"schemas eq \"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User\""
}]
}
[AD Note: The document reflects consensus of the working group at the time of publication, but on review it is believed that any future update work in this space should consider this erratum.]