Subject: [Id-event] Eric Rescorla's No Objection on draft-ietf-secevent-token-10: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sun, 06 May 2018 15:31:10 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-secevent-token-10: No Objection

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-secevent-token/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4210

IMPORTANT
S 2.2.
>         *  a URI representing a user resource that was modified; or,
>   
>         *  a token identifier (e.g. "jti") for a revoked token.
>   
>         If used, the profiling specification SHOULD define the content and
>         format semantics for the value.  This claim is OPTIONAL, as the

Doesn't this need to be a MUST for interoperability?

S 4.
>         present but require that all be understood if the SET is to be
>         accepted.  Some profiles might require that only a single value be
>         present.  All such choices are within the scope of profiling
>         specifications to define.
>   
>   4.  Preventing Confusion between SETs and other JWTs

Why don't you include some claim that makes these unambiguously SETs?
That would at least prevent one directional confusion.

COMMENTS
S 2.2.
>   
>      "iss" (Issuer) Claim
>         As defined by Section 4.1.1 of [RFC7519], this claim contains a
>         string identifying the service provider publishing the SET (the
>         issuer).  In some cases, the SET issuer is not the issuer of the
>         security subject.  Therefore, implementers cannot assume that the

I am having a hard time reading this text. What do you mean "issue or
security subject?"

S 3.
>         Profiling specifications MUST define how the event subject is
>         identified in the SET, as well as how to differentiate between the
>         event subject's issuer and the SET issuer, if applicable.  It is
>         NOT RECOMMENDED for profiling specifications to use the "sub"
>         claim in cases in which the subject is not globally unique and has
>         a different issuer from the SET itself.

Doesn't this contradict the SHOULD i called out above?

S 5.1.
>      personally identifiable information SHOULD be encrypted using JWE
>      [RFC7516] or secured for confidentiality by other means.
>   
>      Unless integrity of the JWT is ensured by other means, it MUST be
>      signed using JWS [RFC7515] so that the SET can be authenticated and
>      validated by the SET recipient.

This MUST seems less helpful than it would otherwise be because it
doesn't specify what a valid signer is.

S 5.4.
>      When SETs are delivered asynchronously and/or out-of-band with
>      respect to the original action that incurred the security event, it
>      is important to consider that a SET might be delivered to a SET
>      recipient in advance of or behind the process that caused the event.
>      For example, a user having been required to log out and then log back
>      in again, may cause a token revoked SET to be issued, typically

Might be clearer to quote "token revoked"

---

From: Phil Hunt <[email-masked]>
Date: Sun, 6 May 2018 15:56:55 -0700

Eric, 

Thanks for the great comments, my responses in line. 

Mike can you answer the disambiguation question?

Phil

> On May 6, 2018, at 3:31 PM, Eric Rescorla <[email-masked]> wrote:
> 

Agreed. Also per your comment below. 
> That would at least prevent one directional confusion.

I will leave Mike to comment here. 
> I am having a hard time reading this text. What do you mean "issue or

“issuer of the security subject” not ‘or’. 

JWT has a usage pattern where iss of the assertion is the same issuer of the subject. 

In SET an issuer may wish to talk about someone else's subject. Hence the issuer of the subject is not the issuer of the security token assertion. 

If you like, I am happy to work on the text some more.  
> Doesn't this contradict the SHOULD i called out above?

Agreed. Will change per above suggestion. 
> doesn't specify what a valid signer is.

Will reference the appropriate section in 7515. 
> Might be clearer to quote "token revoked"

Will do.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 May 2018 16:19:36 -0700

> “issuer of the security subject” not ‘or’.

Sorry, typo.

> In SET an issuer may wish to talk about someone else's subject. Hence the
> issuer of the subject is not the issuer of the security token assertion.
>

Yeah, I think it might be helpful, because, as you say, this deviates from
standard JWT practice.

-Ekr

---

From: Mike Jones <[email-masked]>
Date: Mon, 7 May 2018 16:22:06 +0000

Hi EKR,

> That would at least prevent one directional confusion.

Actually, the required "events" claim makes a JWT unambiguously a SET.  So your suggestion is already satisfied by normative text in the specification.

				Thanks again,
				-- Mike

-----Original Message-----
From: Phil Hunt <[email-masked]> 
Sent: Sunday, May 6, 2018 3:57 PM
To: Eric Rescorla <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-secevent-token-10: (with COMMENT)

Eric, 

Phil

> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Will do.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 May 2018 09:47:28 -0700

On Mon, May 7, 2018 at 9:22 AM, Mike Jones <[email-masked]>
wrote:

> Actually, the required "events" claim makes a JWT unambiguously a SET.  So
> your suggestion is already satisfied by normative text in the specification.
>

Might it be worth making this point slightly more sharply?

With that said, isn't it possible other specifications might define
"events"?

-Ekr

> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Mon, 7 May 2018 16:51:48 +0000

We can look at beefing up this statement, as you suggest – probably somewhere in Section 4 (Preventing Confusion between SETs and other JWTs).

Other specifications cannot define “events” because this specification registers “events” in the IANA JWT Claims registry (that is, unless they plan to be non-conforming with the registered claims usages).

                                                       -- Mike

