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

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:
> 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 < mamille2@cisco.com >
> 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 <rlb@ipv.sx>
>   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
>> 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 <Michael.Jones@microsoft.com>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:rlb@ipv.sx]
>>> *Sent:* Thursday, June 20, 2013 8:15 AM
>>> *To:* Mike Jones
>>> *Cc:* jose@ietf.org
>>>
>>> *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 <Michael.Jones@microsoft.com>
>>> 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
>>> 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.****
>>>
>>> ****
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>> ** **
>>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose