Subject: [scim] Feedback on the charter from IESG and IAB

From: Barry Leiba <[email-masked]>
Date: Fri, 11 May 2012 09:55:41 -0400

The first step in chartering is to get feedback from the IESG and IAB,
and I have the first few comments.  For the record, the attached
charter text is what's being commented on.

1. We should include intended document status in the milestones.  To
that end, I suggest this:

  06/2012    Initial adoption of SCIM use cases, as a living document
  06/2012    Initial adoption of SCIM core schema
  08/2012    Initial adoption of SCIM restful interface draft
| 12/2012    Snapshot version of SCIM use cases to IESG as
Informational (possibly)
  12/2012    Proposal for client targeting of SCIM endpoints
| 02/2013    SCIM core schema to IESG as Proposed Standard
| 05/2013    SCIM restful interface to IESG as Proposed Standard
  07/2013    Initial adoption of SCIM SAML bindings draft
  07/2013    Initial adoption of SCIM LDAP mapping draft
| 08/2013    Client targeting of SCIM endpoints to IESG as Proposed Standard
| 09/2013    Snapshot update of SCIM use cases as Informational (possibly)
| 11/2013    SCIM SAML bindings to IESG as Proposed Standard
| 12/2013    SCIM LDAP mapping to IESG as Proposed Standard
  01/2014    Work completed; discuss re-charter

Are those correct?  That is, everything is meant to be Proposed
Standard except for the use cases document (which might or might not
get published)?

2. There's concern about the "gaps" text in this part:

>  In addition, the working group will ensure that the SCIM protocol
>  embodies good security practices, and will document gaps in its
>  capabilities and propose a path forward for addressing those gaps.

What's that really meant to be saying?  That is, why shouldn't the
sentence simply end after "good security practices"?  We certainly
can't produce documents that *don't* use good security practices, so
if the rest of the sentence is important we have to separate it and
make it clear what we're getting at.

3. There's concern by more than one AD that doing the schema
definition without having the LDAP mapping there with it will result
in problems, and will end up with a new schema that ultimately has as
many problems as the existing one(s).  The best suggestion to deal
with that is to move the order around, do the LDAP mapping along with
the schema, and send both documents to the IESG together.

4. The name did come up (I told you...).  It's not getting in the way,
at least not yet, but folks are balking at both the "simple" and the
"cloud" parts.  They wonder if there isn't a way to keep "scim", but
to make up something new that it can stand for.  Keep in mind that
this is a minor point, though -- the other three above need to be
fixed.

Feedback to the feedback?

Barry

---

From: Pete Resnick <[email-masked]>
Date: Fri, 11 May 2012 12:00:35 -0500

> this is a minor point, though -- the other three above need to be

"Yet" has arrived. It is getting in the way. Here's more or less what I 
said to the IESG:

Having the word "simple" is just nonsense and I think it should go, but 
that's not my big concern.

Having the word "cloud" is flypaper for the loons to come out of the 
woodwork and disrupt this WG. There will obviously be engineering loons 
who will come to work on this thing simply because it is about "clouds" 
and try to get their cloud nonsense into the work. But there also will 
be press loons, and there will be otherwise normal people who end up 
pandering to the press loons. I think this will really do damage to the 
productivity of the WG.

(Others in the IESG are equally concerned about "Identity Management", 
in that we have lots of work on what people refer to as "Identity 
Management", but it normally involves protocols used to log in and log 
out, which is not what this is doing.)

The "name recognition" argument does nothing for me. Jabber survived 
just fine after it got called XMPP in the IETF. You can continue to call 
your management scheme "SCIM" in your own circles, but in the IETF it 
should have a name that doesn't carry baggage.

I am truly opposed to the current name. Come up with a new name. Please.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Melinda Shore <[email-masked]>
Date: Fri, 11 May 2012 09:18:23 -0800

> make it clear what we're getting at.

While we're kvetching about language I'm not a huge fan of the
phrase "gap analysis" but it's my understanding that that's
what's being talked about here.  That said, I'm still not sure
whether it's going to take the form of a few paragraphs in
the security considerations section of <whatever> document saying
"we don't do <xyz> and we need to address that" or something more
rigorous.  A gap analysis usually starts with a requirements
document and there isn't one here, but it may be worth taking a
look at the current document set, putting together a threat
analysis, which I think is not a huge job for scim, and using
that as a starting point.  I'd be happy to take that on.

> the schema, and send both documents to the IESG together.

I'm coming at this from the IETF side and haven't had any involvement
with scim prior to it being brought to the IETF, but there seems to
be more concern with SAML, which would face a similar problem.
I've started working on an implementation and it very quickly
became clear that this is almost certainly the most likely source
of incompatibilities/non-interoperability between implementations,
and I'd be good with seeing both the SAML and LDAP mappings being
folded into the schema document as appendices.

> this is a minor point, though -- the other three above need to be

It seems to me that including "provisioning" (or something similar)
in the protocol's name has the twin virtues of being accurate and
helping to distinguish from authentication/authorization protocols.
And yeah, definitely - "cloud" has got to go.  "Simple" would seem
to depend on what folks decide to do about element mappings (nyuk,
nyuk, nyuk).

Melinda

---

From: Michael Hammer <[email-masked]>
Date: Fri, 11 May 2012 17:39:54 +0000

Pete,

So, to summarize:

Simple is out
Cloud is out
Identity 
Management is out.

What was left?  :)
Do you have a proposal?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pete
Resnick
Sent: Friday, May 11, 2012 1:01 PM
To: Barry Leiba
Cc: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

> this is a minor point, though -- the other three above need to be 

"Yet" has arrived. It is getting in the way. Here's more or less what I said
to the IESG:

Having the word "cloud" is flypaper for the loons to come out of the
woodwork and disrupt this WG. There will obviously be engineering loons who
will come to work on this thing simply because it is about "clouds" 
and try to get their cloud nonsense into the work. But there also will be
press loons, and there will be otherwise normal people who end up pandering
to the press loons. I think this will really do damage to the productivity
of the WG.

(Others in the IESG are equally concerned about "Identity Management", in
that we have lots of work on what people refer to as "Identity Management",
but it normally involves protocols used to log in and log out, which is not
what this is doing.)

The "name recognition" argument does nothing for me. Jabber survived just
fine after it got called XMPP in the IETF. You can continue to call your
management scheme "SCIM" in your own circles, but in the IETF it should have
a name that doesn't carry baggage.

pr

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

---

From: Michael Hammer <[email-masked]>
Date: Fri, 11 May 2012 17:50:34 +0000

I would avoid the word simple too.
IETF has a SIMPLE WG already. :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Melinda Shore
Sent: Friday, May 11, 2012 1:18 PM
To: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

> make it clear what we're getting at.

While we're kvetching about language I'm not a huge fan of the phrase "gap
analysis" but it's my understanding that that's what's being talked about
here.  That said, I'm still not sure whether it's going to take the form of
a few paragraphs in the security considerations section of <whatever>
document saying "we don't do <xyz> and we need to address that" or something
more rigorous.  A gap analysis usually starts with a requirements document
and there isn't one here, but it may be worth taking a look at the current
document set, putting together a threat analysis, which I think is not a
huge job for scim, and using that as a starting point.  I'd be happy to take
that on.

> the schema, and send both documents to the IESG together.

I'm coming at this from the IETF side and haven't had any involvement with
scim prior to it being brought to the IETF, but there seems to be more
concern with SAML, which would face a similar problem.
I've started working on an implementation and it very quickly became clear
that this is almost certainly the most likely source of
incompatibilities/non-interoperability between implementations, and I'd be
good with seeing both the SAML and LDAP mappings being folded into the
schema document as appendices.

> this is a minor point, though -- the other three above need to be 

