Subject: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

From: Mike Jones <[email-masked]>
Date: Wed, 19 Jun 2013 01:26:04 +0000

The JWS and JWE documents currently define these MIME types for the convenience of applications that may want to use them:
                application/jws
                application/jws+json
                application/jwe
                application/jwe+json

That being said, I'm not aware of any uses of these by applications at present.  Thus, I think that makes it fair game to ask whether we want to keep them or remove them - in which case, if applications ever needed them, they could define them later.

Another dimension of this question for JWS and JWE is that it's not clear that the four types application/jws, application/jws+json, application/jwe, and application/jwe+json are even the right ones.  It might be more useful to have generic application/jose and application/jose+json types, which could hold either JWS or JWE objects respectively using the compact or JSON serializations (although I'm not advocating adding them at this time).

Having different JWS versus JWE MIME types apparently did contribute to at least Dick's confusion about the purpose of the "typ" field, so deleting them could help eliminate this possibility of confusion in the future.  Thus, I'm increasingly convinced we should get rid of the JWS and JWE types and leave it up to applications to define the types they need, when they need them.

Do people have use cases for these four MIME types now or should we leave them to future specs to define, if needed?

                                                                -- Mike

P.S.  For completeness, I'll add that the JWK document also defines these MIME types:
                application/jwk+json
                application/jwk-set+json

There are already clear use cases for these types, so I'm not advocating deleting them, but wanted to call that out explicitly.  For instance, when retrieving a JWK Set document referenced by a "jku" header parameter, I believe that the result should use the application/jwk-set+json type.  (In fact, I'll add this to the specs, unless there are any objections.)  Likewise, draft-miller-jose-jwe-protected-jwk-02 already uses application/jwk+json.  Both could also be as "cty" values when encrypting JWKs and JWK Sets, in contexts where that that would be useful.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 Jun 2013 13:52:29 +1000

Good questions, Mike. My (backward compatible) suggestions below.

> The JWS and JWE documents currently define these MIME types for the
> convenience of applications that may want to use them:
>                 application/jws
>                 application/jws+json
>                 application/jwe
>                 application/jwe+json

Drop these.
Define application/jose and application/jose+json.

Allow two optional parameters on these media types:

  inner -- indicates the media type of the content of the JOSE message, after removing 1 or more layers of JOSE protection. For instance, if a JPEG image is signed with an RSA key, then encrypted with AES-GCM, inner would be image/jpeg.

  mode -- indicates the sort of protection applied (eg signed, encrypted, unprotected...). If multiple modes of protection are applied in turn (eg signed then encrypted) they can all be listed: from the outer-most mode to the inner-most; separated by a plus (eg mode="enc+sig").

