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

[Ballot comment]
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

[...]

[Ballot comment]

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

[Ballot discuss]
-- 3.4.2: "SHOULD ignore any query parameters they do not understand"

I'm curious why this is not a MUST. What are the alternatives--that is, can you envision situations where it might be reasonable to _not_ ignore parameters you don't understand?

-- 3.4.2.2, reference to [Order-Operations]

As written, that needs to be a normative reference. That's problematic for a reference to wikipedia, since articles are extremely changeable. Furthermore, the referenced article doesn’t indicate one true operator precedence for programming languages. If the rest of the paragraph fully defines the precedence, I suggest saying “MUST… according to the following”, and making the reference truly informational (or even dropping it entirely.)

-- 3.8:

The first paragraph says servers MUST respond with JSON in UTF-8. But the following paragraphs talk about how the client may request different response formats. This seems contradictory.

-- 3.13:

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

[Ballot comment]
-- General: There seems to be a pervasive use of 2119 keywords in ways that seem like statements of fact, rather than normative requirements. This is especially true with MAY, where it seems like people may have gotten into the habit of capitalizing every occurrence of the word. I've called out a number of instances below, but probably didn't catch them all.

-- 1.3, 3rd paragraph:

The paragraph is indented as if part of the definition of "Base URI". I suspect that is not the intent.

"It is expected that SCIM servers MAY...": Is the normative MAY intentional? It's odd to see a 2119 keyword following a phrase like "It is expected..."

-- 2, Basic Authentication:

"Implementers SHOULD combine the use of basic authentication with other factors": Do you mean that they SHOULD NOT use basic _without_ combining it with other factors? If so, that is subtly different than the text as written.

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

This seems more a statement of fact than a normative assertion.

-- 3.1, 2nd paragraph "... a JSON object that MAY be created...", "in cases where SCIM MAY be used...", "reasonable to expect that some service providers MAY only support"

s/MAY/may

-- 3.1, 3rd paragraph:

"... implementations MAY vary": Should not be normative.
"... techniques such as document validation...are not recommended.": Maybe that one _should_ be normative.
"... a SCIM client SHOULD NOT expect...": Probably should not be normative. (But if it really is intended as normative, when might a client reasonably choose to violate it?)


-- 3.3, 3rd bullet:

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

-- 3.4.2, totalResults: "... SHALL NOT be equal..."

Never? Is it never possible that all results fit into one "page"? Perhaps this should have been a non-normative "might not be equal"?

-- 3.4.1.2, paragraph starting with "A query against a server root..."

What is the significance of "ALL" in caps?

-- 3.4.2.2, "... the the resource MUST match if any of the instances of the given attribute match the specified criterion..."

