Subject: Re: [jose] updated draft charter text incorporating AD's comments

From: Sean Turner <[email-masked]>
Date: Fri, 05 Apr 2013 08:29:03 -0400

Hi,

We've gotten what amounts to two discusses on the charter.  I wanted to 
run these by the WG in case there were any violent objections.

1. (easy one first) What does "JSON-structured integrity protection" and 
"JSON-structured encryption" mean?

It was explained "JSON-structured" means that the metadata about how you 
did the encryption/integrity is expressed in JSON not that the payload 
itself is JSON.  I.e., the algorithm description, key identifiers, etc. 
are in JSON but not necessary the payload.

I proposed:

OLD:

   specifying how to apply JSON-structured integrity
   protection to data

NEW:

   specifying a JSON structure for integrity-protected data

and the same again for encryption:

OLD:

   specifying how to apply a JSON-structured encryption to data

NEW:

   specifying a JSON structure for encrypted data

2. (hard one) Barry's been told by some App folks who are working on new 
JSON-based protocols that they don't see the applicability of JOSE to 
their work.

I think there is some concern that we're doing our own thing here in 
security land and not consulting with others.  That's not a true 
characterization based the use case we have from ALTO and XMPP, but 
nonetheless this feedback worries both Barry and myself.   What I'm 
going to do is prompt/prod the Apps folks to engage and say why/how it 
won't work for them.  What we might also do is some education in the 
appsawg; one of those here's how it works kind of presentations.  We'll 
reach out, but they need to reach out too because I don't want to have 
to be pinned waiting on a input that may never come.  To that end, 
putting some wording in the charter earlier than the numbered bullet 
about the uses cases, I think, solves this dilemma:

   The WG will strive to gather use cases to ensure the broadest
   possible applicability of the mechanism.

spt

On 3/10/13 2:13 PM, Karen O'Donoghue wrote:
> Folks,
>
> Here is the updated charter text based on Sean's comments and Mike's
> response. If there are any errors, please identify them asap as I plan
> to forward this back to Sean (and thus the IESG) in the very near future.
>
> Regards,
> Karen
>
>
> Description of JOSE 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 for JSON with encryption, digital signatures, and
> message authentication
> codes (MACs).
>
> Different proposals for providing such security services have already
> been defined
> and implemented.  This Working Group will standardize the mechanism for
> integrity
> protection (signature and MAC) and encryption as well as the format for
> keys and algorithm
> identifiers to support interoperability of security services for
> 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 sound.
>
> As JSON adoption expands, the different applications utilizing JSON
> security services
> will grow and this leads to the need to support different requirements.
> The WG will
> develop a generic syntax that can be used by applications to secure
> JSON-data, but
> it will be up to the application to fully specify the use of the WG's
> documents much
> the same way S/MIME is the application of CMS to MIME-based media types.
>
> This group is chartered to work on the following deliverables:
>
> (1) A Standards Track document or documents specifying how to apply
> JSON-structured
> integrity protection to data, including (but not limited to) JSON data
> structures.
> "Integrity protection" includes public-key digital signatures as well as
> symmetric-key MACs.
>
> (2) A Standards Track document or documents specifying how to apply a
> JSON-structured
> encryption to data, including (but not limited to) JSON data structures.
>
> (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 for
> the previous three documents.
>
> (5) 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).
>
> (6) A Standards Track document specifying a means of protecting private
> and symmetric
> keys via encryption.  This document will build upon the concepts and
> structures in (2)
> and (5).  This document may register additional algorithms in registries
> defined by (4).
>
> (7) An Informational document detailing Use Cases and Requirements for
> JSON Object
> Signing and Encryption (JOSE).
>
> (8) An Informational document that tells an application what needs to be
> specified in order
> to implement JOSE.
>
> One or more of these goals may be combined into a single document, in
> which case the
> concrete milestones for these goals will be satisfied by the
> consolidated document(s).
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2013 13:28:50 +0000

