Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, October 21, 2014 6:17 AM
To: Mike Jones; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
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:[e-mail]] On Behalf Of Mike Jones
>> Sent: Monday, October 06, 2014 7:20 PM
>> To: Stephen Farrell; The IESG
>> Cc: [e-mail]; draft-ietf-oauth-json-web- 
>> [e-mail]; [e-mail]
>> 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:[e-mail]]
>>> Sent: Monday, October 06, 2014 2:43 PM
>>> To: Mike Jones; The IESG
>>> Cc: [e-mail]; draft-ietf-oauth-json-web- 
>>> [e-mail]; [e-mail]
>>> 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:[e-mail]] Sent: Thursday, October 02, 
>>>>> 2014
>>>>> 5:03 AM To: The IESG Cc: [e-mail];
>>>>> draft-ietf-oauth-json-web- [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>