It seems to me that including "provisioning" (or something similar) in the
protocol's name has the twin virtues of being accurate and helping to
distinguish from authentication/authorization protocols.
And yeah, definitely - "cloud" has got to go.  "Simple" would seem to depend
on what folks decide to do about element mappings (nyuk, nyuk, nyuk).

Melinda

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Fri, 11 May 2012 13:00:15 -0500

IAPI: Identity Attributes Provisioning Interface

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Friday, May 11, 2012 1:51 PM
To: [email-masked]; [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Friday, May 11, 2012 1:18 PM
To: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

> make it clear what we're getting at.

While we're kvetching about language I'm not a huge fan of the phrase "gap analysis" but it's my understanding that that's what's being talked about here.  That said, I'm still not sure whether it's going to take the form of a few paragraphs in the security considerations section of <whatever> document saying "we don't do <xyz> and we need to address that" or something more rigorous.  A gap analysis usually starts with a requirements document and there isn't one here, but it may be worth taking a look at the current document set, putting together a threat analysis, which I think is not a huge job for scim, and using that as a starting point.  I'd be happy to take that on.

> the schema, and send both documents to the IESG together.

I'm coming at this from the IETF side and haven't had any involvement with scim prior to it being brought to the IETF, but there seems to be more concern with SAML, which would face a similar problem.
I've started working on an implementation and it very quickly became clear that this is almost certainly the most likely source of incompatibilities/non-interoperability between implementations, and I'd be good with seeing both the SAML and LDAP mappings being folded into the schema document as appendices.

> this is a minor point, though -- the other three above need to be 

It seems to me that including "provisioning" (or something similar) in the protocol's name has the twin virtues of being accurate and helping to distinguish from authentication/authorization protocols.
And yeah, definitely - "cloud" has got to go.  "Simple" would seem to depend on what folks decide to do about element mappings (nyuk, nyuk, nyuk).

Melinda

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Fri, 11 May 2012 13:01:14 -0500

I did not realize ... but at the same time it could stand for Identity API:-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Friday, May 11, 2012 1:51 PM
To: [email-masked]; [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Friday, May 11, 2012 1:18 PM
To: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Melinda

---

From: Michael Hammer <[email-masked]>
Date: Fri, 11 May 2012 18:03:39 +0000

Cool

-----Original Message-----
From: Brenner, Michael Ralf (Michael)
[mailto:[email-masked]] 
Sent: Friday, May 11, 2012 2:01 PM
To: Brenner, Michael Ralf (Michael); Michael Hammer;
[email-masked]; [email-masked]
Subject: RE: [scim] Feedback on the charter from IESG and IAB

I did not realize ... but at the same time it could stand for Identity
API:-)

-----Original Message-----
Brenner, Michael Ralf (Michael)

-----Original Message-----
Michael Hammer

Mike

-----Original Message-----

Melinda

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 11 May 2012 17:09:25 -0400

This has now become generic enough that CybOX could
be used at the interface.  It's just been added to
MAEC.

If you're not familiar with CybOX, check out
cybox.mitre.org
Identity attributes are ultimately nothing
more than observables.

--tony

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 11 May 2012 17:41:25 -0400

The loon has arrived to ask a (simple) question: What does "S" stand for 
in SNMP,?

(For the record, this very loon had always been on a megalomaniac side,  
as when insisting, successfully, that a WG designing a /simple/ media 
gateway protocol be called MEGACO. But simple is simple is simple.)

Igor the Loon

On 5/11/2012 1:00 PM, Pete Resnick wrote:
> "Yet" has arrived. It is getting in the way. Here's more or less what 
> I said to the IESG:
>
> Having the word "simple" is just nonsense and I think it should go, 
> but that's not my big concern.
>
> woodwork and disrupt this WG. There will obviously be engineering 
> loons who will come to work on this thing simply because it is about 
> "clouds" and try to get their cloud nonsense into the work. But there 
> also will be press loons, and there will be otherwise normal people 
> who end up pandering to the press loons. I think this will really do 
> damage to the productivity of the WG.
>
> just fine after it got called XMPP in the IETF. You can continue to 
> call your management scheme "SCIM" in your own circles, but in the 
> IETF it should have a name that doesn't carry baggage.
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 May 2012 14:43:08 -0700

I think we're talking about just renaming the project rather then starting all over.

I think RESTful and cross-domain are important aspects worth highlighting in the name.

Phil

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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 12 May 2012 00:03:12 +0100

Scalable Cross-domain Identity Migration?

---

From: Melinda Shore <[email-masked]>
Date: Fri, 11 May 2012 15:05:05 -0800

> Scalable Cross-domain Identity Migration?

Pretty sure "scalable" is not that much of an improvement over "simple."

Melinda

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 12 May 2012 00:09:05 +0100

> Pretty sure "scalable" is not that much of an improvement over "simple."

Yeah, nor would secure be. Whatever.

S

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 May 2012 16:10:40 -0700

Sophisticated.  Brings a new classy protocol to the IETF.  8-)

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 May 2012 16:12:53 -0700

Service-based Cross-domain Identity Migration

Ugh.

Phil

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

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Fri, 11 May 2012 18:45:15 -0500

No "service-based" in the charter text ...

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Friday, May 11, 2012 7:13 PM
To: Stephen Farrell
Cc: Melinda Shore; Brenner, Michael Ralf (Michael); [email-masked]; [email-masked]; Michael Hammer
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Ugh.

Phil

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

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Fri, 11 May 2012 18:46:53 -0500

RESTful Identity Migration: RIM ... is the coincidence an issue?

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Friday, May 11, 2012 7:13 PM
To: Stephen Farrell
Cc: Melinda Shore; Brenner, Michael Ralf (Michael); [email-masked]; [email-masked]; Michael Hammer
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Ugh.

Phil

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 11 May 2012 15:53:35 -0800

> RESTful Identity Migration: RIM ... is the coincidence an issue?

There's about 45 things wrong with that one.

I'm personally not a fan of cute IETF acronyms and tend to prefer
names that actually describe the thing being named.  RESTful
Identity Provisioning unfortunately shares an acronym with an
important existing protocol's name, but something like Interdomain
RESTful Identity Provisioning would get around that (there are
obvious problems with "Cross-domain RESTful Identity Provisioning").

At any rate there were some other bullet items in the feedback
from the IESG and IAB.

Melinda

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Fri, 11 May 2012 19:01:38 -0500

Nor am I for cute names, but IRIP sounds kind of morbid (and that's not much better than cute). Although it may catch fire with sci-fi fans.

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Friday, May 11, 2012 7:54 PM
To: Brenner, Michael Ralf (Michael)
Cc: Phil Hunt; Stephen Farrell; [email-masked]; Michael Hammer; [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 May 2012 22:48:30 -0600

> out, which is not what this is doing.)

Pete, I'm surprised that you didn't object to "identity", which as I
learned when working on RFC 6125 is awfully vague (it's much better to
talk about identifiers and attributes and such, not identity). By
contrast, (1) "simple" might be light on content but it I think it was
related to one purpose behind this initiative, which was to keep it
simple and not add undue complexity, (2) "cloud" hasn't brought out
loons yet so I don't see why we're worried about future loonies, and (3)
management seems like an apprpriate term for moving information from one
place to another.

> should have a name that doesn't carry baggage.

Having gone through the Jabber=>XMPP transition, I can tell you that ten
years later it *still* confuses people.

> I am truly opposed to the current name. Come up with a new name. Please.

Silly Changes for IESG Mandates? ;-)

Although I think the name was a Stupid Choice to Improve Marketing, it
doesn't seem actively harmful to me. Most people are just going to call
it "SCIM" anyway and won't even know what it stands for.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Sat, 12 May 2012 09:05:39 -0400

> At any rate there were some other bullet items in the feedback

