Subject: [scim] Stephen Farrell's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 14 May 2015 01:42:21 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-scim-core-schema-20: No Objection

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/

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

---

From: Phil Hunt <[email-masked]>
Date: Mon, 18 May 2015 13:42:20 -0700

Stephen,

Thanks for your feedback!

Comments inline.  

I plan to post draft 21 including these comments later today.

Phil

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

> On May 14, 2015, at 1:42 AM, Stephen Farrell <[email-masked]> wrote:
> 

ok.  added "(e.g., a directory)” as an example.
> that such "sharing" is not allowed? (As a future extension, if

Agreed. I’m not aware of any current proposals. 
> mean all 24 hours of Jan 1 this year or just the first second

The reference in XML-schema says that no properties except timezoneOffset are permitted to be absent.  Therefore time must always be included. I will add text indicating such in case some don’t want to chase the reference.
> cleartext password which definitely needs fixing.

Should be fixed. Added further clarification for draft 21. Let me know if this works.
> this respect and would be better fixed now.

Agreed. However, I think the consensus is to continue with the current definition due to a desire to follow the LDAP definition.

I think a future extension could handle this more generically. This might fit in as part of the overall discussion around credential management that has been proposed in the WG.
> that mistake in the past and it causes interop problems.

Agreed. I have added this to the definition.

> recently - it's long and detailed and I didn't have time.

Yes. We did have to correct a few characteristics that have evolved over time during WG consensus process.
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Leif Johansson <[email-masked]>
Date: Tue, 19 May 2015 00:00:53 +0200

> Agreed. I’m not aware of any current proposals. 

A warning we can do. And it will be ignored (or at best passed
to lawyers) but I'm not sure SCIM is the right place to design
a privacy-layer for pass-by-value.

	Cheers Leif