Ballot for draft-ietf-scim-core-schema
Yes
No Objection
Note: This ballot was opened for revision 17 and is now closed.
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!