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

From: Mike Jones <[email-masked]>
Date: Mon, 6 Oct 2014 07:54:14 +0000

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-masked]]
> Sent: Thursday, October 02, 2014 5:03 AM
> To: The IESG
> Cc: [email-masked]; draft-ietf-oauth-json-web-
> [email-masked]
> 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.

> (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 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.

> (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, 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.

> ----------------------------------------------------------------------
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 22:42:45 +0100

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-masked]] Sent: Thursday, October 02, 2014
>> 5:03 AM To: The IESG Cc: [email-masked];
>> draft-ietf-oauth-json-web- [email-masked] Subject: Stephen
>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with 
>> DISCUSS and COMMENT)
>> 
>> 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.
>> 
>> 
(1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised
wrt DNS
> 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.

> 
>> (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.)

> 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 think I'll look back over the wg thread and either hold my
nose or

> 
>> (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.

S.

> 
> 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 
> 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
>

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Oct 2014 19:48:09 -0300

While my personal preference is to not release PII as part of authentication, We do have people demanding attributes in SAML and Connect at LoA 2+ for identity resolution at the relying party.
https://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_ATOS.pdf  (see Appendix A)

JWT is used in much more than just OAuth these days.

John B.

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 02:19:45 +0000

Thanks for tracking all of this Stephen.  Responses inline below...

> Sent: Monday, October 06, 2014 2:43 PM
> To: Mike Jones; The IESG
> [email-masked]; [email-masked]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27:
> (with DISCUSS and COMMENT)
> 
> 
> Hi Mike,
> 
> >> 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
> 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

> >> (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.)
> >
> 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.

> > Unsecured JWT is fine there.

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.

> Great. "Just say no" is workable here:-) I'll clear when we get such text.
> 
> > but sometimes the very
> 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.
> 
> S.
> 
> 
> 
> >
> > digitally signed or MACed and/or encrypted.  That's the reason we have
> > JWTs, rather than just JSON.
> >
> >> - again I think the secdir comments are being handled by Kathleen and
> >> the authors.
> >