On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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." > I like this wording suggestion, thanks. > > 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 > > > > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
