Subject: [apps-discuss] a new web security list

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Feb 2011 14:24:58 -0700

Folks, a dedicated list has been established for discussion about
requirements and potential implementation of JSON to provide security
services for Web-based applications. You can subscribe here:

https://www.ietf.org/mailman/listinfo/woes

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 17 Feb 2011 14:03:50 -0800

> https://www.ietf.org/mailman/listinfo/woes

It's almost refreshing to see a healthy anticipation of resistance from 
potential participants.

I assume that accounts for the second word in the acronym:

> Web Objection Encryption and Signatures (WOES)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Feb 2011 15:05:42 -0700

>> Web Objection Encryption and Signatures (WOES)

That's classic! I'll blame the Security Area ADs. ;-)

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 17 Feb 2011 15:33:28 -0800

> That's classic! I'll blame the Security Area ADs. ;-)

I object.

d/

-- 

   Dave Crocker

---

From: Eric Burger <[email-masked]>
Date: Thu, 17 Feb 2011 19:13:37 -0500

You object to the object? <g>

On Feb 17, 2011, at 6:33 PM, Dave CROCKER wrote:

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Feb 2011 19:15:17 -0500

that's cryptic.

---

From: Graham Klyne <[email-masked]>
Date: Sun, 20 Feb 2011 18:32:11 +0000

Peter,

I'm rather puzzled by your description.

Using "JSON to provide security services" seems a bit like "using gasolene to 
provide transportation services".  I.e., it has a part to play, but doesn't seem 
to be more than a bit-part player in the whole service provision issue.

In providing security services, I would expect the encoding syntax of the 
service to be the easy bit.  Determining the trust and service models is harder, 
and that should stand independently of (say) JSON, no?

#g
--

Peter Saint-Andre wrote:
> ------------------------------------------------------------------------
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Feb 2011 12:04:29 +0200

Maybe the charter text writeup I did earlier this year may help you:

-----

JSON Cryptographic Syntax and Processing

Background

JSON (an acronym for JavaScript Object Notation) is a text format for the
serialization of structured data. It is derived from the JavaScript
programming language for representing simple data structures and associative
arrays, called objects. Despite its relationship to JavaScript, it is
language-independent, with parsers available for almost every programming
language.

The JSON format is described in RFC 4627 and builds on two structures:
* A collection of name/value pairs. In various languages, this is realized
as an object, record, struct, dictionary, hash table, keyed list, or
associative array.
* An ordered list of values. In most languages, this is realized as an
array, vector, list, or sequence.

The JSON format is often used for serializing and transmitting structured
data over a network connection. It was initially used in the Web environment
to transmit data between a server and web application, serving as an
alternative to XML. Now, JSON is being used in various other protocols as
well.

With the increased usage of JSON in protocols there is now also the desire
to offer security services, such as encryption, and message signing, for
JSON encoded data. Different proposals for providing these security services
have been defined and implemented.  Examples are: JSON Web Token [JWT],
Simple Web Tokens [SWT], Magic Signatures [MagicSignatures], JSON Simple
Sign [JSS]. 

This working group aims to develop specifications to standardize these
security services for JSON encoded data to improve interoperability, and to
increase confidence in the offered security functionality based on the
expert review process utilized in the IETF. Future work in the group could
include support for other security services. Re-chartering of the group is,
however, required.

This working group aims to re-use well-defined concepts from Cryptographic
Message Syntax
(CMS) [CMS], XML Digital Signature [XMLDSIG] and XML Encryption [XMLENC].
Since this work is within the realm of the security domain, respective
experts will be involved.

References

[JWT] M. Jones, et al. "JSON Web Token (JWT)", 
draft-jones-json-web-token-01, January 2011.  Available at
http://self-issued.info/docs/draft-jones-json-web-token.html.

[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", September
2010.

[MagicSignatures] Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", August 2010.

[SWT] Hardt, D. and Y. Goland, "Simple Web Token (SWT)", Version 0.9.5.1,
November 2009.

XMLDIG] W3C, "XML Signature Syntax and Processing (Second Edition)",
available at
http://www.w3.org/TR/xmldsig-core/, Jun. 2008. 

[XMLENC] W3C, "XML Encryption Syntax and Processing", available at
http://www.w3.org/TR/xmlenc-core/, Dec. 2002.

[CMS]  R. Housley, "Cryptographic Message Syntax", RFC 3852, Jul. 2004. 

Deliverables

A document illustrating how to digitally sign arbitrary JSON encoded data.
This document shall be Standards Track.

A document illustrating how to encrypt arbitrary JSON encoded data. This
document shall be Standards Track.

Goals and Milestones

Dec 2010    Submit initial document on JSON object signing as individual
submission.

Feb 2011    Submit initial document on JSON object encryption as individual
submission.

Mar 2011    Hold a BOF at IETF#80 (Prague).

May 2011    Formation of a working group

Jul 2011    Submit JSON object signing document as a WG item.

Jul 2011    Submit JSON object encryption document as a WG item.

Dec 2011    Start Working Group Last Call on JSON object signing document.

Dec 2011    Start Working Group Last Call on JSON object signing document.

Feb 2012    Submit JSON object signing document to IESG for consideration as
Standards Track document.

Feb 2012    Submit JSON object encryption document to IESG for consideration
as Standards Track document.

-------

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 21 Feb 2011 11:07:06 -0700

And we should take this discussion to the WOES list, please.  There are now
subscribers there that are not on apps-discuss.

-- 
Joe Hildebrand