Subject: Re: [scim] Draft charter - v7

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 12 Apr 2012 00:10:45 -0500

Lots of interesting discussions on the thread. I am trying to figure out
what edits I should make to the latest charter to address
concerns/issues raised.  Summarizing the thread it seems there were two
major points discussed.

Name of the protocol/WG

I personally think there is significant value in the existing
implementations of 1.0 and traction the whole effort has had and
renaming it would be a poor decision.  With that said, it sounds like
most folks either don't care or interested in keeping the name the same.
If someone strongly objects to this or has concerns please raise it.

Actual scope of work

There were a lot of discussions on whether SCIM is solving a cloud use
case or addressing enterprise provisioning case as well.  The problem I
am having is that the discussion is mainly around high level semantics
of cloud vs. enterprise.

Melinda, I fully agree that overgeneralizing the problem is just as bad
as boiling the ocean, however we need to come up with specific use cases
that we think should be included in the charter and problem statement.
The charter actually says:

"The Simple Cloud Identity Management (SCIM) specification will be
designed to simplify user identity management in services and
applications by defining standard protocols and schemas for creating,
reading/searching, modifying, and deleting user identities and
identity-related objects across administrative domains."

Note that it says "services" and "applications".  In my view enterprise
identity provisioning use cases fall under the application part of this
statement. Does anyone have a specific use case that you think should be
addressed by SCIM that given the current charter wording is excluded?

Cheers,

Morteza

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Morteza Ansari (moransar)
Sent: Monday, April 09, 2012 6:56 PM
To: [email-masked]
Subject: [scim] Draft charter - v7

Hi folks,

Here is the updated charter based on the discussions that took place in
the BoF meeting and some guidance from a hallway conversation with Pete
after the meeting.  Please review the text and send your comments.
Hopefully we can close this soon and hand it over to the ADs.

Phil, I added a note regarding targeting extensions in the updated
charter given the email discussions.

Cheers,

Morteza

---

From: Melinda Shore <[email-masked]>
Date: Wed, 11 Apr 2012 21:30:21 -0800

On 4/11/12 9:10 PM, Morteza Ansari (moransar) wrote:
> Note that it says “services” and “applications”. In my view enterprise

Actually, I think the issue may be more around "across adminmistrative
domains," although 1) I think that can be addressed in the security
considerations (and eventually mechanisms), and 2) implementers are 
going to  do what they're going to do, anyway, and being fussy about
anything other than protocol details tends to have a poor return on
investment, as tempting as it is.

Melinda

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 12 Apr 2012 01:06:38 -0500

"across administration domain" typically exists within an enterprise.
There are many layers of identity data and typically they are managed
using different policies and control points.  So a notion of
administrative boundary is part of the enterprise provisioning problem
space as well between enterprise and service providers.

Cheers,
Morteza
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Melinda Shore
Sent: Wednesday, April 11, 2012 10:30 PM
To: [email-masked]
Subject: Re: [scim] Draft charter - v7

> identity provisioning use cases fall under the application part of 
> this statement. Does anyone have a specific use case that you think 
> should be addressed by SCIM that given the current charter wording is
excluded?

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 11 Apr 2012 22:16:52 -0800

> space as well between enterprise and service providers.

I'm certainly aware of this but in conversation it seems as if
it's so common to point out that there are administrative boundaries
within an enterprise that there's an assumption that nobody knows
this, which is either an odd thing or a thing to keep in mind when
writing documents.  At any rate there can be issues around trust
that are somewhat different within an enterprise than across entirely
unrelated organizations, in terms of the ability to make assumptions
about trust anchors, etc.  As I said I'm not sure this needs to be
much of an issue outside of the security discussion.

Melinda

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Apr 2012 10:34:27 -0400

> implementations of 1.0 and traction the whole effort has had and renaming it
> would be a poor decision.  With that said, it sounds like most folks either
> don’t care or interested in keeping the name the same. If someone strongly
> objects to this or has concerns please raise it.

Let me stick my oar in as an AD.

