Re: [jose] Should we delete the "typ" header field

["Jim Schaad" <[e-mail]>]

<no hat>

I kept trying to send this message out during the last week, but I have been
doing too much physical activity to be awake at night and produce a coherent
message.

The opinions here are my personal opinions, some of them might be things
that I would also advocate as a chair, but don't assume just because it is
here I would.

I have been looking at the conversation on this topic with slight surprise,
I did not really expect this type of firestorm to occur on a part of the
spec that had been in for quite a while.

Givens:
1.  My general inclination is that things in the document generally stay in
the document, however they do need to be shown to be clearly described and
useful.

2.  My general inclination is that things which can be shown to be useful
for multiple applications can be done in the base document.  That said,
there is nothing that says such a thing could not be defined in one of the
application specs which uses it rather than the base document.

My understanding:

My understanding of what Mike has said is that this field is meant to
clearly present that this is a JSON thing for a specific application.  This
is contrary to the expectation that Richard, Dick and myself had where it
was a description of the "security service" rather than the application.

My problem with this understanding is I am not sure when it is a useful
concept to have.  In order for it to be needed you would need to have two
statements being true:

1.  There is no way to know the application from the current protocol being
exercised and
2.  There is no way to correctly infer the application from the value of the
ctyp field (if present).

Under the current circumstances as I understand the JWT specification,
neither of these criteria would be met.

Nat gave an interesting example of a case where it might be useful, that of
a Time Stamp Provider.  My problem with this is that I don't think of this
as being an application protocol, but as being a different security service.
Thus a timestamp JWS is a specialized version of a normal JWS.  As such, yes
it would make sense to me that the type field could be used to differentiate
between a normal JWS and a timestamp-JWS.  But a timestamp would be, by
definition, completely agnostic about the inner content provided.  The same
could not be said of a JWT application.  It needs to understand the specific
inner content that was provided.  

SideBar:  It is not immediately clear to me that a classic timestamp
provider could be done using the JOSE data structures as it normally
requires that one can produce a timestamp without sharing the content with
the timestamp producer.  There are also interesting discussions on if the
fact that it is a timestamp or other special signature should be signaled in
the signature object or as a key parameter.  However none of this paragraph
is relevant to the current discussion.

I think that I would like to see the following things:

1.  Two clear use cases provided, one for JWT and one for something else
where the typ field as an application indicator would be useful/required.  I
think that such a thing needs to address the two points that I presented
previously.

2.  I don't believe that anyone has addressed the question I raised about
the fact that both the ctyp and typ fields are using the same registry, thus
JWT would mean different things depending on which field it is in.

3.  I had a message dated 5/30/13 where I asked a couple of questions.  This
message was not responded to.

Jim