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 < [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]>
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]>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]
*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]>
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]
https://www.ietf.org/mailman/listinfo/jose****
** **
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
