Subject: [Id-event] Event time and the relationship between "iat" and "toe" in SET

From: Mike Jones <[email-masked]>
Date: Mon, 22 Jan 2018 14:56:41 +0000

The "iat" and "toe" claims are currently defined as follows:

iat

As defined by Section 4.1.6 of [RFC7519], a value representing when the event was issued. Unless otherwise specified, the value SHOULD be interpreted as equivalent to the actual time of the event. This claim is REQUIRED.
toe

A value that represents the date and time at which the event occurred. This value is a NumericDate (see Section 2 of [RFC7519]). This claim is RECOMMENDED. Note that some profiles may choose to omit toe and convey event time information with the iat claim or another claim.

On this topic, Annabelle recently wrote:
b.  Require that in the absence of a "toe" claim, recipients MUST NOT interpret the "iat" claim as also representing the time of event. Without this, transmitters have no way to express that they either don't know or are not willing to share the actual time of the event being described.

I understand the ask - that it be possible to express "the event time is unknown", which is a reasonable thing for some profiles to want to do.  Towards that end, I would propose to change the second sentence of the "iat" definition from:
Unless otherwise specified, the value SHOULD be interpreted as equivalent to the actual time of the event.
to:
Whether the "iat" value also conveys the time of the event or not is up to the Profiling Specification; if the event time might not be known in a particular use case, the Profiling Specification for that use case SHOULD indicate that "iat" does not convey the event time.

Explicitly leaving this up to the profile is preferable to prohibiting profiles for using "iat" as the event time, as Annabelle's proposal would do, especially because there are multiple profiles already doing so in practice.  For instance, see  Vladimir Dzhuvinov's comments<https://mailarchive.ietf.org/arch/msg/id-event/z3u-ulHbdWVqoZUcOXf3QMz-Vyc> about his implementation and the Back-Channel Logout spec<http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken>.  When the times are known to be coincident, using a single time claim is preferable to using two.

What do others think of the proposed wording making it more explicit that it's up to the profile whether "iat" also conveys the event time (something that's already true)?  The current "SHOULD" seems overly prescriptive.

                                                       -- Mike

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 22 Jan 2018 11:47:51 -0800

As I commented in the other thread, I think iat should explicitly state
that it does not imply toe. If the time of the event is know, and can be
disclosed, then it should be explicitly be included with toe.

Marius

On Mon, Jan 22, 2018 at 6:56 AM, Mike Jones <[email-masked]>
wrote:

> The “iat” and “toe” claims are currently defined as follows:
>
>
>
> iat
>
>
> As defined by Section 4.1.6 of [RFC7519], a value representing when the
> event was issued. Unless otherwise specified, the value SHOULD be
> interpreted as equivalent to the actual time of the event. This claim is
> REQUIRED.
>
> toe
>
>
> A value that represents the date and time at which the event occurred.
> This value is a NumericDate (see Section 2 of [RFC7519]). This claim is
> RECOMMENDED. Note that some profiles may choose to omit toe and convey
> event time information with the iat claim or another claim.
>
>
>
> b.  Require that in the absence of a “toe” claim, recipients MUST NOT
> interpret the “iat” claim as also representing the time of event. Without
> this, transmitters have no way to express that they either don’t know or
> are not willing to share the actual time of the event being described.
>
>
>
> I understand the ask – that it be possible to express “the event time is
> unknown”, which is a reasonable thing for some profiles to want to do.
> Towards that end, I would propose to change the second sentence of the
> “iat” definition from:
>
> *Whether the “iat” value also conveys the time of the event or not is up
> to the Profiling Specification; if the event time might not be known in a
> particular use case, the Profiling Specification for that use case SHOULD
> indicate that “iat” does not convey the event time.*
>
>
>
> Explicitly leaving this up to the profile is preferable to prohibiting
> profiles for using “iat” as the event time, as Annabelle’s proposal would
> do, especially because there are multiple profiles already doing so in
> practice.  For instance, see  Vladimir Dzhuvinov’s comments
> <https://mailarchive.ietf.org/arch/msg/id-event/z3u-ulHbdWVqoZUcOXf3QMz-Vyc>
> about his implementation and the Back-Channel Logout spec
> <http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken>.
> When the times are known to be coincident, using a single time claim is
> preferable to using two.
>
>
>
> What do others think of the proposed wording making it more explicit that
> it’s up to the profile whether “iat” also conveys the event time (something
> that’s already true)?  The current “SHOULD” seems overly prescriptive.
>
>
>
>                                                        -- Mike
>
>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 22 Jan 2018 12:22:16 -0800