Indeed, and I'd like to fix those up first.  How 'bout we say this?:

Everyone think about the naming thing, and/or sharpen your twibil for
when you see Pete in Vancouver... but *think* about it, letting it
roll around in the back of your mind.

In the front of your mind, and on the tips of your fingers, work on
sorting out the other three items I mentioned:

1. Confirm that I have the milestone changes right.

2. Explain the "gaps" stuff, and help fix up the text so it doesn't
give Stephen the willies.

3. Help resolve the point about how to handle the schema with respect
to potential problems with the LDAP mapping (and maybe the SAML
profile as well).

Barry

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 May 2012 08:19:33 +0200

Dear Barry,

I wanted to comment on your substantial issues 2 and 3:

> make it clear what we're getting at.

+1.  Let's just drop the text after practices.

> the schema, and send both documents to the IESG together.

+1, although I find the interoperability risk in this case low.  My
logic is that there are at leastnine implementations already in
development.  In addition, this is sort of what PS is meant to kink out.

Eliot

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 14 May 2012 02:47:20 -0500

Comments inline:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Leiba
Sent: Friday, May 11, 2012 6:56 AM
To: [email-masked]
Subject: [scim] Feedback on the charter from IESG and IAB

The first step in chartering is to get feedback from the IESG and IAB,
and I have the first few comments.  For the record, the attached charter
text is what's being commented on.

| 08/2013    Client targeting of SCIM endpoints to IESG as Proposed
Standard
| 09/2013    Snapshot update of SCIM use cases as Informational
(possibly)

Are those correct?  That is, everything is meant to be Proposed Standard
except for the use cases document (which might or might not get
published)?

MA> I was thinking LDAP mapping would be informational as there are many
variations of identity schema in LDAP directories and this would only be
an instantiation of such mapping. However if others think this should be
proposed standard, I am fine with it.

What's that really meant to be saying?  That is, why shouldn't the
sentence simply end after "good security practices"?  We certainly can't
produce documents that *don't* use good security practices, so if the
rest of the sentence is important we have to separate it and make it
clear what we're getting at.

MA> I think this is a side effect of tweaking the original paragraph
over 9 revision and an unintentional use of gap in the context of
"security practices". I originally put the "functional gap" in the
charter as we are starting  with a list of protocol/schema extensions
some of the vendors were interested in, but we felt need additional
discussion and thinking so we left them out of 1.0 specs. The goal of
this original sentence was that the WG will review this list of gaps and
decide what to do with them. This had nothing to do with security.
Unfortunately between version 8 and 9, this was changed in addition to
"functional gaps" we ended up with "gap" in the new paragraph covering
security.  I am perfectly find removing it and making it more clear.

3. There's concern by more than one AD that doing the schema definition
without having the LDAP mapping there with it will result in problems,
and will end up with a new schema that ultimately has as many problems
as the existing one(s).  The best suggestion to deal with that is to
move the order around, do the LDAP mapping along with the schema, and
send both documents to the IESG together.

MA> I am fine with that change.

4. The name did come up (I told you...).  It's not getting in the way,
at least not yet, but folks are balking at both the "simple" and the
"cloud" parts.  They wonder if there isn't a way to keep "scim", but to
make up something new that it can stand for.  Keep in mind that this is
a minor point, though -- the other three above need to be fixed.

MA> Personally speaking, I still think we should stick with SCIM. If the
current traction of SCIM v1 is any indication, by the time v2 is out
there will be quite a few implementations of it out there and we will
have many implementations (we are almost at 10 now). A rename between v1
and v2 will only result in confusion and 10 years from now we will be
using both SCIM and new name to refer to it. It is not worth it
especially if you consider other protocol names that have "simple" in
the name (including IETF protocols). If we *really* must change
something, let's stay with SCIM and change "cloud" which is the only
word there is no precedence for something else like "cross-domain"
Stephen suggested.

Cheers,
Morteza

---

From: Phil Hunt <[email-masked]>
Date: Mon, 14 May 2012 06:32:38 -0700

Unfortunately, no draft proposal for the LDAP Mapping has been submitted to IETF for consideration.  So it is not clear to me what the objective of an LDAP mapping draft is -- though I can guess based on the name.

As Morteza points out, many LDAP variations are possible and I agree, very likely given the suggested architecture in the SCIM scenarios. 

Is the LDAP mapping draft limited to specifying how complex attributes are handled?  Or does it cover more? What is the interop issue being solved?

I'm not saying I'm against it, but I can't comment without seeing more about it.

The same is true for the SAML binding (no draft).  Though I can guess more clearly the scope of such a binding.

Phil

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

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 14 May 2012 13:35:06 +0000

+1 on removing the "gaps" text.

