Subject: [scim] Cloud definition

From: Gene Golovinsky <[email-masked]>
Date: Thu, 29 Mar 2012 02:19:31 -0700

Cloud definition

Just following up on Dan’s request to outsource the definition of The Cloud
to other orgs.

NIST has done a pretty decent job of it:

*http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf*<http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf>

IMHO it is reasonably clear and accepted by many as an operating basis.

Cheers.

--Gene

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 29 Mar 2012 09:42:36 -0400

The NIST definition also has significant
buy-in among multiple other standards bodies.
There are, however, a few minor "deltas" for
clarity worth noting.

Other bodies have found "cloud service user"
to be preferable to "consumer" in the various
paragraphs.  "Consumer" is a term with a lot
of baggage and not defined in the NIST text.

Other bodies have found "cloud service
provider" to be preferable to "provider"
in the various paragraphs.  The term
"provider" by itself is ambiguous.

The term "appropriated" in "rapid elasticity"
has been generally replaced with "obtained."
"Appropriated" is a term with some undesirable
alternative meanings.

--tony

On 3/29/2012 5:19 AM, Gene Golovinsky wrote:
>
> Just following up on Dan's request to outsource the definition of The 
> Cloud to other orgs.
>
> _http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf_
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Mar 2012 15:49:32 +0200

As an individual (I have no hat to wear at this point), I would suggest
that focusing on the definition of cloud will not improve the SCIM protocol.

---

From: Gene Golovinsky <[email-masked]>
Date: Thu, 29 Mar 2012 06:57:53 -0700

I agree. My previous post was a mere attempt to show that "cloud" in our
world has reasonable definition and is accepted my many in the engineering
community.
No relation to SCIM, but rather to the BoF conversation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eliot Lear
Sent: Thursday, March 29, 2012 06:50 AM
To: [email-masked]
Subject: Re: [scim] Cloud definition

As an individual (I have no hat to wear at this point), I would suggest
that focusing on the definition of cloud will not improve the SCIM
protocol.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 29 Mar 2012 17:20:18 +0200

> that focusing on the definition of cloud will not improve the SCIM protocol.

Hm... a cloud is, by definition, fuzzy.  To talk about, say, "google cloud"
as neatly separated from all other clouds sounds unreal.  Avoiding
cloud-to-cloud data transfers and privacy questions is consistent with such
enterprise-oriented model.

IMHO, that model is lacks a somewhat wider perspective.  That's why I
dis-hummed this morning.

Regards

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Mar 2012 09:36:10 -0800

> No relation to SCIM, but rather to the BoF conversation.

I suppose, but I don't think that this is a "cloud"-specific project in
the first place and so definition of "cloud" is largely irrelevant,
anyway.

Melinda

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 29 Mar 2012 13:02:17 -0500

... if this is NOT cloud-specific ... then I am confused. What else could the context be, when there are specific cloud-related scenarios and non-other scenarios in scope?

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, March 29, 2012 1:36 PM
To: [email-masked]
Subject: Re: [scim] Cloud definition

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Mar 2012 10:27:16 -0800

On 3/29/12 10:02 AM, Brenner, Michael Ralf (Michael) wrote:
> ... if this is NOT cloud-specific ... then I am confused.
 > What else could the context be, when there are specific
 > cloud-related scenarios and non-other scenarios in scope?

I believe this might be the first time I've seen it suggested
that a particular technology has no applicability to stuff not
in a document, and I've been involved with the IETF a very long
time.  I suppose there might be something new under the sun,
after all.

At any rate, "cloud" vendors are by no means the only ones
dealing with identity provisioning problems.  At a prior gig
they're generating bulk updates out of their ERP and loading
them into an Oracle database, and from that they're generating
updates to a SQL database and LDIF for the LDAP directory.
(Software longa, hardware brevis).  Because each is run as a
batch job overnight it's 48 hours between the time a new person
is brought in and when their account is actually provisioned.
They've been trying to move to a SPML-based transactional
provisioning model but vendor support is poor.  I don't think
this situation is *that* unusual in large enterprisese.

Melinda

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 29 Mar 2012 13:57:39 -0500

Thanks Melinda.

Disclaimer: I have NOT been involved for a long time with IETF, other than in a IETF specs consumer role. But I have been involved for a long time as an active contributor to other standards bodies. Therefore, I hope to be excused if my thought process is quite different than the one used by long-time IETF active contributors.