To clarify, if the time of event is known, then a 'toe' is present. If no
'toe' is present, then 'toe' is not known.

For implementers that don't care, or don't know about time of event, then
they don't need to put it in. I strongly think the semantics of 'iat"
should ONLY be what they are defined as now, the time the JWT was issued at.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 23 Jan 2018 20:58:45 +0000

+1 to Dick and Marius’s comments. To my mind having one claim mean one thing, and absence of that claim means that thing is not stated is far simpler than unbounded, profile-specific conditional logic.

With that in mind, I propose the following definitions for iat and toe:

iat
    As defined by Section 4.1.6 of [RFC7519]<https://tools.ietf.org/html/rfc7519#section-4.1.6>, a value representing

    when the event was issued.  This claim is REQUIRED.

toe

    A value that represents the date and time at which the event

    occurred.  This value is a NumericDate (see Section 2 of<https://tools.ietf.org/html/rfc7519#section-2>

    [RFC7519]<https://tools.ietf.org/html/rfc7519#section-2>).  This claim is OPTIONAL.  By omitting this claim,

    the issuer indicates that they are not sharing the time of the

    event with the recipient. This could be due to privacy concerns,

    the time of the event being unknown, or any other reason.

Key points:

  *   “iat” is left as defined by JWT.
  *   There is one and only one way to express the time of event.
  *   There is one and only one way to refuse to express time of event.
  *   All rules regarding representing and interpreting the time of event are defined in one place, in the “toe” claim definition.
--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Monday, January 22, 2018 at 12:23 PM
To: Marius Scurtescu <[email-masked]>
Cc: Mike Jones <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

To clarify, if the time of event is known, then a 'toe' is present. If no 'toe' is present, then 'toe' is not known.

For implementers that don't care, or don't know about time of event, then they don't need to put it in. I strongly think the semantics of 'iat" should ONLY be what they are defined as now, the time the JWT was issued at.

On Mon, Jan 22, 2018 at 11:47 AM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
As I commented in the other thread, I think iat should explicitly state that it does not imply toe. If the time of the event is know, and can be disclosed, then it should be explicitly be included with toe.

Marius

On Mon, Jan 22, 2018 at 6:56 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The “iat” and “toe” claims are currently defined as follows:

iat

On this topic, Annabelle recently wrote:
b.  Require that in the absence of a “toe” claim, recipients MUST NOT interpret the “iat” claim as also representing the time of event. Without this, transmitters have no way to express that they either don’t know or are not willing to share the actual time of the event being described.

I understand the ask – that it be possible to express “the event time is unknown”, which is a reasonable thing for some profiles to want to do.  Towards that end, I would propose to change the second sentence of the “iat” definition from:
Unless otherwise specified, the value SHOULD be interpreted as equivalent to the actual time of the event.
to:
Whether the “iat” value also conveys the time of the event or not is up to the Profiling Specification; if the event time might not be known in a particular use case, the Profiling Specification for that use case SHOULD indicate that “iat” does not convey the event time.

Explicitly leaving this up to the profile is preferable to prohibiting profiles for using “iat” as the event time, as Annabelle’s proposal would do, especially because there are multiple profiles already doing so in practice.  For instance, see  Vladimir Dzhuvinov’s comments<https://mailarchive.ietf.org/arch/msg/id-event/z3u-ulHbdWVqoZUcOXf3QMz-Vyc> about his implementation and the Back-Channel Logout spec<http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken>.  When the times are known to be coincident, using a single time claim is preferable to using two.

What do others think of the proposed wording making it more explicit that it’s up to the profile whether “iat” also conveys the event time (something that’s already true)?  The current “SHOULD” seems overly prescriptive.

                                                       -- Mike

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Jan 2018 22:07:01 +0000

I too am all for clean and orthogonal definitions.  Thanks for trying to move this forward, Annabelle and Dick.  I agree that the “iat” and “toe” usages you advocate are the best practices.  Below I start with your definitions and slightly tweak them, to try to get us to a common position on this.

iat

(no changes from your proposal)

toe

    event with the recipient.

This deletes “This could be due to privacy concerns, the time of the event being unknown, or any other reason.”  This is editorializing and should not be part of the normative claim definition.  If you want to add something along these lines to a Privacy Considerations section or maybe the existing “Confidentiality and Integrity” section, I’d be fine with that.  If this is important to you, please propose specific text and a specific location for it.

However, for me to sign onto the new definitions that change the existing semantics, I believe that we also need to acknowledge existing practice based on the SET drafts to date.  Therefore, I would also ask that we include this disclaimer text at the end of the Core SET Claims section:

Note that some existing SET profiles and deployments use the “iat” value to represent both the SET issuance time and the event time, when they are coincident, which was a practice recommended in earlier drafts of this specification.  The overloading of “iat” to also convey the event time is NOT RECOMMENDED.

If you can live with a disclaimer along those lines that acknowledges existing practice, then I think we have a common path forward for these claims.

                                                       -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Tuesday, January 23, 2018 12:59 PM
To: Dick Hardt <[email-masked]>; Marius Scurtescu <[email-masked]>
Cc: Mike Jones <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

iat

toe

Key points:

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 22, 2018 at 12:23 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Marius

iat

                                                       -- Mike

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 23 Jan 2018 14:21:20 -0800

Looks good to me. Thanks Mike.

Marius

On Tue, Jan 23, 2018 at 2:07 PM, Mike Jones <[email-masked]>
wrote:

> I too am all for clean and orthogonal definitions.  Thanks for trying to
> move this forward, Annabelle and Dick.  I agree that the “iat” and “toe”
> usages you advocate are the best practices.  Below I start with your
> definitions and slightly tweak them, to try to get us to a common position
> on this.
>
>
>
> iat
>
>     As defined by Section 4.1.6 of [RFC7519]
> <https://tools.ietf.org/html/rfc7519#section-4.1.6>, a value representing
>
>     occurred.  This value is a NumericDate (see Section 2 of <https://tools.ietf.org/html/rfc7519#section-2>
>
>     [RFC7519] <https://tools.ietf.org/html/rfc7519#section-2>).  This claim is OPTIONAL.  By omitting this claim,
>
> If you can live with a disclaimer along those lines that acknowledges
> existing practice, then I think we have a common path forward for these
> claims.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Richard Backman, Annabelle [mailto:[email-masked]]
> *Sent:* Tuesday, January 23, 2018 12:59 PM
> *To:* Dick Hardt <[email-masked]>; Marius Scurtescu <
> [email-masked]>
> *Cc:* Mike Jones <[email-masked]>; SecEvent <
> [email-masked]>
>
> *Subject:* Re: [Id-event] Event time and the relationship between "iat"
> and "toe" in SET
>
>
>
> +1 to Dick and Marius’s comments. To my mind having one claim mean one
> thing, and absence of that claim means that thing is not stated is far
> simpler than unbounded, profile-specific conditional logic.
>
>
>
>     As defined by Section 4.1.6 of [RFC7519]
> <https://tools.ietf.org/html/rfc7519#section-4.1.6>, a value representing
>
>     occurred.  This value is a NumericDate (see Section 2 of <https://tools.ietf.org/html/rfc7519#section-2>
>
>     [RFC7519] <https://tools.ietf.org/html/rfc7519#section-2>).  This claim is OPTIONAL.  By omitting this claim,
>
>    - “iat” is left as defined by JWT.
>    - There is one and only one way to express the time of event.
>    - There is one and only one way to refuse to express time of event.
>    - All rules regarding representing and interpreting the time of event
>    are defined in one place, in the “toe” claim definition.
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Monday, January 22, 2018 at 12:23 PM
> *To: *Marius Scurtescu <[email-masked]>
> *Cc: *Mike Jones <[email-masked]>, SecEvent <
> [email-masked]>
> *Subject: *Re: [Id-event] Event time and the relationship between "iat"
> and "toe" in SET
>
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 23 Jan 2018 23:30:21 +0000

Mike,

I’m fine with both of those adjustments to the text. I will work on some text for the Privacy Considerations section regarding time of event.

One more tweak - let’s add “approximate” to the first line of the “toe” definition: ”A value that represents the approximate date and time at which the event occurred.“

From: Marius Scurtescu <[email-masked]>
Date: Tuesday, January 23, 2018 at 2:22 PM
To: Mike Jones <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, Dick Hardt <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Marius

On Tue, Jan 23, 2018 at 2:07 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I too am all for clean and orthogonal definitions.  Thanks for trying to move this forward, Annabelle and Dick.  I agree that the “iat” and “toe” usages you advocate are the best practices.  Below I start with your definitions and slightly tweak them, to try to get us to a common position on this.

iat

toe

                                                       -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 23, 2018 12:59 PM
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>

iat

toe

Key points:

Marius

iat

                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Jan 2018 23:34:15 +0000

Thanks, Annabelle.

What’s your rationale for “approximate”?  In my experience, this is exactly the kind of thing that’s likely to generate IESG feedback asking us to be more precise, unless we clearly justify why the imprecision is there.

I would be fine adding this in a note, something along the lines of “(Note that in some use cases, the represented time might be approximate.)”  That’s less likely to trigger negative IESG feedback.  Would that work for you?

                                                       -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Tuesday, January 23, 2018 3:30 PM
To: Marius Scurtescu <[email-masked]>; Mike Jones <[email-masked]>
Cc: Dick Hardt <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Mike,

From: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 23, 2018 at 2:22 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Marius

iat

toe

                                                       -- Mike

iat

toe

Key points:

Marius

iat

                                                       -- Mike

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 23 Jan 2018 23:45:22 +0000

Works for me. There are two reasons why we should make it clear that “toe” may not be the exact time:

  1.  In many cases that will be impossible or prohibitively expensive for the issuer to determine.
  2.  The issuer may want to limit precision for security or privacy reasons, e.g. to minimize the ability of recipients to correlate different events. I will go into more detail on this in the Privacy Considerations text.

From: Mike Jones <[email-masked]>
Date: Tuesday, January 23, 2018 at 3:34 PM
To: "Richard Backman, Annabelle" <[email-masked]>, Marius Scurtescu <[email-masked]>
Cc: Dick Hardt <[email-masked]>, SecEvent <[email-masked]>
Subject: RE: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Thanks, Annabelle.

                                                       -- Mike

Mike,

Marius

iat

toe

                                                       -- Mike

iat

toe

Key points:

Marius

iat

                                                       -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Tue, 23 Jan 2018 15:56:33 -0800

The use case andy expressed was an estimate, often by hand or by data analysis that an event may have occurred on an estimated date in the past. 

Eg. Accounts are being reset due to a breach on or about a specific date. 

Phil

> On Jan 23, 2018, at 3:45 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> In many cases that will be impossible or prohibitively expensive for the issuer to determine.
> The issuer may want to limit precision for security or privacy reasons, e.g. to minimize the ability of recipients to correlate different events. I will go into more detail on this in the Privacy Considerations text.
>  
> -- 
> On Tue, Jan 23, 2018 at 2:07 PM, Mike Jones <[email-masked]> wrote:
>     As defined by Section 4.1.6 of [RFC7519], a value representing
>     occurred.  This value is a NumericDate (see Section 2 of
>     [RFC7519]).  This claim is OPTIONAL.  By omitting this claim,
>     As defined by Section 4.1.6 of [RFC7519], a value representing
>     occurred.  This value is a NumericDate (see Section 2 of
>     [RFC7519]).  This claim is OPTIONAL.  By omitting this claim,
> “iat” is left as defined by JWT.
> There is one and only one way to express the time of event.
> There is one and only one way to refuse to express time of event.
> All rules regarding representing and interpreting the time of event are defined in one place, in the “toe” claim definition.
> -- 
> On Mon, Jan 22, 2018 at 11:47 AM, Marius Scurtescu <[email-masked]> wrote:
> On Mon, Jan 22, 2018 at 6:56 AM, Mike Jones <[email-masked]>  wrote:
> Explicitly leaving this up to the profile is preferable to prohibiting profiles for using “iat” as the event time, as Annabelle’s proposal would do, especially because there are multiple profiles already doing so in practice.  For instance, see  Vladimir Dzhuvinov’s comments about his implementation and the Back-Channel Logout spec.  When the times are known to be coincident, using a single time claim is preferable to using two.
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=O-dbtcRF1BE7-zkFAgJonCH7v2u2FygI7yA5ts_ySEc&e=

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Jan 2018 00:23:31 +0000

Sounds good.  I’ll be looking forward to your Privacy Considerations text, Annabelle.

                                                       Thanks again,
                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, January 23, 2018 3:57 PM
To: Richard Backman, Annabelle <[email-masked]>
Cc: Mike Jones <[email-masked]>; Marius Scurtescu <[email-masked]>; SecEvent <[email-masked]>; Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Phil

On Jan 23, 2018, at 3:45 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Works for me. There are two reasons why we should make it clear that “toe” may not be the exact time:

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 23, 2018 at 3:34 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Dick Hardt <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Thanks, Annabelle.

                                                       -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Tuesday, January 23, 2018 3:30 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Dick Hardt <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Mike,

Marius

iat
    As defined by Section 4.1.6 of [RFC7519]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.6&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=Sjfq91vd57uL0jeRuaJTp2b_RikrLnE8CG04lxa7CrI&e=>, a value representing

toe

    occurred.  This value is a NumericDate (see Section 2 of<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=3GnbDQ5QNcH39gfMDGWmpH76nhzGEe3rLeah_stFfvI&e=>

    [RFC7519]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=3GnbDQ5QNcH39gfMDGWmpH76nhzGEe3rLeah_stFfvI&e=>).  This claim is OPTIONAL.  By omitting this claim,

                                                       -- Mike

iat
    As defined by Section 4.1.6 of [RFC7519]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.6&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=Sjfq91vd57uL0jeRuaJTp2b_RikrLnE8CG04lxa7CrI&e=>, a value representing

toe

    occurred.  This value is a NumericDate (see Section 2 of<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=3GnbDQ5QNcH39gfMDGWmpH76nhzGEe3rLeah_stFfvI&e=>

    [RFC7519]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=3GnbDQ5QNcH39gfMDGWmpH76nhzGEe3rLeah_stFfvI&e=>).  This claim is OPTIONAL.  By omitting this claim,

Key points:

Marius

iat

Explicitly leaving this up to the profile is preferable to prohibiting profiles for using “iat” as the event time, as Annabelle’s proposal would do, especially because there are multiple profiles already doing so in practice.  For instance, see  Vladimir Dzhuvinov’s comments<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_z3u-2DulHbdWVqoZUcOXf3QMz-2DVyc&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=vDYyGgOyPFFnmDg5wJwExwaGFtKD6SMNfKLbLo_Hk9g&e=> about his implementation and the Back-Channel Logout spec<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=8ZvohQ-vvFKMwpBj1wVHHSHHttW87EkeAPEaRIwtjYY&e=>.  When the times are known to be coincident, using a single time claim is preferable to using two.

                                                       -- Mike

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=O-dbtcRF1BE7-zkFAgJonCH7v2u2FygI7yA5ts_ySEc&e=>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tOorAsulHCO98isMHeOXZD1tO3adBJEcYH3P6SJPMBY&s=O-dbtcRF1BE7-zkFAgJonCH7v2u2FygI7yA5ts_ySEc&e=>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 24 Jan 2018 08:37:20 -0800

Mike

I'm not keen on this being in the draft.

Note that some existing SET profiles and deployments use the “iat”
value to represent both the SET issuance time and the event time, when
they are coincident, which was a practice recommended in earlier
drafts of this specification.  The overloading of “iat” to also convey
the event time is NOT RECOMMENDED.

I think something more like

"a profile where the iat is coincident with the event, MAY specify to use
the time the token was issued as the time of the event."

Wiggle language seems inappropriate in a spec. For profiles where iat ==
toe always, there is no need to have independant values as they are the
same thing.

/Dick

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Jan 2018 16:54:47 +0000

Your proposed language:
"a profile where the iat is coincident with the event, MAY specify to use the time the token was issued as the time of the event."
actually violates the proposed definitions of “iat” and “toe”.  If we’re clearly differentiating between them, let’s actually do that.

The text you don’t like isn’t wiggle language – it’s a true statement about (all) existing deployments, to date.  It’s providing context and clearly saying not to do that anymore, even though the spec has recommended it in the past.

                                                       -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Wednesday, January 24, 2018 8:37 AM
To: Mike Jones <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; Marius Scurtescu <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Event time and the relationship between "iat" and "toe" in SET

Mike

"a profile where the iat is coincident with the event, MAY specify to use the time the token was issued as the time of the event."

Wiggle language seems inappropriate in a spec. For profiles where iat == toe always, there is no need to have independant values as they are the same thing.

/Dick

iat

toe

                                                       -- Mike

iat

toe

Key points:

Marius

iat

                                                       -- Mike

---

From: Dick Hardt <[email-masked]>
Date: Wed, 24 Jan 2018 10:36:20 -0800

There is no spec today, there are drafts. I don't think "wiggle language"
to make it seem like pre-existing deployments are compliant is useful to
the spec.

I do think that for many profiles, the JWT is a claim, and the 'iat' is
consistent with the signal those profiles are looking for.

'toe' deals with when an event has different semantics

On Wed, Jan 24, 2018 at 8:54 AM Mike Jones <[email-masked]>
wrote:

> actually violates the proposed definitions of “iat” and “toe”.  If we’re
> clearly differentiating between them, let’s actually do that.
>
>
>
> The text you don’t like isn’t wiggle language – it’s a true statement
> about (all) existing deployments, to date.  It’s providing context and
> clearly saying not to do that anymore, even though the spec has recommended
> it in the past.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt [mailto:[email-masked]]
> *Sent:* Wednesday, January 24, 2018 8:37 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Richard Backman, Annabelle <[email-masked]>; Marius Scurtescu <
> [email-masked]>; SecEvent <[email-masked]>
>
>