Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04

From: "Kepeng Li" <[email-masked]>
Date: Tue, 17 Mar 2015 15:11:31 +0800

> I think the security considerations section is too brief, and would
be better fleshed out a bit.

How about this:

OLD:

   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.

NEW:

   Authentication and authorization must be
   guaranteed for the SCIM operations.
   Because SCIM builds on the Hypertext Transfer Protocol and
   thus subject to the security considerations of HTTP Section 9
   [RFC7230] <http://tools.ietf.org/html/rfc7230#section-9>  and its related
specifications.

   SCIM depends on standard HTTP authentication schemes. Implementers SHOULD
support
   existing authentication/authorization schemes.  In particular, OAuth2
   (see [RFC6749 <http://tools.ietf.org/html/rfc6749> ], [RFC6750
<http://tools.ietf.org/html/rfc6750> ]) is RECOMMENDED.  Appropriate
security
   considerations of the selected authentication and authorization
   schemes SHOULD be taken.

   SCIM resources (e.g., Users and Groups) can contain sensitive
   information. Thus, data confidentiality MUST be guaranteed at the
transport layer.
   TLS MUST be implemented by SCIM clients and service providers.
   TLS version 1.0 [RFC5246 <http://tools.ietf.org/html/rfc5246> ] or TLS
version 1.2 [RFC5246 <http://tools.ietf.org/html/rfc5246> ] can be chosen
depending on
   the widespread deployment and known security vulnerabilities at the time
of implementation. 

   The SCIM attributes MAY contain personally
   identifiable information as well as other sensitive data.
   Thus private information of the SCIM resources MUST be protected.
   Industry best practices SHOULD be undertaken to protect
   the storage of credentials and in particular SHOULD follow
   recommendations outlines in Section 5.1.4.1 [RFC6819]
<http://tools.ietf.org/html/rfc6819#section-5.1.4.1> .

END

In the new text, we talked about authentication, authorization, data
confidentiality, privacy protection.
Then the details about how to achieve that can be specified in API spec and
Schema spec.

Comments or suggestions are welcome.

Thanks,

Kind Regards
Kepeng

在 13/3/15 3:26 am， "Barry Leiba" <[email-masked]> 写入:

> I like this document, and I think it's about ready to go.  I just have
> two issues I'd like to discuss with the editors and working group:
> 
> 1. I think the security considerations section is too brief, and would
> be better fleshed out a bit.  There are going to be details that'll be
> left to the schema and api documents -- details that have to do with
> the schema and api, of course.  But this document could and should
> talk about the general security considerations for what SCIM is doing.
> What are the general threats and privacy issues, and how do you expect
> them to be dealt with?  Let the security considerations in this
> document form the basis on which the other documents with expand when
> the protocol details are in place.
> 
> 2. The IESG has been strongly questioning the value of publishing
> use-case documents as RFCs.  The question is whether they really have
> archival value, or whether no one will read them in six months or so,
> when the protocols they informed have been published.  Often, it would
> be better to publish collections of use cases and related discussion
> in the working group's wiki, rather than going for RFC publication.  I
> very much support that questioning.  But...
> 
> This document is more than a use-cases document, and it sells itself
> short by burying that, by making the reader figure that out.  It's
> really definitions and overview, flows, use cases, and requirements.
> As such, I think it *does* have value as an RFC.  Let's not make the
> rest of the IESG wonder about that, and perhaps take a different view.
> I suggest you retitle the document something like this:
> 
> OLD
> SCIM Use Cases
> 
> NEW
> System for Cross-domain Identity Management (SCIM) Definitions,
> Overview, and Flows
> 
> END
> 
> (That also expands SCIM, which the RFC Editor will insist on, so you
> might as well do it now.)
> 
> Then for the abstract:
> 
> OLD
>    This document lists the user scenarios and use cases of System for
>    Cross-domain Identity Management (SCIM).
> 
> NEW
>    This document provides definitions and an overview of the System
>    for Cross-domain Identity Management (SCIM).  It lays out the
>    system's modes and flows, and includes user scenarios, use cases,
>    and requirements.
> 
> END
> 
> And then tweak the Introduction accordingly.
> 
> Do those points sound reasonable?
> (I will put the document into "AD Evaluation: Revised I-D Needed" state.)
> 
> Barry
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 19 Mar 2015 17:04:16 +0000

Thanks Kepeng.  WG, please provide your feedback/thoughts on the suggested text.

Cheers,
Morteza

From: Kepeng Li <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 17, 2015 at 12:11 AM
To: "Barry org>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04

How about this:

OLD:

NEW:

   thus subject to the security considerations of HTTP Section 9
   [RFC7230]<http://tools.ietf.org/html/rfc7230#section-9> and its related specifications.

   SCIM depends on standard HTTP authentication schemes. Implementers SHOULD support
   existing authentication/authorization schemes.  In particular, OAuth2
   (see [RFC6749<http://tools.ietf.org/html/rfc6749>], [RFC6750<http://tools.ietf.org/html/rfc6750>]) is RECOMMENDED.  Appropriate security
   considerations of the selected authentication and authorization
   schemes SHOULD be taken.

   information. Thus, data confidentiality MUST be guaranteed at the transport layer.

   TLS version 1.0 [RFC5246<http://tools.ietf.org/html/rfc5246>] or TLS version 1.2 [RFC5246<http://tools.ietf.org/html/rfc5246>] can be chosen depending on

   the widespread deployment and known security vulnerabilities at the time of implementation.

   recommendations outlines in Section 5.1.4.1 [RFC6819]<http://tools.ietf.org/html/rfc6819#section-5.1.4.1>.

END

In the new text, we talked about authentication, authorization, data confidentiality, privacy protection.
Then the details about how to achieve that can be specified in API spec and Schema spec.

Thanks,

Kind Regards
Kepeng

在 13/3/15 3:26 am， "Barry Leiba" <[email-masked]<mailto:[email-masked]>> 写入:

OLD
SCIM Use Cases

NEW

END

Then for the abstract:

OLD

NEW

END

Barry

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 20 Mar 2015 14:44:00 +0000

It seems like much of this text is copied and changed slightly from the API doc.  Would it make sense to just link to section 7 of the API doc instead?

https://tools.ietf.org/html/draft-ietf-scim-api-16#section-7

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Morteza Ansari (moransar)
Sent: Thursday, March 19, 2015 12:04 PM
To: Kepeng Li; Barry Leiba; [email-masked]
Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04

Cheers,
Morteza

How about this:

OLD:

NEW:

   thus subject to the security considerations of HTTP Section 9<http://tools.ietf.org/html/rfc7230#section-9>

   schemes SHOULD be taken.

END

Thanks,

Kind Regards
Kepeng

OLD
SCIM Use Cases

NEW

END

Then for the abstract:

OLD

NEW

END

Barry

---

From: "Kepeng Li" <[email-masked]>
Date: Sun, 22 Mar 2015 03:32:48 +0800

>It seems like much of this text is copied and changed slightly from the API doc. Yes, but I just copied the general part, and the details are left in the API doc.As Barry mentioned: There are going to be details that'll be left to the schema and api documents -- details that have to do with the schema and api, of course. But this document could and should talk about the general security considerations for what SCIM is doing.I hope my copied texts have followed that guidance.>Would it make sense to just link to section 7 of the API doc instead?
I would prefer to keep some general texts in this document, and leave the details in the API spec.But I am open to other people's thoughts.Thanks,Kind RegardsKepeng------------------------------------------------------------------
发件人：Kelly Grizzle <[email-masked]>
发送时间：2015年3月20日(星期五) 22:44
收件人：Morteza Ansari (moransar) <[email-masked]>; 李克鹏(易深) <[email-masked]>; Barry Leiba <[email-masked]>; [email-masked] <[email-masked]>
主　题：Re: [scim] AD review of draft-ietf-scim-use-cases-04

font-family: Courier;panose-1: 2 7 4 9 2 2 5 2 4 4;font-family: SimSun;panose-1: 2 1 6 0 3 1 1 1 1 1;font-family: Cambria Math;panose-1: 2 4 5 3 5 4 6 3 2 4;font-family: Calibri;panose-1: 2 15 5 2 2 2 4 3 2 4;font-family: Tahoma;panose-1: 2 11 6 4 3 5 4 4 2 4;font-family: Consolas;panose-1: 2 11 6 9 2 2 4 3 2 4;font-family: \@SimSun;panose-1: 2 1 6 0 3 1 1 1 1 1;p.MsoNormal, li.MsoNormal, div.MsoNormal {margin: 0.0in;margin-bottom: 1.0E-4pt;font-size: 12.0pt;font-family: Times New Roman , serif;}
a:link, span.MsoHyperlink {mso-style-priority: 99;color: blue;text-decoration: underline;}
a:visited, span.MsoHyperlinkFollowed {mso-style-priority: 99;color: purple;text-decoration: underline;}
pre {mso-style-priority: 99;mso-style-link: HTML Preformatted Char;margin: 0.0in;margin-bottom: 1.0E-4pt;font-size: 10.0pt;font-family: Courier New;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority: 99;mso-style-link: Balloon Text Char;margin: 0.0in;margin-bottom: 1.0E-4pt;font-size: 8.0pt;font-family: Tahoma , sans-serif;}
span.HTMLPreformattedChar {mso-style-name: HTML Preformatted Char;mso-style-priority: 99;mso-style-link: HTML Preformatted;font-family: Consolas;}
span.EmailStyle19 {mso-style-type: personal-reply;font-family: Calibri , sans-serif;color: #1f497d;}
span.BalloonTextChar {mso-style-name: Balloon Text Char;mso-style-priority: 99;mso-style-link: Balloon Text;font-family: Tahoma , sans-serif;}
*.MsoChpDefault {mso-style-type: export-only;font-size: 10.0pt;}
size: 8.5in 11.0in;margin: 1.0in 1.0in 1.0in 1.0in;div.WordSection1 {page: WordSection1;}

 
--Kelly

From: scim [mailto:[email-masked]]
On Behalf Of Morteza Ansari (moransar)

 

 

Cheers,

Morteza

From:
Kepeng Li <[email-masked]>

To: "Barry org>" <[email-masked]>, "[email-masked]" <[email-masked]>

 

How about this:

OLD:

NEW:

   [RFC7230] and its related specifications.

   SCIM depends on standard HTTP authentication schemes. Implementers SHOULD support
   existing authentication/authorization schemes.  In particular, OAuth2
   (see [RFC6749], [RFC6750]) is RECOMMENDED.  Appropriate security
   considerations of the selected authentication and authorization
   schemes SHOULD be taken.  

   TLS version 1.0 [RFC5246] or TLS version 1.2 [RFC5246] can be chosen depending on
   recommendations outlines in Section 5.1.4.1 [RFC6819].    

END

 

 

Thanks,

Kind Regards

Kepeng

 

 

 

 

 

OLD

SCIM Use Cases

NEW

Overview, and Flows

END

 

Then for the abstract:

OLD

 

NEW

   and requirements.

END

 

 

Barry

scim mailing list

[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Sat, 21 Mar 2015 20:41:15 +0100

On 03/21/2015 08:32 PM, Kepeng Li wrote:
>>It seems like much of this text is copied and changed slightly from the
> API doc.
> 
> Yes, but I just copied the general part, and the details are left in the
> API doc.
> 
> As Barry mentioned: There are going to be details that'll be left to the
> schema and api documents -- details that have to do with the schema and
> api, of course. But this document could and should talk about the
> general security considerations for what SCIM is doing.
> 
> I hope my copied texts have followed that guidance.
> 
>>Would it make sense to just link to section 7 of the API doc instead?
> 
> I would prefer to keep some general texts in this document, and leave
> the details in the API spec.
> 
> But I am open to other people's thoughts.
> 

I don't think it matters that much what we do here and we should avoid
bikeshedding if we can...

---

From: Phil Hunt <[email-masked]>
Date: Sat, 21 Mar 2015 13:14:30 -0700

I don't have good network access at the moment (or I would check) but it might be good to double check for any editorial conflicts/sync issues between  documents. 

In the last couple of api and core-schema revs we made some subtle clarifications that I have not double checked against the use cases. 

Phil

> On Mar 21, 2015, at 12:41, Leif Johansson <[email-masked]> wrote:
>

---

From: Leif Johansson <[email-masked]>
Date: Sat, 21 Mar 2015 21:34:44 +0100

> In the last couple of api and core-schema revs we made some subtle clarifications that I have not double checked against the use cases. 

Can you review when you get bits?

---

From: Phil Hunt <[email-masked]>
Date: Sat, 21 Mar 2015 13:40:24 -0700

Phil

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Mar 2015 09:45:12 -0500

Leif,

I think the document is ok. One thing I wonder about is the emphasis on triggers. In reality, the SCIM specs simply specify protocol for CRUD operations without looking at the motivation (as the use case documents do) for why an operation would be invoked. The document does make this clear that the core specs:
> Triggers may not be relevant at the protocol or the schema,
>    they really serve to help identify the type or activity that resulted
>    in a SCIM protocol exchange.

That said, I note the new “Notify” drafts specify a way for formalize “triggers” that cause SCIM protocol commands to be issued.

In that sense, the document fits well including the new potential items the WG is considering.

Phil

@independentid
www.independentid.com
[email-masked]

> On Mar 21, 2015, at 3:34 PM, Leif Johansson <[email-masked]> wrote:
>

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Mar 2015 16:25:23 +0100

> In that sense, the document fits well including the new potential items the WG is considering.

Good!

Note that the point of the uc document is not for the WG to be governed
by the use-cases set down (we have the charter for that) but rather
that the WG (and future efforts in this area) be informed about what
use-cases were initial motivation for scim.

So discrepancies between the uc doc and future extensions of scim may
not necessarily be a problem per se - it may just be the natural way
the scim community evolves.