Subject: [jose] draft revision to JOSE charter

From: Karen O'Donoghue <[email-masked]>
Date: Fri, 11 Jan 2013 15:02:54 -0500

Folks,

Below is a draft update to our charter based on discussions at the last 
IETF meeting. The key changes are adding key representations and 
algorithm identifiers to the scope of work. This includes some minor 
language updates in the general section, the addition of deliverables 
5-8, and the addition and modification of a number of milestones related 
to these documents.

In addition, the phrase "using a compact URL-safe representation" has 
been added to the descriptions of the first two deliverables and 
"compact JSON object" used in the milestones.

Jim and I will be submitting a revised charter shortly, and we would 
like your comments by 18 January if possible.

Thanks,
Karen

Description of Working Group

JavaScript Object Notation (JSON) is a text format for the serialization 
of structured data described in RFC 4627.  The JSON format is often used 
for serializing and transmitting structured data over a network 
connection.  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, message authentication codes (MACs), and 
key representations for data that is being carried in JSON format.

Different proposals for providing such security services have already 
been defined and implemented.  This Working Group's task is to 
standardize four kinds of security services, integrity protection 
(signature and MAC), encryption, key representations, and algorithm 
identifiers, in order to increase interoperability of security features 
between protocols that use JSON.  The Working Group will base its work 
on well-known message security primitives (e.g., CMS), and will solicit 
input from the rest of the IETF Security Area to be sure that the 
security functionality in the JSON format is correct.

This group is chartered to work on eight documents:

(1) A Standards Track document specifying how to apply JSON-structured 
integrity protection to data, including (but not limited to) JSON data 
structures, using a compact URL-safe representation.  "Integrity 
protection" includes public-key digital signatures as well as 
symmetric-key MACs.

(2) A Standards Track document specifying how to apply a JSON-structured 
encryption to data, including (but not limited to) JSON data structures, 
using a compact URL-safe representation.

(3) A Standards Track document specifying how to encode public keys as 
JSON-structured objects.

(4) A Standards Track document specifying algorithms and algorithm 
identifiers, including mandatory-to-implement algorithms for the 
previous three documents.

(5) A Standards Track document specifying how to apply JSON-structured 
integrity protection to data, including (but not limited to) JSON data 
structures, using a JSON representation supporting multiple recipients.  
This document will build upon the concepts and structures in (1).

(6) A Standards Track document specifying how to apply a JSON-structured 
encryption to data, including (but not limited to) JSON data structures, 
using a JSON representation supporting multiple recipients.  This 
document will build upon the concepts and structures in (2).

(7) A Standards Track document specifying how to encode private and 
symmetric keys as JSON-structured objects.  This document will build 
upon the concepts and structures in (3).

(8) A Standards Track application document specifying a means of 
protecting private and symmetric keys via encryption.  This document 
will build upon the concepts and structures in (2) and (7).  This 
document may register additional algorithms in registries defined by (4).

The working group may decide to address combinations of these goals in 
consolidated document(s), in which case the concrete milestones for 
these goals will be satisfied by the consolidated document(s).

Goals and Milestones

Jan 2012              Submit compact JSON object integrity document (1) 
as a WG item.

Jan 2012              Submit compact JSON object encryption document (2) 
as a WG item.

Jan 2012              Submit JSON key format document (3) as a WG item.

Jan 2012              Submit JSON algorithm document (4) as a WG item.

Feb 2013              Start Working Group Last Call on compact JSON 
object integrity document (1).

Feb 2013              Start Working Group Last Call on compact JSON 
object encryption document (2).

Feb 2013              Start Working Group Last Call on JSON key format 
document (3).

Feb 2013              Start Working Group Last Call on JSON algorithm 
document (4).

Mar 2013             Submit JSON object integrity document (1) to IESG 
for consideration as Standards Track document.

Mar 2013             Submit JSON object encryption document (2) to IESG 
for consideration as Standards Track document.

Mar 2013             Submit JSON key format document (3) to IESG for 
consideration as Standards Track document.

Mar 2013             Submit JSON algorithm document (4) to IESG for 
consideration as Standards Track document.

Mar 2013             Submit multi-recipient JSON object integrity 
document (5) as a WG item.

