Subject: [Id-event] draft-ietf-secevent-token-04 : "toe" comment

From: Dick Hardt <[email-masked]>
Date: Sun, 21 Jan 2018 14:36:31 -0800

Why is "toe" not REQUIRED? Why are we providing two ways of providing the
time of event?
I would also suggest we specify a value for "toe" if it is unknown. "iat"
is when the token was issued, and it is useful to differentiate these
signals.

---

From: Mike Jones <[email-masked]>
Date: Mon, 22 Jan 2018 13:23:46 +0000

“toe” isn’t required because most use cases don’t need it or use it.  For instance, as Vladimir Dzhuvinov wrote<https://mailarchive.ietf.org/arch/msg/id-event/z3u-ulHbdWVqoZUcOXf3QMz-Vyc> about his implementation:

Simplicity was one of the things that made JWT successful. Let's find a way to preserve that simplicity in the SET.

When we implemented SETs internally (based on draft-ietf-secevent-token-00) I urged developers to keep the events simple, and this has worked quite well so far. The "events" is often just an identifier. We didn't find use for the "toe" and "txn" claims.

The logout event in production that’s defined at http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken doesn’t use it.

The consent receipt use case doesn’t use it.

The RISC event specification doesn’t use it.

Rather, the data seems to support a different question – why is “toe” even present in the spec?  (Note that I’m not advocating its removal, but a better case could be made for its removal than requiring its use.)

====

Annabelle did raise a good question about the relationship between “iat” and “toe”.  I’ll write about that separately.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Sunday, January 21, 2018 2:37 PM
To: SecEvent <[email-masked]>
Subject: [Id-event] draft-ietf-secevent-token-04 : "toe" comment

Why is "toe" not REQUIRED? Why are we providing two ways of providing the time of event?
I would also suggest we specify a value for "toe" if it is unknown. "iat" is when the token was issued, and it is useful to differentiate these signals.

---

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

I think the suggestion was to make toe required and have a special value
like "null" explicitly signal that the value is not known or not
applicable. This way any ambiguity with iat would be eliminated.

At a minimum I think we need very strong language to clarify that iat does
not imply toe, if toe is known then it should appear explicitly.

Marius

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

> “toe” isn’t required because most use cases don’t need it or use it.  For
> instance, as Vladimir Dzhuvinov wrote
> <https://mailarchive.ietf.org/arch/msg/id-event/z3u-ulHbdWVqoZUcOXf3QMz-Vyc>
> about his implementation:
>
> Simplicity was one of the things that made JWT successful. Let's find a
> way to preserve that simplicity in the SET.
>
> When we implemented SETs internally (based on
> draft-ietf-secevent-token-00) I urged developers to keep the events simple,
> and this has worked quite well so far. The "events" is often just an
> identifier. We didn't find use for the "toe" and "txn" claims.
>
>
>
> The logout event in production that’s defined at http://openid.net/specs/
> openid-connect-backchannel-1_0.html#LogoutToken doesn’t use it.
>
>
>
> Rather, the data seems to support a different question – why is “toe” even
> present in the spec?  (Note that I’m not advocating its removal, but a
> better case could be made for its removal than requiring its use.)
>
>
>
> ====
>
>
>
> Annabelle did raise a good question about the relationship between “iat”
> and “toe”.  I’ll write about that separately.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] * On Behalf Of *Dick
> Hardt
> *Sent:* Sunday, January 21, 2018 2:37 PM
> *To:* SecEvent <[email-masked]>
> *Subject:* [Id-event] draft-ietf-secevent-token-04 : "toe" comment
>
>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Jan 2018 12:54:45 -0800

This discussion seems to have a number of sub-threads...

A) Profile specification
I don’t believe this is a profile controllable item.  It has more to do with a particular transmitter's information and systems architecture and how they came upon the determination of an event.  It may be true that some events are likely to be more retroactive than others, but this may be just a rathole.

B) What is toe addressing

The requirement brought forward by Andy Nash was to be able to issue retroactive SETs.

Even when toe is retroactive, it may still only be an estimate.  The use case would be to indicate that an event is suspected to have happened as of a date in the past.

C) What if toe is unknown?
To solve the unknown issue I think you have to take the perspective of the receiver…how would asserting toe is null help them? In practical terms they’ll just use the issue date.  IOW - how does asserting toe as unknown help a receiver if at all?

D) Risks of too much honesty?
We’ve said in the spec, that time cannot be used for sorting/sequencing events, we should not add to the problem with toe.  

If transmitter start asserting small differences that show “skew” this may itself be a risk that allows receivers to infer behavior by the transmitter that can be used against them.

If toe is used, it should be because iat and toe values are hours or days apart rather than usecs.

Phil

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

