Javascript Object Signing and Encryption
charter-ietf-jose-03

[Ballot comment]
It seems that the use of MD URL makes the text difficult to read (probably a datatracker rendering issue).

The 4th paragraph starting with "A multi-decade research activity..." is a little long (suggest to skip the first sentence). Having two sentences starting with "Some" makes this paragraph rather vague. Finally, once ZKP abbreviation is introduced, then let's use it.

s/This group is chartered to work on the following deliverables/This group is chartered to work on the following goals/ as later in the charter "One or more of these goals may be combined into a single document" (which would make sense).

About the CBOR encoding, should CDDL be mentioned ? Should CBOR WG be listed in the interested parties ?

[Ballot comment]
Basically LGTM. There was one paragraph I found a little stilted, I provide some suggestions below. Take 'em or leave 'em, up to you.

While this sentence is grammatical, IMO it's a little denser to parse than it needs to be: "Concurrent to the growth of adoption of these standards to express and communicate sensitive data has been an increasing societal focus on privacy." Perhaps something like this instead? "As adoption of these standards to express and communicate sensitive data has grown, so too has an increasing societal focus on privacy." (Arguably "grown ... increasing" is redundant and "increasing" could be dropped but I don't think it hurts if you want to emphasize by repetition.)

For similar reasons maybe reword "Common privacy themes in identity solutions are user consent, minimal disclosure, and unlinkability." For example, "User consent, minimal disclosure, and unlinkability are common privacy themes in identity solutions."

[Ballot comment]
My previous feedback (https://datatracker.ietf.org/doc/charter-ietf-jose/ballot/329647/#benoit-claise) was not taken into account. So here it is again:

I always prefer to see the milestones, to understand how long the charter
completion could take, and to see the logical order of the document delivery.
However, I know that some people don't consider the milestones part of the
charter. Let's not redo the discussion here, but can you please order the
milestones in a logical order. For example, I guess that the following entry
should be number 1.
  (7) An Informational document detailing Use Cases and Requirements
  for JSON Object Signing and Encryption (JOSE).

[Ballot block]
I support Pete's points on this.  One further point:

The proposed charter makes the following change to deliverable (1):
CURRENT: "integrity protection to data, including (but not limited to) JSON data structures."
PROPOSED: "... integrity-protected data using JSON-based data structures, including (but not limited to) JSON data structures."
This appears to change the antecedent of the "including ..." clause to the metadata instead of the data.  I don't think this change is what the WG intended.  For example, it would not be acceptable for the group to work on an ASN.1 data structure that was somehow "JSON-based".

Proposed change:
OLD: "including (but not limited to) JSON data structures."
NEW: "where the data to be protected includes (but is not limited to) JSON data structures"
... in both (1) and (2)

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for
  JSON with encryption, digital signatures, and message authentication
  codes (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such
  as encryption, digital signatures, and message authentication
  codes (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for JSON
  with encryption, digital signatures, and message authentication codes
  (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such
  as encryption, digital signatures, and message authentication
  codes (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for JSON
  with encryption, digital signatures, and message authentication codes
  (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such
    as encryption, digital signatures, and message authentication
    codes (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for JSON
  with encryption, digital signatures, and message authentication codes
  (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such as
  encryption, digital signatures, and message authentication codes
  (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot comment]
This was formerly a BLOCK, moved to a COMMENT:

> The WG will develop a generic syntax that can be used by
> applications to secure JSON-data, but it will be up to the
> application to fully specify the use of the WG's documents
> much the same way S/MIME is the application of CMS to
> MIME-based media types.

When I've asked App folks who are working on new JSON-based protocols and formats about JOSE, the feedback I've gotten is that they don't see the applicability of JOSE to their work.  It's possible that this is simply short-sightedness, but it disturbs me.  I'd like to have some assurance that there is some real communication between JOSE development and the target uses -- the JSON-based applications -- and that the needs of those targets are being fed into JOSE now, during the development cycle.

Part of this probably involves pushing items 7 and 8 up to the top, working on them actively -- with direct input from the target users -- before nailing down the details.

--- UPDATE for -01-02 ---
The following text was added in -01-02:
The WG will strive to gather use cases to ensure the broadest possible applicability of the mechanism.

That, in addition to discussion with the chairs, makes me happy that we will collectively connect with potential users and collect use cases, dispel myths, figure out who can and should make use of this, and sing "Kumbayah".

[Ballot comment]
I always prefer to see the milestones, to understand how long the charter completion could take, and to see the logical order of the document delivery.
However, I know that some people don't consider the milestones part of the charter. Let's not redo the discussion here, but can you please order the milestones in a logical order.
For example, I guess that the following entry should be number 1.
  (7) An Informational document detailing Use Cases and Requirements
  for JSON Object Signing and Encryption (JOSE).

[Ballot comment]
I always prefer to see the milestones, to understand how long the charter completion could take, and to see the logical order of the document delivery.
However, I know that some people don't consider the milestones part of the charter. Let's not redo the discussion here, but can you please order the milestones in a logical order.
For example, I guess that the following entry should be number 1.
  (7) An Informational document detailing Use Cases and Requirements for
  JSON Object Signing and Encryption (JOSE).

[Ballot block]
I have two points:

1.
> The WG will develop a generic syntax that can be used by
> applications to secure JSON-data, but it will be up to the
> application to fully specify the use of the WG's documents
> much the same way S/MIME is the application of CMS to
> MIME-based media types.

When I've asked App folks who are working on new JSON-based protocols and formats about JOSE, the feedback I've gotten is that they don't see the applicability of JOSE to their work.  It's possible that this is simply short-sightedness, but it disturbs me.  I'd like to have some assurance that there is some real communication between JOSE development and the target uses -- the JSON-based applications -- and that the needs of those targets are being fed into JOSE now, during the development cycle.

Part of this probably involves pushing items 7 and 8 up to the top, working on them actively -- with direct input from the target users -- before nailing down the details.

2.
> (1) A Standards Track document or documents specifying how
> to apply JSON-structured integrity protection to data,
...
> (2) A Standards Track document or documents specifying how
> to apply a JSON-structured encryption to data,

I know this text is from the original charter, but I don't understand what "JSON-structured integrity protection" and "JSON-structured encryption" mean.  "JSON-structured data" makes sense.  But how does the adjective "JSON-structured" apply to the noun "encryption"?