RFC Errata
Found 16 records.
Status: Verified (3)
RFC 7644, "System for Cross-domain Identity Management: Protocol", September 2015
Source of RFC: scim (sec)
Errata ID: 7916
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francois LASNE
Date Reported: 2024-04-29
Verifier Name: Deb Cooley
Date Verified: 2024-05-11
Section 3.7.3 says:
containing a human-readable explanation of the error.
"status": "201"
The following is an example of a status in a failed operation.
"status": "400",
"response":{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax"
"detail":
"Request is unparsable, syntactically incorrect, or violates schema.",
"status":"400"
}
It should say:
containing a human-readable explanation of the error.
The following is an example of a status in a failed operation.
{
"status": "400",
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"invalidSyntax",
"detail":"Request is unparsable, syntactically incorrect, or violates schema.",
}
Notes:
it misses a { at the beginning of the 400 sample
it missies a , after invalidSyntax
the overall response looks wrong
Notice that even putting a there can be questionnable as well , and an alternative would be to just drop the content mentionned
SecAD Summary of the changes (per the authors):
* Remove line: “status”: “201”
* Add leading brace ‘{‘
* Add missing comma after “invalidSyntax”
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 (12)
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.
Errata ID: 8057
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Häber
Date Reported: 2024-07-30
Section 3.4.2.2 says:
The following are examples of valid filters. Some attributes (e.g., rooms and rooms.number) are hypothetical extensions and are not part of the SCIM core schema:
It should say:
The following are examples of valid filters.
Notes:
The mentioned hypothetical extensions "rooms" and "rooms.number" cannot be found in the examples in Figure 2. It makes it a bit confusing when reading it because it takes some time to see that actually all attributes in the examples can be found in RFC7643. Only the filter for schema with the Enterprise user extension is outside the core schema, but that is also not a hypothetical extension. Therefore, I think it is more clear to remove that sentence since all filters in the examples are valid.
Errata ID: 8084
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Éloi Rivard
Date Reported: 2024-08-19
Section 3.4.3 says:
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults":100,
"itemsPerPage":10,
"startIndex":1,
"Resources":[
{
"id":"2819c223-7f76-413861904646",
"userName":"jsmith",
"displayName":"Smith, James"
},
{
"id":"c8596b90-7539-4f20968d1908",
"displayName":"Smith Family"
},
...
]
}
It should say:
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults":100,
"itemsPerPage":10,
"startIndex":1,
"Resources":[
{
"id":"2819c223-7f76-413861904646",
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName":"jsmith",
"displayName":"Smith, James"
},
{
"id":"c8596b90-7539-4f20968d1908",
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName":"Smith Family"
},
...
]
}
Notes:
RFC7643 §3 indicates that the schema attribute is needed for all the representations:
The "schemas" attribute is a REQUIRED attribute and is an array of
Strings containing URIs that are used to indicate the namespaces
of the SCIM schemas that define the attributes present in the
current JSON structure. [...]
All representations of SCIM schemas MUST include a
non-empty array with value(s) of the URIs supported by that
representation.
Errata ID: 8096
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Siqing Zheng
Date Reported: 2024-09-07
Section 3.5.2.1 says:
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"add",
"value":{
"emails":[
{
"value":"babs@jensen.org",
"type":"home"
}
],
"nickname":"Babs"
}]
}
It should say:
{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"add",
"value":{
"emails":[
{
"value":"babs@jensen.org",
"type":"home"
}
],
"nickname":"Babs"
}
}]
}
Notes:
missing one closing curly bracket
Errata ID: 8097
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Siqing Zheng
Date Reported: 2024-09-08
Section 3.5.2.1 says:
o If the target location does not exist, the attribute and value are
added.
o If the target location specifies a complex attribute, a set of
sub-attributes SHALL be specified in the "value" parameter.
o If the target location specifies a multi-valued attribute, a new
value is added to the attribute.
It should say:
N/A Please see Notes.
Notes:
Looks Microsoft Azure had a different understanding about the patch 'add' operation, in which they add an additional element to the multi-value attribute by the filter in the path.
For example,
{
...
"op":"add",
"path":"emails[type eq \"work\"].value"
"value":"example@email.com"
...
}
Microsoft Azure expects to add a new email with value "example@email.com" and type "work".
However, I think it's a pretty hacky way to do it and may not be the RFC intent. I also found there was a discussion about it, which they claim the RFC is not very clear about the patch 'add' part.
Link to discussion on Microsoft platform: https://learn.microsoft.com/en-us/answers/questions/708183/scim-patch-of-complex-multi-valued-attribute-inclu#:~:text=are%20relevant%20here%3A-,If%20the%20target%20location%20does%20not%20exist,-%2C%20the%20attribute%20and
Could we please clarify if such 'add' patch by filter is expected or not? or may be add an extra example?
Thanks!
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.]