> On Jan 22, 2018, at 11:43 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> I think the suggestion was to make toe required and have a special value like "null" explicitly signal that the value is not known or not applicable. This way any ambiguity with iat would be eliminated.
> 
> At a minimum I think we need very strong language to clarify that iat does not imply toe, if toe is known then it should appear explicitly.
> 
> Marius
> 
> On Mon, Jan 22, 2018 at 5:23 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> “toe” isn’t required because most use cases don’t need it or use it.  For instance, as Vladimir Dzhuvinov wrote <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_z3u-2DulHbdWVqoZUcOXf3QMz-2DVyc&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=xpd_JglCe_3O8lJFFZto4G62-21BuU723hechWSH3Kc&e=> about his implementation:
> 
> The logout event in production that’s defined at http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=_P8_-4PAHWWOl1a5CxSm2fSBPbJs9edNcXHiwIzA91M&e=> doesn’t use it.
> 
>  
> 
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Dick Hardt
> To: SecEvent <[email-masked] <mailto:[email-masked]>>
> [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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=xk3bGW_EZoywzT6jinuYMGMgylh1hVYfNi19qPfZSfM&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=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=xk3bGW_EZoywzT6jinuYMGMgylh1hVYfNi19qPfZSfM&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 22 Jan 2018 13:50:52 -0800

On Mon, Jan 22, 2018 at 12:54 PM, Phil Hunt <[email-masked]> wrote:

> I don’t believe this is a profile controllable item.  It has more to do
> with a particular transmitter's information and systems architecture and
> how they came upon the determination of an event.  It may be true that some
> events are likely to be more retroactive than others, but this may be just
> a rathole.
>

+1

> Even when toe is retroactive, it may still only be an estimate.  The use
> case would be to indicate that an event is suspected to have happened as of
> a date in the past.
>

+1

> To solve the unknown issue I think you have to take the perspective of the
> receiver…how would asserting toe is null help them? In practical terms
> they’ll just use the issue date.  IOW - how does asserting toe as unknown
> help a receiver if at all?
>

Not sure that "null" is a good option, I just mentioned what was proposed
before.

That being said, confusing iat for toe is very problematic IMO. My main
suggestion is to keep the two claims separate and to make that very clear
in the spec. Receivers can deal with that. Having a "null" value define for
toe, and toe being required, would be an even stronger signal to Receivers
about the semantics of these two claims.

> We’ve said in the spec, that time cannot be used for sorting/sequencing
> events, we should not add to the problem with toe.
>
> If transmitter start asserting small differences that show “skew” this may
> itself be a risk that allows receivers to infer behavior by the transmitter
> that can be used against them.
>

At the point where a transmitter decides that toe is close enough to iat so
it can be omitted, it can also decide to set the value of toe the exact
same as iat. This is an implementation detail, maybe a security
consideration. I am much more worried about the case when toe is missing
and we cannot distinguish between toe unknown and toe and iat are the same.

I would prefer for toe to be removed altogether than have this ambiguity.

> www.independentid.com
> [email-masked]
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_z3u-2DulHbdWVqoZUcOXf3QMz-2DVyc&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=xpd_JglCe_3O8lJFFZto4G62-21BuU723hechWSH3Kc&e=>
>> The logout event in production that’s defined at
>> http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=_P8_-4PAHWWOl1a5CxSm2fSBPbJs9edNcXHiwIzA91M&e=>
>> doesn’t use it.
>>
>>
>>
>> Rather, the data seems to support a different question – why is “toe”
>> even present in the spec?  (Note that I’m not advocating its removal, but a
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=GA3qC_Qpu_9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=xk3bGW_EZoywzT6jinuYMGMgylh1hVYfNi19qPfZSfM&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=GA3qC_Qpu_
> 9LvzC71PDKxKzCMaRahy9ZsPB4nah0SvA&s=xk3bGW_EZoywzT6jinuYMGMgylh1hVYfNi19q
> PfZSfM&e=
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 22 Jan 2018 15:13:04 -0800

> events are likely to be more retroactive than others, but this may be just

I think toe is likely event specific.

> case would be to indicate that an event is suspected to have happened as of

There are a wide array of events that may be issued, and there may be
reasons for delaying publishing a signal. Who knows. The point is that we
are clear on what it means.

> help a receiver if at all?

Lack of information is as useful of a signal as presence of information.
Per my other email, it toe is unknown, let's not have it present.

> events, we should not add to the problem with toe.

Um. Correlating events based on time is pretty useful.

> If toe is used, it should be because iat and toe values are hours or days

Likely. Minute or seconds may be useful.

---

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

[inline]

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Monday, January 22, 2018 at 3:13 PM
To: Phil Hunt <[email-masked]>
Cc: Mike Jones <[email-masked]>, SecEvent <[email-masked]>, Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] draft-ietf-secevent-token-04 : "toe" comment

On Mon, Jan 22, 2018 at 12:54 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
This discussion seems to have a number of sub-threads...

A) Profile specification

There are a wide array of events that may be issued, and there may be reasons for delaying publishing a signal. Who knows. The point is that we are clear on what it means.