Surely, any technology MAY apply to some domains that were not identified by the technology. However, it must be more important to deterministically make sure that the technology DOES apply to at least 1 particular domain?

Of course, "cloud" vendors or service providers are not the only ones faced with Identity Management provisioning and/or retrieving issues. But that was the entire point of me questioning the premise that the SCIM work is NOT cloud-specific. I agree that a technology may not necessarily be domain-specific, and may not even have to identify a single specific domain but I also think that this is only true once the technology is at a very low level of granularity (e.g. how best to package large amounts of data in a given size packet, or how to transmit the packet from one endpoint to another). That is not the case with IdM, IMO. Unless specific scenarios (cloud-related or otherwise) are used to focus the work, the technology developed will miss the target (which will be made easier by the fact that there is NO target). It will become a beautiful academic piece of work.

Note that I am not arguing for a specific definition of "cloud", but I am arguing for specific scenarios. If those scenarios happen to apply to other domains, great.

Michael

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Thursday, March 29, 2012 2:27 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Cloud definition

Melinda

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 29 Mar 2012 19:15:30 +0000

I agree ... And would note that sometimes the "academic piece[s] of work" are not even all that "beautiful"! :)

BB,
BobN

----- Original Message -----
From: Brenner, Michael Ralf (Michael) [mailto:[email-masked]]
Sent: Thursday, March 29, 2012 02:57 PM
To: Melinda Shore <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [scim] Cloud definition

Thanks Melinda.

Michael

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Thursday, March 29, 2012 2:27 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Cloud definition

Melinda

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 29 Mar 2012 19:45:48 +0000

I believe that this was mentioned at the BoF, but the charter calls for a use cases doc:

  draft-scim-use-cases-00 as the initial use cases for SCIM

SCIM has no ambitions to live in an ivory tower, and all of the existing work has leaned towards pragmatism.  There actually was a use cases doc developed outside of the IETF which may serve as a basis for the draft.

Regarding "cloud", I 100% agree that the identity management is not specific to the cloud (and as Pete put it today, that the cloud is a bit cloudy).  There are many scenarios that SCIM can help with, ranging from cloud-to-cloud, enterprise-to-cloud, and any combination of these.  The existing REST protocol is very cloud-friendly, though, and my feeling is that cloud providers are where much of the benefit will be seen initially.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Thursday, March 29, 2012 9:16 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: Re: [scim] Cloud definition

BB,
BobN

----- Original Message -----
From: Brenner, Michael Ralf (Michael) [mailto:[email-masked]]
Sent: Thursday, March 29, 2012 02:57 PM
To: Melinda Shore <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [scim] Cloud definition

Thanks Melinda.

Michael

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Thursday, March 29, 2012 2:27 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Cloud definition

On 3/29/12 10:02 AM, Brenner, Michael Ralf (Michael) wrote:
 > What else could the context be, when there are specific  > cloud-related scenarios and non-other scenarios in scope?

I believe this might be the first time I've seen it suggested that a particular technology has no applicability to stuff not in a document, and I've been involved with the IETF a very long time.  I suppose there might be something new under the sun, after all.

At any rate, "cloud" vendors are by no means the only ones dealing with identity provisioning problems.  At a prior gig they're generating bulk updates out of their ERP and loading them into an Oracle database, and from that they're generating updates to a SQL database and LDIF for the LDAP directory.
(Software longa, hardware brevis).  Because each is run as a batch job overnight it's 48 hours between the time a new person is brought in and when their account is actually provisioned.
They've been trying to move to a SPML-based transactional provisioning model but vendor support is poor.  I don't think this situation is *that* unusual in large enterprisese.

Melinda

---

From: Emmanuel dreux <[email-masked]>
Date: Thu, 29 Mar 2012 20:15:39 +0000

Hi,

As an IAM consultant for a long time, I can say that in on premise scenario, I do not need a universal provisioning protocol.
I'm using metadirectory products that read/write directly to LDAP, SQL databases, flat files, etc.

In SAAS / ASP scenario, it's different. 
I do not have access directly to the directory that contains the accounts (LDAP,SQL,etc).
The provider has to expose provisioning APIs that will allow me to programmatically and remotely manage accounts.

Today every SAAS provider creates his proprietary API exposed  for example through webservices or REST apis.
As an editor of a provisioning solution for Cloud based applications, each time we integrate a new SAAS provider, we have to learn his programming model and provisioning APIs.

