Hi Mike, I've one remaining discuss point and a comment. See below...
On 14/10/14 13:50, Mike Jones wrote: > The proposed resolutions below have been included in the -28 draft. > Hopefully you'll be able to clear your DISCUSSes on that basis. > > The String Comparison Rules in Section 7.3 have been expanded to talk about > when the application may need canonicalization rules. > > Thanks again, > -- Mike > >> -----Original Message----- >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones >> Sent: Monday, October 06, 2014 7:20 PM >> To: Stephen Farrell; The IESG >> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- >> to...@tools.ietf.org; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json- >> web-token-27: (with DISCUSS and COMMENT) >> >> Thanks for tracking all of this Stephen. Responses inline below... >> >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] >>> Sent: Monday, October 06, 2014 2:43 PM >>> To: Mike Jones; The IESG >>> Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- >>> to...@tools.ietf.org; oauth@ietf.org >>> Subject: Re: Stephen Farrell's Discuss on >>> draft-ietf-oauth-json-web-token-27: >>> (with DISCUSS and COMMENT) >>> >>> >>> Hi Mike, >>> >>> On 06/10/14 08:54, Mike Jones wrote: >>>> Thanks for your review, Stephen. I've added the working group to >>>> the thread so they're aware of your comments. >>>> >>>>> -----Original Message----- From: Stephen Farrell >>>>> [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 >>>>> 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; >>>>> draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with >>>>> DISCUSS and COMMENT) >>>>> >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-oauth-json-web-token-27: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to >>>>> all email addresses included in the To and CC lines. (Feel free to >>>>> cut this introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>>> information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found >>>>> here: >>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>> DISCUSS: >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>>>> >>>>> >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I >>> raised wrt DNS >>>>> names for another JOSE spec - do you need to say those SHOULD be >>>>> [upper|lower]cased when used in these? >>>> >>>> I believe that somewhere we should say that if case-insensitive >>>> values, such as DNS names, are used when constructing "kid" values, >>>> that the application doing so needs to define a convention on the >>>> canonical case to use for the case-insensitive portions, such as >>>> lowercasing them. >>> >>> As that discussion's happening on the key draft, I'll clear it here >>> and trust you to fix if a change is the end result. >> >> Thanks np >> >>>>> (2) Section 8: Why is "none" MTI? That seems both broken and going >>>>> in the oppostite direction from other WGs and so should be >>>>> explicitly jusified I think. (If a good enough justification exists >>>>> that is.) >>>> >>>> It is MTI because there are several existing applications of JWTs in >>>> which both unsigned and signed representations of the JWTs are >>>> requirements. These include draft-ietf-oauth-token-exchange, >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty >>>> common pattern where you sign something if the recipient cares who >>>> made the statements and where you don't have to sign it either if >>>> the recipient doesn't care who made the statements >>> >>> I don't see how (non-)signers can divine non-verifier's wishes that >>> way. (Absent negotiation or a directory.) >> >> Sometimes it does occur via negotiation. For instance, in some protocols, at >> registration time, relying parties explicitly tell identity providers what >> algorithms >> are acceptable to them, which may include "none". No divination - explicit >> communication. >> >>>> or if it can tell from >>>> another secured aspect of the application protocol (typically >>>> through the use of TLS) who made the statements. In the TLS case, >>>> the server authentication step makes a signature step unnecessary, >>>> so an Unsecured JWT is fine there. >>> >>> That's arguable IMO. >> >> I agree that it's application and context-dependent whether it's OK or not. >> The >> point is that there exist some circumstances in which it is OK, and this >> feature is >> being used in some of those cases. >> >>> I think I'll look back over the wg thread and either hold my nose or >> >> This issue was tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >> Karen O'Donoghue recorded this conclusion in the tracker "Note: There was >> extensive discussion on the mailing list, and the rough consensus of the >> working >> group was to leave "none" in the document." >> >> Discussion threads on this topic include: >> [jose] #36: Algorithm "none" should be removed http://www.ietf.org/mail- >> archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 messages) >> [jose] Text about applications and "alg":"none" http://www.ietf.org/mail- >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages) >> >> This issue was a topic of a special working group call on Aug 19, 2013. The >> text >> discussed in the last thread and published at >> https://tools.ietf.org/html/draft- >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security >> Considerations) was the result of the working group's decisions resulting >> from all >> of this discussion. Thanks for all the pointers above. I read through all the (many!) Aug 19 mails and most of the `"none" should be removed" thread. So I do see that there was rough consensus to keep "none" in the draft and can (with difficulty;-) hold my nose and let that pass. I do not however, see that there was consensus to make "none" MTI for this draft. I did see a bit of haggling about this draft vs. JWS but still do not see why none ought be MTI here. >> >>>>> (3) Section 12: another way to handle privacy is to not include >>>>> sensitive data - I think you ought mention that as a bit of thought >>>>> along those lines can be much simpler than putting in place the key >>>>> management to handle thoughtlessly included PII. >>>> >>>> We can include a discussion of that point, >>> >>> Great. "Just say no" is workable here:-) I'll clear when we get such text. >>> >>>> but sometimes the very >>>> point of a JWT is to securely deliver PII from a verifiable party to >>>> an intended party with appropriate rights to receive it. >>> >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often >>> PII is really needed for authorization with oauth. My guess would be >>> that its needed far less often than its found to be profitable >>> perhaps, or that carelessness plays a big role in using PII for such >>> purposes. I've cleared on this as you added this text: "Of course, including only necessary privacy-sensitive information in a JWT is the most basic means of minimizing any potential privacy issues." That seems to me like a fairly offputting way to phrase it. I'd suggest instead: "Omitting privacy-sensitive information from a JWT is the simplest way of minimizing privacy issues." Cheers, S. PS: I didn't check the comments. >>> >>> S. >>> >>> >>> >>>> >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>> COMMENT: >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>>>> >>>>> >>> - abstract: 2nd sentence isn't needed here, in intro would be fine. >>>> >>>> I don't know - I think it's a big deal that the claims can be >>>> digitally signed or MACed and/or encrypted. That's the reason we >>>> have JWTs, rather than just JSON. >>>> >>>>> - 4.1.7: maybe worth adding that jti+iss being unique enough is not >>>>> sufficient and jti alone has to meet that need. In X.509 the >>>>> issuer/serial has the equivalent property so someone might assume >>>>> sequential jti values starting at 0 are ok. >>>> >>>> Makes sense to add a warning of some kind along these lines. I >>>> think I know the reasons you say that, but can you expand on that >>>> thought a bit before I take a stab on writing this up? For >>>> instance, while normally true, I don't think your observation is >>>> true if a relying party will only accept tokens from a single issuer. >>>> >>>>> - section 6: yuk >>>>> >>>>> - again I think the secdir comments are being handled by Kathleen >>>>> and the authors. >>>> >>>> Again, this is there because multiple applications asked for the >>>> ability to represent content that is optionally signed, sometimes >>>> securing it another way, such as with TLS. JWTs are used specific >>>> application protocol contexts - not in isolation. >>>> >>>> Thanks again, -- Mike >>>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
