"typ" declares what the type of THIS OBJECT is.
"cty" declares what the type of THE PAYLOAD or THE PLAINTEXT is.
They're different.
In the JWT case, a JWT Claims Set (the normal JWT Payload), which is a JSON
Object containing Claims, is a completely different data structure from a JWT,
which is a dot-separated list of base64url encoded fields. The "cty"
represents the former; the "typ" represents the latter.
-- Mike
From: Jim Schaad [mailto:[email protected]]
Sent: Wednesday, May 29, 2013 4:43 PM
To: Mike Jones; [email protected]
Subject: RE: [jose] Should we delete the "typ" header field
Can you justify why the JWT spec should not specify that it should not be
"ctyp" : "JWT"?
Jim
From: Mike Jones [mailto:[email protected]]
Sent: Wednesday, May 29, 2013 4:24 PM
To: Jim Schaad; [email protected]<mailto:[email protected]>
Subject: RE: [jose] Should we delete the "typ" header field
"typ" is there so that there's a standard header parameter field for declaring
what the data structure is so that it's there for applications for which this
declaration is useful. For instance, the JWT spec specifies that "typ": "JWT"
can be used to declare that the object is a JSON Web Token, should that be
useful in context.
For those of you who may not be aware of it, the JSON Web Signature and
Encryption Type Values
Registry<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-10.2>
semantically ties short "typ" names to MIME types - so there's a well-defined
way that the types of JOSE objects relate to the well-established MIME type
system. In fact, MIME types are explicitly allowed to be used as "typ" values.
Ironically, there was actually a working discussion on this late 2011 and early
2012 that resulted in the decision to keep "typ" in our specs, rather than
having the JWT spec define it, and that resulted in the creation of the
registry. In that thread ("[jose] Comments on the -03 JSON Web Signature
document"), you wrote Jim:
[JLS] If it is believe that a parameter this list is going to be "commonly"
used by many different profilers, then I believe that the core items needs to
be done the in the base specification. I would therefore not be in favor of
punting it out to somebody else. The only exception would be if we are going
to have a very light core and a "real" core specs. In this case the very light
core spec could punt to the "real" core spec. Having said that I think that a
registry would be a good idea.
That's been the state of the "typ" parameter specs ever since - I believe for
the good reasons that you cited then. I haven't heard anyone argue that that
reasoning was wrong - only that *their particular use case* may not need a
"typ" value. Just because all use cases don't need it isn't a sufficient
argument to delete it and thereby hinder those that do.
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Wednesday, May 29, 2013 3:03 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] Should we delete the "typ" header field
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]
https://www.ietf.org/mailman/listinfo/jose