Hmmm...  I feel really queasy about the proposed rewording for (1), as it could lead to significant unintended consequences and potential obstacles when we go for final approval of the JWS and JWE specs.  Here's why...

The wording could easily be interpreted as a mandate that the end-representation itself be JSON - not just that the representation utilize JSON for representing structured data, which is what is actually the case now.  I could easily imagine the new wording enabling a situation where someone would then file a DISCUSS saying that the current Compact Serialization representations aren't JSON and so don't meet the requirements of the charter.

For that reason, I believe we would be FAR better off to leave the first two charter items exactly as they are at http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wording.  The current wording is:

1) A Standards Track document specifying how to apply JSON-structured

 structures. "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

So yes, I strongly object to the new wording, as I don't want to open the door for the current representations to be rejected on charter grounds later.  If it helps, you can reassure objectors that we ARE producing pure JSON representations too, but that they're not the only JSON-based representations for integrity protected and encrypted content.

Why don't we just scale back the recharter request to only add the new items and leave the existing items alone, if that's what it will take to be approved.

                                                            Thanks for asking,

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Friday, April 05, 2013 5:29 AM
To: [email-masked]
Subject: Re: [jose] updated draft charter text incorporating AD's comments

Hi,

We've gotten what amounts to two discusses on the charter.  I wanted to run these by the WG in case there were any violent objections.

1. (easy one first) What does "JSON-structured integrity protection" and "JSON-structured encryption" mean?

It was explained "JSON-structured" means that the metadata about how you did the encryption/integrity is expressed in JSON not that the payload itself is JSON.  I.e., the algorithm description, key identifiers, etc.

I proposed:

OLD:

   protection to data

NEW:

OLD:

NEW:

2. (hard one) Barry's been told by some App folks who are working on new JSON-based protocols that they don't see the applicability of JOSE to their work.

I think there is some concern that we're doing our own thing here in security land and not consulting with others.  That's not a true characterization based the use case we have from ALTO and XMPP, but

going to do is prompt/prod the Apps folks to engage and say why/how it won't work for them.  What we might also do is some education in the appsawg; one of those here's how it works kind of presentations.  We'll reach out, but they need to reach out too because I don't want to have to be pinned waiting on a input that may never come.  To that end, putting some wording in the charter earlier than the numbered bullet about the uses cases, I think, solves this dilemma:

spt

> 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

> message authentication codes (MACs).

> been defined and implemented.  This Working Group will standardize the

> mechanism for integrity protection (signature and MAC) and encryption

> as well as the format for keys and algorithm identifiers to support

> interoperability of security services for 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 sound.

> security services will grow and this leads to the need to support

> different requirements.

> JSON-data, but it will be up to the application to fully specify the

> use of the WG's documents much the same way S/MIME is the application

> of CMS to MIME-based media types.

> JSON-structured integrity protection to data, including (but not

> limited to) JSON data structures.

> "Integrity protection" includes public-key digital signatures as well

> as symmetric-key MACs.

> JSON-structured encryption to data, including (but not limited to)

> JSON data structures.

> identifiers for the previous three documents.

> symmetric keys as JSON-structured objects.  This document will build

> upon the concepts and structures in (3).

> (6) A Standards Track document specifying a means of protecting

> private and symmetric keys via encryption.  This document will build

> upon the concepts and structures in (2) and (5).  This document may

> register additional algorithms in registries defined by (4).

> JSON Object Signing and Encryption (JOSE).

> (8) An Informational document that tells an application what needs to

> be specified in order to implement JOSE.

> which case the concrete milestones for these goals will be satisfied

> by the consolidated document(s).

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

jose mailing list

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Apr 2013 10:37:27 -0400

> For that reason, I believe we would be FAR better off to leave the first two
> charter items exactly as they are at
> http://datatracker.ietf.org/wg/jose/charter/ than to accept the new wording.
> The current wording is:
>

