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

[Edmund Jay <[e-mail]>]

+1 in favor of dropping



________________________________
From: Mike Jones <[e-mail]>
To: "[e-mail]" <[e-mail]>
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.