System for Cross-domain Identity Management: Core Schema
draft-ietf-scim-core-schema-22

[Ballot comment]
I agree with the mis-use of 2119 keywords raised by other ADs and I held my nose at the repeated use of the word "cloud".

[Ballot comment]
Here is Qin's OPS DIR review:

I think this draft is ready for publication. Here are a few editorial comments:

1.      Section 1.1 “Requirements Notation and Conventions”



I am wondering how RFC2119 languages are applied to this document,

In Section 4.1.1, “RECOMMENDED” is applied to the attribute “userName” by adding

“RECOMMENDED” at the end of attribute “userName” description.

In section 7, “DEFAULT”is applied to subattibute “readwrite” by adding “DEFAULT”

at the end of “readwrite” sub-attribute description. “DEFAULT” seems not RFC2119 language.

Therefore RFC2119 language used to apply to some attribute seems not consistent with other

language(e.g., DEFAULT) applied to some other attributes. Or the language used at the end of

each attribute is not totally RFC2119 language.



Please distinct where RFC2119 language is used from where other language(e.g.,”DEFAULT” ) is

used in the draft.



2.      Section 2.2 said:

“

2.2.  Attribute Data Types



  Attribute data types are derived from JSON [RFC7159] and unless

  otherwise specified have the following characteristics (see Section

  7 for attribute characteristic definitions):



”

Who has the following characteristics, attribute data types or attributes?

If it is the former,I am not sure all the attribute data types listed here have

the following characteristics(e.g., mutability, and returnability, uniqueness),

For example. Boolean and Integer, Decimal are not of type string.

Attribute data type “Reference” is not case insensitive.

Can you give an example to explain the attribute data types are modifiable?

Or attributes corresponding to attribute data type listed here are modifiable?

How to understand attribute data type are returned in response to queries?

Are you saying attribute corresponding to attribute data types listed here are

usually returned in response to queries?



3.      Section 3.1 said:

“

For backwards compatibility reasons, some existing schema MAY list

common attributes as part of the schema.  The attribute

characteristics listed here SHALL take precedence.

”

Where the attribute characteristics are listed here? Section 7?

It looks what is listed here are a list of common attributes? What am I missing?

Also please clarify how to understand “take precedence of these attribute characteristics ”?



4.      Section 3.2 said

“

In order to offer new types of resources, a

service provider defines the new resource type as specified in

Section 6and defines a schema representation (see Section 8.7).

”

Miss a blank space between “section 6” and “and” in this sentence.



5.      Section 6 said:

“

  The following Singular Attributes are defined:



  id

      The resource type's server unique id.  Often this is the same

      value as the "name" attribute.  OPTIONAL



  name

      The resource type name.  When applicable service providers MUST

      specify the name specified in the core schema specification; e.g.,

      "User" or "Group".  This name is referenced by the

      "meta.resourceType" attribute in all resources.

”

It looks not all the attributes are suffixed with “RECOMMEND”,”REQUIRED”,”OPTIONAL”,”DEFAULT”.

So what is the default characteristics pertaining to the attribute if it is not suffixed with “RECOMMEND”,

”REQUIRED”,”OPTIONAL”,”DEFAULT”?

If there is no default characteristics associated with the attribute,  For consistency, I think each attribute

should add a suffix like “DEFAULT”,”RECOMMENDED”,”REQUIRED”.



6.      Section 7 said:

“

"Schema" resources have mutability of "readOnly"

  and are identified using the following schema URI:

”

Is SCIM Resources “shema”resource?

If they are the same thing, please use consistent terminology.



7.      Section 7 also said:

“

  id

      The unique URI of the schema.  When applicable service providers

      MUST specify the URI specified in the core schema specification;

      e.g., "urn:ietf:params:scim:schemas:core:2.0:User".  Unlike most

      other schemas, which use some sort of a GUID for the "id", the

      schema "id" is a URI so that it can be registered and is portable

      between different service providers and clients.

”

Does attribute “id” has the attribute characteristics described in section 2.2? i.e.,

“

  o  are OPTIONAL (is not required).



  o  are case insensitive ("caseExact" is "false"),



  o  are modifiable ("mutability" is "readWrite"),



  o  are returned in response to queries (returned by default),



  o  have no canonical values (e.g. type is "home" or "work"),



  o  are not unique ("uniqueness" is "none"), and,



  o  of type string (Section 2.2.1).

”

8.      Section 8.6 said:

“



  The following is a non-normative example of the SCIM resource types

  in JSON format.

”

Section 7 said, A SCIM resource type can be “user” or “group”. I am wondering how represented

using JSON format in the example of section 8.6?

Using schema attribute

