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

Small nit in Section 1.1

s/Throughout this documents all figures MAY contain spaces/Throughout
this document all figures may contain spaces

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

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.

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".

my comments on api apply to the security considerations here also.

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.

- 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!