Re: [Jmap] Secdir last call review of draft-ietf-jmap-sharing-07

[Neil Jenkins <[e-mail]>]

Hi Yaron,

Thank you for the review. I have published an updated draft <https://www.ietf.org/archive/id/draft-ietf-jmap-sharing-08.html> addressing your comments, as detailed below.

> ### What are groups?
> In Sec. 2, a group is defined as a "group of people". Directories often support
> groups of resources, too.

Yes, I have changed this definition to just a "group of other principals".

> Also, can groups be hierarchical, i.e. contain other groups?

This would be up to the directory system backing the principals, and not relevant to the protocol, as there's no way to create a group or manage membership via this protocol.

> ### Principal type
> Why is the type not immutable? It is just as security-sensitive as the name, maybe more so.

As noted, in the `Principal/set` method description, it's highly likely the server will forbid any changes by the user via this protocol (again, any such changes would be done within the directory management system by whomever is authorised to do so). The spec recommends users be allowed to update their own name, description, and time zone, but that's it, and it recognises this too may be forbidden for security reasons.

The `type` therefore is likely to only be changeable by an admin of the directory and the type is mutable simply because this is likely to be mutable in whatever system is backing this. While it probably shouldn't change, I can see it happening simply because someone made a mistake, and then updated it. If we made it immutable, but it was mutable in the entity system backing the API then an implementer would either have to violate the RFC or do considerable contortions to make the id different.

> ### Time zone ID
> I think you mean time zone name, and please include an example such as America/Los_Angeles.

I have changed this to "time zone name". There is already an example in the examples section.

> ### Filter definition
> "Looks for the text" is very informal wording. Perhaps: the filter matches if
> the filter string is a substring of the name (email, etc.) property. Also, I
> assume (but you do not say) that all filter properties are optional.

I have rewritten this, and noted that all are optional.

> ### Spoofing
> The type and email properties are also sensitive. And probably capabilities.

I have added that type/email properties are relevant here. Capabilities are to do with the data associated with the Principal and I have now marked them as `server-set` in the object definition; they can't be modified directly as properties.

> ### ShareNotification Object Properties
> Why is the changedBy property restricted to a Person? What about cases when it's an application that makes the change?

I have changed "person" to "entity" to cover this.

> ### ShareNotifiction sent to a group principal
> For some reason this is SHOULD NOT. IMO this is a security feature, and often
> has a trade off vs. usability, so it should be left to the server's discretion.

Yes, agreed. I've changed this to a "MAY choose not".

> ### Object Properties objectType
> Where is the list of possible data types defined?

In the JMAP Data Types registry <https://www.iana.org/assignments/jmap/jmap.xhtml#jmap-data-types>. I have noted this in the document.

> ### ShareNotification Filtering
> Again, please specify that each of the FilterCondition properties is optional.

Done.

Cheers,
Neil.