A "mode" media type parameter would be easy to specify if JOSE messages had a corresponding header field, instead of inferring the sort of processing from the "alg" value. :-(

Suggestion:

1. Define a header parameter that indicates the sort of processing. Its name could be "T", or "mode" (just not "typ" as that is too confused).
[I like "T" (short; stands out as THE primary field in a JOSE message), but I use "mode" below to be a little less controversial.]

2. Create a registry for "mode" values.

3. Define some initial "mode" values, alongside the spec for that processing:
  "sig1" for digitally signing B64(header).B64(content);
  "mac1" for MAC over B64(header).B64(content);
  "enc1" for AEAD, where AAD is B64(header)
  "none" for unprocessed content
  "cmp" for compressed (but not protected) content
  "enc2" for AEAD applied differently (as per the JSON representation)
  ...

4. Allow the "mode" parameter to be absent if an "alg" value is present and has a default "mode". This maintains compatibility with JOSE messages based on previous drafts.

5. Define the default "mode" for existing "alg" values. For instance, for "alg":"HS256" the default is "mode":"mac1". The registry of alg values would have a column for the default mode (though new algs can leave that column blank).

6. Drop the "crit" field. If you are creating a JOSE message with new semantics that MUST be understood, just define a new "mode" value. For example, to avoid some base64 overhead you could define "mode":"sig2" to mean digitally sign header||content||len(header).

7. Allow a list of "mode" values to be specified as a parameter on a JOSE media type.

[probably]
8. A plus sign "+" can be appended to any "mode" value to indicate that the content of this JOSE layer is another JOSE layer. That is, process this message as per the "mode" without the "+", then process the content as another JOSE message.
[Appending "+" is simpler than "cty":"jws" or "more":true, but assumes the inner JOSE message uses the same serialization as the outer one.]

End result: simpler, more easily understood by people; one field that is suitable for an implementation to use to switch to the appropriate processing code; backward compatible with earlier drafts; clear mechanism for making changes that MUST-be-understood (that we can be confident code will notice).

> That being said, I’m not aware of any uses of these by applications at
> present.

Apps such as OpenID Connect could use:
  application/jose;inner=application/jwt+json

Apps can still define their own media types for JOSE messages (eg application/jwt) though that should not be necessary.

>  Thus, I think that makes it fair game to ask whether we want
> to keep them or remove them – in which case, if applications ever
> needed them, they could define them later.
> 
> Another dimension of this question for JWS and JWE is that it’s not
> clear that the four types application/jws, application/jws+json,
> application/jwe, and application/jwe+json are even the right ones.  It
> might be more useful to have generic application/jose and
> application/jose+json types, which could hold either JWS or JWE objects
> respectively using the compact or JSON serializations (although I’m not
> advocating adding them at this time).
> 
> Having different JWS versus JWE MIME types apparently did contribute to
> at least Dick’s confusion about the purpose of the “typ” field, so
> deleting them could help eliminate this possibility of confusion in the
> future.  Thus, I’m increasingly convinced we should get rid of the JWS
> and JWE types and leave it up to applications to define the types they
> need, when they need them.
> 
> Do people have use cases for these four MIME types now or should we
> leave them to future specs to define, if needed?

We are defining a format for use on the web. The web identifies formats via media types. So JOSE needs to define media types.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 18 Jun 2013 21:47:48 -0700

One possible way to do this can be seen in this document  http://www.ietf.org/internet-drafts/draft-turner-application-cms-media-type-04.txt that is doing much the same thing for CMS.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Manger, James H
> Sent: Tuesday, June 18, 2013 8:52 PM
> To: Mike Jones; [email-masked]
> Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
> types?
> 
>   inner -- indicates the media type of the content of the JOSE message, after
> removing 1 or more layers of JOSE protection. For instance, if a JPEG image is
> signed with an RSA key, then encrypted with AES-GCM, inner would be
> image/jpeg.
> 
>   mode -- indicates the sort of protection applied (eg signed, encrypted,
> unprotected...). If multiple modes of protection are applied in turn (eg
> signed then encrypted) they can all be listed: from the outer-most mode to
> the inner-most; separated by a plus (eg mode="enc+sig").
> 
> 
> A "mode" media type parameter would be easy to specify if JOSE messages
> had a corresponding header field, instead of inferring the sort of processing
> from the "alg" value. :-(
> 
> 
> Suggestion:
> 
> 1. Define a header parameter that indicates the sort of processing. Its name
> could be "T", or "mode" (just not "typ" as that is too confused).
> [I like "T" (short; stands out as THE primary field in a JOSE message), but I use
> "mode" below to be a little less controversial.]
> 
> 4. Allow the "mode" parameter to be absent if an "alg" value is present and
> has a default "mode". This maintains compatibility with JOSE messages based
> on previous drafts.
> 
> 5. Define the default "mode" for existing "alg" values. For instance, for
> "alg":"HS256" the default is "mode":"mac1". The registry of alg values would
> have a column for the default mode (though new algs can leave that column
> blank).
> 
> 6. Drop the "crit" field. If you are creating a JOSE message with new
> semantics that MUST be understood, just define a new "mode" value. For
> example, to avoid some base64 overhead you could define "mode":"sig2" to
> mean digitally sign header||content||len(header).
> 
> 8. A plus sign "+" can be appended to any "mode" value to indicate that the
> content of this JOSE layer is another JOSE layer. That is, process this message
> as per the "mode" without the "+", then process the content as another
> JOSE message.
> [Appending "+" is simpler than "cty":"jws" or "more":true, but assumes the
> inner JOSE message uses the same serialization as the outer one.]
> 
> 
> End result: simpler, more easily understood by people; one field that is
> suitable for an implementation to use to switch to the appropriate processing
> code; backward compatible with earlier drafts; clear mechanism for making
> changes that MUST-be-understood (that we can be confident code will
> notice).
> 
> 
> 
> > That being said, I m not aware of any uses of these by applications at
> > present.
> 
> Apps can still define their own media types for JOSE messages (eg
> application/jwt) though that should not be necessary.
> 
> 
> >  Thus, I think that makes it fair game to ask whether we want  to keep
> >them or remove them   in which case, if applications ever  needed them,
> >they could define them later.
> >
> > Another dimension of this question for JWS and JWE is that it s not
> > application/jose+json types, which could hold either JWS or JWE
> > objects respectively using the compact or JSON serializations
> > (although I m not advocating adding them at this time).
> >
> > Having different JWS versus JWE MIME types apparently did contribute
> > to at least Dick s confusion about the purpose of the  typ  field, so
> > deleting them could help eliminate this possibility of confusion in
> > the future.  Thus, I m increasingly convinced we should get rid of the
> > JWS and JWE types and leave it up to applications to define the types
> > they need, when they need them.
> >
> We are defining a format for use on the web. The web identifies formats via
> media types. So JOSE needs to define media types.
> 
> --
> James Manger
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Jun 2013 05:29:16 +0000

So we agree that dropping the JWS and JWE media types is a reasonable thing to do.

As far as adding a complicated new media type without a clear use case to do so, we don't agree.  We're not trying to boil the ocean here.  This thread was intended to be about simplifying things by removing things that aren't actually being used - not adding new complicated things that also aren't being used.

For context on your proposal below, you've proposed several times in several ways to completely restructure the processing rules for JWS and JWE.  None of those have gained traction with the working group to date.  Your proposal below seems to be more of the same - at least to me.

One of the problems this would create would be having multiple ways of indicating whether the object is a JWS or JWE - both the "alg" value and the additional values you propose.  A problem with such duplication is that it creates new error conditions to handle.  For instance, what if your new parameters said that the content was a JWS but the content was actually a JWE?  That's a new error condition that rules would have to be specified to handle.  It seems better to have one way of determining this, rather multiple ways that might conflict.

Without a clear use case for adding the complicated media type you describe below which seems far from minimal, including saying why its goals can't be accomplished with what already exists, I don't think it makes sense.  My view, anyway...

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Tuesday, June 18, 2013 8:52 PM
To: Mike Jones; [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

Drop these.

Suggestion:

[probably]

>them or remove them – in which case, if applications ever  needed them, 
> (although I’m not advocating adding them at this time).
> 
> to at least Dick’s confusion about the purpose of the “typ” field, so 
> the future.  Thus, I’m increasingly convinced we should get rid of the

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 Jun 2013 16:20:45 +1000

> So we agree that dropping the JWS and JWE media types is a reasonable

*Replacing* them with a JOSE media type is a reasonable thing to do.

> As far as adding a complicated new media type without a clear use case
> to do so, we don't agree.  We're not trying to boil the ocean here.

The web works by labelling each data format with a media type.
I don't want to boil the ocean. I want to work with the web.

> This thread was intended to be about simplifying things by removing
> things that aren't actually being used - not adding new complicated
> things that also aren't being used.

The only reason a JOSE media type is not being used is that JWT defined its own media type, probably because no suitable JOSE media type existed.

As an analogy, if application/json was not defined every app using JSON would need to define an app-specific media type. In practice, application/json is convenient in many situations.

> For context on your proposal below, you've proposed several times in
> several ways to completely restructure the processing rules for JWS and
> JWE.  None of those have gained traction with the working group to
> date.  Your proposal below seems to be more of the same - at least to
> me.

The "typ" fiasco showed many others also want a way to indicate the "mode" of a JOSE message.

> One of the problems this would create would be having multiple ways of
> indicating whether the object is a JWS or JWE - both the "alg" value
> and the additional values you propose.

As opposed to the multiple ways today - both the "alg" value and the presence/absence of "enc".

My proposal defines 1 deterministic way (ie "mode" takes precedence):

  Mode = header.get("mode)
  If mode === undefined then
    Alg = header.get("alg")
    Mode = TABLE_OF_ALGS.get(alg).get("mode")
  EndIf
  Switch (mode)
    Case "sig1" ...verify signature...
    Case "enc1" ...decrypt...
    Default ...ERROR: unsupported message...
  EndSwitch

>  A problem with such duplication
> is that it creates new error conditions to handle.  For instance, what
> if your new parameters said that the content was a JWS but the content
> was actually a JWE?

{"mode":"sig1", "alg":"ECDH-ES"}
"mode" is "sig1" so the recipient tries to verify a signature, but fails because the "alg" value isn't a signature algorithm. Trivial.

Not much different from a draft-11 message that has {"alg":"HS256", "enc":"A256GCM"}.

Actually, my proposal is much better. With draft-11, half the recipients will process this as a JWS (based on "alg"), the other half will process this as a JWE (based on "enc") so who knows what will happen.

>  That's a new error condition that rules would have
> to be specified to handle.

Draft-11 doesn't specify rules for handling {"alg":"HS256", "enc":"A256GCM"}. It merely implies it cannot occur for legal input values -- no different than "mode" and "alg" contradicting each other.

> It seems better to have one way of
> determining this, rather multiple ways that might conflict.

Agree. My proposal gives 1 way (that involves 2 steps to aid backward compatibility).

> Without a clear use case for adding the complicated media type you
> describe below which seems far from minimal, including saying why its
> goals can't be accomplished with what already exists, I don't think it
> makes sense.  My view, anyway...

If the JOSE group decides media type parameters are too complicated I could live with just application/jose and application/jose+json. Even that would be much better than the current JWE/JWS/JWT media types. I think "inner" and "mode" media type parameters add value.

--
James Manger

>   inner -- indicates the media type of the content of the JOSE message,
> after removing 1 or more layers of JOSE protection. For instance, if a
> JPEG image is signed with an RSA key, then encrypted with AES-GCM,
> inner would be image/jpeg.
> 
>   mode -- indicates the sort of protection applied (eg signed,
> encrypted, unprotected...). If multiple modes of protection are applied
> in turn (eg signed then encrypted) they can all be listed: from the
> outer-most mode to the inner-most; separated by a plus (eg
> mode="enc+sig").
> 
> 
> had a corresponding header field, instead of inferring the sort of
> processing from the "alg" value. :-(
> 
> 
> Suggestion:
> 
> 1. Define a header parameter that indicates the sort of processing. Its
> name could be "T", or "mode" (just not "typ" as that is too confused).
> [I like "T" (short; stands out as THE primary field in a JOSE message),
> but I use "mode" below to be a little less controversial.]
> 
> 4. Allow the "mode" parameter to be absent if an "alg" value is present
> and has a default "mode". This maintains compatibility with JOSE
> messages based on previous drafts.
> 
> 5. Define the default "mode" for existing "alg" values. For instance,
> for "alg":"HS256" the default is "mode":"mac1". The registry of alg
> values would have a column for the default mode (though new algs can
> leave that column blank).
> 
> example, to avoid some base64 overhead you could define "mode":"sig2"
> to mean digitally sign header||content||len(header).
> 
> 8. A plus sign "+" can be appended to any "mode" value to indicate that
> the content of this JOSE layer is another JOSE layer. That is, process
> this message as per the "mode" without the "+", then process the
> content as another JOSE message.
> [Appending "+" is simpler than "cty":"jws" or "more":true, but assumes
> the inner JOSE message uses the same serialization as the outer one.]
> 
> 
> End result: simpler, more easily understood by people; one field that
> is suitable for an implementation to use to switch to the appropriate
> processing code; backward compatible with earlier drafts; clear
> mechanism for making changes that MUST-be-understood (that we can be
> confident code will notice).
> 
> 
> 
> We are defining a format for use on the web. The web identifies formats
> via media types. So JOSE needs to define media types.
> 
> --
> James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 11:15:25 -0400

Multiplexing JWE and JWS under a single JOSE media type only makes sense if
there's a defined algorithm to demux them.  So if you want to do this, you
would need to write down the algorithm.

Personally, it seems simpler and clearer to me to just have the four
current types, so that you know which type of object you're dealing with,
and in what serialization, without having to do content sniffing.

On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <[email-masked]>wrote:

> convenience of applications that may want to use them:****
>
>                 application/jws****
>
>                 application/jws+json****
>
>                 application/jwe****
>
>                 application/jwe+json****
>
> ** **
>
> present.  Thus, I think that makes it fair game to ask whether we want to
> keep them or remove them – in which case, if applications ever needed them,
> they could define them later.****
>
> ** **
>
> Another dimension of this question for JWS and JWE is that it’s not clear
> that the four types application/jws, application/jws+json, application/jwe,
> and application/jwe+json are even the right ones.  It might be more useful
> to have generic application/jose and application/jose+json types, which
> could hold either JWS or JWE objects respectively using the compact or JSON
> serializations (although I’m not advocating adding them at this time).****
>
> ** **
>
> Having different JWS versus JWE MIME types apparently did contribute to at
> least Dick’s confusion about the purpose of the “typ” field, so deleting
> them could help eliminate this possibility of confusion in the future.
> Thus, I’m increasingly convinced we should get rid of the JWS and JWE types
> and leave it up to applications to define the types they need, when they
> need them.****
>
> ** **
>
> Do people have use cases for these four MIME types now or should we leave
> them to future specs to define, if needed?****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> P.S.  For completeness, I’ll add that the JWK document also defines these
> MIME types:****
>
>                 application/jwk+json****
>
>                 application/jwk-set+json****
>
> ** **
>
> There are already clear use cases for these types, so I’m not advocating
> deleting them, but wanted to call that out explicitly.  For instance, when
> retrieving a JWK Set document referenced by a “jku” header parameter, I
> believe that the result should use the application/jwk-set+json type.  (In
> fact, I’ll add this to the specs, unless there are any objections.)
> Likewise, draft-miller-jose-jwe-protected-jwk-02 already uses
> application/jwk+json.  Both could also be as “cty” values when encrypting
> JWKs and JWK Sets, in contexts where that that would be useful.****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jun 2013 15:19:38 +0000

There is a defined algorithm to distinguish between the JWS and JWE objects in the third paragraph of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, June 20, 2013 8:15 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

Multiplexing JWE and JWS under a single JOSE media type only makes sense if there's a defined algorithm to demux them.  So if you want to do this, you would need to write down the algorithm.

Personally, it seems simpler and clearer to me to just have the four current types, so that you know which type of object you're dealing with, and in what serialization, without having to do content sniffing.

On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The JWS and JWE documents currently define these MIME types for the convenience of applications that may want to use them:
                application/jws
                application/jws+json
                application/jwe
                application/jwe+json

                                                                -- Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Justin Richer <[email-masked]>
Date: Thu, 20 Jun 2013 11:20:46 -0400

And I'd like to point out that we need this method anyway because you 
won't always have a mimetype along with the JOSE object -- they can be 
sent as HTTP headers, query parameters, any number of things really.

  -- Justin

On 06/20/2013 11:19 AM, Mike Jones wrote:
>
> There is a defined algorithm to distinguish between the JWS and JWE 
> objects in the third paragraph of 
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4.
>
> -- Mike
>
> *From:*Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, June 20, 2013 8:15 AM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Should we keep or remove the JOSE JWS and JWE 
> MIME types?
>
> Multiplexing JWE and JWS under a single JOSE media type only makes 
> sense if there's a defined algorithm to demux them.  So if you want to 
> do this, you would need to write down the algorithm.
>
> current types, so that you know which type of object you're dealing 
> with, and in what serialization, without having to do content sniffing.
>
> On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> That being said, I'm not aware of any uses of these by applications at 
> present.  Thus, I think that makes it fair game to ask whether we want 
> to keep them or remove them -- in which case, if applications ever 
> Another dimension of this question for JWS and JWE is that it's not 
> (although I'm not advocating adding them at this time).
>
> to at least Dick's confusion about the purpose of the "typ" field, so 
> the future.  Thus, I'm increasingly convinced we should get rid of the 
> There are already clear use cases for these types, so I'm not 
> advocating deleting them, but wanted to call that out explicitly.  For 
> instance, when retrieving a JWK Set document referenced by a "jku" 
> header parameter, I believe that the result should use the 
> application/jwk-set+json type.  (In fact, I'll add this to the specs, 
> unless there are any objections.) Likewise, 
> draft-miller-jose-jwe-protected-jwk-02 already uses 
> application/jwk+json.  Both could also be as "cty" values when 
> encrypting JWKs and JWK Sets, in contexts where that that would be useful.
>
>
> [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Thu, 20 Jun 2013 11:49:16 -0400

Which is to say, if what I said wasn't exactly clear, that the different 
mimetypes don't necessarily add anything. If we're going to define a 
mimetype we might as well just have the one, application/jose for the 
compact encoding.

For the JSON-based encodings, the same argument applies. However, 
personally, I've never been a fan of the plus-style mimetypes like 
application/jose+json, since in most dev frameworks that I've worked in 
you get "application/json" for free when you start spitting out JSON 
objects. It raises the question: is it valid to put a JSON-encoded JOSE 
object out as just application/json? I'd think you'd want it to be. I'd 
predict that that's what you're going to have developers doing in general.

  -- justin

On 06/20/2013 11:20 AM, Justin Richer wrote:
>> sense if there's a defined algorithm to demux them.  So if you want 
>> to do this, you would need to write down the algorithm.
>>
>> That being said, I'm not aware of any uses of these by applications 
>> at present.  Thus, I think that makes it fair game to ask whether we 
>> want to keep them or remove them -- in which case, if applications 
>> ever needed them, they could define them later.
>>
>> application/jwe, and application/jwe+json are even the right ones.  
>> It might be more useful to have generic application/jose and 
>> the future.  Thus, I'm increasingly convinced we should get rid of 
>> the JWS and JWE types and leave it up to applications to define the 
>> types they need, when they need them.
>>
>> advocating deleting them, but wanted to call that out explicitly.  
>> For instance, when retrieving a JWK Set document referenced by a 
>> "jku" header parameter, I believe that the result should use the

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 12:49:05 -0400

That algorithm is part of the story, but it's incomplete.  What we need is
an algorithm that starts with an arbitrary octet string and sorts by
JWS/JWE and serialization.  An outline of the flow chart:

1. If content parses as valid JSON
1.*. Parse JSON
1.1. Iontains a "ciphertext" field -> JWE + JSON
1.2. Contains a "payload" field -> JWS + JSON
1.3. Else fail
2. Else if content matches the regex "^[a-zA-Z0-9_.-]*$"
2.*. Split on "."
2.1. If 5 components -> JWE + compact
2.2. If 3 components -> JWS + compact
2.3. Else fail
3. Else fail

There's also the question of which document this goes in.  It would be a
natural thing for a combined JWS+JWE document, but we don't have one of
those :(

On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <[email-masked]>wrote:

> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4
> .****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Subject:* Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
> types?****
>
> ** **
>
> Multiplexing JWE and JWS under a single JOSE media type only makes sense
> if there's a defined algorithm to demux them.  So if you want to do this,
> you would need to write down the algorithm.****
>
> ** **
>
> and in what serialization, without having to do content sniffing.****
>
> ** **
>
> On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <[email-masked]>
> wrote:****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 20 Jun 2013 17:32:39 +0000

I just want to say that I think having a media type is important and useful.  It might not be important and useful for JWT or OAuth or OpenID-Connect, but I can think of many applications that would make use of them if at all possible.

I personally don't care if it's a generic media type or individual application/jwe and application/jws.  However, I think a generic media type would require a separate document; trying to fit this into the one shared document (JWA) seems wrong.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

PS: I've found +json useful for other things, because I do have applications that present in different formats (right now that's usually +xml).  While there's not a simple corollary with XML-based concepts, I think there will be corollaries in the future (e.g., CBOR).  Having them now means we're not painted into a corner if (when) we look at JOSE2 and support for binary representations.

---

From: Justin Richer <[email-masked]>
Date: Thu, 20 Jun 2013 13:33:34 -0400

It seems like JWA is quickly becoming the document with all the actual 
concrete content in it.

  -- Justin

On 06/20/2013 01:32 PM, Matt Miller (mamille2) wrote:
>>> keep them or remove them -- in which case, if applications ever needed them,
>>> Another dimension of this question for JWS and JWE is that it's not clear
>>> serializations (although I'm not advocating adding them at this time).****
>>>
>>> ****
>>>
>>> least Dick's confusion about the purpose of the "typ" field, so deleting
>>> Thus, I'm increasingly convinced we should get rid of the JWS and JWE types
>>> P.S.  For completeness, I'll add that the JWK document also defines these
>>> MIME types:****
>>>
>>>                 application/jwk+json****
>>>
>>> There are already clear use cases for these types, so I'm not advocating
>>> retrieving a JWK Set document referenced by a "jku" header parameter, I
>>> fact, I'll add this to the specs, unless there are any objections.)
>>> application/jwk+json.  Both could also be as "cty" values when encrypting

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jun 2013 17:41:07 +0000

I know of no use cases where the application won't know whether it's using the Compact Serialization or the JSON Serialization.

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, June 20, 2013 9:49 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

That algorithm is part of the story, but it's incomplete.  What we need is an algorithm that starts with an arbitrary octet string and sorts by JWS/JWE and serialization.  An outline of the flow chart:

There's also the question of which document this goes in.  It would be a natural thing for a combined JWS+JWE document, but we don't have one of those :(

On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
There is a defined algorithm to distinguish between the JWS and JWE objects in the third paragraph of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, June 20, 2013 8:15 AM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jun 2013 17:47:04 +0000

Editorially, if we do decide to add application/jose and application/jose+json MIME types, I would register them in draft-ietf-jose-json-web-signature, just like other registry content shared between JWS and JWE, such as the JSON Web Signature and Encryption Header Parameters Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#page-18>.

                                                            -- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]]
Sent: Thursday, June 20, 2013 10:33 AM
To: Richard Barnes
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

- m&m

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

Cisco Systems, Inc.

On Jun 20, 2013, at 10:49 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>>

> On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <[email-masked]<mailto:[email-masked]>>wrote:

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

>> On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>>

>> keep them or remove them - in which case, if applications ever needed them,

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 14:39:01 -0400

What you mean to say is that there are really two algorithms here,
depending on the media type:

application/jose
-> If 3 components, JWS
-> If 5 components, JWE

application/jose+json
-> If 'payloaod', JWS
-> If 'ciphertext', JWE

On Thu, Jun 20, 2013 at 1:41 PM, Mike Jones <[email-masked]>wrote:

>  I know of no use cases where the application won’t know whether it’s
> using the Compact Serialization or the JSON Serialization.****
>
> ** **
>
> *Sent:* Thursday, June 20, 2013 9:49 AM
>
> *To:* Mike Jones
> *Cc:* [email-masked]
> JWS/JWE and serialization.  An outline of the flow chart:****
>
> ** **
>
> 1. If content parses as valid JSON****
>
> 1.*. Parse JSON****
>
> 1.1. Iontains a "ciphertext" field -> JWE + JSON****
>
> 1.2. Contains a "payload" field -> JWS + JSON****
>
> 1.3. Else fail****
>
> 2. Else if content matches the regex "^[a-zA-Z0-9_.-]*$"****
>
> 2.*. Split on "."****
>
> 2.1. If 5 components -> JWE + compact****
>
> 2.2. If 3 components -> JWS + compact****
>
> 2.3. Else fail****
>
> 3. Else fail****
>
> ** **
>
> those :(****
> On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <[email-masked]>
> wrote:****
>
> *Cc:* [email-masked]****

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 20 Jun 2013 11:49:24 -0700

I have a question, why is there both an application/jose and and
application/jose+json.  Why not have just one of them?

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Thursday, June 20, 2013 10:47 AM
To: Matt Miller (mamille2); Richard Barnes
Cc: [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
types?

Editorially, if we do decide to add application/jose and
application/jose+json MIME types, I would register them in
draft-ietf-jose-json-web-signature, just like other registry content shared
between JWS and JWE, such as the JSON Web Signature and Encryption Header
Parameters Registry
<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#page-18> .

                                                            -- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]] 
Sent: Thursday, June 20, 2013 10:33 AM
To: Richard Barnes
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME
types?

I just want to say that I think having a media type is important and useful.
It might not be important and useful for JWT or OAuth or OpenID-Connect, but
I can think of many applications that would make use of them if at all
possible.

I personally don't care if it's a generic media type or individual
application/jwe and application/jws.  However, I think a generic media type
would require a separate document; trying to fit this into the one shared
document (JWA) seems wrong.

- m&m

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

Cisco Systems, Inc.

PS: I've found +json useful for other things, because I do have applications
that present in different formats (right now that's usually +xml).  While
there's not a simple corollary with XML-based concepts, I think there will
be corollaries in the future (e.g., CBOR).  Having them now means we're not
painted into a corner if (when) we look at JOSE2 and support for binary
representations.

On Jun 20, 2013, at 10:49 AM, Richard Barnes < <mailto:[email-masked]>
[email-masked]>

> On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones <
<mailto:[email-masked]> [email-masked]>wrote:

<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11#section-4

>> *From:* Richard Barnes [ <mailto:[email-masked]> mailto:[email-masked]]

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

>> On Tue, Jun 18, 2013 at 9:26 PM, Mike Jones <
<mailto:[email-masked]> [email-masked]>

>> Having different JWS versus JWE MIME types apparently did contribute to
at

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

>>  <https://www.ietf.org/mailman/listinfo/jose****>

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

>  <https://www.ietf.org/mailman/listinfo/jose>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jun 2013 18:56:25 +0000

Because the syntax is completely different.  One is period-separated base64url encoded fields.  The other is JSON.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, June 20, 2013 11:49 AM
To: Mike Jones; 'Matt Miller (mamille2)'; 'Richard Barnes'
Cc: [email-masked]
Subject: RE: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

I have a question, why is there both an application/jose and and application/jose+json.  Why not have just one of them?

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, June 20, 2013 10:47 AM
To: Matt Miller (mamille2); Richard Barnes
Cc: [email-masked]
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

                                                            -- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]]
Sent: Thursday, June 20, 2013 10:33 AM
To: Richard Barnes
Cc: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

- m&m

Cisco Systems, Inc.

---

From: Edmund Jay <[email-masked]>
Date: Thu, 20 Jun 2013 13:39:29 -0700 (PDT)

+1 in favor of dropping

________________________________
From: Mike Jones <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Tue, June 18, 2013 6:42:15 PM
Subject: [jose] Should we keep or remove the JOSE JWS and JWE MIME types?

The JWS and JWE documents currently define these MIME types for the convenience 
of applications that may want to use them:
                application/jws
                application/jws+json
                application/jwe
                application/jwe+json
 
That being said, I’m not aware of any uses of these by applications at present.  
Thus, I think that makes it fair game to ask whether we want to keep them or 
remove them – in which case, if applications ever needed them, they could define  
them later.
 
Another dimension of this question for JWS and JWE is that it’s not clear that 
the four types application/jws, application/jws+json, application/jwe, and 
application/jwe+json are even the right ones.  It might be more useful to have 
generic  application/jose and application/jose+json types, which could hold 
either JWS or JWE objects respectively using the compact or JSON serializations 
(although I’m not advocating adding them at this time).
 
Having different JWS versus JWE MIME types apparently did contribute to at least 
Dick’s confusion about the purpose of the “typ” field, so deleting them could 
help eliminate this possibility of confusion in the future.  Thus, I’m 
increasingly  convinced we should get rid of the JWS and JWE types and leave it 
up to applications to define the types they need, when they need them.
 
Do people have use cases for these four MIME types now or should we leave them 
to future specs to define, if needed?
 
                                                                -- Mike
 
P.S.  For completeness, I’ll add that the JWK document also defines these MIME 
types:
                application/jwk+json
                application/jwk-set+json
 
There are already clear use cases for these types, so I’m not advocating 
deleting them, but wanted to call that out explicitly.  For instance, when 
retrieving a JWK Set document referenced by a “jku” header parameter, I believe 
that the  result should use the application/jwk-set+json type.  (In fact, I’ll 
add this to the specs, unless there are any objections.)  Likewise, 
draft-miller-jose-jwe-protected-jwk-02 already uses application/jwk+json.  Both 
could also be as “cty” values when encrypting  JWKs and JWK Sets, in contexts 
where that that would be useful.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 16:44:48 -0400

Also: http://tools.ietf.org/html/rfc6839

On Thu, Jun 20, 2013 at 2:56 PM, Mike Jones <[email-masked]>wrote:

>  Because the syntax is completely different.  One is period-separated
> base64url encoded fields.  The other is JSON.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Thursday, June 20, 2013 11:49 AM
> *To:* Mike Jones; 'Matt Miller (mamille2)'; 'Richard Barnes'
> *Cc:* [email-masked]
> *Subject:* RE: [jose] Should we keep or remove the JOSE JWS and JWE MIME
> types?****
>
> ** **
>
> application/jose+json.  Why not have just one of them?****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mike Jones
> *Sent:* Thursday, June 20, 2013 10:47 AM
> *To:* Matt Miller (mamille2); Richard Barnes
> *Cc:* [email-masked]
> Parameters Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#page-18>
> .****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> From: Matt Miller (mamille2) [mailto:[email-masked]<[email-masked]>]
>
> I just want to say that I think having a media type is important and
> useful.  It might not be important and useful for JWT or OAuth or
> OpenID-Connect, but I can think of many applications that would make use of
> them if at all possible.****
>
> ** **
>
> document (JWA) seems wrong.****
>
> ** **
>
> ** **
>
> - m&m****
>
> ** **
>
> Matt Miller < [email-masked] >****
>
> Cisco Systems, Inc.****
>
> ** **
>
> PS: I've found +json useful for other things, because I do have
> applications that present in different formats (right now that's usually
> +xml).  While there's not a simple corollary with XML-based concepts, I
> think there will be corollaries in the future (e.g., CBOR).  Having them
> now means we're not painted into a corner if (when) we look at JOSE2 and
> support for binary representations.****
>
> ** **
>
> On Jun 20, 2013, at 10:49 AM, Richard Barnes <[email-masked]>****
>
> wrote:****
>
> ** **
>
> > That algorithm is part of the story, but it's incomplete.  What we need
> is****
>
> > an algorithm that starts with an arbitrary octet string and sorts by****
>
> > natural thing for a combined JWS+JWE document, but we don't have one of*
> ***
>
> > those :(****
>
> > ****
>
> > ****
>
> > ****
>
> > ****
>
> [email-masked]>wrote:****
>
> > ****
>
> >> There is a defined algorithm to distinguish between the JWS and JWE****
>
> >> objects in the third paragraph of****
>
> >>
> >> .********
> >> ** ******
> >>                                                            -- Mike*****
> ***
> >> ** ******
> >> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]****
>
> >> *Sent:* Thursday, June 20, 2013 8:15 AM****
>
> >> *To:* Mike Jones****
>
> >> *Cc:* [email-masked]****
>
> >> ****
>
> >> types?********
> >> ** ******
> >> if there's a defined algorithm to demux them.  So if you want to do
> this,****
>
> >> you would need to write down the algorithm.********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> >> Personally, it seems simpler and clearer to me to just have the four***
> *
>
> with,****
> >> and in what serialization, without having to do content sniffing.******
> **
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> [email-masked]>****
>
> >> wrote:********
>
> >> ****
>
> >> The JWS and JWE documents currently define these MIME types for the****
>
> >> convenience of applications that may want to use them:********
>
> >> ****
>
> >>                application/jws********
>
> >> ****
>
> >>                application/jws+json********
>
> >> ****
>
> >>                application/jwe********
>
> >> ****
>
> >>                application/jwe+json********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> That being said, I’m not aware of any uses of these by applications at*
> ***
>
> to****
> >> keep them or remove them – in which case, if applications ever needed
> them,****
>
> >> they could define them later.********
>
> >> ****
>
> >> ********
>
> >> ****
>
> clear****
> >> that the four types application/jws, application/jws+json,
> application/jwe,****
>
> >> and application/jwe+json are even the right ones.  It might be more
> useful****
>
> >> could hold either JWS or JWE objects respectively using the compact or
> JSON****
>
> >> serializations (although I’m not advocating adding them at this
> time).********
>
> >> ****
>
> >> ********
>
> >> ****
>
> at****
> >> them could help eliminate this possibility of confusion in the future.*
> ***
>
> >> Thus, I’m increasingly convinced we should get rid of the JWS and JWE
> types****
>
> >> need them.********
> >> ********
> leave****
> >> them to future specs to define, if needed?********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >>                                                                --
> Mike*******
>
> >> *****
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> P.S.  For completeness, I’ll add that the JWK document also defines
> these****
>
> >> MIME types:********
>
> >> ****
>
> >>                application/jwk+json********
>
> >> ****
>
> >>                application/jwk-set+json********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> deleting them, but wanted to call that out explicitly.  For instance,
> when****
>
> >> believe that the result should use the application/jwk-set+json type.
> (In****
>
> >> fact, I’ll add this to the specs, unless there are any objections.)****
>
> >> Likewise, draft-miller-jose-jwe-protected-jwk-02 already uses****
>
> >> application/jwk+json.  Both could also be as “cty” values when
> encrypting****
>
> >> JWKs and JWK Sets, in contexts where that that would be useful.********
>
> >> ****
>
> >> ********
>
> >> ****
>
> >> ****
>
> >> _______________________________________________****
>
> >> jose mailing list****
>
> >> [email-masked]****
>
> >> https://www.ietf.org/mailman/listinfo/jose********
>
> >> ****
>
> >> ** ******
>
> >> ****
>
> > _______________________________________________****
>
> > jose mailing list****
>
> > [email-masked]****
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 20 Jun 2013 14:47:46 -0600

I'm okay dropping them.

On Thu, Jun 20, 2013 at 2:39 PM, Edmund Jay <[email-masked]> wrote:

> +1 in favor of dropping
>
> ------------------------------
> *From:* Mike Jones <[email-masked]>
> *To:* "[email-masked]" <[email-masked]>
> *Sent:* Tue, June 18, 2013 6:42:15 PM
> *Subject:* [jose] Should we keep or remove the JOSE JWS and JWE MIME
> types?
>
> serializations (although I’m not advocating adding them at this time).
>
>
>
> need them.
> them to future specs to define, if needed?
>
>
>
>                                                                 -- Mike
>
>
>
> MIME types:
> JWKs and JWK Sets, in contexts where that that would be useful.
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 16:52:40 -0400

To be clear, when people say "dropping them", you mean "changing from four
MIME types to two", right?

Dropping the MIME types altogether is not an option, as Matt noted.

--Richard

On Thu, Jun 20, 2013 at 4:47 PM, Brian Campbell
<[email-masked]>wrote:

>> at least Dick’s confusion about the purpose of the “typ” field, so deleting

---

From: John Bradley <[email-masked]>
Date: Mon, 24 Jun 2013 19:49:41 -0400

+1 I am OK with dropping those 4 Mime types. 

I think a single generic media type for JOSE is the correct thing. 

John B.

On 2013-06-20, at 4:47 PM, Brian Campbell <[email-masked]> wrote:

> That being said, I’m not aware of any uses of these by applications at present.  Thus, I think that makes it fair game to ask whether we want to keep them or remove them – in which case, if applications ever needed them, they could define them later.
> 
>  
> Another dimension of this question for JWS and JWE is that it’s not clear that the four types application/jws, application/jws+json, application/jwe, and application/jwe+json are even the right ones.  It might be more useful to have generic application/jose and application/jose+json types, which could hold either JWS or JWE objects respectively using the compact or JSON serializations (although I’m not advocating adding them at this time).
> 
>  
> Having different JWS versus JWE MIME types apparently did contribute to at least Dick’s confusion about the purpose of the “typ” field, so deleting them could help eliminate this possibility of confusion in the future.  Thus, I’m increasingly convinced we should get rid of the JWS and JWE types and leave it up to applications to define the types they need, when they need them.
> 
>  
> P.S.  For completeness, I’ll add that the JWK document also defines these MIME types:
> 
>                 application/jwk+json
> 
>                 application/jwk-set+json
> 
>  
> There are already clear use cases for these types, so I’m not advocating deleting them, but wanted to call that out explicitly.  For instance, when retrieving a JWK Set document referenced by a “jku” header parameter, I believe that the result should use the application/jwk-set+json type.  (In fact, I’ll add this to the specs, unless there are any objections.)  Likewise, draft-miller-jose-jwe-protected-jwk-02 already uses application/jwk+json.  Both could also be as “cty” values when encrypting JWKs and JWK Sets, in contexts where that that would be useful.
> 
>  
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 25 Jun 2013 12:44:27 +1000

> I think a single generic media type for JOSE is the correct thing.

John,
Are you saying you want to replace those 4 with 1?
So 1 media type would cover 2 serializations?

--
James Manger

> ________________________________________

---

From: Tony Hansen <[email-masked]>
Date: Mon, 24 Jun 2013 23:14:17 -0400

Of all of the suggestions I've seen so far on this topic, I think this
one gives the best way to proceed on the media type.

To paraphrase, it

    1) replaces application/jws and application/jwe with application/jose
and
    2) replaces application/jws+json and application/jwe+json with
application/jose+json

And there is a simple algorithm that can be applied to determine whether
it's jwe or jws.

    Tony Hansen

On 6/20/2013 2:39 PM, Richard Barnes wrote:
> On Thu, Jun 20, 2013 at 1:41 PM, Mike Jones
>     I know of no use cases where the application won't know whether
>     it's using the Compact Serialization or the JSON Serialization.
>
>      
>
>     *From:*Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [jose] Should we keep or remove the JOSE JWS and
>     JWE MIME types?
>
>      
>
>     That algorithm is part of the story, but it's incomplete.  What we
>     need is an algorithm that starts with an arbitrary octet string
>     and sorts by JWS/JWE and serialization.  An outline of the flow chart:
>
>      
>
>     There's also the question of which document this goes in.  It
>     would be a natural thing for a combined JWS+JWE document, but we
>     don't have one of those :(
>
>      
>
>      
>
>      
>
>     On Thu, Jun 20, 2013 at 11:19 AM, Mike Jones
>     There is a defined algorithm to distinguish between the JWS and
>     JWE objects in the third paragraph of
>     *From:*Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>
>
>
>     *Subject:* Re: [jose] Should we keep or remove the JOSE JWS and
>     JWE MIME types?
>
>      
>
>     sense if there's a defined algorithm to demux them.  So if you
>     want to do this, you would need to write down the algorithm.
>
>      
>
>     Personally, it seems simpler and clearer to me to just have the
>     four current types, so that you know which type of object you're
>     dealing with, and in what serialization, without having to do
>     content sniffing.
>
>      
>
>     The JWS and JWE documents currently define these MIME types for
>     the convenience of applications that may want to use them:
>
>                     application/jws
>
>                     application/jws+json
>
>                     application/jwe
>
>                     application/jwe+json
>
>      
>
>     That being said, I'm not aware of any uses of these by
>     applications at present.  Thus, I think that makes it fair game to
>     ask whether we want to keep them or remove them -- in which case,
>     if applications ever needed them, they could define them later.
>
>      
>
>     Another dimension of this question for JWS and JWE is that it's
>     not clear that the four types application/jws,
>     application/jws+json, application/jwe, and application/jwe+json
>     are even the right ones.  It might be more useful to have generic
>     application/jose and application/jose+json types, which could hold
>     either JWS or JWE objects respectively using the compact or JSON
>     serializations (although I'm not advocating adding them at this time).
>
>      
>
>     Having different JWS versus JWE MIME types apparently did
>     contribute to at least Dick's confusion about the purpose of the
>     "typ" field, so deleting them could help eliminate this
>     possibility of confusion in the future.  Thus, I'm increasingly
>     convinced we should get rid of the JWS and JWE types and leave it
>     Do people have use cases for these four MIME types now or should
>     we leave them to future specs to define, if needed?
>
>      
>
>                                                                     --
>     Mike
>
>      
>
>     application/jwk-set+json type.  (In fact, I'll add this to the
>     specs, unless there are any objections.)  Likewise,