Mar 2013             Submit multi-recipient JSON object encryption 
document (6) as a WG item.

Mar 2013             Submit JSON private and symmetric key document (7) 
as a WG item.

Mar 2013             Submit JSON key protection application document (8) 
as a WG item.

Jun 2013              Start Working Group Last Call on multi-recipient 
JSON object integrity document (5).

Jun 2013              Start Working Group Last Call on multi-recipient 
JSON object encryption document (6).

Jun 2013              Start Working Group Last Call on JSON private and 
symmetric key document (7).

Jun 2013              Start Working Group Last Call on JSON key 
protection application document (8).

Jul 2013               Submit multi-recipient JSON object integrity 
document (5) to IESG for consideration as Standards Track document.

Jul 2013               Submit multi-recipient JSON object encryption 
document (6) to IESG for consideration as Standards Track document.

Jul 2013               Submit JSON private and symmetric key document 
(7) to IESG for consideration as Standards Track document.

Jul 2013               Submit JSON key protection application document 
(8) to IESG for consideration as Standards Track document.

---

From: Mike Jones <[email-masked]>
Date: Fri, 11 Jan 2013 20:22:59 +0000

+1

________________________________
From: Karen O'Donoghue
Sent: 1/11/2013 12:03 PM
To: [email-masked]
Subject: [jose] draft revision to JOSE charter

Folks,

Thanks,
Karen

Goals and Milestones

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Jan 2013 16:16:03 -0500

On 1,2,3,5,6:

Do I understand correctly that milestones 5 and 6 are intended to be something like the JSON serialization documents, whereas 1, 2, and 3 are supposed to be something like the current documents?  If that's the case, then we might as well call a spade a spade and remove "JSON-structured" from 1, 2, and 3.

I find that sort of back-tracking pretty distasteful, though.  As I've said before, it would be better if we could come up with a reasonable JSON syntax that would profile down to something compact and URL-safe.  

On 4:

This group has agreed time and again that we will not have mandatory to implement algorithms.  As Mr. Housley put it, according to the IETF 85 minutes, "Each app defines MTI, achieving separation of MTI from syntax.".  So the phrase "including mandatory-to-implement algorithms" needs to be struck from item (4).

On 7,8:

I have no idea what milestones 7 and 8 are supposed to entail.  JWE already has wrapped keys, and JWS should (for MAC).  As above, we should strive to get this right the first time instead of doing something halfway with a promise to patch it later.

--Richard

On Jan 11, 2013, at 3:02 PM, Karen O'Donoghue <[email-masked]> wrote:

> Folks,
> 
> Below is a draft update to our charter based on discussions at the last IETF meeting. The key changes are adding key representations and algorithm identifiers to the scope of work. This includes some minor language updates in the general section, the addition of deliverables 5-8, and the addition and modification of a number of milestones related to these documents.
> 
> In addition, the phrase "using a compact URL-safe representation" has been added to the descriptions of the first two deliverables and "compact JSON object" used in the milestones.
> 
> Jim and I will be submitting a revised charter shortly, and we would like your comments by 18 January if possible.
> 
> Thanks,
> Karen
> 
> 
> JavaScript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627.  The JSON format is often used for serializing and transmitting structured data over a network connection.  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, message authentication codes (MACs), and key representations for data that is being carried in JSON format.
> 
> Different proposals for providing such security services have already been defined and implemented.  This Working Group's task is to standardize four kinds of security services, integrity protection (signature and MAC), encryption, key representations, and algorithm identifiers, in order to increase interoperability of security features between protocols that use JSON.  The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct.
> 
> (1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures, using a compact URL-safe representation.  "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs.
> 
> (2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures, using a compact URL-safe representation.
> 
> (3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
> 
> (4) A Standards Track document specifying algorithms and algorithm identifiers, including mandatory-to-implement algorithms for the previous three documents.
> 
> (5) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures, using a JSON representation supporting multiple recipients.  This document will build upon the concepts and structures in (1).
> 
> (6) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures, using a JSON representation supporting multiple recipients.  This document will build upon the concepts and structures in (2).
> 
> (7) A Standards Track document specifying how to encode private and symmetric keys as JSON-structured objects.  This document will build upon the concepts and structures in (3).
> 
> (8) A Standards Track application document specifying a means of protecting private and symmetric keys via encryption.  This document will build upon the concepts and structures in (2) and (7).  This document may register additional algorithms in registries defined by (4).
> 
> The working group may decide to address combinations of these goals in consolidated document(s), in which case the concrete milestones for these goals will be satisfied by the consolidated document(s).
> 
> Goals and Milestones
> 
> Jan 2012              Submit compact JSON object integrity document (1) as a WG item.
> 
> Jan 2012              Submit compact JSON object encryption document (2) as a WG item.
> 
> Feb 2013              Start Working Group Last Call on compact JSON object integrity document (1).
> 
> Feb 2013              Start Working Group Last Call on compact JSON object encryption document (2).
> 
> Feb 2013              Start Working Group Last Call on JSON key format document (3).
> 
> Feb 2013              Start Working Group Last Call on JSON algorithm document (4).
> 
> Mar 2013             Submit JSON object integrity document (1) to IESG for consideration as Standards Track document.
> 
> Mar 2013             Submit JSON object encryption document (2) to IESG for consideration as Standards Track document.
> 
> Mar 2013             Submit JSON key format document (3) to IESG for consideration as Standards Track document.
> 
> Mar 2013             Submit JSON algorithm document (4) to IESG for consideration as Standards Track document.
> 
> Mar 2013             Submit multi-recipient JSON object integrity document (5) as a WG item.
> 
> Mar 2013             Submit multi-recipient JSON object encryption document (6) as a WG item.
> 
> Mar 2013             Submit JSON private and symmetric key document (7) as a WG item.
> 
> Mar 2013             Submit JSON key protection application document (8) as a WG item.
> 
> Jun 2013              Start Working Group Last Call on multi-recipient JSON object integrity document (5).
> 
> Jun 2013              Start Working Group Last Call on multi-recipient JSON object encryption document (6).
> 
> Jun 2013              Start Working Group Last Call on JSON private and symmetric key document (7).
> 
> Jun 2013              Start Working Group Last Call on JSON key protection application document (8).
> 
> Jul 2013               Submit multi-recipient JSON object integrity document (5) to IESG for consideration as Standards Track document.
> 
> Jul 2013               Submit multi-recipient JSON object encryption document (6) to IESG for consideration as Standards Track document.
> 
> Jul 2013               Submit JSON private and symmetric key document (7) to IESG for consideration as Standards Track document.
> 
> Jul 2013               Submit JSON key protection application document (8) to IESG for consideration as Standards Track document.
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 15 Jan 2013 22:20:36 +0000

Replies inline in green...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, January 15, 2013 1:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] draft revision to JOSE charter

On 1,2,3,5,6:

Yes, (1), (2), (3) (and (4)) are the deliverables in the present charter (http://datatracker.ietf.org/wg/jose/charter/).  The "JSON-structured" wording is from the current charter.  I suppose it could be changed to "JSON-based" if people prefer that.  But minimizing changes to the existing charter items also seems like a good goal.  I'd be fine with either the "JSON-structured" wording from the current charter or "JSON-based".

And yes, (5) and (6) are the JSON serialization documents, which we decided adopt as working group documents and create charter items for at the working group meeting in Atlanta.  Consensus to do this is recorded at http://www.ietf.org/proceedings/85/minutes/minutes-85-jose.    See http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 and http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04 for the current versions of these documents.

On 4:

This statement makes no sense, as our current charter already *requires* us to produce "A Standards Track document specifying mandatory-to-implement algorithms for the other three documents".  The rechartering is about adding the new deliverables 5-8 - not changing our existing deliverables, of which this is one already one.

On 7,8:

I'm surprised that you say that don't understand 7 and 8, as you were in the Friday morning meeting in Atlanta that was organized by Joe Hildebrand and Jim Schaad that defined them.  The minutes of that meeting are at http://www.ietf.org/mail-archive/web/jose/current/msg01337.html.  Deliverable (A) in the minutes is charter item (7).  Deliverable (B) in the minutes is charter item (8).

(7) extends (3) to define JSON representations for private and symmetric keys (whereas (3) only defines representations for public keys).  See http://tools.ietf.org/html/draft-jones-jose-json-private-and-symmetric-key-00 for a draft that does this.

As we discussed at that meeting, while JWE uses wrapped key *values* (wrapped CMKs), this new document that Matt is writing will enable us to wrap both key values and associated key properties.  It wraps a JWK representation (which per (7), may represent private and symmetric keys), including potential key properties as the key's "alg" and "kid" values, as well as others that may be used.  It's intentionally more general than the wrapped CMK value used in JWE, again, as discussed during the Friday meeting in Atlanta.

--Richard

                                                                Best wishes,

                                                                -- Mike

> [email-masked]<mailto:[email-masked]>

jose mailing list

[email-masked]<mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Jan 2013 11:21:13 -0500

Inline

> -----
> Yes, (1), (2), (3) (and (4)) are the deliverables in the present charter (http://datatracker.ietf.org/wg/jose/charter/).  The “JSON-structured” wording is from the current charter.  I suppose it could be changed to “JSON-based” if people prefer that.  But minimizing changes to the existing charter items also seems like a good goal.  I’d be fine with either the “JSON-structured” wording from the current charter or “JSON-based”.
>  
> And yes, (5) and (6) are the JSON serialization documents, which we decided adopt as working group documents and create charter items for at the working group meeting in Atlanta.  Consensus to do this is recorded at http://www.ietf.org/proceedings/85/minutes/minutes-85-jose.    See http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 andhttp://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04 for the current versions of these documents.

I just don't see any reason for us to have separate documents for a "JSON serialization".  It's what we should have done in the first place -- make something "JSON-structured".  Rather than having separate documents/milestones, let's just put the JSON stuff in the base spec.  It will help ensure coherence between the formats, and it's really not that much text.

If we make the explicit decision not to include a JSON format in our base deliverables, then we should just strike "JSON" altogether.  JW* is as much "ASN.1-based" as it is "JSON-based" -- it contains base64-serialized objects of both types.

> This statement makes no sense, as our current charter already *requires* us to produce “A Standards Track document specifying mandatory-to-implement algorithms for the other three documents”.  The rechartering is about adding the new deliverables 5-8 – not changing our existing deliverables, of which this is one already one.

You want to deviate from the first three milestones, I want to deviate from this one :)

There have been clear consensus calls at the last few IETF meetings that run against this milestone.  If the chairs would like to have an explicit call on removing "mandatory to implement" from this milestone, then I would support that.

> I’m surprised that you say that don’t understand 7 and 8, as you were in the Friday morning meeting in Atlanta that was organized by Joe Hildebrand and Jim Schaad that defined them.  The minutes of that meeting are at http://www.ietf.org/mail-archive/web/jose/current/msg01337.html.  Deliverable (A) in the minutes is charter item (7).  Deliverable (B) in the minutes is charter item (8).
>  
> As we discussed at that meeting, while JWE uses wrapped key *values* (wrapped CMKs), this new document that Matt is writing will enable us to wrap both key values and associated key properties.  It wraps a JWK representation (which per (7), may represent private and symmetric keys), including potential key properties as the key’s “alg” and “kid” values, as well as others that may be used.  It’s intentionally more general than the wrapped CMK value used in JWE, again, as discussed during the Friday meeting in Atlanta.

I was at that meeting, and I did not leave convinced that having a separate document was the correct path, as opposed to doing wrapped keys right the first time.

JWE already has a mechanism for wrapping keys.  Instead of inventing some separate syntax, we should consolidate the "wrapped key" bits of JWE into an object ("JSON Wrapped Key", or JWK :) ), and give that object a way to protect attributes.  If there are no attributes, then this just looks like what's already in JWE. I can send a more thorough proposal to the list if you like.

In any case, I oppose adding these two milestones based on the above.  If we are going to handle this separately, then 7 and 8 should be combined, since the format for symmetric/private keys will have to have a protection mechanism.

--Richard

---

From: Mark Watson <[email-masked]>
Date: Fri, 18 Jan 2013 17:13:53 +0000

> In any case, I oppose adding these two milestones based on the above.  If we are going to handle this separately, then 7 and 8 should be combined, since the format for symmetric/private keys will h…

Both the W3C WebCrypto and HTML media groups have use-cases for an unprotected representation of a symmetric key. In the WebCrypto case for export of such keys (where that is allowed according to the key properties) and for a representation that includes attributes which could then be wrapped (with AES Key Wrap, for example). In the HTML media group they would like to use this format for the "clearkey" key system for encrypted media, where the requirement is again just for a clear unprotected representation of the key and associated attributes.

So (7) at least has stand-alone use-cases.

…Mark

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Jan 2013 12:27:48 -0500

Hey Mark,

> So (7) at least has stand-alone use-cases.

Just to clarify: I certainly agree that need to solve the problem.  I'm just not really convinced in needs a separate document (as opposed to an upgrade to JWK).

Cheers,
--Richard

---

From: Mike Jones <[email-masked]>
Date: Fri, 18 Jan 2013 21:39:36 +0000

I'll observe that the primary purpose of the rechartering is to authorize additional work to occur within the JOSE working group.  A secondary artifact of doing the restructuring is listing possible delivery vehicles for the outputs of the working group.  I'll note that the rechartering text *explicitly allows* the working group to combine deliverables if it chooses to; it says "The working group may decide to address combinations of these goals in consolidated document(s), in which case the concrete milestones for these goals will be satisfied by the consolidated document(s)".  So I would assert that arguments against the current rechartering text of the kind "deliverables X and Y should be combined" should not carry much weight, as the working group is free to make explicit decisions down the road to combine deliverables if it so sees fit.

Whereas, allowing them to be separate in the charter gives the working group more flexibility.  Given that in Atlanta several working group members spoke up for keeping each of these deliverables separate, I don't think there's general agreement to combine them.  Thus, moving forward with rechartering them as separate items let the work of the working group continue, while leaving open the possibility of combining deliverables, should there be consensus to do so.  I believe we should proceed on that basis.

Other working groups, including OAuth, W3C WebCrypto, and OpenID Connect are all depending upon us to produce our specifications in a timely fashion.  We owe it to them and ourselves to continue making timely progress.  Rechartering is necessary to enable the progress that they're counting on.

Other comments inline in green...

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, January 18, 2013 8:21 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [jose] draft revision to JOSE charter

Inline

This is one of the places that you make the argument that we should block rechartering unless we combine deliverables.  As already discussed, we already have the freedom to combine deliverables later, so this doesn't seem like a reasonable basis for not proceeding with the rechartering.

The reason that the original charter said "JSON-structured" rather than "JSON" was exactly to allow URL-safe representations (since JSON is not URL-safe).  The header is represented as JSON object - hence meeting the JSON-structured criteria in the current charter.  (Again, if you prefer "JSON-based" over "JSON-structured", I'm OK with that wording change, as is doesn't change the meaning of the text.)

We *did* make an explicit decision to also include JSON representations in our output, Karen's consensus call for which is recorded in the Atlanta minutes.  Hence, the need for deliverables (5) and (6).

No, I don't want to deviate from the first three milestones.  We already have working group drafts fulfilling them.

Those consensus calls have not occurred in this working group, nor do they apply to the output of this working group, to my knowledge.  Decisions that may be right on one application context may not be the right ones in different application contexts.  Nor do I think we should delay rechartering to possibly tweak this existing deliverable.  We need the new work items to be able to make the progress that others are counting on us for.

Further, I believe the IETF in general likes to have enough features be mandatory-to-implement such that interoperable implementations result.  That's the reason for the existing charter language, as I understand it.

I believe that this is another instance of you trying to make the argument that we should block rechartering unless we combine deliverables, which again, I believe isn't a valid reason not to proceed.

I'll note that you're expressing agreement with the need to define a wrapped key representation, so that means that you support us producing deliverable (8).  The charter mostly is about "what".  We can continue to refine "how" in the working group after the charter authorizes the work.

Again, given that the working group can combine deliverables if it sees fit, arguing not to enumerate those deliverables in the rechartering because they have not been combined doesn't seem like a reasonable position.

--Richard

                                                                Cheers,

                                                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Jan 2013 18:33:58 -0500

I agree that we should work on moving the docs to completion.  I just submitted a set of issues that I've been collecting for a little while, meaning to submit.

Given that we're free to combine use documents, I guess I'll let most of the below slide.  For the deliverables I thought should be combined, I will propose some ways forward in the next few days.

Chairs: I would like to request a consensus call on whether we should take the following two actions: 
(1) Update item 4 in the charter to remove the string ", including mandatory-to-implement algorithms", and 
(2) Update draft-ietf-jose-json-web-algorithms to remove requirements levels (namely, the "Implementation Requirements" columns)

--Richard

On Jan 18, 2013, at 4:39 PM, Mike Jones <[email-masked]> wrote:

> I’ll observe that the primary purpose of the rechartering is to authorize additional work to occur within the JOSE working group.  A secondary artifact of doing the restructuring is listing possible delivery vehicles for the outputs of the working group.  I’ll note that the rechartering text *explicitly allows* the working group to combine deliverables if it chooses to; it says “The working group may decide to address combinations of these goals in consolidated document(s), in which case the concrete milestones for these goals will be satisfied by the consolidated document(s)”.  So I would assert that arguments against the current rechartering text of the kind “deliverables X and Y should be combined” should not carry much weight, as the working group is free to make explicit decisions down the road to combine deliverables if it so sees fit.
>  
> Whereas, allowing them to be separate in the charter gives the working group more flexibility.  Given that in Atlanta several working group members spoke up for keeping each of these deliverables separate, I don’t think there’s general agreement to combine them.  Thus, moving forward with rechartering them as separate items let the work of the working group continue, while leaving open the possibility of combining deliverables, should there be consensus to do so.  I believe we should proceed on that basis.
>  
> Other working groups, including OAuth, W3C WebCrypto, and OpenID Connect are all depending upon us to produce our specifications in a timely fashion.  We owe it to them and ourselves to continue making timely progress.  Rechartering is necessary to enable the progress that they’re counting on.
>  
> This is one of the places that you make the argument that we should block rechartering unless we combine deliverables.  As already discussed, we already have the freedom to combine deliverables later, so this doesn’t seem like a reasonable basis for not proceeding with the rechartering.
>  
> The reason that the original charter said “JSON-structured” rather than “JSON” was exactly to allow URL-safe representations (since JSON is not URL-safe).  The header is represented as JSON object – hence meeting the JSON-structured criteria in the current charter.  (Again, if you prefer “JSON-based” over “JSON-structured”, I’m OK with that wording change, as is doesn’t change the meaning of the text.)
>  
> We *did* make an explicit decision to also include JSON representations in our output, Karen’s consensus call for which is recorded in the Atlanta minutes.  Hence, the need for deliverables (5) and (6).
>  
> > On 4:
> > 
> No, I don’t want to deviate from the first three milestones.  We already have working group drafts fulfilling them.
>  
> Further, I believe the IETF in general likes to have enough features be mandatory-to-implement such that interoperable implementations result.  That’s the reason for the existing charter language, as I understand it.
>  
> > On 7,8:
> > 
> I believe that this is another instance of you trying to make the argument that we should block rechartering unless we combine deliverables, which again, I believe isn’t a valid reason not to proceed.
>  
> I’ll note that you’re expressing agreement with the need to define a wrapped key representation, so that means that you support us producing deliverable (8).  The charter mostly is about “what”.  We can continue to refine “how” in the working group after the charter authorizes the work.
>  
> Again, given that the working group can combine deliverables if it sees fit, arguing not to enumerate those deliverables in the rechartering because they have not been combined doesn’t seem like a reasonable position.
>  
> --Richard
>                                                                 Cheers,
>                                                                 -- Mike
>  
>

---

From: Harry Halpin <[email-masked]>
Date: Wed, 23 Jan 2013 12:18:25 +0100

I'd just like to note that the W3C Web Crypto WG (of which Mike Jones is 
a member) have been informally liasoning. However, as we enter Last Call 
we may need to formalize this relationship more.

  I expect the Web Crypto WG to give a formal review of JOSE specs when 
they hit Last Call. We probably don't need to sync charters (as that 
would delay JOSE and we'd prefer JOSE to be stable *before* we hit Last 
Call), but we do need to review and may need to ask for changes. If that 
is necessary to note in the rechartering, please do so.