“

"schema": "urn:ietf:params:scim:schemas:core:2.0:User"

”

Or using combination of several attribute, e.g., “id”,”name”,etc.

[Ballot comment]

- intro: I've no idea what "a general profile service for
in-domain applications" might be. 

- intro: hmm, the pass-info-to-3rd-party is a bit unsettling
all right. I think some earlier discussion resuled in a
suggested addition that should help, so I'd just like to add
more backing to the idea that such warnings can be useful.
Maybe there ought also be a way to annotate elements to say
that such "sharing" is not allowed? (As a future extension, if
that can be done.)

- 2.3.5: I didn't have time to chase the references here but
is the TZ always clear in this encoding? And does 2015-01-01
mean all 24 hours of Jan 1 this year or just the first second
of that day?

- 3.1: lastModified - this is sometimes used as a secondary
thing to authenticate the system to a user and so in some
cases could be somewhat sensitive if it were world readable,
or easily readable by someone who wanted to spoof as a server
to a valid user.  Not sure if that's worth a note here.
Probably not.

- 4.1.1: password, I agree with Ben's ex-DISCUSS.  Section
8.7.1 also says that the password element contains the
cleartext password which definitely needs fixing.

- 4.1: why only x509Certificates? I think you should also
allow PGP keys in some form or else generalise to "public key
containers" that would allow both plus "bare" public keys
maybe of varying forms.  This is not a discuss because it
could be fixed later, but the current design is IMO wrong in
this respect and would be better fixed now.

- 4.1: if you do keep an element named x509Certificates then
it may be worth adding a negative bit of guideance such as
'Each value here contains exactly one (base64) encoding of a
DER encoding of a Certificate data structure. A single value
MUST NOT contain multiple certificates and so does not contain
the encoding of a "SEQUENCE OF Certificate" in any guise.' It
has been a while since it's been done afresh but I've seen
that mistake in the past and it causes interop problems.

- 8.x: Nice that Olson gets a hat-tip in the TZ definition!

- 8.x: I hope someone has carefully read the schema stuff
recently - it's long and detailed and I didn't have time.

- Thanks for section 9.3!

[Ballot comment]
Thanks for addressing my discuss issue--I've cleared.


-- General:

As in the API draft, there's quite a bit of misuse of the 2119 "MAY" keyword (details below.)

-- 1.1, 3rd paragraph: "... all figures MAY contain spaces."

s/MAY/may

-- 2.1, 2nd paragraph : "MAY be camel-case"

Seems like if they are case insensitive, they can be any case.

-- 2.1, last paragraph: "... MAY need to be escaped..."

s/MAY/may

-- 2.2, 2nd bullet:

I assume this refers to the value/content of the attribute, since the previous section said the attribute name is always case insensitive.

-- 2.3.4:

integer is defined as a _decimal_ number that MUST NOT contain fractional or exponent parts. But the definition of “Decimal” says it has to have at least one digit to the right of the period. Do these conflict? Do Integers always need a trailing zero after a period?  (I suspect the answer is that you didn’t mean to say Integer was derived from Decimal, but if so, the use of “decimal” is confusing.)

-- 2.3.7, 2nd to last paragraph, first sentence:

To whom does this requirement apply? It sounds like an attempt to apply a MUST to whatever service a reference happens to refer to. I gather that could be any arbitrary service addressable with a URL.

-- 2.4, paragraph after bullet list : "The pre-defined set of sub-attributes for a multi-valued attribute"

I’m not sure what that means. These are the only sub-attrs that can be used? All multi-valued attributes have these sub-attributes?

-- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED attribute that MUST be
      present"

The REQUIRED and MUST are redundant.

-- 3.1, first paragraph, last sentence: "SHALL NOT be considered schema extensions."

Should this really be normative? Does “considering them a schema extension” involve observable implementation behavior differences?

-- 3.1, meta/resourceType: "The attribute is REQUIRED when provided by the service
        provider."

I’m not sure I understand—this seems to say the attribute is REQUIRED when it is present. (Same wording occurs for multiple attributes)

-- 4.1.1, "name"

This is defined as components of the user's "real" name. That sounds like an assertion of a real-name policy. Does the schema really require real names?

-- 4.1.2, "groups" : "... which MAY influence
      indirect memberships.:

s/MAY/may

-- same section, "entitlements": "An entitlement MAY be an additional right"

s/MAY/may

-- 9.3. 2nd paragraph

s/MAY/may (both occurrences)

-- 10.3.1:

Is there a reason not to use one or more of the well known registration policies from RFC 5226?

Editorial Comments

-- 4.1.1, "active"
s/infers/implies