+1 on at least keeping the SCIM acronym.  To Peter's point, as an outsider I had heard of both Jabber and XMPP, but until recently had no idea that the two were the same.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, May 14, 2012 2:47 AM
To: Barry Leiba; [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Comments inline:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, May 11, 2012 6:56 AM
To: [email-masked]
Subject: [scim] Feedback on the charter from IESG and IAB

The first step in chartering is to get feedback from the IESG and IAB, and I have the first few comments.  For the record, the attached charter text is what's being commented on.

1. We should include intended document status in the milestones.  To that end, I suggest this:

Are those correct?  That is, everything is meant to be Proposed Standard except for the use cases document (which might or might not get published)?

MA> I was thinking LDAP mapping would be informational as there are many
variations of identity schema in LDAP directories and this would only be an instantiation of such mapping. However if others think this should be proposed standard, I am fine with it.

> capabilities and propose a path forward for addressing those gaps.

What's that really meant to be saying?  That is, why shouldn't the sentence simply end after "good security practices"?  We certainly can't produce documents that *don't* use good security practices, so if the rest of the sentence is important we have to separate it and make it clear what we're getting at.

MA> I think this is a side effect of tweaking the original paragraph
over 9 revision and an unintentional use of gap in the context of "security practices". I originally put the "functional gap" in the charter as we are starting  with a list of protocol/schema extensions some of the vendors were interested in, but we felt need additional discussion and thinking so we left them out of 1.0 specs. The goal of this original sentence was that the WG will review this list of gaps and decide what to do with them. This had nothing to do with security.
Unfortunately between version 8 and 9, this was changed in addition to "functional gaps" we ended up with "gap" in the new paragraph covering security.  I am perfectly find removing it and making it more clear.

3. There's concern by more than one AD that doing the schema definition without having the LDAP mapping there with it will result in problems, and will end up with a new schema that ultimately has as many problems as the existing one(s).  The best suggestion to deal with that is to move the order around, do the LDAP mapping along with the schema, and send both documents to the IESG together.

4. The name did come up (I told you...).  It's not getting in the way, at least not yet, but folks are balking at both the "simple" and the "cloud" parts.  They wonder if there isn't a way to keep "scim", but to make up something new that it can stand for.  Keep in mind that this is a minor point, though -- the other three above need to be fixed.

MA> Personally speaking, I still think we should stick with SCIM. If the
current traction of SCIM v1 is any indication, by the time v2 is out there will be quite a few implementations of it out there and we will have many implementations (we are almost at 10 now). A rename between v1 and v2 will only result in confusion and 10 years from now we will be using both SCIM and new name to refer to it. It is not worth it especially if you consider other protocol names that have "simple" in the name (including IETF protocols). If we *really* must change something, let's stay with SCIM and change "cloud" which is the only word there is no precedence for something else like "cross-domain"
Stephen suggested.

Cheers,
Morteza

---

From: Chris Phillips <[email-masked]>
Date: Mon, 14 May 2012 10:25:46 -0400

+1 to clarifying the gap portion as Morteza offers
 
Working on the LDAP & SAML mapping pieces, there are some interesting
places this could go (e.g. How much of a SCIM transaction should be
encapsulated within a SAML based trust environment instead of over HTTP
with TLS or HTTP+OAUTH? Are the security challenges the same or different
for how SCIM reaches the endpoints? what security challenges should be
commented on/folded into the spec?  Those are the topics I see being
fleshed out more deeply as the conversation continues.

+1 to keeping the SCIM name/acronym.
  
The longevity of the original name will persist for years as others have
pointed out and is confusing as people try to find the right information
about the topic. 
Jabber as XMPP is one, and another I have been observing is Project
Moonshot but known as ABFAB in the IETF, which is hard to understand
looking from the outside in as to  why this was done.

I would put forth that existing implementations already out there have
some public mindshare in the provisioning space. This attention benefits
both  'brands', SCIM, AND the IETF as being seen in the public eye as
involved.  Keeping the name will fortify it, changing the name will be a
less fortified position and still have some confusion in the environment.

To the question about LDAP mappings:

While there are a number of LDAP variations out there, many schemas
descend from inetOrgPerson and extend from there. This is the starting
point for the mappings.
 Stumbling blocks have always been 'what to do with complex objects?' for
LDAP (and anything else actually).
The high fidelity SCIM schema is great for SCIM-to-SCIM endpoints to
preserve data exchange regardless of what your data model is, but it is
expected that the SCIM high fidelity schema will be transformed to a lower
fidelity one depending on the endpoint's capabilities(e.g. LDAP).
Recommending ways to do it will benefit adopters everywhere breeding
consistency of mappings, leveraging existing schemas in production, and
allow implementers to focus on their data, not how to get it from point A
to point B.

Chris.

---

From: William Mills <[email-masked]>
Date: Mon, 14 May 2012 10:05:45 -0700 (PDT)

On naming persistency, I'll add TLS and SSL...

>________________________________
> From: Kelly Grizzle <[email-masked]>
>To: Morteza Ansari (moransar) <[email-masked]>; Barry Leiba <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, May 14, 2012 6:35 AM

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 May 2012 13:40:24 -0400

> On naming persistency, I'll add TLS and SSL...

Insufficient information to be useful.

Are you mentioning this by way of support for NOT renaming, or as an
example of why it doesn't matter.  Some explanation would be helpful.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 May 2012 11:55:52 -0600

> allow implementers to focus on their data, not how to get it from point A

If the SCIM WG (if formed) decides to pursue another approach to the
schema representation, e.g. vCard4, then we might be able to work
together with other folks on the LDAP mapping (I know that a mapping
between LDAP and vCard4 was under consideration in the VCARDDAV WG).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alan Sill <[email-masked]>
Date: Mon, 14 May 2012 13:01:57 -0500

I can't resist an entry into the naming sweepstakes - as it is my personal belief that the naming *should* stand for something substantial and provide a summary for those looking to understand things further.

SChemas for Identity Management Atrtibutes -- SCIMA

(It even sounds right when pronounced!)

Alan

---

From: Melinda Shore <[email-masked]>
Date: Mon, 14 May 2012 10:12:02 -0800

> +1.  Let's just drop the text after practices.

"In addition, the working group will ensure that the SCIM protocol
embodies good security practices" struck me as awfully thin so I
took a look at several other charters and it seems consistent with
those, so this is probably good for the purpose of getting the
charter approved.

> +1, although I find the interoperability risk in this case low.

Having been through an attempted SPML deployment I think the
risk is potentially considerable.  As I mentioned earlier I
think an appendix with a proposed LDAP mapping is probably a
good, useful thing, with the mapping not necessarily needing to
be normative.

Melinda

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 14 May 2012 14:19:58 -0400

If the mapping is informative, how can it effect interoperability?

(I am neither +1 nor -1 on this; I am just trying to understand.)

Igor

On 5/14/2012 2:12 PM, Melinda Shore wrote:
> ...

---

From: Melinda Shore <[email-masked]>
Date: Mon, 14 May 2012 10:39:34 -0800

> If the mapping is informative, how can it effect interoperability?

That's a fair question and I'm going to be candid, here:

1) getting informative text through is a lot easier than getting
    normative text through, and I think we need to allow for a fair
    amount of flexibility here, anyway
2) a complete mapping of inetOrgPerson will be difficult, for
    reasons discussed here previously
3) implementers, frankly, tend not to distinguish between normative
    and informational text, anyway.  They generally implement what's
    recommended but I don't think we want to say that an implementation
    that doesn't strictly conform to the suggested mapping is broken.

i.e. mostly for political reasons.

Melinda

---

From: William Mills <[email-masked]>
Date: Mon, 14 May 2012 11:43:35 -0700 (PDT)

Ah, that the common usage for many is still "SSL", and that "TLS" will still get you a "you mean SSL right?"

> From: Barry Leiba <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Monday, May 14, 2012 10:40 AM

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 May 2012 14:49:53 -0400

> get you a "you mean SSL right?"

And does that mean that you think we should NOT rename "SCIM", are you
just making a neutral comment, or something else?

Barry

---

From: William Mills <[email-masked]>
Date: Mon, 14 May 2012 12:06:15 -0700 (PDT)

I am agreeing that name changes are hard.  At this point I'd almost suggest pulling the "RFC" naming trick, SCIM can be a brand name that no longer means what it used to.  Trying to find a name that matches the acronym, while amusing, is perhaps pointless.  I'll take my go now though with "SyndiCated Identity Management".

>Sent: Monday, May 14, 2012 11:49 AM

---

From: Phil Hunt <[email-masked]>
Date: Mon, 14 May 2012 13:20:08 -0700

Please keep the SCIM name as it is.  

I agree, XMPP/Jabber, TLS/SSL are all examples of serious confusion caused by IETF renaming. 

IMHO it is important to see the WG formed before the Vancouver meeting. Let's focus on the other issues and get them resolved now.

Phil

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

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 14 May 2012 16:34:52 -0400

+1 on both proposals.

Igor

On 5/14/2012 4:20 PM, Phil Hunt wrote:
> IMHO it is important to see the WG formed before the Vancouver 
> meeting. Let's focus on the other issues and get them resolved now.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> I am agreeing that name changes are hard.  At this point I'd almost 
>> suggest pulling the "RFC" naming trick, SCIM can be a brand name that 
>> no longer means what it used to.  Trying to find a name that matches 
>> the acronym, while amusing, is perhaps pointless.  I'll take my go 
>> now though with "SyndiCated Identity Management".
>>
>>     ------------------------------------------------------------------------
>>     *From:* Barry Leiba <[email-masked]
>>     <mailto:[email-masked]>>
>>     *To:* William Mills <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* "[email-masked] <mailto:[email-masked]>" <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Sent:* Monday, May 14, 2012 11:49 AM
>>     *Subject:* Re: [scim] Feedback on the charter from IESG and IAB
>>
>>     > Ah, that the common usage for many is still "SSL", and that
>>     "TLS" will still
>>     > get you a "you mean SSL right?"
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Mon, 14 May 2012 16:34:33 -0500

+1, looks like keeping the name can be justified.

From: Igor Faynberg [mailto:[email-masked]]
Sent: Monday, May 14, 2012 03:34 PM
To: [email-masked] <[email-masked]>
Subject: Re: [scim] Feedback on the charter from IESG and IAB

+1 on both proposals.

Igor

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

________________________________
From: Barry Leiba <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, May 14, 2012 11:49 AM
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Barry

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

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

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 14 May 2012 17:08:46 -0500

Given this is new work it is hard to define what the mapping document
will contain.  However, my thinking was that it describes how one would
map between inetOrgPerson and SCIM schema.

Given this mapping is provided more for informational purposes and also
the fact RFC 2798 itself is an informational RFC, I had assumed the
mapping document will be informational.  Does anyone think otherwise and
this should be a proposed standard?

