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

From: Likepeng <[email-masked]>
Date: Wed, 18 Jun 2014 08:50:44 +0000

Hello Bert,

Thanks for your review comments.

> [BG1] Section 2.2.1, 3d line: change "identity" to "identify".

OK. Changed in -02.

> [BG2] Section 2.2.1, the abbreviation "C.R.U.D." is expanded, whereas "SSO" is not. 
>I suggest to expand SSO too.

OK. Changed in -02.

> [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.

OK. Changed in -02.

> [BG4] Section 2.2.1, first item last sentence, add ", and" between
> "implementation" and "not to the use cases".

OK. Changed in -02.

> [BG5] Section 2.2.2, second item: replace "entitle" by "entity".

OK. Changed in -02.

> [BG6] Section 2.2.2, third item: replace "end-end" by "end".

OK. Changed in -02.

> [BG7] Section 2.2.3, "real work use cases" -> "real world use cases".

OK. Changed in -02.

> [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.

I changed the sentence to the following to clarify that:
   After receiving the confirmation from CSP-2, CSP-1
   finalizes the deletion operation and sends an acknowledgment to the
   requesting ECS.

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

The comment actually is to section 2.4.4. Yes, it should be "ECS-1". Changed in -02.

> [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.

Storing information is mentioned in the use cases. That can derive the log requirement.

> [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.

I changed the sentence to the following:
   The local YourCoI offices are responsible for collecting
   personal information(i.e. user identities and attributes).  

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

OK, changed in -02.

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

OK, I added this sentence:
A maximum period should be set for the relying party to 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.

OK, I added the following two paragraphs to the "Security Considerations" section:

   SCIM resources (e.g., Users and Groups) can contain sensitive
   information.  Therefore, authentication and authorization must be
   guaranteed for the SCIM operations.

   Also, private information of the SCIM resources must be kept
   confidential and protected.

I will upload -02 soon.

Thanks,
Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: scim [mailto:[email-masked]] 代表 Bert Greevenbosch
> 发送时间: 2014年2月28日 15:07
> 收件人: [email-masked]
> 主题: [scim] Comments on SCIM use cases draft
> 
> 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