And yes, its via discussions in the WebCrypto WG that the need for 
private and symmetric key JOSE formats was brought up. Our spec is not 
in Last Call, and thus our use of those is not yet set in stone, but it 
does seem like a good idea to add them to the charter as we may need them.

   cheers,
     harry

On 01/11/2013 09:02 PM, Karen O'Donoghue wrote:
> Folks,
>
> Below is a draft update to our charter based on discussions at the 
> last IETF meeting. The key changes are adding key representations and 
> 5-8, and the addition and modification of a number of milestones 
> related to these documents.
>
> JavaScript Object Notation (JSON) is a text format for the 
> serialization of structured data described in RFC 4627.  The JSON 
> format is often used for serializing and transmitting structured data 
> over a network connection.  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, message 
> authentication codes (MACs), and key representations for data that is 
> being carried in JSON format.
>
> identifiers, in order to increase interoperability of security 
> features between protocols that use JSON.  The Working Group will base 
> its work on well-known message security primitives (e.g., CMS), and 
> will solicit input from the rest of the IETF Security Area to be sure 
> that the security functionality in the JSON format is correct.
>
> (2) A Standards Track document specifying how to apply a 
> JSON-structured encryption to data, including (but not limited to) 
> JSON data structures, using a compact URL-safe representation.
>
> structures, using a JSON representation supporting multiple 
> recipients.  This document will build upon the concepts and structures 
> in (1).
>
> (6) A Standards Track document specifying how to apply a 
> JSON-structured encryption to data, including (but not limited to) 
> JSON data structures, using a JSON representation supporting multiple 
> recipients.  This document will build upon the concepts and structures 
> in (2).
>
> Mar 2013             Submit JSON object encryption document (2) to 
> IESG for consideration as Standards Track document.
>

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 25 Jan 2013 08:44:09 +0100