That seems like a statement of fact. (e.g. "the resource matches if..."

-- 3.4.2.4, 1st paragraph: "clients SHOULD never
  assume repeatable results"
 
  That seems like a statement of fact, not a normative assertion.
 
-- 3.5.1, 1st paragraph:

"Clients that MAY have..." : s/MAY/may

-- table 8, tooMany: "... MAY not be acceptable..."

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

s/MAY/may

-- editorial

-- 2, HOBA paragraph:

Is this intended as part of the TLS Client Authentication entry? It doesn't seem so, but the paragraph lacks its own heading.


3.2, 1st paragraph, sentence starting with "Given there are cases..."

Sentence fragment.

-- 3.3, first two bullet list entries

The "For" at the beginning of both entries does not fit the rest of the sentence structure.

[Ballot comment]
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.

[Ballot comment]
"  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.

[Ballot discuss]
Thanks for your work on this draft.  I have a few items I'd like to discuss and have provided suggestions to help the discussion.  I think this should be fairly easy to get through.

1. OAuth is used for authorization and is limited to insecure methods of authentication via HTTP supported methods and of those, OAuth only has a few registered.  HTTP Basic authentication is the default, which is horrible.  Later in this draft, SCIM encourages the use of asymmetric crypto.  Can this be the preferred option and there be more details listed on how to do with (references)?

What is specified now is really an authorization protocol, so you'll need to say if HTTP Basic is what's used for authentication with OAuth (default) or something else and then the security considerations for OAuth bearer tokens and HHTP Basic.  Here are some links to help:

A reference to security considerations from this draft will be needed:
see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions
Reference to the HTTP Basic draft will be needed to show the security issues with this option: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/

OAuth can't use something like HOBA in RFC7486, which was designed to avoid the need for passwords when using HTTP Authentication.  Can SCIM work directly with other HTTP Auth methods like HOBA? The OAuth folks are thinking about this problem, but aren't there yet (non-password auth methods to then use Oauth authorization tokens).

2. The Holder-of-Key Assertions would get you a lot more security than the bearer token.  Why are all the examples bearer token?  Or is there no support for proof of possession of the key?


3. Section 7.1
I'm guessing the text on TLS versions is old and this was overlooked in last call.  The minimum version that should be supported is 1.2.  TLS 1.0 is not considered a good starting point these days and browsers, such as Chrome show it as obsolete.  The text on implementation information for TLS 1.2 is no longer correct, it's widely implemented and is pretty much the standard at the moment (1.3 will be soon enough).  Referencing the TLS BCP would be preferred, https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/.  It not only starts from v1.2, but includes preferred algorithms and other configuration/implementation details to avoid attacks.  It is close to final publication and is ahead int he queue of this draft.

4. Section 7.2
Please review the Privacy Considerations, https://tools.ietf.org/html/rfc6973.  I was expecting to see more specific guidance as to what needs to be protected and options to protect the data since there is quite a bit of personal information passed in this protocol.  We care about this for the protection of user's privacy, not just because it is required by laws.  You can leave mention of the laws out, but it would be helpful to be specific on options to protect the data or options to leave out certain data elements to protect privacy (such as, make them optional or provide a way to encrypt/obscure, etc.).  RFC6973 will help with current guidance and IETF considerations.  If it is a per element or attribute consideration, a pointer to that text from the privacy considerations section to the schema draft may be more appropriate than covering the options in this draft.  Then  a better TLS option will help as well so the session is less subject to attacks.

I see there is some text on privacy n the schema draft, but it's probably not enough.  I'll read that within the next few days and give feedback to help improve the text.

[Ballot comment]

This is really just here to see if better Authentication options are possible in current implementations and guidance for SCIM.

Section 7.5
While I like this bullet:
    o Avoid passwords and consider use of asymmetric cryptography based
      credentials.
Earlier in this draft the use of OAuth is specified, and the default for that is passwords  via HTTP basic.  If asymmetric crypto is an option, can that be the preferred option?  If it's possible, more detail on how to do that would be good as that's not a supported option with OAuth.

Thanks!

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-scim-api-16. Please see below and report any inaccuracies.

IANA's reviewer has the following comments/questions:

IANA notes that at least one of the actions requested in the IANA Considerations section of this document is dependent upon the approval of another Internet Draft.

Upon approval of this document, IANA understands that there are two actions which must be completed.

First, in the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new application media type will be added to the registry as follows:

name: scim+json
template: [ As-provided-in-draft ]
reference: [ RFC-to-be ]

NOTE: The next action requested in the IANA Considerations section of the current document is dependent on actions in another Internet Draft. The name of the registry these registrations are being placed in is not clear.

In the SCIM Schema URIs for Data Resources registry proposed by [ I-D.ietf-scim-core-schema ], new registrations will be added as follows:

Schema URI Name: Reference:
------------------------------------------------------------------------
urn:ietf:params:scim:api:messages:2.0:ListResponse List/Query Response [ RFC-to-be Section 3.4.2 ]
urn:ietf:params:scim:api:messages:2.0:SearchRequest POST Query Response [ RFC-to-be Section 3.4.3 ]
urn:ietf:params:scim:api:messages:2.0:PatchOp Patch Operation [ RFC-to-be Section 3.5.2 ]
urn:ietf:params:scim:api:messages:2.0:BulkRequest Bulk Operations Request [ RFC-to-be Section 3.7 ]
urn:ietf:params:scim:api:messages:2.0:BulkResponse Bulk Operations Response [ RFC-to-be Section 3.7 ]
urn:ietf:params:scim:api:messages:2.0:Error Error Response [ RFC-to-be Section 3.12 ]

IANA understands that these two actions are the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (System for Cross-Domain Identity Management: Protocol) to Proposed Standard


The IESG has received a request from the System for Cross-domain Identity
Management WG (scim) to consider the following document:
- 'System for Cross-Domain Identity Management: Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The System for Cross-Domain Identity Management (SCIM) specification
  is an HTTP based protocol that makes managing identities in multi-
  domain scenarios easier to support through a standardized services.
  Examples include but are not limited to enterprise to cloud service
  providers, and inter-cloud based scenarios.  The specification suite
  seeks to build upon experience with existing schemas and deployments,
  placing specific emphasis on simplicity of development and
  integration, while applying existing authentication, authorization,
  and privacy models.  SCIM's intent is to reduce the cost and
  complexity of user management operations by providing a common user
  schema and extension model and a service protocol defined by this
  document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-scim-api/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-scim-api/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary
=======

Document shepherd: Leif Johansson
Responsible AD: Barry Leiba
Publication type: Proposed Standard

The two documents (draft-ietf-scim-api and draft-ietf-core-schema) are
the core documents of the SCIM protocol - a simple API for "CRUD"
operations on (mainly) user and group objects associated with Internet
services (aka cloud services). The schema document defines the object
model for the core resources as well as extension mechanisms for adding
new resource types and extending core resources.

Review and Consensus
====================

The documents have been extensively reviewed and are being implemented
by multiple parties. The set of active contributors is mostly made up of
vendors and is relatively small. Most of the work has been done via
interim conference calls, which may have caused the set of active
contributors to be a bit smaller than otherwise might have been the
case, but it has also made the active contributors more active and
productive.

The current documents represent "version 2.0" of an existing standard
that was developed by an informal collaboration. Version 2.0 represents
a significant number of changes but there are already (partial)
implementations that have informed the WG. The documents have gone
through two WGLC's because a number of nits were discovered after the
first WGLC. It is the opinion of the shepherd that the WG has reached
broad consensus on the specification, and several vendors are getting to
a point where they could demonstrate interoperability between multiple
independent implementations. Although it may be possible to keep finding
nits for a while longer it is the view of the shepherd that the
documents should be published now as Proposed Standard, and revised soon
with any additional nits that are discovered during continued deployment
and interoperability-testing.

Intellectual Property
=====================

No issues

Other Points
============

A major change for version 2.0 is a switch from XML to JSON. The WG
would appreciate external review from the JSON community.

There is one nit for each document. Both issues are small enough to be
addressed together with the IESG comments.

There are no downref issues.

Summary
=======

Document shepherd: Leif Johansson
Responsible AD: Barry Leiba
Publication type: Proposed Standard

The two documents (draft-ietf-scim-api and draft-ietf-core-schema) are the two core documents of the
SCIM protocol - a simple API for "CRUD" operations on (mainly) user and group objects associated with
Internet services (aka cloud services). The schema document defines the object model for the core
resources as well as extension mechanisms for adding new resource types and extending core resources.

Review and Consensus
====================

The document has been extensively reviewed and is being implemented by multiple parties. The active
contributors is mostly made up of vendors and is relatively small. Most of the work has been done via
interim conference calls which may have caused the the active contributors to be a bit smaller than
otherwise might have been the case but it has also made the active contributors more active and productive.

The current documents represent "version 2.0" of an existing standard that was developed by an
informal collaboration. Version 2.0 represents a significant number of changes but there are already
(partial) implementations that has informed the WG. The documents have gone through two WGLC's because
a number of nits were discovered after the first WGLC. It is the opinion of the shepherd that the WG
has reach broad consensus on the specification and several vendors are getting to a point where they
could demonstrate interoperability between multiple independent implementations. Although it may be
possible to keep finding nits for a while longer it is the view of the shepherd that the documents
should be published and revised soon with any additional nits that are discovered during the
interoperability-testing phase.

Intellectual Property
=====================

No issues

Other Points
============

A major change for version 2.0 is a switch from XML to JSON. The WG would appreciate external
review from the JSON community.

There is one nit for each document. Both issues are small enough to be addressed together with
the IESG comments.

There are no downref issues.