On Tue, Oct 21, 2014 at 9:16 AM, Stephen
Farrell<stephen.farr...@cs.tcd.ie
<mailto: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
<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
<mailto:oauth-cha...@tools.ietf.org>; draft-ietf-oauth-json-web-
>>to...@tools.ietf.org
<mailto:to...@tools.ietf.org>;oauth@ietf.org
<mailto: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
<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
<mailto:oauth-cha...@tools.ietf.org>; draft-ietf-oauth-json-web-
>>>to...@tools.ietf.org
<mailto:to...@tools.ietf.org>;oauth@ietf.org
<mailto: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
<mailto:stephen.farr...@cs.tcd.ie>] Sent: Thursday, October
02, 2014
>>>>> 5:03 AM To: The IESG Cc:oauth-cha...@tools.ietf.org
<mailto:oauth-cha...@tools.ietf.org>;
>>>>> draft-ietf-oauth-json-web-to...@tools.ietf.org
<mailto: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.htmlfor
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
ashttp://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
removedhttp://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
athttps://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 <mailto:OAuth@ietf.org>
>>https://www.ietf.org/mailman/listinfo/oauth
>
--
Best regards,
Kathleen
