System for Cross-domain Identity Management: Protocol
draft-ietf-scim-api-19

Small nit in Section 1.2

s/Throughout this documents all figures MAY contain spaces/Throughout this document all figures may contain spaces

Update: I've released my DISCUSS on this. All my DISCUSS items have been resolved save the last one that I am moving to a comment. My point was to make sure the concern was discussed--if the authors answer that the working group thought about this want to keep it as is, that's okay with me.

Former Discuss Point:

It's optional (MAY) to include the API version. If the version is missing, the service provider SHOULD perform the operation using the most recent supported version. This seems to allow the client and service provider to disagree on the version being used. Does this cause an interop problem if the later version is not backwards compatible? (Are all new versions expected to be backwards compatible with old versions?)

[ I've removed comments that I think have been addressed.]

[...]

-- 2.1, last paragraph:

Just SHOULD? Do you invision situations where it might be reasonable _not_ to take the threats into account?

Also, the reference to oath-assertions needs to be normative

-- 2.2, "... it MAY be acceptable"

[...]

-- 3.3, 3rd bullet:

How does a service provider know which attributes a client understands?

[...]


As worded, that sounds like a statement of fact.

-- 7.3:

That needs to be a normative reference. Also, why is this a SHOULD? Can you envision scenarios where it might be reasonable for implementors NOT to take the countermeasures into account?

-- 7.4:

Reference to oauth-assertions needs to be normative.

-- 7.6, 2nd bullet

[...]

"   o  Limit the number of requests any particular client MAY make in a       period of time."

Great so we going to limit the extent to which an attacker can spam the  the thing. that sounds comforting.

"
These    recommendations include but are not limited to:  
o  Provide injection attack counter measures (e.g., by validating all       inputs and parameters),  
o  No cleartext storage of credentials,  
o  Store credentials using an encrypted protection mechanism, and
"

I don’t really think of that as being a recommendation so much as a requirement . if you’re storing clear text passwords somebody needs to take away all your toys.

Feel free to ignore any of these that overlap with earlier
comments, I've not been following all discussion on this one.

- section 2 says that bearer tokens based on no authenticaton
may be used (as the exception to the "SHOULD NOT be used").
Why is that ok? Maybe s/SHOULD NOT/MUST NOT/ here would be
better and justified?

- 3.1: seems odd to define schema but then say it's entirely
fine to ignore all of that - or am I reading this wrong?

- p9, figures and tables should have captions and be numbered
and this looks like a table of HTTP methods (not
"operations") that has neither.

- general: I came across a bunch of places where some forward
reference would help (e.g. 3.3 assumes I get what readOnly
means; 3.4.2.1 does the same for a "json attribute"). An
editing pass to try improve that before the RFC editor would
be good I think.

- 3.4.2 says: "This SHALL NOT be equal to the number of
elements in the resources attribute of the list response if
pagination (Section 3.4.2.4) is requested. " What if I ask
for pagination with 10 per page and there are a total of 10
matching results? That SHALL NOT seems broken.

- 3.4.2.2: Is "pr()" true when a client didn't send a value
to the server at creation time but the server included the
default value in the response to the PUT? (And what happens
to pr() and eq() when the default value changes?)

- 3.4.2.2, p21: eq() is case insensitive?  I think you badly
need a fwd ref to sections 3.8 and 5.

- 7.4, para 2 looks truncated