[Ballot discuss]
Hopefully this one will be easy to address:

Section 4.1.1, under "password", says that passwords SHOULD be hashed or encrypted. But the security considerations say that passwords MUST NOT be stored in clear-text. These seem to be in conflict. (I prefer the MUST NOT).

[Ballot comment]
-- General:

As in the API draft, there's quite a bit of misuse of the 2119 "MAY" keyword (details below.)

-- 1.1, 3rd paragraph: "... all figures MAY contain spaces."

s/MAY/may

-- 2.1, 2nd paragraph : "MAY be camel-case"

Seems like if they are case insensitive, they can be any case.

-- 2.1, last paragraph: "... MAY need to be escaped..."

s/MAY/may

-- 2.2, 2nd bullet:

I assume this refers to the value/content of the attribute, since the previous section said the attribute name is always case insensitive.

-- 2.3.4:

integer is defined as a _decimal_ number that MUST NOT contain fractional or exponent parts. But the definition of “Decimal” says it has to have at least one digit to the right of the period. Do these conflict? Do Integers always need a trailing zero after a period?  (I suspect the answer is that you didn’t mean to say Integer was derived from Decimal, but if so, the use of “decimal” is confusing.)

-- 2.3.7, 2nd to last paragraph, first sentence:

To whom does this requirement apply? It sounds like an attempt to apply a MUST to whatever service a reference happens to refer to. I gather that could be any arbitrary service addressable with a URL.

-- 2.4, paragraph after bullet list : "The pre-defined set of sub-attributes for a multi-valued attribute"

I’m not sure what that means. These are the only sub-attrs that can be used? All multi-valued attributes have these sub-attributes?

-- 3, "Schema Attribute": "The "schemas" attribute is a REQUIRED attribute that MUST be
      present"

The REQUIRED and MUST are redundant.

-- 3.1, first paragraph, last sentence: "SHALL NOT be considered schema extensions."

Should this really be normative? Does “considering them a schema extension” involve observable implementation behavior differences?

-- 3.1, meta/resourceType: "The attribute is REQUIRED when provided by the service
        provider."

I’m not sure I understand—this seems to say the attribute is REQUIRED when it is present. (Same wording occurs for multiple attributes)

-- 4.1.1, "name"

This is defined as components of the user's "real" name. That sounds like an assertion of a real-name policy. Does the schema really require real names?

-- 4.1.2, "groups" : "... which MAY influence
      indirect memberships.:

s/MAY/may

-- same section, "entitlements": "An entitlement MAY be an additional right"

s/MAY/may

-- 9.3. 2nd paragraph

s/MAY/may (both occurrences)

-- 10.3.1:

Is there a reason not to use one or more of the well known registration policies from RFC 5226?

Editorial Comments

-- 4.1.1, "active"
s/infers/implies

[Ballot discuss]
Thanks for your work on this draft and the updates that took care of most of the items I wanted to discuss.  There is just one left and maybe an email response will clear up the scope of SCIM for me.  I'm not entirely clear on how data might pass between service providers on behalf of a customer, or if this is just between an customer and a service provider.  The latter doesn't have to worry about some security considerations of the former, so it would be good to know how the scope is limited.

4. It would help to have a statement that lists the scope of where SCIM is used and that the protocol design requires encryption when this data is in transit (per the api draft), since most of the attributes defined would contain PII when used. 

I'm making some assumptions, so please correct the text to the scope of SCIM.  The abstract has the following sentence:
  "This schema is intended for exchange and use with cloud
  service providers."
What about the following:
  "This schema is intended for exchange and use with cloud
  service providers and their customers."

There is also this statement int he introduction:
  "This schema is intended for exchange and use with
  cloud service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, permission to provide customers user information between service providers gets tricky and I don't think that was covered in the API draft, but please let me know if I missed it.

[Ballot comment]
Thanks for addressing the SecDir review adding text on clear text/hashed passwords and best practices (to avoid storing clear text, etc.).
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html

Thanks for the additional privacy considerations, pointing out that most of the data that could be sent using the SCIM schema could be sensitive in addition to the id and externalId.

Thanks for the additional text to out-of-scope some of the security controls that are really in the hands of implementers and may be specified through security SLAs or contracts.

[Ballot discuss]
Thanks for your work on this draft.  I do have a few items to discuss, but think they should be fairly easy to resolve.

1. Thanks for addressing the SecDir review and agreeing to put some text in about the clear text passwords and the difference between a hashed version.  I'll remove the discuss on this once the updated draft is posted.
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html

2. I see the discussion from the SecDir review changes "MAY" to "may' in section 9, but I'm wondering why the word may is used as many of the attributes are PII.  How about:

"defines attributes that are sensitive and the contents are considered personally identifiable information(PII)"

I have some more questions on PII and a suggestion to help resolve the concerns.

3. Is there a reason why the considerations are limited to/with an emphasis on the id and externalId?  Most of the attributes defined in section 4 are considered PII.  The id and externalID provide an index and that's important to protect, but so are many of the (optional) attributes.  It would be good to make this clear in the draft.  Since it is pointed out on id, it seems like the other attributes don't have privacy considerations when reading the draft, but a summary statement at the start of the draft would help where the index "id" is distinguished from the other sensitive attributes.

4. It would help to have a statement that lists the scope of where SCIM is used and that the protocol design requires encryption when this data is in transit (per the api draft), since most of the attributes defined would contain PII when used. 

I'm making some assumptions, so please correct the text to the scope of SCIM.  The abstract has the following sentence:
  "This schema is intended for exchange and use with cloud
  service providers."
What about the following:
  "This schema is intended for exchange and use with cloud
  service providers and their customers."

There is also this statement int he introduction:
  "This schema is intended for exchange and use with
  cloud service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, permission to provide customers user information between service providers gets tricky and I don't think that was covered in the API draft, but please let me know if I missed it.

If data exchanged using the SCIM schema is just between an organization and a contracted service provider, there should be SLAs for security and that could be noted in the introduction with the scope statement.  This will alleviate some of the privacy and security concerns as you can state the concerns, but leave it up to implementers and contracts to handle the details.  If the scope statement changes, something along the lines of the following could help:
    "Security service level agreements for the handling of these
    attributes are outside the scope of this document, but are to
    be carefully considered by implementers."

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-scim-core-schema-17.  Please report any inaccuracies and respond to the questions below as soon as possible.

IANA's reviewer has the following questions and comments:

Note: for future reference, phrasing the creation of new registries in the past tense is a little problematic, because it often isn't clear to the reviewer whether the registry already exists, or whether it should have been created by an earlier document.

Upon approval of this document, IANA understands that one registration will be made and that either two or three registries will be created.

First, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers subregistry of the Uniform Resource Name (URN) Namespace for IETF Use located at:

https://www.iana.org/assignments/params/

a new URN is to be registered as follows:

Sub-namespace: scim
Reference: [ RFC-to-be ]
IANA Registry Reference: [ TBD-at-registration ]

QUESTION: We understand that new registries will be created, but it isn't clear whether the document is creating two or three. We understand that Section 10.4 is creating registries called "SCIM Schema URIs for Data Resources" and "SCIM Server Related Schema URIs." Is IANA also being asked to create a registry called "SCIM Identifiers" (or "SCIM Schema Identifiers"?) for the schemas listed in Section 10.2.2?

QUESTION: If these registries should be created at a new URL, what should be the name of the new category at http://www.iana.org/protocols?

QUESTION: Should the IANA Considerations section contain templates for the "SCIM Schema URIs for Data Resources" and "SCIM Server Related Schema URIs" registrations?

The registration procedure for the new registries, if we understand it correctly, should be listed as "RFC Required with Expert Review; Standards Action under circumstances described in [RFC-to-be]."

QUESTION/NOTE: We understand that IANA will not make registrations approved by the expert until the document containing the template is approved for publication by the IESG. If this is not correct, please clarify this here and in the document.

IANA will create the following registries at a new URL, in a new category:

Registry Name: SCIM Schema URIs for Data Resources
Reference: [RFC-to-be]
Registration Procedure: RFC Required with Expert Review; Standards Action under circumstances described in [RFC-to-be]

  +-----------------------------------+-----------------+-------------+
  | Schema URI                        | Name            | Reference  |
  +-----------------------------------+-----------------+-------------+
  | urn:ietf:params:scim:schemas:    | User Resource  | See Section |
  | core:2.0:User                    |                | 4.1        |
  | urn:ietf:params:scim:schemas:    | Enterprise User | See Section |
  | extension:enterprise:2.0:User    | Extension      | 4.3        |
  | urn:ietf:params:scim:schemas:    | Group Resource  | See Section |
  | core:2.0:Group                    |                | 4.2        |
  +-----------------------------------+-----------------+-------------+