The problem is that I do not understand what you mean by
"JSON-structured integrity protection" and "JSON-structured
encryption".  Sean's suggested wording is intended to say this in an
understandable way; if it's not correct, please try to come up with an
alternative.  The existing text doesn't work, because I don't
understand how to apply the modifier "JSON-structured" to the noun
"encryption" and get anything sensible out of it.  What does it mean
for *encryption* to be "JSON-structured"?

> So yes, I strongly object to the new wording, as I don’t want to open the
> door for the current representations to be rejected on charter grounds
> later.  If it helps, you can reassure objectors that we ARE producing pure
> JSON representations too, but that they’re not the only JSON-based
> representations for integrity protected and encrypted content.

To be clear: what you're producing is not the issue.  It's an issue of
the wording in the charter.

Barry

---

From: Dick Hardt <[email-masked]>
Date: Fri, 5 Apr 2013 08:11:05 -0700

I'm with Mike on not being aligned on the new change. Here is my take on why yet-another-token-format was desired 

+ Ability to represent complex data
=> simple name/value pairs in URL query strings and and HTTP headers led to obtuse, overloaded representations
=> JSON

+ Easy to parse using readily available libraries
=> JSON

+ Easy to include in URLs and HTTP headers
=> the token did not require special encoding
=> the token was short
	=> URL base 64 encoding JSON and separating binary fields with '.' separator => easy to parse

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2013 15:10:02 +0000

Thanks Barry.

How about "representing integrity-protected data using JSON-based data structures" and "representing encrypted data using JSON-based data structures"?  That would read better than the original and still not be able to be misconstrued to say that what the working group has produced doesn't meet the charter goals.

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, April 05, 2013 7:37 AM
To: Mike Jones
Cc: Sean Turner; [email-masked]
Subject: Re: [jose] updated draft charter text incorporating AD's comments

> For that reason, I believe we would be FAR better off to leave the 
> first two charter items exactly as they are at 
> 2) A Standards Track document specifying how to apply a 
> JSON-structured  encryption to data, including (but not limited to) JSON data structures.

The problem is that I do not understand what you mean by "JSON-structured integrity protection" and "JSON-structured encryption".  Sean's suggested wording is intended to say this in an understandable way; if it's not correct, please try to come up with an alternative.  The existing text doesn't work, because I don't understand how to apply the modifier "JSON-structured" to the noun "encryption" and get anything sensible out of it.  What does it mean for *encryption* to be "JSON-structured"?

> So yes, I strongly object to the new wording, as I don't want to open 
> the door for the current representations to be rejected on charter 
> grounds later.  If it helps, you can reassure objectors that we ARE 
> producing pure JSON representations too, but that they're not the only 
> JSON-based representations for integrity protected and encrypted content.

To be clear: what you're producing is not the issue.  It's an issue of the wording in the charter.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Apr 2013 11:20:36 -0400

> How about "representing integrity-protected data using JSON-based data
> structures" and "representing encrypted data using JSON-based data structures"?
> That would read better than the original and still not be able to be misconstrued
> to say that what the working group has produced doesn't meet the charter goals.

I can understand that; thanks.

Barry

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 18:43:20 -0400

On Fri, Apr 5, 2013 at 9:28 AM, Mike Jones <[email-masked]>wrote:

>  Hmmm...  I feel really queasy about the proposed rewording for (1), as
> it could lead to significant unintended consequences and potential
> obstacles when we go for final approval of the JWS and JWE specs.  Here's
> why...****
>
> ** **
>
> The wording could easily be interpreted as a mandate that the
> end-representation itself be JSON – not just that the representation
> utilize JSON for representing structured data, which is what is actually
> the case now.  I could easily imagine the new wording enabling a situation
> where someone would then file a DISCUSS saying that the current Compact
> Serialization representations aren't JSON and so don't meet the
> requirements of the charter.
>