This is where SCIM becomes useful and relevant by allowing to standardize the management of the accounts.
Tipically a SAAS issue because we do not have access natively to the repository (LDAP, SQL database, etc...).

--
Regards,
Emmanuel Dreux
http://www.bcpsoft.fr
Tel: +33 1 46 15 07 22
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Brenner, Michael Ralf (Michael) [mailto:[email-masked]] 
Envoyé : jeudi 29 mars 2012 20:58
À : Melinda Shore
Cc : [email-masked]
Objet : Re: [scim] Cloud definition

Thanks Melinda.

Michael

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Thursday, March 29, 2012 2:27 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]
Subject: Re: [scim] Cloud definition

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Mar 2012 12:21:01 -0800

On 3/29/12 12:15 PM, Emmanuel dreux wrote:
> In SAAS / ASP scenario, it's different. I do not have access directly
> to the directory that contains the accounts (LDAP,SQL,etc). The
> provider has to expose provisioning APIs that will allow me to
> programmatically and remotely manage accounts.

You run into exactly this sort of situation in very large enterprises,
where the people who run the ERP may not have write access to the
corporate directory or be able to provision accounts.  But even in
cases where they are there's a lot of interest in moving from a batching
model to a transactional one.

Melinda

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 30 Mar 2012 09:23:26 +0200

I´m new at IETF so I don´t know if I will offend someone with this
post, if so I´m sorry for that.

First I like the point that Michael does, just because it is aimed for
cloud services does not mean that it cannot be used for other things
too.

And further, SCIM is just a name in the end.

Cheers
//Samuel

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Mar 2012 09:30:47 +0200

> I´m new at IETF so I don´t know if I will offend someone with this

No, not 'tall.

 That's what I was getting at in the meeting, when I asked people not to
spin their wheels on the name right now.

But you have to understand the history.  We have had several attempts to
"standardize clouds", with rambling, unfocused, and unpopular results.
 That's caused IETF people to be sensitive to and skeptical of the "cloud"
word.  Apart from that, we generally prefer not to take something of more
general use and name it for a specific use case.  The name will be what
draws attention to the work, and people who would be important contributors
might be put off, confused, or simply not drawn in by a too-narrow name.

Barry, Applications AD

---

From: William Mills <[email-masked]>
Date: Fri, 30 Mar 2012 08:07:40 -0700 (PDT)

Annoyingly perhaps, naming matters in a branding way and how people think about things.  We can trivially get this much closer to what it actually does.  I personally like Push Identity Management Protocol (excepts it's not a protocol), so we could PIMP my cloud.

-bill

>________________________________
> From: Samuel Erdtman <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>; Emmanuel dreux <[email-masked]> 
>Sent: Friday, March 30, 2012 12:23 AM

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Fri, 30 Mar 2012 10:36:30 -0500

Well, you could still PIMP it by replacing Protocol with Provisioning (Push Identity Management Provisioning):)

Michael

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Friday, March 30, 2012 11:08 AM
To: Samuel Erdtman; Melinda Shore
Cc: [email-masked]; Emmanuel dreux
Subject: Re: [scim] Cloud definition

-bill

Cheers
//Samuel

On Thu, Mar 29, 2012 at 10:21 PM, Melinda Shore <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: William Mills <[email-masked]>
Date: Fri, 30 Mar 2012 08:48:06 -0700 (PDT)

Now THAT is chock full of awesome, with awesome sauce...

> From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
>To: William Mills <[email-masked]>; Samuel Erdtman <[email-masked]>; Melinda Shore <[email-masked]> 
>Sent: Friday, March 30, 2012 8:36 AM
>Subject: RE: [scim] Cloud definition
> 
>
>Well, you could still PIMP it by replacing Protocol with Provisioning (Push Identity Management Provisioning)J
> 
>Michael
> 
>From:[email-masked] [mailto:[email-masked]] On Behalf Of William Mills
>>From:Samuel Erdtman <[email-masked]>

---

From: Mahalingam Mani <[email-masked]>
Date: Fri, 30 Mar 2012 20:04:11 -0700

Very succinct problem statement. I wish this type of use-case was added to
the problem statement presentation made to the BoF. That would have likely
lessened the raining down on the cloud term while highlighting the
cloud-specific reason. That is not to say the resulting proposed solution
approach (of secondary importance to PS in BoF) cannot apply to narrower
deployments (large enterprise, pseudo multi-tenant, multitenanted contact
centers, etc); if anything those should derive as specific cases.

