What I was thinking as an example was to have 'datetime' as a public header parameter to be used generally, and then differentiate between two cases of 'agreement' and 'timestamp'. It is the same signing operation over the original (e.g., a MS word document), but from an application point of view, it is a bit different. Former constitute an agreement while the later does not. The type=timestamp just signifies that the original document existed at the time indicated.
2013/6/5 Richard Barnes <[email protected]> > I'm not sure I understand the use case here. Let me look at a couple of > options, and hopefully one of them will be what you meant :) > > If it's just a signed timestamp you're talking about, then that's > adequately described by cty="timestamp", typ="JWS". > > If you want to sign something and add a timestamp in the header, then > typ="timestamp" isn't accurate according to the current specification. The > type of the whole object would have to be something like > "timestamped-content". And in that case, an application can easily > recognized that it's timestamped content by looking for the timestamp field > in the header, so the "typ" isn't really helpful. > > > Moving from the example to the general question: > > I think we finally have some common understanding on this list as to what > Mike means by "typ" in the current document -- a label for the > application-layer type of the overall object. Thanks to Mike for > clarifying that in this discussion. > > The question is whether this is a sufficiently useful thing to have in the > core spec. Obviously, applications have to know what type of object > they're dealing with when they get a JOSE object. That includes (1) what > type of content is in the payload, and (2) what application-layer fields > are required to be in the header. (1) is covered by "cty". So "typ" is > only useful in the case where: > A. The application is storing application-layer data in the JOSE header > B. The required application-layer fields can be different for different > objects > C. The required application-layer fields can be different for different > objects of the same content type > D. The required application-layer fields are not indicated by other > application-layer context > > Are there any known applications that meet these criteria? JWT does not, > for several reasons. > 1. (!A) JWT does not store application-layer data in the JOSE header, only > in the claims in the body > 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims > or another JWT, either of which makes it obvious that this is a JWT > 3. (!D) In the OAuth context, the Token Type value indicates what type of > token is being presented, e.g., JWT > > So there's not really any known use case for "typ" as currently specified. > On the other hand, Dick and James have pointed out that it can be useful > to have "typ" indicate whether the object at hand is a JWE or JWS. Which > brings us back to: > -- Change the definition of "typ" so that it indicates the JOSE-layer type > (JWE/JWS) > -- Remove "typ" altogether > > > > > > > > On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <[email protected]> wrote: > >> What about such as this? >> >> cty: original >> typ: timestamp >> >> >> 2013/6/5 Richard Barnes <[email protected]> >> >>> It would be a good point, if it were true :) In particular, this part: >>> "[dropping 'typ'] is going to cause each and every application that >>> uses JOSE to define their own field" >>> >>> So far, I've heard of exactly one application of JOSE that requires >>> "typ" in the way it is currently specified, namely JWT. >>> >>> On the other hand, Dick's applications are apparently using it >>> differently (and, IMO, properly) to distinguish JWE/JWS. Then there are >>> all the applications out there that are OK using application context and >>> "cty" to recognize what type of object they have. Apps using CMS have been >>> doing this for ages. >>> >>> So it's not at all clear to me that there's any other application that >>> would use "typ" besides JWT. And it's not clear to me that JWT needs it. >>> >>> --Richard >>> >>> >>> >>> >>> >>> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell < >>> [email protected]> wrote: >>> >>>> Nat makes a good point here, I think. >>>> >>>> >>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <[email protected]>wrote: >>>> >>>>> From what I understand, both typ and cty are something to be consumed >>>>> by the application and not JOSE processor. From the point of view of the >>>>> JOSE processor, they should be ignored. >>>>> >>>>> We could drop both fields from JOSE specs, but that is going to cause >>>>> each and every application that uses JOSE to define their own field, which >>>>> is a waste. That is why we are defining them here. >>>>> >>>>> I would rather drop them than define JOSE processing semantics to >>>>> these fields. >>>>> >>>>> >>>>> 2013/5/31 Mike Jones <[email protected]> >>>>> >>>>>> 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]> 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]] >>>>>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>>>>> >>>>>> >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; [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]> 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]] *On >>>>>> Behalf Of *Richard Barnes >>>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; [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]> 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]] >>>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; [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]> 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]] *On >>>>>> Behalf Of *Dick Hardt >>>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>>>>> >>>>>> >>>>>> *To:* Jim Schaad >>>>>> *Cc:* [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]> >>>>>> 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]] >>>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>>>>> *To:* Jim Schaad >>>>>> *Cc:* [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]> >>>>>> 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] >>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>> >>>>>> >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> -- Dick **** >>>>>> >>>>>> >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> -- Dick **** >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>> >>>>>> >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> -- Dick **** >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> ** ** >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>> >>>>> >>>> >>> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