That won't be a problem as long as there is *a* JSON representation in the
base specification.  Which we have agreed to do.

--Richard

> ****
>
> ** **
>
> For that reason, I believe we would be FAR better off to leave the first
> two charter items exactly as they are at
> http://datatracker.ietf.org/wg/jose/charter/ than to accept the new
> wording.  The current wording is:****
>
> ** **
>
> 1) A Standards Track document specifying how to apply JSON-structured ****
>
>  integrity protection to data, including (but not limited to) JSON data **
> **
>
>  structures. "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.*
> ***
>
> ** **
>
> representations for integrity protected and encrypted content.****
>
> ** **
>
> Why don’t we just scale back the recharter request to only add the new
> items and leave the existing items alone, if that’s what it will take to be
> approved.****
>
> ** **
>
>                                                             Thanks for
> asking,****
>
>                                                             -- Mike ****
>
> ** **
>
> ** **
> Hi,****
> ** **
> run these by the WG in case there were any violent objections.****
>
> ** **
>
> "JSON-structured encryption" mean?****
>
> ** **
>
> itself is JSON.  I.e., the algorithm description, key identifiers, etc. **
> **
>
> are in JSON but not necessary the payload.****
>
> ** **
>
> I proposed:****
>
> ** **
>
> OLD:****
>
> ** **
>
>    specifying how to apply JSON-structured integrity****
>
>    protection to data****
>
> ** **
>
> NEW:****
>
> ** **
>
>    specifying a JSON structure for integrity-protected data****
>
> ** **
>
> and the same again for encryption:****
>
> ** **
>
> OLD:****
>
> ** **
>
>    specifying how to apply a JSON-structured encryption to data****
>
> ** **
>
> NEW:****
>
> ** **
>
>    specifying a JSON structure for encrypted data****
>
> ** **
>
> JSON-based protocols that they don't see the applicability of JOSE to their
> work.****
>
> ** **
>
> characterization based the use case we have from ALTO and XMPP, but ****
>
> nonetheless this feedback worries both Barry and myself.   What I'm ****
>
> reach out, but they need to reach out too because I don't want to have to
> be pinned waiting on a input that may never come.  To that end, putting
> some wording in the charter earlier than the numbered bullet about the uses
> cases, I think, solves this dilemma:****
>
> ** **
>
>    The WG will strive to gather use cases to ensure the broadest****
>
>    possible applicability of the mechanism.****
>
> ** **
>
> spt****
>
> ** **
>
> On 3/10/13 2:13 PM, Karen O'Donoghue wrote:****
>
> > Folks,****
>
> >** **
>
> > Here is the updated charter text based on Sean's comments and Mike's ***
> *
>
> > response. If there are any errors, please identify them asap as I plan *
> ***
>
> ****
> >** **
> > Regards,****
> > Karen****
> >** **
> >** **
> > Description of JOSE 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 for JSON with encryption, digital signatures, and ****
>
> > message authentication codes (MACs).****
>
> >** **
>
> > Different proposals for providing such security services have already **
> **
>
> > been defined and implemented.  This Working Group will standardize the *
> ***
>
> > mechanism for integrity protection (signature and MAC) and encryption **
> **
>
> > as well as the format for keys and algorithm identifiers to support ****
>
> > interoperability of security services for 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 sound.****
>
> >** **
>
> > As JSON adoption expands, the different applications utilizing JSON ****
>
> > security services will grow and this leads to the need to support ****
>
> > different requirements.****
>
> > The WG will****
>
> > develop a generic syntax that can be used by applications to secure ****
>
> > JSON-data, but it will be up to the application to fully specify the ***
> *
>
> > use of the WG's documents much the same way S/MIME is the application **
> **
>
> > of CMS to MIME-based media types.****
>
> >** **
>
> > This group is chartered to work on the following deliverables:****
>
> >** **
>
> > (1) A Standards Track document or documents specifying how to apply ****
>
> > JSON-structured integrity protection to data, including (but not ****
>
> > limited to) JSON data structures.****
>
> > "Integrity protection" includes public-key digital signatures as well **
> **
>
> > as symmetric-key MACs.****
>
> >** **
>
> > (2) A Standards Track document or documents specifying how to apply a **
> **
>
> > JSON-structured encryption to data, including (but not limited to) ****
>
> > JSON data structures.****
>
> >** **
>
> > (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 for the previous three documents.****
>
> >** **
>
> > (5) 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).****
>
> >** **
>
> > (6) A Standards Track document specifying a means of protecting ****
>
> > private and symmetric keys via encryption.  This document will build ***
> *
>
> > upon the concepts and structures in (2) and (5).  This document may ****
>
> > register additional algorithms in registries defined by (4).****
>
> >** **
>
> > (7) An Informational document detailing Use Cases and Requirements for *
> ***
>
> > JSON Object Signing and Encryption (JOSE).****
>
> >** **
>
> > (8) An Informational document that tells an application what needs to **
> **
>
> > be specified in order to implement JOSE.****
>
> >** **
>
> > One or more of these goals may be combined into a single document, in **
> **
>
> > which case the concrete milestones for these goals will be satisfied ***
> *
>
> > by the consolidated document(s).****
>
> >** **
>
> > _______________________________________________****
>
> > jose mailing list****
>
> > [email-masked]****
>
> > https://www.ietf.org/mailman/listinfo/jose****
>
> >** **
>
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Apr 2013 18:45:33 -0400