Cheers,
Morteza

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Monday, May 14, 2012 6:33 AM
To: Morteza Ansari (moransar)
Cc: Barry Leiba; [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Unfortunately, no draft proposal for the LDAP Mapping has been submitted
to IETF for consideration.  So it is not clear to me what the objective
of an LDAP mapping draft is -- though I can guess based on the name.

As Morteza points out, many LDAP variations are possible and I agree,
very likely given the suggested architecture in the SCIM scenarios. 

Is the LDAP mapping draft limited to specifying how complex attributes
are handled?  Or does it cover more? What is the interop issue being
solved?

I'm not saying I'm against it, but I can't comment without seeing more
about it.

The same is true for the SAML binding (no draft).  Though I can guess
more clearly the scope of such a binding.

Phil

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

> MA> I was thinking LDAP mapping would be informational as there are 
> MA> many
> variations of identity schema in LDAP directories and this would only 
> be an instantiation of such mapping. However if others think this 
> should be proposed standard, I am fine with it.
> 
> this original sentence was that the WG will review this list of gaps 
> and decide what to do with them. This had nothing to do with security.

fixed.
> 
> MA> Personally speaking, I still think we should stick with SCIM. If 
> MA> the
> have many implementations (we are almost at 10 now). A rename between 
> v1 and v2 will only result in confusion and 10 years from now we will 
> be using both SCIM and new name to refer to it. It is not worth it

---

From: Phil Hunt <[email-masked]>
Date: Mon, 14 May 2012 16:28:18 -0700

I think it is worth having the SCIM LDAP Mapping proposal submitted as a draft so it can be discussed more broadly in the IETF.

You may be right - it only needs to be informational from a the proposed SCIM WG charter perspective. However, it might be that another WG should take the proposal on -- especially the issue of evolving LDAP to support complex attributes. In the LDAP perspective, inter-operability becomes a potential issue.

Phil

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 May 2012 19:10:18 -0600

It seems informational to me.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 May 2012 11:46:40 -0400

> It seems informational to me.

OK, so I have done the following in my copy of the charter:

- Changed the milestones as I noted above, but made the LDAP one
Informational (I presume the SAML bindings doc will still be PS).

- Removed the "gaps" part of the sentence about good security practices.

Shall I also move the LDAP milestone, and/or put text into the charter
that LDAP mapping(s) will be developed alongside the schema
definition?  Someone want to be specific about what text to change to
make this work in the charter?

Barry

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 17 May 2012 01:23:01 -0500

Barry,

How about this (if you give me your changes, I can roll them in or you
can apply these changes to your version):

*** charter9.txt	2012-04-30 06:56:43.000000000 -0700
--- charter10.txt	2012-05-16 23:20:14.000000000 -0700
***************
*** 42,50 ****
  - schema discovery
  - read and search
  - bulk operations
  It will follow that by considering extensions for client targeting of
! specific SCIM endpoints, SAML binding, and LDAP mapping.  The approach
! will be extensible.
  
  The group will use, as starting points, the following drafts in the
  following ways:
--- 42,51 ----
  - schema discovery
  - read and search
  - bulk operations
+ - mapping between inetOrgPerson (RFC2798) and SCIM schema
  It will follow that by considering extensions for client targeting of
! specific SCIM endpoints and SAML binding.  The approach will be
! extensible.
  
  The group will use, as starting points, the following drafts in the
  following ways:
***************
*** 60,69 ****
  including the OASIS Provisioning TC.
  
  The group will produce Proposed Standards for a schema, a REST-based
! protocol, a SAML binding, and an LDAP mapping.  In doing so, the group
! will make the terminology consistent, identify any functional gaps
! that would be useful for future work, address internationalization,
! and provide guidelines and mechanisms for extensibility.
  
  In addition, the working group will ensure that the SCIM protocol
  embodies good security practices, and will document gaps in its
--- 61,71 ----
  including the OASIS Provisioning TC.
  
  The group will produce Proposed Standards for a schema, a REST-based
! protocol, a SAML binding, and an LDAP mapping Informational document.
! In doing so, the group will make the terminology consistent, identify
! any functional gaps that would be useful for future work, address
! internationalization, and provide guidelines and mechanisms for
! extensibility.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Leiba
Sent: Tuesday, May 15, 2012 8:47 AM
To: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Shall I also move the LDAP milestone, and/or put text into the charter
that LDAP mapping(s) will be developed alongside the schema definition?
Someone want to be specific about what text to change to make this work
in the charter?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 May 2012 10:47:02 -0400

> can apply these changes to your version):

That looks good, and attached is the next draft version that includes
these changes (with some text tweaks from me).

The only question left before I send this version in and schedule it
for the telechat is whether we want to move the LDAP milestone dates.
Right now, the initial adoption of a draft for the LDAP mapping is 5
months after the completion of the SCIM schema.  I suggest pulling
that back significantly, perhaps thus:

OLD
  12/2012    Proposal for client targeting of SCIM endpoints
  02/2013    SCIM core schema to IESG as Proposed Standard
  05/2013    SCIM restful interface to IESG as Proposed Standard
  07/2013    Initial adoption of SCIM SAML bindings draft
| 07/2013    Initial adoption of SCIM LDAP inetOrgPerson mapping draft
  08/2013    Client targeting of SCIM endpoints to IESG as Proposed Standard
  09/2013    Snapshot update of SCIM use cases as Informational (possibly)
  11/2013    SCIM SAML bindings to IESG as Proposed Standard
| 12/2013    SCIM LDAP inetOrgPerson mapping to IESG as Informational
  01/2014    Work completed; discuss re-charter

NEW
  12/2012    Proposal for client targeting of SCIM endpoints
| 01/2013    Initial adoption of SCIM LDAP inetOrgPerson mapping draft
  02/2013    SCIM core schema to IESG as Proposed Standard
  05/2013    SCIM restful interface to IESG as Proposed Standard
| 06/2013    SCIM LDAP inetOrgPerson mapping to IESG as Informational
  07/2013    Initial adoption of SCIM SAML bindings draft
  08/2013    Client targeting of SCIM endpoints to IESG as Proposed Standard
  09/2013    Snapshot update of SCIM use cases as Informational (possibly)
  11/2013    SCIM SAML bindings to IESG as Proposed Standard
  01/2014    Work completed; discuss re-charter

Does that work?  I should get the update in today in order to put it
on next week's telechat.

Barry

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 17 May 2012 16:53:17 -0500

Looks good to me.

Cheers,
Morteza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Leiba
Sent: Thursday, May 17, 2012 7:47 AM
To: Morteza Ansari (moransar)
Cc: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

The only question left before I send this version in and schedule it for
the telechat is whether we want to move the LDAP milestone dates.
Right now, the initial adoption of a draft for the LDAP mapping is 5
months after the completion of the SCIM schema.  I suggest pulling that
back significantly, perhaps thus:

OLD
  08/2013    Client targeting of SCIM endpoints to IESG as Proposed
  09/2013    Snapshot update of SCIM use cases as Informational

NEW
  08/2013    Client targeting of SCIM endpoints to IESG as Proposed
  09/2013    Snapshot update of SCIM use cases as Informational

Does that work?  I should get the update in today in order to put it on
next week's telechat.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 May 2012 14:15:31 -0400

I have good news and bad news from the IESG telechat today.

The good news is that the IESG is happy with the charter.  The only
change they asked for was a one-word addition to make it clear that
"authorization" will also be included in the security bit:

OLD
  In addition, the working group will ensure that the SCIM protocol
  embodies good security practices. Given both the sensitivity of the
  information being conveyed in SCIM messages and the regulatory
  requirements regarding the privacy of personally identifiable
  information, the working group will pay particular attention to issues