-mani
Sent from Droid
On Mar 29, 2012 1:15 PM, "Emmanuel dreux" <[email-masked]> wrote:

> Hi,
>
> As an IAM consultant for a long time, I can say that in on premise
> scenario, I do not need a universal provisioning protocol.
> The provider has to expose provisioning APIs that will allow me to
> As an editor of a provisioning solution for Cloud based applications, each
> time we integrate a new SAAS provider, we have to learn his programming
> model and provisioning APIs.
>
> Disclaimer: I have NOT been involved for a long time with IETF, other than
> in a IETF specs consumer role. But I have been involved for a long time as
> an active contributor to other standards bodies. Therefore, I hope to be
> excused if my thought process is quite different than the one used by
> long-time IETF active contributors.
>
> Surely, any technology MAY apply to some domains that were not identified
> by the technology. However, it must be more important to deterministically
> make sure that the technology DOES apply to at least 1 particular domain?
>
> Of course, "cloud" vendors or service providers are not the only ones
> faced with Identity Management provisioning and/or retrieving issues. But
> that was the entire point of me questioning the premise that the SCIM work
> is NOT cloud-specific. I agree that a technology may not necessarily be
> domain-specific, and may not even have to identify a single specific domain
> but I also think that this is only true once the technology is at a very
> low level of granularity (e.g. how best to package large amounts of data in
> a given size packet, or how to transmit the packet from one endpoint to
> another). That is not the case with IdM, IMO. Unless specific scenarios
> (cloud-related or otherwise) are used to focus the work, the technology
> developed will miss the target (which will be made easier by the fact that
> there is NO target). It will become a beautiful academic piece of work.
>
> Note that I am not arguing for a specific definition of "cloud", but I am
> arguing for specific scenarios. If those scenarios happen to apply to other
> domains, great.
>
> Michael
>
>  > What else could the context be, when there are specific  >
> I believe this might be the first time I've seen it suggested that a
> particular technology has no applicability to stuff not in a document, and
> I've been involved with the IETF a very long time.  I suppose there might
> be something new under the sun, after all.
>
> At any rate, "cloud" vendors are by no means the only ones dealing with
> identity provisioning problems.  At a prior gig they're generating bulk
> updates out of their ERP and loading them into an Oracle database, and from
> that they're generating updates to a SQL database and LDIF for the LDAP
> directory.
> (Software longa, hardware brevis).  Because each is run as a batch job
> overnight it's 48 hours between the time a new person is brought in and
> when their account is actually provisioned.
> They've been trying to move to a SPML-based transactional provisioning
> model but vendor support is poor.  I don't think this situation is *that*
> unusual in large enterprisese.
>
> Melinda
>
>

---

From: Per Hägerö <[email-masked]>
Date: Sat, 31 Mar 2012 06:50:29 +0000

Would be great to keep the word simple in there (look what happened to SMTP compared to X.400) so it could be SIM.

Per Hägerö  |  CTO
Nexus Group  |  www.nexussafe.com<http://www.nexussafe.com/>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - -
Office: +46 8 655 39 00  Mobile: +46 702 69 14 66
Email: [email-masked]<mailto:[email-masked]> Skype: hagero
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - -
Connect with Nexus
Twitter: @TechnologyNexus<http://www.twitter.com/technologynexus>
Facebook
<https://www.facebook.com/pages/Technology-Nexus/133756470003189>

<http://www.gartner.com/technology/summits/emea/identity-access/index.jsp><http://www.gartner.com/technology/summits/emea/identity-access/index.jsp>

<http://www.nexussafe.com/byodseminarium><http://www.nexussafe.com/byodseminarium>
<http://www.nexussafe.com/byodseminarium><http://www.nexussafe.com/byodseminarium>

http://www.nexussafe.com/byodseminarium
<http://www.nexussafe.com/byodseminarium>

30 mar 2012 kl. 17:36 skrev Brenner, Michael Ralf (Michael):

Michael

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf OfWilliam Mills
Sent: Friday, March 30, 2012 11:08 AM
To: Samuel Erdtman; Melinda Shore
Cc: [email-masked]<mailto:[email-masked]>; Emmanuel dreux
Subject: Re: [scim] Cloud definition

-bill

________________________________
From: Samuel Erdtman <[email-masked]<mailto:[email-masked]>>
To: Melinda Shore <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Emmanuel dreux <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 30, 2012 12:23 AM
Subject: Re: [scim] Cloud definition

Cheers
//Samuel