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