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> On Jan 25, 2013, at 2:44 AM, Thomas Roessler <[email protected]> wrote: > 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 protected]> (@roessler) > > > > On 2013-01-23, at 12:18 +0100, Harry Halpin <[email protected]> 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 >> >> >> >> 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 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. >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> >> >> > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
