Subject: [scim] Complexity

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 4 Nov 2012 09:36:47 -0500

Hi all, 

in light of the discussions about deciding for XML vs. JSON to reduce the complexity of the protocol I thought I should raise a few remarks about complexity in the rest of the protocol suite. 

draft-ietf-scim-api defines two protocols that roughly accomplish the same functionality but are encoded differently. 

The main part of the document focuses on changing and modifying a single entry in the database. It is based on a REST-ful design (since that's very popular). Then, of course people realize that that leads to slow interactions when multiple exchanges are being made. For this reason, an entirely different protocol is defined for bulk transfer. Of course this bulk transfer has to replicate all the functionality of the rest of the exchange and will also have to do this with any future extension. Is there room to harmonize this a bit more. For example, a bulk transfer with a single entry provides the functionality of the other approach. 

Section 3 of draft-ietf-scim-api defines what HTTP messages are being used, such as GET, POST, PUT, PATCH, DELETE. It is nice to re-use the HTTP functionality but as some folks had found out that there are misbehaving intermediaries. Section 3.12 then introduces an alternative approach. It might be nice to have some data about the problem caused by intermediaries. Does it make sense to decide for one approach rather than using two?

The base specification has a lot of optional functionality. For this reason there is a feature discovery mechanism introduced. I wonder why the core specification does not only contain the mandatory-to-implement functionality. It also feels strange that the functionality for the configuration parameters are actually defined in a separate document, namely in draft-ietf-scim-core-schema rather than in  draft-ietf-scim-api where the actual features are described.

Section 4 of draft-ietf-scim-api talks about TLS being mandatory to implement. I believe that the specification should go further and say that it is mandatory to use for the type of data that is being shuffled around that is highly sensible. The document refers to OAuth about client authentication but I am not sure how you came to that conclusion. OAuth is a good protocol for delegated authorization but here there is no delegation happening. 

More related to the complexity of the specification: I also wonder why you have to introduce a "schema" for JSON, as you did it in Section 11.6 of draft-ietf-scim-core-schema. If you remove the XML support is there actually a need for Section 3 anymore? JSON supports certain data types. If this schema concept is of more generic usage, which may well be, then maybe that should be in a separate document for others to use as well. 

The schema / namespace concept is interesting since it is different to how XML does it. So, I am wondering how you ensure that two schema specifications do not define the same attribute names. 

Ciao
Hannes

---

From: Eliot Lear <[email-masked]>
Date: Mon, 05 Nov 2012 07:35:29 +0100

> Section 3 of draft-ietf-scim-api defines what HTTP messages are being used, such as GET, POST, PUT, PATCH, DELETE. It is nice to re-use the HTTP functionality but as some folks had found out that t…

Yes, but intermediaries shouldn't be our concern in this case.  The
protocol requires TLS by its nature, and so the usual plain text
problems should be dispensed with.  In the case where we're talking
about a reverse TLS proxy, that something that can be dealt with by a
party to the transaction.

Eliot