| around authenticity and privacy.

NEW
  In addition, the working group will ensure that the SCIM protocol
  embodies good security practices. Given both the sensitivity of the
  information being conveyed in SCIM messages and the regulatory
  requirements regarding the privacy of personally identifiable
  information, the working group will pay particular attention to issues
| around authorization, authenticity, and privacy.

The bad news is on the name, "SCIM": that dog will not hunt.  It's not
just Pete, who fought it on this list: at least three other ADs want
the name changed before we can approve the charter for external
review.

The IESG is working on an alternative name -- one that was suggested
was "Inter-Domain User Identity Management", giving a working group
acronym of "iduim".

This group can, of course, propose other names... in the end, the IESG
will pick the name, though it would be nice to have agreement from the
community.  But here's the thing:
- Give up on "simple".  There've been too many protocols with that in
the name, and none of them are.
- Give up on "cloud".  This will certainly be used by cloud providers,
but is not specific to that use, and the name "cloud" carries too much
baggage and too many other assumptions.
- "Identity management" by itself is a broader topic than what we're
talking about here.  "User identity management" might work (see the
suggestion above), as might other formulations you may come up with.

Barry

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 May 2012 10:26:58 -0800

Barry Leiba wrote:
> The bad news is on the name, "SCIM": that dog will not hunt.  

*GOOD*.

> was "Inter-Domain User Identity Management", giving a working group

I'd drop "user" and switch "management" to "provisioning."

I hope the days of cute, tortured working group names are
over.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 May 2012 12:29:24 -0600

> I hope the days of cute, tortured working group names are

Inter Domain Identity Operation Tools is catchy.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 May 2012 10:31:41 -0800

> Inter Domain Identity Operation Tools is catchy.

Okay, that one I can live with.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 May 2012 20:35:18 +0200

Barry,

I'm sorry but arguing over a name is not something that should be done
by the IESG.  It impacts the wire not one little bit, and it's
disrespectful to those who brought the work into the IETF.  It also
wastes the time of many people diverting them from what I'm sure we'd
all prefer them to work on- things that DO effect the wire.  Honestly,
can't we PLEASE move along?

Eliot

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 May 2012 11:38:02 -0700

Peter,

You are joking yes?

Phil

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 May 2012 12:56:33 -0600

> You are joking yes?

Just trying to inject a little levity.

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 24 May 2012 14:07:53 -0500

Why can't we keep SCIM and have it stand for Schema for Cross-domain Identity Management?
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Thursday, May 24, 2012 2:35 PM
To: Barry Leiba
Cc: [email-masked]; 'IESG'
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Barry,

Eliot

---

From: Alan Sill <[email-masked]>
Date: Thu, 24 May 2012 14:12:03 -0500

+1

Alan

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 May 2012 15:18:12 -0400

> Just trying to inject a little levity.

I will point out that in the discussions that eventually led to MARF,
the Mail Abuse Reporting Format WG, one suggestion had been "Basic
Abuse Reporting Format".

b

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 May 2012 19:18:25 +0000

MIROR - Management of Identities and identity-Related Objects across administrative Realms

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, May 24, 2012 11:16 AM
To: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

The good news is that the IESG is happy with the charter.  The only change they asked for was a one-word addition to make it clear that "authorization" will also be included in the security bit:

OLD

NEW

The bad news is on the name, "SCIM": that dog will not hunt.  It's not just Pete, who fought it on this list: at least three other ADs want the name changed before we can approve the charter for external review.

The IESG is working on an alternative name -- one that was suggested was "Inter-Domain User Identity Management", giving a working group acronym of "iduim".

This group can, of course, propose other names... in the end, the IESG will pick the name, though it would be nice to have agreement from the community.  But here's the thing:
- Give up on "simple".  There've been too many protocols with that in the name, and none of them are.
- Give up on "cloud".  This will certainly be used by cloud providers, but is not specific to that use, and the name "cloud" carries too much baggage and too many other assumptions.
- "Identity management" by itself is a broader topic than what we're talking about here.  "User identity management" might work (see the suggestion above), as might other formulations you may come up with.

Barry

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 May 2012 21:25:06 +0200

+1 if it moves us along!

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 24 May 2012 14:30:19 -0500

Why would it not? I understand the opposition came from the "simple" and "cloud", which with this proposal are no longer part of the acronym.

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 3:25 PM
To: Alan Sill
Cc: Brenner, Michael Ralf (Michael); Barry Leiba; [email-masked]; 'IESG'
Subject: Re: [scim] Feedback on the charter from IESG and IAB

+1 if it moves us along!

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 24 May 2012 19:33:45 +0000

-1 for "Schema".  The SCIM spec currently contains a schema and a protocol (ie - the REST API).  Using "schema" in the name seems to imply that the only concern is with the schema.

--Kelly

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 3:25 PM
To: Alan Sill
Cc: Brenner, Michael Ralf (Michael); Barry Leiba; [email-masked]; 'IESG'
Subject: Re: [scim] Feedback on the charter from IESG and IAB

+1 if it moves us along!

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 24 May 2012 14:45:31 -0500

Maybe we can convince IESG to get over the "Simple" if we drop the "cloud" (Simple Cross-domain Identity Management), if we are keen on keeping SCIM.

-----Original Message-----
From: Kelly Grizzle [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 3:34 PM
To: Brenner, Michael Ralf (Michael); Eliot Lear; Alan Sill
Cc: [email-masked]; Barry Leiba; 'IESG'
Subject: RE: [scim] Feedback on the charter from IESG and IAB

--Kelly

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 3:25 PM
To: Alan Sill
Cc: Brenner, Michael Ralf (Michael); Barry Leiba; [email-masked]; 'IESG'
Subject: Re: [scim] Feedback on the charter from IESG and IAB

+1 if it moves us along!

---

From: Alan Sill <[email-masked]>
Date: Thu, 24 May 2012 15:17:56 -0500

That would be OK, too.

Alan

On May 24, 2012, at 2:45 PM, Brenner, Michael Ralf (Michael) wrote:

> Maybe we can convince IESG to get over the "Simple" if we drop the  
> "cloud" (Simple Cross-domain Identity Management), if we are keen on  
> keeping SCIM.

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 24 May 2012 15:20:50 -0500

Secure Cross-domain Identity Management may get us past this hurdle...

-----Original Message-----
From: Alan Sill [mailto:[email-masked]] 
Sent: Thursday, May 24, 2012 4:18 PM
To: Brenner, Michael Ralf (Michael)
Cc: Alan Sill; Kelly Grizzle; Eliot Lear; [email-masked]; Barry Leiba; 'IESG'
Subject: Re: [scim] Feedback on the charter from IESG and IAB

That would be OK, too.

Alan

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 May 2012 14:24:50 -0600

> Secure Cross-domain Identity Management may get us past this hurdle...

WFM. [1]

/psa

[1] But not necessarily for others. No matter what you come up with,
someone will complain...

"Secure?! You're just asserting that it's secure?!"
"Domain?! But this isn't about DNS!"
"Identity?! Don't you know that's a hopeless vague term?"
"Management?! You're not actually managing this information!"

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 24 May 2012 15:35:27 -0500

If no name would be irefutable, (levity says) we should call it UPS (Un-named Protocol and Schema).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, May 24, 2012 4:25 PM
To: Brenner, Michael Ralf (Michael)
Cc: [email-masked]; Barry Leiba; Eliot Lear; Alan Sill; Kelly Grizzle
Subject: Re: [scim] Feedback on the charter from IESG and IAB

WFM. [1]

/psa

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 May 2012 12:35:42 -0800

> Secure Cross-domain Identity Management may get us past this hurdle...

I think "secure" is going to run into virtually identical
objections to the ones raised concerning "simple."  And for
whatever it's worth, the group really has been pretty
hand-wavey about security and I'm pretty sure "secure"
would not be particularly descriptive of the group's
priorities.

I think it's best to find something descriptive, propose
that, and move forward.

Melinda

---

From: Alan Sill <[email-masked]>
Date: Thu, 24 May 2012 15:48:49 -0500

Earlier on, I suggested "SChemas for Identity Management Attributes" (SCIMA) and that went over like a lead balloon! ;-)

