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 > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