From: Eric Rescorla <[email-masked]>
Sent: Monday, May 7, 2018 9:47 AM
To: Mike Jones <[email-masked]>
Cc: Phil Hunt <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-secevent-token-10: (with COMMENT)

On Mon, May 7, 2018 at 9:22 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Hi EKR,

With that said, isn't it possible other specifications might define "events"?

-Ekr

                                Thanks again,
                                -- Mike

-----Original Message-----
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, May 6, 2018 3:57 PM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-secevent-token-10: (with COMMENT)

Eric,

Phil

> On May 6, 2018, at 3:31 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>

Will do.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 7 May 2018 09:53:22 -0700

+1, I was just going to say the same thing.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On May 7, 2018, at 9:51 AM, Mike Jones <[email-masked]> wrote:
> 
> From: Eric Rescorla <[email-masked] <mailto:[email-masked]>> 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Phil Hunt <[email-masked] <mailto:[email-masked]>>; The IESG <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Mon, May 7, 2018 at 9:22 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> Hi EKR,
> 
> You wrote:
> From: Phil Hunt <[email-masked] <mailto:[email-masked]>> 
> To: Eric Rescorla <[email-masked] <mailto:[email-masked]>>
> Cc: The IESG <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > On May 6, 2018, at 3:31 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > https://www.ietf.org/iesg/statement/discuss-criteria.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=h9HmvB9543zWP3cIMJFTAvV_bSyHSuYaL8cJ3XKbIc4&s=W5nvvUY8Ns5cRYJ4Ca2q0ceH7ay29dvYeWiVz_zIEM8&e=>
> > https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=h9HmvB9543zWP3cIMJFTAvV_bSyHSuYaL8cJ3XKbIc4&s=hS65LH5werLbyuOWc62pfBxaS1DJ9f4ldZ4n2FRioME&e=>
> > 
> > 
> > 
> > https://mozphab-ietf.devsvcdev.mozaws.net/D4210 <https://urldefense.proofpoint.com/v2/url?u=https-3A__mozphab-2Dietf.devsvcdev.mozaws.net_D4210&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=h9HmvB9543zWP3cIMJFTAvV_bSyHSuYaL8cJ3XKbIc4&s=TEmBRoYSFy2uyZQxmKMfZvuCqg1bffBCVucNIakRxDQ&e=>
> > 
> > 
> > 
> > IMPORTANT
> > S 2.2.
> _______________________________________________
> Id-event mailing list
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=h9HmvB9543zWP3cIMJFTAvV_bSyHSuYaL8cJ3XKbIc4&s=-yzzJ5T3VeoP3RJMCKwYfNK_kLlOSIag4rrPEqQNEZk&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=h9HmvB9543zWP3cIMJFTAvV_bSyHSuYaL8cJ3XKbIc4&s=-yzzJ5T3VeoP3RJMCKwYfNK_kLlOSIag4rrPEqQNEZk&e=>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 May 2018 09:55:55 -0700

On Mon, May 7, 2018 at 9:51 AM, Mike Jones <[email-masked]>
wrote:

> We can look at beefing up this statement, as you suggest – probably
> somewhere in Section 4 (Preventing Confusion between SETs and other JWTs).
>
>
>
> Other specifications cannot define “events” because this specification
> registers “events” in the IANA JWT Claims registry (that is, unless they
> plan to be non-conforming with the registered claims usages).
>

OK, great!

-Ekr

>
>                                                        -- Mike
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Monday, May 7, 2018 9:47 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Phil Hunt <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>
> *Subject:* Re: Eric Rescorla's No Objection on
> draft-ietf-secevent-token-10: (with COMMENT)
>
>
>
>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 May 2018 07:00:05 +0000

Thanks again for your useful comments, Ekr.  https://tools.ietf.org/html/draft-ietf-secevent-token-11 has been published to address them, as well as comments from Designated Expert Ned Freed.  I'm replying to your original message to hopefully make the replies easier to understand in context.  My replies are inline prefixed by "Mike>".

-----Original Message-----
From: Eric Rescorla <[email-masked]> 
Sent: Sunday, May 6, 2018 3:31 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Yaron Sheffer <[email-masked]>; [email-masked]; [email-masked]
Subject: Eric Rescorla's No Objection on draft-ietf-secevent-token-10: (with 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.)

IMPORTANT
S 2.2.

Mike> It's now a MUST.

S 4.

Mike> There's a new sentence in at the end of the 3rd paragraph of https://tools.ietf.org/html/draft-ietf-secevent-token-11#section-4.3 addressing this very point.

COMMENTS
S 2.2.
>         security subject.  Therefore, implementers cannot assume that 

I am having a hard time reading this text. What do you mean "issue or security subject?"

Mike> The 2nd sentence of the "iss" claim description at https://tools.ietf.org/html/draft-ietf-secevent-token-11#section-2.2 has been reworked to hopefully make it more readable.

S 3.

Mike> Not anymore, because the previous SHOULD is now a MUST.

S 5.1.
>      validated by the SET recipient.

This MUST seems less helpful than it would otherwise be because it doesn't specify what a valid signer is.

Mike> https://tools.ietf.org/html/draft-ietf-secevent-token-11#section-5.1 now says that it "MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case".

S 5.4.

Mike> Done

				Thanks again,
				-- Mike & Phil