Re: [woes] WOES Charter Proposal

[Mike Jones <[e-mail]>]

For what it's worth, the HMAC and signature output representations to use *are* explicitly specified in the JWS and JWT specs (which is necessary to achieve interoperability).

				-- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Thursday, June 16, 2011 11:43 AM
To: Mike Jones
Cc: Joe Hildebrand; Tschofenig, Hannes (NSN - FI/Espoo); extManger, James H; Sean Turner; [e-mail]; [e-mail]
Subject: Re: [woes] WOES Charter Proposal



On 16 Jun 2011, at 19:14, Mike Jones <[e-mail]> wrote:

> About (3), you sign and encrypt things with keys.  The header/envelope often references the key, which must have a known representation.  In a JSON-based world, it's often simpler to represent public keys as JSON rather than ASN.1 (for the same reasons that we're considering JSON signatures and encryption when we already have CMS).  It's not creep - it's providing a complete JSON-based signing/encryption solution.

And you need algorithm ids and parameters and a way to represent hmac outputs etc but those are not called out specifically which makes (3) look like a slippery slope.

> 
> I personal agree that (4) schemas is creep, but I support Joe's desire to have it considered as an input document.

I'm thinking in charter terms, this is the first I think I've heard of non crypto work being proposed here (sorry if I missed that).

Simpler, more tightly scoped, charters seem to get approved easier,

Cheers 
S


> 
>                -- Mike
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]] 
> Sent: Thursday, June 16, 2011 10:52 AM
> To: Joe Hildebrand
> Cc: Mike Jones; Tschofenig, Hannes (NSN - FI/Espoo); ext Manger, James H; Sean Turner; [e-mail]; [e-mail]
> Subject: Re: [woes] WOES Charter Proposal
> 
> 
> 3 & 4 there look a bit like scope-creep to me
> 
> Why are they absolutely needed?
> 
> S.
> 
> On 16/06/11 18:33, Joe Hildebrand wrote:
>> Slight tweaks
>> 
>> 
>> On 6/16/11 11:26 AM, "Mike Jones" <[e-mail]> wrote:
>> 
>>>    1) A JSON-based method of applying digital signatures and keyed 
>>> message digests to data that may represent JSON data structures.
>> 
>> ... may represent arbitrary data, including JSON data structures and 
>> text
>> 
>>>    2) A JSON-based method of applying encryption to data that may 
>>> represent JSON data structures.
>> 
>> Same as 1) above.  Not just for JSON.
>> 
>>> Separately, we may want to consider whether the following should be in scope:
>>> 
>>>    3) A JSON-based method of representing public keys.
>>> 
>>> Also, please update and/or add these references (some were out of 
>>> date, some were missing):
>> 
>> Let's also add:
>> 
>> 4) Any JSON-specific prerequisite tooling such as JSON Schema
>> 
>> And add draft-zyp-json-schema as a reference.  I CC'd Kris Zyp to see 
>> if he's ok with that.  Kris: this might be a chance for a WG to pick 
>> up JSON Schema if you like.
>> 
>