I could live with that text, but I really dislike weasel words like
"JSON-based".  What does that mean?

Given that we're putting a JSON serialization in the base spec, it doesn't
seem like Sean's text would require any change in direction.

--Richard

On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones <[email-masked]>wrote:

> structures" and "representing encrypted data using JSON-based data
> structures"?  That would read better than the original and still not be
> able to be misconstrued to say that what the working group has produced
> doesn't meet the charter goals.
>
>                                 Thanks,
>                                 -- Mike
>
> wording.
> The problem is that I do not understand what you mean by "JSON-structured
> integrity protection" and "JSON-structured encryption".  Sean's suggested
> wording is intended to say this in an understandable way; if it's not
> correct, please try to come up with an alternative.  The existing text
> doesn't work, because I don't understand how to apply the modifier
> "JSON-structured" to the noun "encryption" and get anything sensible out of
> it.  What does it mean for *encryption* to be "JSON-structured"?
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2013 23:15:09 +0000

If you can live with that, let's use it.  I remain profoundly uncomfortable with Sean's wording.

                                                            Thanks,
                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, April 05, 2013 3:46 PM
To: Mike Jones
Cc: Barry Leiba; Sean Turner; [email-masked]
Subject: Re: [jose] updated draft charter text incorporating AD's comments

I could live with that text, but I really dislike weasel words like "JSON-based".  What does that mean?

Given that we're putting a JSON serialization in the base spec, it doesn't seem like Sean's text would require any change in direction.

--Richard

On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Barry.

                                Thanks,
                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Barry Leiba
Sent: Friday, April 05, 2013 7:37 AM
To: Mike Jones
Cc: Sean Turner; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] updated draft charter text incorporating AD's comments

Barry

---

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 16:41:02 -0400

This feedback loop does work ;) I'll put in the modified wording.

spt

