No, "cty" is used by the derived class to determine the type of the
encapsulated field. But that's not a complete description of the *entire
object* - especially not the additional meaning imbued by the additional
parameters the derived type may add to the JOSE header. "typ" is there to
provide the type of the entire object, including what you're calling the
wrapper parts.
-- Mike
From: Richard Barnes [mailto:[email protected]]
Sent: Thursday, May 30, 2013 7:58 AM
To: Mike Jones
Cc: Jim Schaad; [email protected]; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header field
Isn't that requirement met by "cty"? The only thing JOSE adds is a crypto
wrapper around the real application content. If you're an application, you
know a JOSE object is the thing you want because it contains the content you
want -- it's a JWT because it contains JWT claims.
Inheritance is the wrong metaphor. This is encapsulation of application data:
if (jws.valid && jws.cty == "application/jwt_claims") {
jwtClaims = jws.content;
}
--Richard
On Thu, May 30, 2013 at 10:43 AM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Thanks for sharing the S/MIME details. Although I was actually making the
analogy to MIME - not S/MIME. Like many analogies, it's imperfect, but I
believe still illustrative.
The reason that the analogy isn't perfect is that the JOSE data structures are
used to build application-specific data structures that are legal JOSE data
structures but also have additional properties - including additional header
fields with specific semantics. (When we agreed to ignore not-understood
header fields we let that horse out of the barn.) For instance, Dick Hardt
uses JWEs with issuer and audience fields in the headers, so they can be used
by routing software.
Think of JOSE as the base class and the application types built using it as
derived classes. JWT is a derived class. Dick's structures are a derived
class. These derived classes sometimes need names. That's what "typ" is for.
-- Mike
From: Richard Barnes [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, May 30, 2013 7:34 AM
To: Mike Jones
Cc: Jim Schaad; [email protected]<mailto:[email protected]>; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header field
You're mixing up "typ" and "cty". If you want to make the analogy to S/MIME,
"cty" is the equivalent to Content-Type inside the protected MIME body; "typ"
is the content-type on the outer MIME header. Pasting in an example:
-----BEGIN-----
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
-----END-----
<http://tools.ietf.org/html/rfc3851#section-3.4.2>
The outer Content-Type, which is analogous to "typ", MUST be
application/pkcs7-mime, with a parameter indicating the type of CMS object.
This is the same as requiring "typ" to be JWE or JWS. The inner Content-Type
(ASN.1/base64 encoded in the example) can be anything, just like "cty".
--Richard
On Thu, May 30, 2013 at 12:53 AM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Requiring that the "typ" value be only "JWS" or "JWE" would be analogous to the
MIME spec requiring that the Content-Type: field be only "text/plain" or
"message/external-body". It would render it useless.
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of
Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; [email protected]<mailto:[email protected]>; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header field
If this is the level of "type" you're referring to, I think we should drop it
from the spec. It's an application-layer thing that the app can add or not
according to its wishes.
I'm with Dick on this. I think we should either have a mandatory indicator of
what type of JOSE object this, or nothing at all. If the former, the
allowable values are "JWE" and "JWS". The "+JSON" options are non-sensical --
the app needs to know what it's parsing before it gets this header. While I
have a preference for the former (for clarity), the latter approach is also OK
with me, since the MIME types are specific to JWE/JWS.
Another approach here would be to address the JSON and compact forms
separately. The JSON form has no need of "typ" at all, since the type of the
object is completely clear from what fields are there, e.g., "recipients" vs.
"signatures". For the compact form, we could do something like James's
"E."/"S." prefix idea, which you need because the dot-separated components have
different meanings and no field names to indicate this.
--Richard
On Wed, May 29, 2013 at 8:30 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
A standard library is unlikely to know the meanings of all possible "typ"
values - and more to the point, it doesn't have to. It's the application's job
to determine that "this blob is a JOSE object" and then pass it to a standard
library, which will then ignore the "typ" value.
A standard JOSE library won't know what "typ": "JWT" means. It won't know what
"typ": "BCGovToken" is, should the BC Government want to declare that it's
using a token with particular characteristics. It won't know what "typ":
"XMPP" is, should XMPP want to declare that it's using a JOSE data structure
with particular characteristics. Etc.
All these values can be registered in the registry and used by applications
that understand them. That's the application's job - not the library's job.
The "typ" field is just there so that applications have a standard place to
make any such declarations that they may need.
-- Mike
From: Dick Hardt [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; [email protected]<mailto:[email protected]>
Subject: Re: [jose] Should we delete the "typ" header field
I'd prefer to be able to use standard libraries for creating and parsing
tokens, and not specialized libraries dependent on the use case.
I strongly think we either drop "typ" or make it required.
On Wed, May 29, 2013 at 5:03 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
It's fine for your application to specify that it's required for your use case.
Not applications need it, so they shouldn't be forced to pay the space penalty
of an unnecessary field.
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Dick
Hardt
Sent: Wednesday, May 29, 2013 4:56 PM
To: Jim Schaad
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [jose] Should we delete the "typ" header field
I use it all the time and my code would barf if it was not there.
I think it should be required rather than be a hint if it is going ot be there.
On Wed, May 29, 2013 at 4:40 PM, Jim Schaad
<[email protected]<mailto:[email protected]>> wrote:
I think the values just changed
However the way you are using it would be an argument to say that it should be
a required field. Are you just using it as a hint if it exists and then
looking at the rest of the fields if it is not present?
Jim
From: Dick Hardt [mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [jose] Should we delete the "typ" header field
Well, I have been using, but now realize the spec changed or I was confused.
I had been setting "typ" to be either "JWE" or "JWS" depending on the type of
token I was creating or parsing as it was easier than looking at "alg"
As currently defined, I don't see value in "typ".
-- Dick
On Wed, May 29, 2013 at 3:02 PM, Jim Schaad
<[email protected]<mailto:[email protected]>> wrote:
In reading the documents, I am trying to understand the justification for
having the "typ" header parameter in the JOSE documents.
The purpose of the field is to hold the type of the object. In the past, I
believe that values which should now be placed in the cty field (such as "JWT")
were placed in this field as well. However the parameter is optional and an
implementation cannot rely on its being present. This means that for all
practical purposes all of the code to determine the value of the type field
from the values of the alg and enc fields. If the field was mandatory then
this code would disappear at a fairly small space cost and I can understand why
the parameter would be present.
Can anybody justify why this field should be present in the document - or
should it just disappear?
Jim
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
-- Dick
--
-- Dick
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
-- Dick
_______________________________________________
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
