Why would you need that in the header? Why not in the payload?
On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <[email protected]> wrote: > 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 > -- -- Dick
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