On 4/5/13 7:15 PM, Mike Jones wrote:
> If you can live with that, let’s use it.  I remain profoundly
> uncomfortable with Sean’s wording.
>
>                                                              Thanks,
>
>                                                              -- Mike
>
> *From:*Richard Barnes [mailto:[email-masked]]
> *Sent:* Friday, April 05, 2013 3:46 PM
> *To:* Mike Jones
> *Cc:* Barry Leiba; Sean Turner; [email-masked]
> *Subject:* Re: [jose] updated draft charter text incorporating AD's comments
>
> Given that we're putting a JSON serialization in the base spec, it
> doesn't seem like Sean's text would require any change in direction.
>
> --Richard
>
> On Fri, Apr 5, 2013 at 11:10 AM, Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Thanks Barry.
>
> From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
> Of Barry Leiba
> Cc: Sean Turner; [email-masked] <mailto:[email-masked]>
> "JSON-structured integrity protection" and "JSON-structured encryption".
>   Sean's suggested wording is intended to say this in an understandable
> way; if it's not correct, please try to come up with an alternative.
>   The existing text doesn't work, because I don't understand how to
> apply the modifier "JSON-structured" to the noun "encryption" and get
> anything sensible out of it.  What does it mean for *encryption* to be
> "JSON-structured"?
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 16:49:35 -0400

#1 is addressed.

Any issues with sticking the paragraph in?
Barry would that be enough for you to clear?

spt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Apr 2013 17:31:42 -0400

> #1 is addressed.

Yes.

> Barry would that be enough for you to clear?

That and the outreach that you and I and the chairs are working on,
yes, indeed.  Thanks.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Apr 2013 17:39:20 -0600

On 4/5/13 6:29 AM, Sean Turner wrote:

> 2. (hard one) Barry's been told by some App folks who are working
> on new JSON-based protocols that they don't see the applicability
> of JOSE to their work.

Have we heard *why*? Do they not need or want signing and encryption?
Do they think there are technical problems with the solutions being
proposed in the JOSE WG? Do they have aesthetic objections? It would
help to know more about the concerns being expressed (and why they are
not being expressed in the JOSE WG but instead in private to an area
directory).

Peter

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

---

From: Sean Turner <[email-masked]>
Date: Mon, 08 Apr 2013 23:20:08 -0400

I have heard nothing to date, but I get Barry's point we need to reach 
out and ask.  As, I told him though we're going to reach out but we're 
not going to wait indefinitely for a reply.

spt

On 4/8/13 7:39 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRY1UoAAoJEOoGpJErxa2psRQP/jxDVhZEzKWJ7Lnz4zrbW9wu
> 266cYbY+XJxdqHHE0At4kVVPQ/YaV7wPUDOH9owCGLOgQeMGuT4NbaaHgwc5Uw9a
> RBuW0Aw6/otvdkDwHJWOI8jXgRF7ERUSoDAFYK8ynxY4l9ezngOzgWDpHQOK/tQD
> Bmr7+hqDJ4vcmklibH4lzHc/uk71d9hiE8PQE5S5KBeGKzWHwwcY8A1q8GKIFHKn
> eNVEu2yadXqZoFBggtDnAvOiMYN/5BQ3ck7dWWWNgY3ox3g9FHp1F31pJTUEPir/
> fgg7dCWQcwmf9UUujxWMDjbfTNvfO7hYPx2Pu1aL69XAQs0qp3eE6glPBs5Y18P8
> my8NiGcsCSQl6N3knapXCu1oLQ9BOO6qMRSAx7I839873eb7ZOK+5uDo39/gzt3K
> 8feRoNCj/nvhnHLFImQeyB6eGnaudiRyylOfuk6vVcg+ccqqepOATGK5mvgJxnRn
> 7yyVdgU6PcBvjnPJPHp8vObL9FHh+OJRUpozJS1pXHq4SZsIh14z3FYTQafx99XF
> YxAvAVMduLbw/+FMGCX42cv2rDUKWE3tShWNX2uLYacGmyysoKTqmx5xOx7+BdZQ
> WxCx1tPGVL1t11Ekgf6Ft3Lc94Kz06LqRD01wgAjIkpuhcDYREYoBXloE17qTz6y
> zTTNmlmmF9v3x8s9zDPt
> =NNLU
> -----END PGP SIGNATURE-----
>