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.
I personal agree that (4) schemas is creep, but I support Joe's desire to have
it considered as an input document.
-- Mike
-----Original Message-----
From: Stephen Farrell [mailto:[email protected]]
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; [email protected]; [email protected]
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" <[email protected]> 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.
>
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
