Yeah I think that's fair (though regrettable:-). Will look at it before the meeting.
S On 12/11/14 00:03, Mike Jones wrote: > Hi Stephen, > > Your DISCUSS on "alg":"none" being MTI is the only one remaining on the JWT > draft. Given the working group support for keeping things the way they are, > would you be willing to clear this DISCUSS on that basis? The OAuth WG > meeting is tomorrow, so it would be good to hear your thoughts before then, > if possible. > > Thanks, > -- Mike > > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones > Sent: Friday, October 24, 2014 8:33 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) > > Hi Stephen, > > I applied your privacy wording to the -30 draft. Thanks. > > About your DISCUSS on "alg":"none" being MTI, several working group members > have chimed in agreeing that it should continue to be MTI, and said why. In > summary - unsigned security tokens representing claims are really common in > identity protocols; interop will be improved if this functionality is MTI. > Can I therefore ask you hold your nose a little bit more and clear this > remaining DISCUSS? > > Thanks again, > -- Mike > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] > Sent: Tuesday, October 21, 2014 6:17 AM > 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, > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
