System for Cross-domain Identity Management: Protocol
RFC 7644

Note: This ballot was opened for revision 16 and is now closed.

Barry Leiba Yes

(Kathleen Moriarty) (was Discuss) Yes

Comment (2015-05-11 for -18)
No email
send info
Thank you for your work on this draft as I do think the work is important.  Thank you also for working with me to resolve discusses on security and privacy concerns with the authentication and authorization protocols that may be used with SCIM.  The added text on http authentication methods and security problems with OAuth bearer tokens will be very helpful to implementers and customers evaluating/negotiating security services of their service providers for provisioning.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2015-05-14 for -18)
No email
send info
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


(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-05-13 for -18)
No email
send info
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; 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 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.

- 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?)

-, 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

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2015-05-09 for -17)
No email
send info
"   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.

Alvaro Retana No Objection

Comment (2015-05-12 for -18)
No email
send info
Small nit in Section 1.2

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

(Martin Stiemerling) No Objection