From a process perspective, my recommendation would be for Web Crypto to review the JOSE deliverables *before* they hit last call.  

What would be a good time for that from the Jose WG's perspective?

Thanks,
-- 
Thomas Roessler, W3C <[email-masked]> (@roessler)

On 2013-01-23, at 12:18 +0100, Harry Halpin <[email-masked]> wrote:

> I'd just like to note that the W3C Web Crypto WG (of which Mike Jones is a member) have been informally liasoning. However, as we enter Last Call we may need to formalize this relationship more.
> 
> I expect the Web Crypto WG to give a formal review of JOSE specs when they hit Last Call. We probably don't need to sync charters (as that would delay JOSE and we'd prefer JOSE to be stable *before* we hit Last Call), but we do need to review and may need to ask for changes. If that is necessary to note in the rechartering, please do so.
> 
> And yes, its via discussions in the WebCrypto WG that the need for private and symmetric key JOSE formats was brought up. Our spec is not in Last Call, and thus our use of those is not yet set in stone, but it does seem like a good idea to add them to the charter as we may need them.
> 
>  cheers,
>    harry
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 25 Jan 2013 11:28:37 -0500

In my view as a humble participant, now.

It seems that there is a fair bit of disagreement about what exactly should be the relationship between WebCrypto and JOSE, as evidenced by a recent thread on the WebCrypto mailing list [1].  It would be good to find out sooner rather than later what the requirements are for JOSE from WebCrypto, and whether the current specs meet these requirements.

--Richard

[1] <http://lists.w3.org/Archives/Public/public-webcrypto/2013Jan/0024.html>

---

From: Harry Halpin <[email-masked]>
Date: Wed, 30 Jan 2013 00:21:18 +0100

To clarify, we will organize a formal review from Web Crypto in late 
February/early March before Last Call ideally, and one during Last Call 
if needed.

As WebCrypto will not likely hit Last Call till Fall this year, it is 
always possible new requirements may happen after the proposed Last Call 
dates, but I don't think that will necessitate changes to the draft 
charter.

Do notify us once the charter is updated/approved.

I think Mike has done a great job liasoning between the WGs and Richard 
has gone out of his way to get compatibility better. However, there are 
different requirements in WebCrypto than JOSE for some features and we 
need to make sure the members of the WebCrypto API who aren't also 
members of JOSE (i.e. Mike and Richard) spend the time to clarify their 
requirements before you hit Last Call.

    cheers,
        harry