[richanna]
Sure, the recipient could just use the issue date if toe is null, but it might be very wrong for them to do so. It may be better for them to only apply event time-dependent logic when they have an explicitly specified event time. The problem with the current draft is it provides no way to state that iat is not the time of event without specifying an actual value for toe. As written, toe cannot be null and iat SHOULD be considered the time of event in the absence of toe.
[/richanna]

[richanna]
That’s something transmitters can control, since they can arbitrarily decide the precision and accuracy of the toe value.
[/richanna]

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Jan 2018 12:42:57 -0800

The draft as written does not have a syntax for sending a signal that the
toe is unknown. The time of event is the toe if present, otherwise it is
the iat.

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Jan 2018 20:44:21 +0000

Thanks, Annabelle.  The point of the wording I proposed in my note Event time and the relationship between "iat" and "toe" in SET<https://mailarchive.ietf.org/arch/msg/id-event/yOwo5_awt7hDo4VKy_rKRAh9FfQ> was exactly to address your point that being able to express “I don’t know the event time” is important.  I’d proposed changing 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.

Can you live with that new wording?  That allows profiles to express “I don’t know the event time”, while also not breaking the existing deployed profiles that use “iat” as the event time (which the current spec says is a SHOULD).

                                                       -- Mike

From: Richard Backman, Annabelle [mailto:[email-masked]]
Sent: Tuesday, January 23, 2018 12:25 PM
To: Dick Hardt <[email-masked]>; Phil Hunt <[email-masked]>
Cc: Mike Jones <[email-masked]>; SecEvent <[email-masked]>; Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] draft-ietf-secevent-token-04 : "toe" comment

[inline]

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 22, 2018 at 3:13 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>, Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] draft-ietf-secevent-token-04 : "toe" comment

A) Profile specification

[richanna]

[richanna]

---

From: Dick Hardt <[email-masked]>
Date: Tue, 23 Jan 2018 12:45:48 -0800

Mike: is your concern with breaking current implementations, as opposed to
what would be the preferred way to communicate time of event?

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

> Thanks, Annabelle.  The point of the wording I proposed in my note Event
> time and the relationship between "iat" and "toe" in SET
> <https://mailarchive.ietf.org/arch/msg/id-event/yOwo5_awt7hDo4VKy_rKRAh9FfQ>
> was exactly to address your point that being able to express “I don’t know
> the event time” is important.  I’d proposed changing 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.*
>
>
>
> Can you live with that new wording?  That allows profiles to express “I
> don’t know the event time”, while also not breaking the existing deployed
> profiles that use “iat” as the event time (which the current spec says is a
> SHOULD).
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Richard Backman, Annabelle [mailto:[email-masked]]
> *Sent:* Tuesday, January 23, 2018 12:25 PM
> *To:* Dick Hardt <[email-masked]>; Phil Hunt <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; SecEvent <
> [email-masked]>; Marius Scurtescu <[email-masked]>
>
> *Subject:* Re: [Id-event] draft-ietf-secevent-token-04 : "toe" comment
>
>
>
> [inline]
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Monday, January 22, 2018 at 3:13 PM
> *To: *Phil Hunt <[email-masked]>
> *Cc: *Mike Jones <[email-masked]>, SecEvent <
> [email-masked]>, Marius Scurtescu <[email-masked]>
> *Subject: *Re: [Id-event] draft-ietf-secevent-token-04 : "toe" comment
>
>
>
>
>
>
>
> Sure, the recipient could just use the issue date if toe is null, but it
> might be very wrong for them to do so. It may be better for them to only
> apply event time-dependent logic when they have an explicitly specified
> event time. The problem with the current draft is it provides no way to
> state that iat is *not* the time of event without specifying an actual
> value for toe. As written, toe cannot be null and iat SHOULD be considered
> the time of event in the absence of toe.
>
> [/richanna]
>
>
>
>
>
> That’s something transmitters can control, since they can arbitrarily
> decide the precision and accuracy of the toe value.
>
> [/richanna]
>
>
>

---

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

Mike,

I’m opposed to punting this decision to the profiling specifications; I don’t see how that simplifies anything. In the interests of consolidating the discussion onto one thread, let me copy/paste my response on the other thread here:

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

From: Dick Hardt <[email-masked]>
Date: Tuesday, January 23, 2018 at 12:46 PM
To: Mike Jones <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, Phil Hunt <[email-masked]>, SecEvent <[email-masked]>, Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] draft-ietf-secevent-token-04 : "toe" comment

Mike: is your concern with breaking current implementations, as opposed to what would be the preferred way to communicate time of event?

On Tue, Jan 23, 2018 at 12:44 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Annabelle.  The point of the wording I proposed in my note Event time and the relationship between "iat" and "toe" in SET<https://mailarchive.ietf.org/arch/msg/id-event/yOwo5_awt7hDo4VKy_rKRAh9FfQ> was exactly to address your point that being able to express “I don’t know the event time” is important.  I’d proposed changing 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.

                                                       -- Mike

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

[inline]

A) Profile specification

[richanna]

[richanna]