Schema and protocol for Cross-domain Identity Management attributes = SCIM if you want to suppress some initials

Identity Attributes Interchange Protocol = IAIP if you give up the SCIM name

Cross-domain Identity Management Attribute Protocol and Schema = CIMAP
...

Alan

---

From: Likepeng <[email-masked]>
Date: Fri, 25 May 2012 00:37:35 +0000

I like this one. 

The easier way for us is to agree with the IESG proposal, and we can move on.

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Barry Leiba
发送时间: 2012年5月25日 2:16
收件人: [email-masked]
主题: Re: [scim] Feedback on the charter from IESG and IAB

OLD

NEW

Barry

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 May 2012 18:11:39 -0700

Too close to idiot/dum  whatever. 

Synchronous Cross-domain Identity Management

Phil

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 May 2012 17:42:51 -0800

> Synchronous Cross-domain Identity Management

This is going *great*.  Can we just drop the 'S'?

Melinda

---

From: Likepeng <[email-masked]>
Date: Fri, 25 May 2012 01:48:35 +0000

>Can we just drop the 'S'?

+1. 

If we add "user", it becomes "Cross-domain User Identity Management". It is close to IESG proposal now.

I think we care more about User Identity, not Content Identity, so "User" in the name will help.

Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Melinda Shore
发送时间: 2012年5月25日 9:43
收件人: [email-masked]
主题: Re: [scim] Feedback on the charter from IESG and IAB

Melinda

---

From: William Mills <[email-masked]>
Date: Thu, 24 May 2012 18:59:41 -0700 (PDT)

Cross-domain Identity Management System.  The S is sideways....

> From: Phil Hunt <[email-masked]>
>To: Likepeng <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; Barry Leiba <[email-masked]> 
>Sent: Thursday, May 24, 2012 6:11 PM

---

From: Emmanuel Dreux <[email-masked]>
Date: Fri, 25 May 2012 06:40:38 +0000

SCIM is a protocol for provisioning the Cloud, a protocol for provisioning SAAS applications.

It has been designed by the authors for this usage and the community has joined this working group for this reason.

You want to extend his hypothetical use and remove the term Cloud to suggest on premise applications and usage?

Great.

You think that it might be used (for example) to synchronize an ERP system with a LDAP server?

After all, why not, but where is the notion of domain?

It’s not a cross domain scenario. It’s just interoperability between 2 different kinds of directories.

Please do not replace the term cloud by the term domain if your wish is to suggest on premise capabilities.

Our product is a CAM server (Cloud Access Management server). One of our customer wants to use it to provision an open source WIFI system called pfsense that uses RADIUS authentication.

After all, why not, we accepted the challenge of writing an extension for his on premise “application”, and that does not challenge the fact that we keep the name “CloudAnywhere” for our product, neither does it challenge the fact that we will still market it as a solution for provisioning SAAS applications.

What does IP stands for in TCP/IP? Where is it used?

If you want a term for replacing SCIM, LDEP (Lightweight Directory Exchange Protocol), or LDPP (Lightweight Directory Provisioning Protocol) would better fit the usage.

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

De : William Mills [mailto:[email-masked]]
Envoyé : vendredi 25 mai 2012 04:00
À : Phil Hunt; Likepeng
Cc : [email-masked]; Barry Leiba
Objet : Re: [scim] Feedback on the charter from IESG and IAB

________________________________
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Likepeng <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Barry Leiba <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 24, 2012 6:11 PM
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Phil

On 2012-05-24, at 17:37, Likepeng <[email-masked]<mailto:[email-masked]>> wrote:

> 发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 代表 Barry Leiba
> 发送时间: 2012年5月25日 2:16
> 收件人: [email-masked]<mailto:[email-masked]>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 May 2012 22:58:18 -0800

On 5/24/12 10:40 PM, Emmanuel Dreux wrote:
> It has been designed by the authors for this usage and the community has
> joined this working group for this reason.

Some of the community.  I'm here because there's clearly a need
for an identity provisioning protocol, and SPML has tanked.  My
suspicion is that by the time the protocol is published the
pendulum will have swung back towards a more distributed
computing model, as it tends to do, and while the protocol
would continue to be useful its name would be anachronistic.

> What does IP stands for in TCP/IP? Where is it used?

I'm pretty sure that neither 'I' nor 'P' represents the
word "cloud," yet you're using it anyway.

> If you want a term for replacing SCIM, LDEP (Lightweight Directory
> Exchange Protocol), or LDPP (Lightweight Directory Provisioning
> Protocol) would better fit the usage.

??  Where did "Directory" and "Lightweight" come from?

Melinda

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 25 May 2012 03:35:37 -0500

I think we have gone around the block with this discussion a few times.
I am going to repeat my last response to the topic:

Personally speaking I still think we should stick with SCIM. If the
current traction of SCIM v1 is any indication, by the time v2 is
standardized, there will be quite a few implementations of SCIM v1 in
the wild (we are almost at 10 distinct implementations now). A rename
between v1 and v2 will only result in confusion and 10 years from now we
will be using both SCIM and new name to refer to it (SSL vs. TLS, Jabber
vs. XMPP, ...). IMO, what little we gain by renaming it, we will pay 10
fold by causing confusion. If we *really* must change something, let's
stay with SCIM and change "cloud" to any other word that starts with "c"
and move forward with the real work ahead.

Cheers,
Morteza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eliot Lear
Sent: Thursday, May 24, 2012 11:35 AM
To: Barry Leiba
Cc: [email-masked]; 'IESG'
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Barry,

Eliot

---

From: Erik Wahlström <[email-masked]>
Date: Fri, 25 May 2012 08:41:13 +0000

+1

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 25 May 2012 10:42:29 +0200

+1

---

From: Paul Madsen <[email-masked]>
Date: Fri, 25 May 2012 05:08:48 -0400

Surprisingly Contentious IETF Metadata

I will note that OAuth was neither particularly 'open' nor exclusively 
for 'authorization' but that name was able to persist into IETF ....

I vote to keep 'SCIM' and change acronym

Smart CRUD Identity Management

paul

---

From: Trey Drake <[email-masked]>
Date: Fri, 25 May 2012 09:05:15 -0500

+1

---

From: Michael Hammer <[email-masked]>
Date: Fri, 25 May 2012 15:03:15 +0000

Solving Contentious Identity Management

J

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Madsen
Sent: Friday, May 25, 2012 5:09 AM
Cc: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

I will note that OAuth was neither particularly 'open' nor exclusively for
'authorization' but that name was able to persist into IETF ....

paul

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Fri, 25 May 2012 08:56:25 -0800

> for 'authorization' but that name was able to persist into IETF ....

oauth was plagued with neither "simple" nor "cloud."

Melinda

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 25 May 2012 17:11:25 +0000

> oauth was plagued with neither "simple" nor "cloud."

Simplicity has been an overarching goal of SCIM since day one.  Losing the simplicity aspect would prevent adoption (see SPML).  Will everything about SCIM remain simple forever?  No.  Should we strive to keep the 80% case simple?  Absolutely.  I think that having this in the name helps to keep the goals clear and guide design decisions.  Sure ... this could just be highlighted in the charter, but I don't see the problem with keeping it in the name.  In my mind simplicity is one of the most important aspects of this effort.

I understand that cloud is a loaded word and am fine with coming up with something else here (cross-domain works for me).