1. Wasting a lot of time worrying about the name is... wasting a lot
of time.  It's really counter-productive to let such a silly thing
turn into a rat hole.

2. That said, naming is marketing.

2a. For whatever it's worth, and however much we may not like it,
Melinda's note that the term "cloud" has developed some level of
toxicity around parts of the IETF, and in the IESG in particular, is
true.  That's a result of other, repeated, poorly focused efforts, and
it's made many people think that anything called "cloud" is poorly
focused and to be regarded with a lot of suspicion.  I don't think
it's a good idea to start your proposal with that baggage.

2b. I agree with the comments that say this isn't specific to what
we've usually called "cloud" services.  It goes beyond that, and
that's another reason I urge you to take "cloud" out of the name.
Now, you can certainly say that enterprise is cloud, data center is
cloud, <whatever> is cloud, but I note that that supports the concerns
of those who think that "cloud" is just a too-broad term that
eventually swallows up everything [compare:
http://www.imdb.com/title/tt0051418/ ].  I really don't think you want
to have to fight that battle.

3. I don't think "identity management" is the right term here either.
ID management is also a very large sandwich, which has several bites
taken out of it so far (OpenID, AbFab, OAuth, and SAML are all pieces
of it).  This is another *piece* of ID management, and it's best to
label it as a piece, not as an attempt at swallowing the whole
sandwich.  What you're proposing isn't so much "cloud identity
management" as it is identity provisioning within and across
administrative domains.  A name that gets that point across will
server you better than a heels-dug insistence on keeping a name you've
come to love, though I do understand the desire to keep that.

None of this is any official pronouncement from the IESG... just the
opinion of one AD who will be part of the charter approval process
(and one who might wind up being the responsible AD for the WG, if
it's chartered in the App Area).

Barry

---

From: "Diodati,Mark" <[email-masked]>
Date: Thu, 12 Apr 2012 19:59:56 +0000

Morteza - nice work. I cannot think of any additional use cases that are associated with enterprise provisioning.

All-

As for the discussion over the word "cloud", our enterprise clients are beginning to use it to describe their on-premises environment.

If SCIM is renamed, it will negatively impact its success. Also, +1 on Morteza's assessment of the 1.0 value proposition; we are already seeing products adopt it. What message is sent to adopters if we change the name?

The charter statement is long enough; I think that it could be reduced. But more details are not appropriate-the statement is beginning to lose coherence and look SPML-y (which is to say "kitchen sink").

The extended focus on language minimally appears to be distracting, maximally may have negative consequences for adoption.

Apologies in advance; I mean no offense.

Mark

From: Morteza Ansari (moransar) [mailto:[email-masked]]
Sent: Thursday, April 12, 2012 12:11 AM
To: [email-masked]
Subject: Re: [scim] Draft charter - v7

Lots of interesting discussions on the thread. I am trying to figure out what edits I should make to the latest charter to address concerns/issues raised.  Summarizing the thread it seems there were two major points discussed.

Name of the protocol/WG
I personally think there is significant value in the existing implementations of 1.0 and traction the whole effort has had and renaming it would be a poor decision.  With that said, it sounds like most folks either don't care or interested in keeping the name the same. If someone strongly objects to this or has concerns please raise it.

Actual scope of work
There were a lot of discussions on whether SCIM is solving a cloud use case or addressing enterprise provisioning case as well.  The problem I am having is that the discussion is mainly around high level semantics of cloud vs. enterprise.

Melinda, I fully agree that overgeneralizing the problem is just as bad as boiling the ocean, however we need to come up with specific use cases that we think should be included in the charter and problem statement. The charter actually says:

"The Simple Cloud Identity Management (SCIM) specification will be designed to simplify user identity management in services and applications by defining standard protocols and schemas for creating, reading/searching, modifying, and deleting user identities and identity-related objects across administrative domains."

Note that it says "services" and "applications".  In my view enterprise identity provisioning use cases fall under the application part of this statement. Does anyone have a specific use case that you think should be addressed by SCIM that given the current charter wording is excluded?

Cheers,
Morteza

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Morteza Ansari (moransar)
Sent: Monday, April 09, 2012 6:56 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [scim] Draft charter - v7

Hi folks,

Here is the updated charter based on the discussions that took place in the BoF meeting and some guidance from a hallway conversation with Pete after the meeting.  Please review the text and send your comments. Hopefully we can close this soon and hand it over to the ADs.

Phil, I added a note regarding targeting extensions in the updated charter given the email discussions.

Cheers,
Morteza

________________________________

This e-mail message, including any attachments, is for the sole use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Gartner makes no warranty that this e-mail is error or virus free.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Apr 2012 22:05:06 +0200

Barry,

First, putting aside the name for a moment (we'll come back to that)
what do you think of the REST of the charter (pun intended)?

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Fri, 13 Apr 2012 09:34:23 -0400

> what do you think of the REST of the charter (pun intended)?

A fair question.  I had wanted to wait for the next iteration, since I
know that Morteza has updates to make, based on comments.  But yes,
here are my thoughts.

* I do think the charter is well thought out and well scoped, in general.

* I am still concerned about the need to develop a new *protocol*,
rather than using or adapting existing protocols with new,
standardized schemas and uses.  It's often the case that an
applicability statement on an existing protocol can do the job, and
I'd like to see that seriously considered *within the IETF context*.

* That said, something built on REST might, indeed, be the right
thing.  At the risk of repeating: it's hard to know that without a
real analysis.  And as I said in Paris, it's hard to do an objective
analysis when you already have the answer you want.  I'm not sure how
to fix that, but I think we need to try.

* I worry that there's no consideration in the charter for security
aspects of this, other than to specifically *exclude* work on
authentication and authorization.  It's probably good not to spin up
new mechanisms for these, but I'd like the charter to say something
about how the system *will* address issues of authentication,
authorization, access control, privacy, and integrity.

* The milestones are of course very fuzzy at this point, as they
should be.  So I'll stick this in just as an early warning: having
five documents in active development in the working group at once is
probably not the best approach.  I'm less interested in milestones for
adoption of drafts than I am about ones for completion of drafts, and
I expect WG chairs to make sure that the work gets started at an
appropriate time to have a good hope of meeting the completion
milestones.  WGs too often set up too many things going on at once,
and then have trouble coordinating them.  Be aware of that.

Back to the name just for a moment, since Mark said something I have
to respond to, which I think is an important point beyond rat-holing
on the name:

> If SCIM is renamed, it will negatively impact its success.

Really?  OK, I know naming is marketing, and marketing is important.
I also know that this is a statement of one person's opinion, not
necessarily a point of consensus.  But I suggest that if that's really
the case, there's a significant problem here.

If what comes out of this is a useful, well designed, and important
solution, it will be adopted, regardless of the name.  If it *is*
useful, well designed, and important, and its name alone gets in the
way of adoption, then I think we have more problems than a standards
working group can solve, and I'm very much concerned.

You have an established group *outside* the IETF that's been working
on this.  That's a beautiful thing; we like that.  What you're trying
to do now is get people *within* the IETF to come work with you, to
finish and solidify it.  Your marketing focus has shifted: you now
want to market to the IETF, to make sure you get the right people
involved.

> we are already seeing products adopt it. What message is sent to adopters
> if we change the name?

We send the message that we thought there was a good reason to change
the name.  That's all.  It's happened in many cases, and in none of
them did it seriously bother anyone or significantly affect the
success of the result.

Barry

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Apr 2012 14:57:33 -0700

+1 

I agree with Barry, part of the objective of bringing SCIM to IETF is to engage a larger community. In my opinion that broader community has yet to join this potential WG. One of those communities is the members of the OASIS Provisioning TC. Members elected to idle that TC pending SCIMs move into IETF. Many of those members have yet to join this discussion as they are unsure about whether SCIM is to be a provisioning protocol.

When we talk about consensus the group is somewhat skewed towards the perspectives of SPs and directories. The group may be making the same mistake that OASIS SPML made -- just in reverse. -->  SPML emphasized the client role at the expense of the SP, while SCIIM emphasizes the service API at the expense of the client.  I contend we need to look at this problem domain with *appropriate balance*. 

The current draft looks very much like a RESTful LDAP spec with updated schema (e.g. complex attributes) - in fact I understand that was the original objective. Much like you can do provisioning with LDAP, you can do provisioning with SCIM. However, from the perspective of a provisioning "system" client, you can use LDAP (or SCIM) as a connector, but neither LDAP nor SCIM are provisioning protocols (yet).

I think the group should decide whether "provisioning" is an important objective going forwards. If the group is prepared to entertain SCIM being a provisioning protocol, I'm prepared to send another message shortly detailing issues that should be more broadly considered. We can then debate those topics on their merits.  However, I have the strong sense the consensus is SCIM should be a RESTfull Access Protocol (RAP).

Let me state then, that I can support EITHER direction. The case for SCIM/RAP is very STRONG. I've already run across several RESTful LDAP implementations. My own organization has a few. This alone makes a strong case for standardization. Based on supporting customers running LDAP on the open Internet for over 10 years, there are some lessons learned that can be applied to the spec with regards to attacks and error handling. But that won't need charter revisions. I see these as issues that will arise as we go through security considerations (see Melinda's message today).

Does the group wish to exclude provisioning as an objective? I will support either direction.

Phil

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

---

From: "Jeremy Palenchar" <[email-masked]>
Date: Fri, 13 Apr 2012 18:02:07 -0700

I vote for SCIM as an interface that allows for reads and writes. A
read-only interface means that service providers would need to implement a
separate interface to support writes. It would also mean that clients would
need to have two channels for identity data - one for reading from a service
and one for writing to the service. I don't see SCIM as a provisioning
protocol, I see it as an API and core schema for a data endpoint that
supports CRUD. The API allows for an endpoint to be configured in a
read-only way which would result in your RAP.

-Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil
Hunt
Sent: Friday, April 13, 2012 2:58 PM
To: Barry Leiba
Cc: [email-masked]; Morteza Ansari (moransar); Eliot Lear
Subject: Re: [scim] Draft charter - v7

+1

I agree with Barry, part of the objective of bringing SCIM to IETF is to
engage a larger community. In my opinion that broader community has yet to
join this potential WG. One of those communities is the members of the OASIS
Provisioning TC. Members elected to idle that TC pending SCIMs move into
IETF. Many of those members have yet to join this discussion as they are
unsure about whether SCIM is to be a provisioning protocol.

When we talk about consensus the group is somewhat skewed towards the
perspectives of SPs and directories. The group may be making the same
mistake that OASIS SPML made -- just in reverse. -->  SPML emphasized the
client role at the expense of the SP, while SCIIM emphasizes the service API
at the expense of the client.  I contend we need to look at this problem
domain with *appropriate balance*. 

The current draft looks very much like a RESTful LDAP spec with updated
schema (e.g. complex attributes) - in fact I understand that was the
original objective. Much like you can do provisioning with LDAP, you can do
provisioning with SCIM. However, from the perspective of a provisioning
"system" client, you can use LDAP (or SCIM) as a connector, but neither LDAP
nor SCIM are provisioning protocols (yet).

I think the group should decide whether "provisioning" is an important
objective going forwards. If the group is prepared to entertain SCIM being a
provisioning protocol, I'm prepared to send another message shortly
detailing issues that should be more broadly considered. We can then debate
those topics on their merits.  However, I have the strong sense the
consensus is SCIM should be a RESTfull Access Protocol (RAP).

Let me state then, that I can support EITHER direction. The case for
SCIM/RAP is very STRONG. I've already run across several RESTful LDAP
implementations. My own organization has a few. This alone makes a strong
case for standardization. Based on supporting customers running LDAP on the
open Internet for over 10 years, there are some lessons learned that can be
applied to the spec with regards to attacks and error handling. But that
won't need charter revisions. I see these as issues that will arise as we go
through security considerations (see Melinda's message today).

Does the group wish to exclude provisioning as an objective? I will support
either direction.

Phil

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

On 2012-04-13, at 6:34 AM, Barry Leiba wrote:

>> we are already seeing products adopt it. What message is sent to 
>> adopters if we change the name?
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Apr 2012 18:20:28 -0700 (PDT)

For clarification the r in rap stood for REST. :)

Phil

---

From: "Jeremy Palenchar" <[email-masked]>
Date: Fri, 13 Apr 2012 20:22:11 -0700

Understood,

However, I understood you to be arguing against "provisioning" and to me,
provisioning means creating entities, so a service that does not support
provisioning would, in my mind, be read-only.

Perhaps you could clarify the concept of a "provisioning protocol" which you
seem to be leaning against vs. a data API and core schema which you seem to
be leaning towards.

-Jeremy

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Friday, April 13, 2012 6:20 PM
To: Jeremy Palenchar
Cc: Barry Leiba; [email-masked]; Morteza Ansari (moransar); EliotLear
Subject: Re: [scim] Draft charter - v7

Phil

On 2012-04-13, at 18:02, Jeremy Palenchar <[email-masked]> wrote:

> read-only interface means that service providers would need to 
> implement a separate interface to support writes. It would also mean 
> that clients would need to have two channels for identity data - one 
> for reading from a service and one for writing to the service. I don't 
> see SCIM as a provisioning protocol, I see it as an API and core 
> schema for a data endpoint that supports CRUD. The API allows for an 
> endpoint to be configured in a read-only way which would result in your
RAP.
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Phil Hunt
> I agree with Barry, part of the objective of bringing SCIM to IETF is 
> to engage a larger community. In my opinion that broader community has 
> yet to join this potential WG. One of those communities is the members 
> of the OASIS Provisioning TC. Members elected to idle that TC pending 
> SCIMs move into IETF. Many of those members have yet to join this 
> discussion as they are unsure about whether SCIM is to be a provisioning
protocol.
> mistake that OASIS SPML made -- just in reverse. -->  SPML emphasized 
> the client role at the expense of the SP, while SCIIM emphasizes the 
> service API at the expense of the client.  I contend we need to look 
> at this problem domain with *appropriate balance*.
> 
> The current draft looks very much like a RESTful LDAP spec with 
> updated schema (e.g. complex attributes) - in fact I understand that 
> was the original objective. Much like you can do provisioning with 
> LDAP, you can do provisioning with SCIM. However, from the perspective 
> of a provisioning "system" client, you can use LDAP (or SCIM) as a 
> connector, but neither LDAP nor SCIM are provisioning protocols (yet).
> 
> objective going forwards. If the group is prepared to entertain SCIM 
> being a provisioning protocol, I'm prepared to send another message 
> shortly detailing issues that should be more broadly considered. We 
> can then debate those topics on their merits.  However, I have the 
> strong sense the consensus is SCIM should be a RESTfull Access Protocol
(RAP).
> implementations. My own organization has a few. This alone makes a 
> strong case for standardization. Based on supporting customers running 
> LDAP on the open Internet for over 10 years, there are some lessons 
> learned that can be applied to the spec with regards to attacks and 
> error handling. But that won't need charter revisions. I see these as 
> issues that will arise as we go through security considerations (see
Melinda's message today).
>> A fair question.  I had wanted to wait for the next iteration, since 
>> I know that Morteza has updates to make, based on comments.  But yes, 
>> here are my thoughts.
>> 
>> probably not the best approach.  I'm less interested in milestones 
>> for adoption of drafts than I am about ones for completion of drafts, 
>> and I expect WG chairs to make sure that the work gets started at an 
>> necessarily a point of consensus.  But I suggest that if that's 
>> really the case, there's a significant problem here.
>>

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 16 Apr 2012 14:04:49 +0000

I have been discussing a RAP vs. provisioning API with Phil.  The distinction is not a read vs. a write channel, but the use cases that are being solved.  A provisioning API would support use cases that are important to provisioning (aka - IdM) solutions, whereas the RAP concept addresses the single identity use cases that have been the primary focus up until now.  I actually think there is a *lot* of overlap between the two, so I would like to see this discussion/work happen in this group.

Examples of "provisioning" use cases would be:
 - Support for more "operational" attributes, such as unlocking a user.
 - Support for targeting, which enables using SCIM as a gateway/hub to other applications.
 - Deeper support for other IdM concepts, such as a schema around role definitions.
 - etc...

I can see all of these being very relevant for both provisioning solutions and the current identity service providers.  I don't think that all need to necessarily be addressed in SCIM 2.0, but would like to include some of them in the conversation.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeremy Palenchar
Sent: Friday, April 13, 2012 10:22 PM
To: 'Phil Hunt'
Cc: [email-masked]; 'Barry Leiba'; 'Morteza Ansari (moransar)'; 'EliotLear'
Subject: Re: [scim] Draft charter - v7

Understood,

However, I understood you to be arguing against "provisioning" and to me, provisioning means creating entities, so a service that does not support provisioning would, in my mind, be read-only.

Perhaps you could clarify the concept of a "provisioning protocol" which you seem to be leaning against vs. a data API and core schema which you seem to be leaning towards.

-Jeremy

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, April 13, 2012 6:20 PM
To: Jeremy Palenchar
Cc: Barry Leiba; [email-masked]; Morteza Ansari (moransar); EliotLear
Subject: Re: [scim] Draft charter - v7

Phil

RAP.
protocol.
(RAP).

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 11:40:14 -0600

> I'd like to see that seriously considered *within the IETF context*.

We had similar debates during formation of the PAWS WG. See for instance
its original charter:

http://trac.tools.ietf.org/wg/paws/charters?item=charter-paws-2011-06-14.txt

Here is some of the relevant text:

###

  The overall goals of this working group are to:

  1. Standardize a mechanism for discovering a white space database.

  2. Standardize a method for accessing a white space database.

  3. Standardize query and response formats to be carried over the
  database access method.

  4. Ensure that the discovery mechanism, database access method,
  and query/response formats have appropriate security levels in place.

  By "standardize" is not meant that the working group will necessarily
  develop new technologies.  In completing its work, the group will:

  - Evaluate existing discovery mechanisms to determine if one of
    them provides the necessary application features and security
    properties (or can be extended to do so) for discovering a
    white space database.  Examples might include DNS.

  - Evaluate existing application-layer transport protocols to
    determine if one of them provides the necessary application
    features and security properties (or can be extended to do so)
    for use as a building block for communication between location-
    aware devices and white space databases.  If such a method
    exists, the group will reuse it; if not, the group will develop
    one.  Examples might include HTTP.

  - Develop a method for querying a white space database.  Such
    a method will utilize, so far as possible, the features of
    the application-layer transport protocol and not re-implement
    them in the new protocol. It will include mechanisms to verify
    that the requests and responses come from authorized sources,
    and that they have not been modified in transit.  Examples might
    include LDAP.

  - Define extensible formats for both location-specific queries and
    location-specific responses for interaction with radio white
    space databases.  The group will consider whether existing data
    formats can be reused.

###

Something along those lines (but briefer) might be appropriate.

> to fix that, but I think we need to try.

I think we also need to try to respect the fact that there are half a
dozen or more existing implementations, which is different from the PAWS
case. Running code still counts for something, and building upon HTTP
seems like a perfectly fine thing to do here (it's not as if folks are
thinking about designing a completely new application protocols, which
I'd agree would be crazy). In particular, Barry, what would you expect
the results of a more detailed analysis to look like here?

> authorization, access control, privacy, and integrity.

Something along the lines of what was included in the original OAuth
charter seems appropriate:

   * Embody good security practice, or document gaps in its
     capabilities, and propose a path forward for addressing the
     gap.

http://trac.tools.ietf.org/wg/oauth/charters?item=charter-oauth-2009-05-13.txt

Naturally, everything in the IETF undergoes security review, so a short
statement seems sufficient.

As to the name, although I'm no fan of buzzwords in protocol names, I
personally see no active harm in continuity here.

Peter

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Apr 2012 15:58:18 -0400

It's been several days without any further discussion of the charter.
There's active conversation about the specs, and that's a nice thing.
Since the charter comments seem to have settled, why don't you post
another version of the charter with the recent comments (since v7)
incorporated?

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Apr 2012 02:54:22 +0100

I'm not sure if my question (attached) is charter related
or not, but it might be, depending on the answer. I've not
seen an answer so far.

Ta,
S

> another version of the charter with the recent comments (since v7)

Subject: Re: [scim] SCIM Issues
From: Stephen Farrell <[email-masked]>
To: Samuel Erdtman <[email-masked]>
Cc: Radovan Semancik <[email-masked]>, [email-masked]
Date: Tue, 17 Apr 2012 19:34:56 +0100
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>

Just a question on one snippet:

On 04/17/2012 06:09 AM, Samuel Erdtman wrote:
>> >
>> > The familyName and givenName attributes have culture-neutral names. This is
>> > a nice take from FOAF. But the middleName is not that good. It enforces
>> > "american" point of view to the schema. Maybe "additionalName" would be more
>> > appropriate.
> I do not thing that middleName/additionalName is a big deal but good
> point. to be fully compliant with the global view might we also the
> need to make it multiValued for situations where more then one is
> common?

Does this mean that scim intend to re-develop the equivalent of
inetOrgPerson?

That seems like an odd idea. Why is it necessary?

Note - I'm not saying "use ldif" here, but wondering why this
putative WG would need to go re-do all that data modelling work,
as would be implied by the quoted text above.

S

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Apr 2012 11:35:11 -0600

A bit of follow up inline...

On 4/16/12 11:40 AM, Peter Saint-Andre wrote:
>>> First, putting aside the name for a moment (we'll come back to
>>> that) what do you think of the REST of the charter (pun
>>> intended)?
>> 
>> A fair question.  I had wanted to wait for the next iteration,
>> since I know that Morteza has updates to make, based on comments.
>> But yes, here are my thoughts.
>> 
>> * I am still concerned about the need to develop a new
>> *protocol*, rather than using or adapting existing protocols with
>> new, standardized schemas and uses.  It's often the case that an 
>> applicability statement on an existing protocol can do the job,
>> and I'd like to see that seriously considered *within the IETF
>> context*.
> 
> We had similar debates during formation of the PAWS WG. See for
> instance its original charter:
> 
> 4. Ensure that the discovery mechanism, database access method, and
> query/response formats have appropriate security levels in place.
> 
> By "standardize" is not meant that the working group will
> necessarily develop new technologies.  In completing its work, the
> group will:
> 
> properties (or can be extended to do so) for discovering a white
> space database.  Examples might include DNS.
> 
> features and security properties (or can be extended to do so) for
> use as a building block for communication between location- aware
> devices and white space databases.  If such a method exists, the
> group will reuse it; if not, the group will develop one.  Examples
> might include HTTP.
> 
> - Develop a method for querying a white space database.  Such a
> method will utilize, so far as possible, the features of the
> application-layer transport protocol and not re-implement them in
> the new protocol. It will include mechanisms to verify that the
> requests and responses come from authorized sources, and that they
> have not been modified in transit.  Examples might include LDAP.
> 
> location-specific responses for interaction with radio white space
> databases.  The group will consider whether existing data formats
> can be reused.
> 
> ###
> 

Here is some proposed text...

OLD
   The Simple Cloud Identity Management (SCIM) specification
   will be designed to simplify user identity management in
   services and applications by defining standard protocols
   and schemas for creating, reading/searching, modifying,
   and deleting user identities and identity-related objects
   across administrative domains.

NEW

   The Simple Cloud Identity Management (SCIM) working group
   will standardize methods for creating, reading/searching,
   modifying, and deleting user identities and identity-related
   objects across administrative domains, with the goal of
   simplifying common tasks related to user identity management
   in services and applications.

   By "standardize" is not meant that the working group will
   necessarily develop new technologies.  For example, the
   existing specifications for "SCIM 1.0" provide RESTful
   interfaces on top of HTTP rather than defining a new
   application protocol.  However, those specifications do
   define novel payload formats ("schemas") for data exchange;
   these formats are designed to encapsulate an interoperable
   subset of identity-related information for communication
   between administrative domains, of the kind that is often
   contained in formats such as LDAP and vCard within an
   administrative domain.

I'm a bit unsure about the last sentence, and Barry and others might
think that we need to say something more about considering, in the
IETF context, whether to use native LDAP or vCard or other formats
instead of the novel formats currently defined in SCIM 1.0 (e.g., we
could add a sentence at the end like "The working group should
consider whether existing data formats such as LDAP and vCard are
appropriate for interchange between administrative domains.").
Naturally, feedback is welcome on that point and others.

>> thing.  At the risk of repeating: it's hard to know that without
>> a real analysis.  And as I said in Paris, it's hard to do an
>> objective analysis when you already have the answer you want.
>> I'm not sure how to fix that, but I think we need to try.
> 
> I think we also need to try to respect the fact that there are half
> a dozen or more existing implementations, which is different from
> the PAWS case. Running code still counts for something, and
> building upon HTTP seems like a perfectly fine thing to do here
> (it's not as if folks are thinking about designing a completely new
> application protocols, which I'd agree would be crazy). In
> particular, Barry, what would you expect the results of a more
> detailed analysis to look like here?

I'm still curious on this point, but I've tried to address the "design
a new protocol" concern in the text I provided above.

>> * I worry that there's no consideration in the charter for
>> security aspects of this, other than to specifically *exclude*
>> work on authentication and authorization.  It's probably good not
>> to spin up new mechanisms for these, but I'd like the charter to
>> say something about how the system *will* address issues of
>> authentication, authorization, access control, privacy, and
>> integrity.
> 
> Something along the lines of what was included in the original
> OAuth charter seems appropriate:
> 
> capabilities, and propose a path forward for addressing the gap.
> 
>  Naturally, everything in the IETF undergoes security review, so a
> short statement seems sufficient.

I like the text that Melinda Shore provided, so I propose that we
include it in the next version of the charter. I've included it below
(with a tweak or two) after some boilerplate security text copied from
the original OAUTH WG charter:

   The working group will ensure that the SCIM protocol embodies
   good security practices, or document gaps in its capabilities
   and propose a path forward for addressing those gaps.  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.

Does that seem acceptable?

> As to the name, although I'm no fan of buzzwords in protocol names,
> I personally see no active harm in continuity here.

I stand by that statement.

Peter

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

---

From: Chris Phillips <[email-masked]>
Date: Tue, 24 Apr 2012 17:37:38 -0400

+1 to the text from Melinda Shore, it has coverage for what's outside the
payload and talks briefly about what is in the attributes in the payload.

Chris.

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 26 Apr 2012 14:30:38 -0500

My apologies for going quite for the past week or so. I was out of town
with very limited email access. I am going through the comments and will
roll them up into an updated charter text today.

Cheers,
Morteza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Leiba
Sent: Friday, April 20, 2012 12:58 PM
To: Morteza Ansari (moransar)
Cc: [email-masked]
Subject: Re: [scim] Draft charter - v7

Barry

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 27 Apr 2012 02:43:30 -0500

<snip>

OLD

NEW

I'm a bit unsure about the last sentence, and Barry and others might think that we need to say something more about considering, in the IETF context, whether to use native LDAP or vCard or other formats instead of the novel formats currently defined in SCIM 1.0 (e.g., we could add a sentence at the end like "The working group should consider whether existing data formats such as LDAP and vCard are appropriate for interchange between administrative domains.").
Naturally, feedback is welcome on that point and others.

MA> I like your proposed text as it clearly states what we are trying to do and what the current proposal is. However, I am also unsure about the last sentence. I think it is too verbose and does not necessarily add a whole lot for the purposes of charter. The charter simply says defining schema is a core part of the charter and that backward compatibility consideration should be given to the SCIM 1.0 spec. This means the WG should evaluate various options for schema and decide on the best option. For the next revision of the charter I will skip that sentence until others have had a chance to chime in and provide more feedback/suggestions.  Thanks for your text.

Cheers,
Morteza