Subject: Re: [scim] Comments on SCIM use cases draft

From: "[email-masked]" <[email-masked]>
Date: Tue, 4 Mar 2014 01:55:20 -0500

Thanks a lot Bert.

We'll address these in the next version.

Best.

Bhumip

On Fri, Feb 28, 2014 at 2:07 AM, Bert Greevenbosch <
[email-masked]> wrote:

> Hi all,
>
> I have reviewed the SCIM use cases draft:
>
> http://tools.ietf.org/html/draft-ietf-scim-use-cases-00
>
> I have some comments listed below. I think they are not too difficult to
> handle. :-)
>
> Best regards,
> Bert
>
> ---
>
> [BG1] Section 2.2.1, 3d line: change "identity" to "identify".
>
> [BG2] Section 2.2.1, the abbreviation "C.R.U.D." is expanded, whereas
> "SSO" is not. I suggest to expand SSO too.
>
> [BG3] Section 2.2.1, I am not clear on the various triggers. Each item has
> the name of a trigger, but in the description there is another name of a
> trigger. For example, in the first item there is "Create SCIM Identity
> Resource - Service On-boarding Trigger", and in the description "create
> SCIM resource trigger". Are these the same? Then use a single name. Also,
> for readability I suggest to put the name between quotes, e.g. "create SCIM
> resource" trigger.
>
> [BG4] Section 2.2.1, first item last sentence, add ", and" between
> "implementation" and "not to the use cases".
>
> [BG5] Section 2.2.2, second item: replace "entitle" by "entity".
>
> [BG6] Section 2.2.2, third item: replace "end-end" by "end".
>
> [BG7] Section 2.2.3, "real work use cases" -> "real world use cases".
>
> [BG8] Section 2.3.3: "This use case highlights how different CSPs may
> implement different operational semantics behind the same SCIM operation.
> Note that CSP-1 suspends the account representation for its service whereas
> CPS-2 implements a true delete operation."
> Interesting idea. Is it truly desired to have different CSPs treat the
> same request differently? Obviously there will always be some difference
> between implementations, but this difference seems quite big.
> On the other hand, maybe this is also not truly the same SCIM operation,
> since CSP-1 receives the trigger from the ECS, whereas CSP-2 receives a
> termination request from CSP-1.
>
> [BG9] Section 2.2.4, last sentence:
> "However, rather than pre-provisioning accounts from ECS-1 to CSP-1, CSP-1
> waits for a service access request from the Cloud Service User (CSU-1)
> under the control domain of ECS-1, before issuing an account Pull request
> to CSP-1."
> Something seems wrong in this sentence, as it seems to say that CSP-1
> issues a Pull request to itself. Maybe the account Pull request is sent to
> "ECS-1", not to "CSP-1"?
>
> [BG10] In various use cases, there are requirements for logs. However,
> there is no text in the use cases itself. Maybe it would be better to
> elaborate a bit on the logs in the use cases? This should also involve the
> mentioned auditing.
>
> [BG11] Section 3.4, the sentence "The local YourCoI offices are
> responsible for establishing personal information and (i.e., setting the
> user identities and attributes)." needs wordsmithing.
>
> [BG12] Section 3.4, "Identity management of the personal data must be
> secure" is a bit vague. I guess it means protected against unauthorised
> access and remaining confidentiality? Then maybe the following wording
> would be better: "Identity management of the personal data must be
> protected against unauthorised access and remain confidential to only
> authorised parties."
>
> [BG13] Section 3.5: should there be a requirement for expiration of the
> cached copy, i.e. a maximum period for which the relying party may cache
> the information?
>
> [BG14] The "security considerations" section is rather short, only
> mentioning authorisation and authentication. It would be good to add some
> text about confidentiality and privacy protection.
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>