I 100% agree with Morteza that losing the SCIM acronym would cause much more grief in the long run than the couple of plagued words.

--Kelly

---

From: Paul Madsen <[email-masked]>
Date: Fri, 25 May 2012 13:20:46 -0400

is not 'open' just as amorphous? was there a similar naming debate 3 
years ago?

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 May 2012 11:24:16 -0600

On 5/25/12 11:20 AM, Paul Madsen wrote:
> is not 'open' just as amorphous? 

Sure. As I said, people can complain about anything. "Simple", "Secure",
"Open", "Robust", "Scalable", and the like are typically derided as
marketing fluff.

> was there a similar naming debate 3
> years ago?

No.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Melinda Shore <[email-masked]>
Date: Fri, 25 May 2012 09:29:10 -0800

On 5/25/12 9:11 AM, Kelly Grizzle wrote:
> Simplicity has been an overarching goal of SCIM since day one.  Losing
 > the simplicity aspect

I'm not saying "Using the word 'simple' in a protocol name is
problematic, so let's develop a hairball protocol."  Making
a protocol as simple as possible (but no simpler) should always
be a goal of any protocol.  *Any* protocol.

There are certain words that are problematic in protocol names.  They
include "secure," "scalable," and, yes, "simple."  They provide no
discriminatory value and typically do not really describe the
protocol they're being used to describe.  Off the top of my head
I can't think of a security protocol that uses "secure" as an
adjective in its name (not saying there isn't one, just that
typically security protocol names are descriptive of the protocol
and don't include the word "secure").

Also, consider SIP.  When it came along everybody said "Isn't
it outstanding to have a much simpler alternative to H.323?"
And look at it now.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 May 2012 11:38:19 -0600

On 5/25/12 11:29 AM, Melinda Shore wrote:

> adjective in its name 

The SIDR WG is building "Secure Inter-Domain Routing". It's in the
Routing Area, but it's a security protocol.

Searching http://tools.ietf.org/wg/concluded for "secure" or "security"
leads to other interesting results (e.g., "Secure Shell").

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phil Hunt <[email-masked]>
Date: Fri, 25 May 2012 10:41:13 -0700

It's time for the IESG to decide to ignore the group consensus or not.

We've debated this about 4 times there has never been consensus for a new name - let alone new words for the same acronym. I'd say the opposite has now happened with the send backs -- there is now a very hardened consensus around the name SCIM. 

Form the WG or not.  Choose the name the IESG deems appropriate.

Please, let's move on.

Phil

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 May 2012 11:49:00 -0600

On 5/11/12 7:55 AM, Barry Leiba wrote:

<snip/>

Do we have revised text that addresses the first three points?

> this is a minor point, though -- the other three above need to be

It seems that several folks have posted proposed names that would
overcome the concerns about "simple" and "cloud". Can we perhaps move on
from this naming kerfuffle?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 May 2012 11:53:56 -0600

On 5/25/12 11:41 AM, Phil Hunt wrote:
> We've debated this about 4 times there has never been consensus for a
> new name - let alone new words for the same acronym. I'd say the
> opposite has now happened with the send backs -- there is now a very
> hardened consensus around the name SCIM.
> 

Well, the minutes from the relevant IESG meeting have not yet been
posted, so we don't really know the rationale for concerns about the
words "simple" and "cloud" in the name:

http://www.ietf.org/iesg/minutes/2012/index.html

IMHO this naming kerfuffle is distracting from the real work to be done
here, but I'll wait for the IESG minutes before saying more.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Melinda Shore <[email-masked]>
Date: Fri, 25 May 2012 10:02:39 -0800

On 5/25/12 9:41 AM, Phil Hunt wrote:
> [T]here is now a very hardened consensus around the name SCIM.

Not in any meaningful sense of the word "consensus."  Welcome
to the IETF.  The good news is that it's much easier to get
agreement on technical questions than it is on working group
names.

Melinda

---

From: Barry Leiba <[email-masked]>
Date: Fri, 25 May 2012 14:13:43 -0400

> Do we have revised text that addresses the first three points?

We're fine with that, and the IESG seems satisfied with the content of
the charter.

> from this naming kerfuffle?

I posted to the IESG list this morning, and am waiting for responses.
I think we can use one of the names that keeps the "SCIM" acronym,
yes.  I'll post back when I know something for sure.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 May 2012 12:14:46 -0600

> We're fine with that, and the IESG seems satisfied with the content of

Excellent.

> yes.  I'll post back when I know something for sure.

Thanks for following up and for letting us know.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Chris Phillips <[email-masked]>
Date: Sat, 26 May 2012 00:02:34 -0400

+1 to Morteza's proposal.
(apologies as my reply is a few hours behind)

There is an opportunity here for the IETF to capitalize on the momentum of
the existing adopters over the past year and those in progress as well.
A (drastic) name change now just dilutes and fragments the environment and
will be a burden on all to explain it in perpetuity.

Attending and presenting(on SCIM actually[1]) at TERENA in Iceland this
past week, the theme I heard from some of the IETF related tracks was the
concern and sounding the alarm for lack of adoption or not staying current
on protocols.  (IPv6 & what is (not)happening, simply enabling all the
features of BGP spec to increase security of the routing fabric to name a
few topics...).

In the world of provisioning, the lack of adoption problem is there in
spades and hurts us all. This is why the SCIM pragmatic simplicity
approach has traction where others don't.  Changing the name at this stage
in the game will result in dissipating any momentum gained over the past
year.

I'm hopeful that as we move on from the naming topic that we can apply the
same energy and debate to the technical topics in SCIM...

Chris.

[1] https://tnc2012.terena.org/core/presentation/125

---

From: Melinda Shore <[email-masked]>
Date: Fri, 25 May 2012 20:39:41 -0800

> in the game will result in dissipating any momentum gained over the past

I'm not sure I find this kind of hyperbole particularly
helpful.  While there continues to be some confusion
about whether it's "TLS" or "SSL," TLS seems to be doing
just fine in the marketplace.  The important thing is
identifying a problem well and solving it well.

I'm just fine with kicking this whole thing to the IESG and
telling them that if they've got a problem with "scim" (and
I agree that there are problems with both "simple" and
"cloud"), it's up to them to come up with something that's
descriptive and at least acceptable, and accepting it as
a mediated solution.  Sometimes coming to "consensus" means
saying "I don't agree, but I can live with it."  I feel
pretty strongly that both "simple" and "cloud" need to go,
and while I really dislike tortured acronyms I can live
with the IESG or someone else coming up with something ghastly
that acronymifies as "scim" in the interest of getting this
resolved.

Melinda

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Sat, 26 May 2012 10:52:44 -0500

Considering SCIM's origin/history, I am also in favor of AT LEAST NOT changing the acronym. Seems so far that if that is pre-condition for many in this list, it is still us that should find a matching name, and not the IESG (I am not sure why they would know better what this WG intends to do).

I had the feeling that Cross-domain may not have significant opposition within this group (although it still may in IESG, and then we need to come up with something else for the "C", for example somebody suggested CRUD). However, so far we failed to get even average support for anything for the "S" (scalable, secure, simple, synchronous, etc... did not seem to gain support).

But how about Stateless? This would be indicative of the intent of the group to use REST architectural style.

Stateless Cross-domain Identity Management?
OR
Stateless CRUD Identity Management?

Going into IESG with 2 options, both having removed the contentious Simple and Cloud may entice them to accept one of them.

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Saturday, May 26, 2012 12:40 AM
To: [email-masked]
Subject: Re: [scim] Feedback on the charter from IESG and IAB

Melinda

---

From: Paul Madsen <[email-masked]>
Date: Sun, 27 May 2012 18:22:55 -0400

+ 1 to Stateless CRUD Identity Management

next issue?