On Tuesday, September 16, 2014, Richard Barnes <[email protected]> wrote: > I will re-iterate here my strong preference that an "unsecured" or > "plaintext" JWS object be syntactically distinct from a real JWS object. > E.g. by having two dot-separated components instead of three. >
So, *I* was just grumping about the term used in the draft, but yes, these should (IMO, etc) be different. I'm also still uncomfortable about the "you can have the same information in the "secured" and "unsecured" section, but the secured one shold be trusted more bit. This seems like it will end in fail. (Apologies if this was already discussed and I missed it, and for rushed tone of mail, traveling...) W > Beyond that, seems like just shuffling deck chairs. > > On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. >> >> I agree that "plaintext” is not the most intuitive wording choice and >> that "unsecured" might better convey what's going on with the "none" JWS >> algorithm. >> >> Mike mentioned that, if this change is made in JWT, there are parallel >> changes in JWS. But note that there are also such changes in JWA (more than >> in JWS actually). >> >> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> -----Original Message----- >>> From: Warren Kumari [mailto:[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>] >>> Sent: Monday, September 01, 2014 3:40 PM >>> To: [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>; >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> Subject: Review of: draft-ietf-oauth-json-web-token >>> >>> I'm a little confused by something in the Terminology section (Section >>> 2): >>> >>> Plaintext JWT >>> >>> A JWT whose Claims are not integrity protected or encrypted. >>> >>> The term plaintext to me means something like "is readable without >>> decrypting / much decoding" (something like, if you cat the file to a >>> terminal, you will see the information). Integrity protecting a string >>> doesn't make it not easily readable. If this document / JOSE uses >>> "plaintext" differently (and a quick skim didn't find anything about >>> >>> this) it might be good to clarify. Section 6 *does* discuss plaintext >>> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term >>> "plaintext" here. >>> >>> >>> >>> I’ve discussed this with the other document editors and we agree with >>> you that “plaintext” is not the most intuitive wording choice in this >>> context. Possible alternative terms are “Unsecured JWT” or “Unsigned >>> JWT”. I think that “Unsecured JWT” is probably the preferred term, since >>> JWTs that are JWEs are also unsigned, but they are secured. Working group >>> – are you OK with this possible terminology change? (Note that the >>> parallel change “Plaintext JWS” -> “Unsecured JWS” would also be made in >>> the JWS spec.) >>> >>> >>> >> >> _______________________________________________ >> jose mailing list >> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://www.ietf.org/mailman/listinfo/jose >> >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
