Subject: [scim] Ben Campbell's Discuss on draft-ietf-scim-core-schema-20: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 May 2015 14:19:21 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-scim-core-schema-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

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

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

---

From: Phil Hunt <[email-masked]>
Date: Wed, 13 May 2015 16:22:07 -0700

Ben,

Thanks again for another review! 

Regarding the discuss item, I think you are correct, we should change password storage from SHOULD NOT to MUST NOT be clear text.

Regarding the other nits, I will apply them to the next edit along with the above discuss item.

Phil

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

> On May 13, 2015, at 2:19 PM, Ben Campbell <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 May 2015 21:26:29 -0500

Thanks, clearing the discuss now.

On 13 May 2015, at 18:22, Phil Hunt wrote:

> Regarding the discuss item, I think you are correct, we should change 
> password storage from SHOULD NOT to MUST NOT be clear text.
>
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 May 2015 13:02:15 -0700

Please note, I will publish draft 21 in the coming days to handle Ben’s comments and any other pending comments.

Phil

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

> On May 13, 2015, at 7:26 PM, Ben Campbell <[email-masked]> wrote:
>