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 protected]]
Sent: Thursday, June 20, 2013 10:33 AM
To: Richard Barnes
Cc: Mike Jones; [email protected]
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 < [email protected]<mailto:[email protected]> >
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 protected]<mailto:[email protected]>>
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
> <[email protected]<mailto:[email protected]>>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 protected]]
>> *Sent:* Thursday, June 20, 2013 8:15 AM
>> *To:* Mike Jones
>> *Cc:* [email protected]<mailto:[email protected]>
>>
>> *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 protected]<mailto:[email protected]>>
>> 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
>> [email protected]<mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>> ** **
>>
> _______________________________________________
> jose mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