Registry Name: SCIM Server Related Schema URIs
Reference: [this document]
Registration Procedure: RFC Required with Expert Review; Standards Action under circumstances described in [RFC-to-be]

  +-----------------------------------+-------------------+-----------+
  | Schema URI                        | Name              | Reference |
  +-----------------------------------+-------------------+-----------+
  | urn:ietf:params:scim:schemas:    | Service Provider  | See      |
  | core:2.0:ServiceProviderConfig    | Configuration    | Section 5 |
  |                                  | Schema            |          |
  | urn:ietf:params:scim:schemas:    | Resource Type    | See      |
  | core:2.0:ResourceType            | Config            | Section 6 |
  | urn:ietf:params:scim:schemas:    | Schema            | See      |
  | core:2.0:Schema                  | Definitions      | Section 7 |
  |                                  | Schema            |          |
  +-----------------------------------+-------------------+-----------+


IANA understands that these actions are the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (System for Cross-Domain Identity Management: Core Schema) to Proposed Standard


The IESG has received a request from the System for Cross-domain Identity
Management WG (scim) to consider the following document:
- 'System for Cross-Domain Identity Management: Core Schema'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The System for Cross-Domain Identity Management (SCIM) specifications
  are designed to make identity management in cloud based applications
  and services easier.  The specification suite builds upon experience
  with existing schemas and deployments, placing specific emphasis on
  simplicity of development and integration, while applying existing
  authentication, authorization, and privacy models.  Its intent is to
  reduce the cost and complexity of user management operations by
  providing a common user schema and extension model, as well as
  binding documents to provide patterns for exchanging this schema
  using HTTP protocol.

  This document provides a platform neutral schema and extension model
  for representing users and groups and other resource types in JSON
  format.  This schema is intended for exchange and use with cloud
  service providers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary
=======

Document shepherd: Leif Johansson
Responsible AD: Barry Leiba
Publication type: Proposed Standard

The two documents (draft-ietf-scim-api and draft-ietf-core-schema) are
the core documents of the SCIM protocol - a simple API for "CRUD"
operations on (mainly) user and group objects associated with Internet
services (aka cloud services). The schema document defines the object
model for the core resources as well as extension mechanisms for adding
new resource types and extending core resources.

Review and Consensus
====================

The documents have been extensively reviewed and are being implemented
by multiple parties. The set of active contributors is mostly made up of
vendors and is relatively small. Most of the work has been done via
interim conference calls, which may have caused the set of active
contributors to be a bit smaller than otherwise might have been the
case, but it has also made the active contributors more active and
productive.

The current documents represent "version 2.0" of an existing standard
that was developed by an informal collaboration. Version 2.0 represents
a significant number of changes but there are already (partial)
implementations that have informed the WG. The documents have gone
through two WGLC's because a number of nits were discovered after the
first WGLC. It is the opinion of the shepherd that the WG has reached
broad consensus on the specification, and several vendors are getting to
a point where they could demonstrate interoperability between multiple
independent implementations. Although it may be possible to keep finding
nits for a while longer it is the view of the shepherd that the
documents should be published now as Proposed Standard, and revised soon
with any additional nits that are discovered during continued deployment
and interoperability-testing.

Intellectual Property
=====================

No issues

Other Points
============

A major change for version 2.0 is a switch from XML to JSON. The WG
would appreciate external review from the JSON community.

There is one nit for each document. Both issues are small enough to be
addressed together with the IESG comments.

There are no downref issues.

Summary
=======

Document shepherd: Leif Johansson
Responsible AD: Barry Leiba
Publication type: Proposed Standard

The two documents (draft-ietf-scim-api and draft-ietf-core-schema) are the two core documents of the
SCIM protocol - a simple API for "CRUD" operations on (mainly) user and group objects associated with
Internet services (aka cloud services). The schema document defines the object model for the core
resources as well as extension mechanisms for adding new resource types and extending core resources.

Review and Consensus
====================

The document has been extensively reviewed and is being implemented by multiple parties. The active
contributors is mostly made up of vendors and is relatively small. Most of the work has been done via
interim conference calls which may have caused the the active contributors to be a bit smaller than
otherwise might have been the case but it has also made the active contributors more active and productive.

The current documents represent "version 2.0" of an existing standard that was developed by an
informal collaboration. Version 2.0 represents a significant number of changes but there are already
(partial) implementations that has informed the WG. The documents have gone through two WGLC's because
a number of nits were discovered after the first WGLC. It is the opinion of the shepherd that the WG
has reach broad consensus on the specification and several vendors are getting to a point where they
could demonstrate interoperability between multiple independent implementations. Although it may be
possible to keep finding nits for a while longer it is the view of the shepherd that the documents
should be published and revised soon with any additional nits that are discovered during the
interoperability-testing phase.

Intellectual Property
=====================

No issues

Other Points
============

A major change for version 2.0 is a switch from XML to JSON. The WG would appreciate external
review from the JSON community.

There is one nit for each document. Both issues are small enough to be addressed together with
the IESG comments.

There are no downref issues.