Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

From: Mike Jones <[email-masked]>
Date: Tue, 24 Oct 2017 00:05:38 +0000

Annabelle and I agreed with this proposed change (as correctly wordsmithed by Brian) during our in-person review – as also noted in the reply to Marius’ comments.

                                                                Thanks Phil and all,
                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, September 28, 2017 8:23 AM
To: Phil Hunt <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

+1 to SET defining a time of event claim rather than trying to redefine a standard claim. And who doesn't like a claim named "toe"?
However, the text there for nbf is still effectively redefining it by saying it should be ignored, which isn't consistent with the "MUST NOT be accepted for processing" from RFC 7519. It would be more appropriate to say that nbf should/must not be included in a SET. Or just not mention nbf at all. But don't change the meaning.
Also toe would not be "Defined by Section 4.1.5 [RFC7519]", which is the nbf section. The value of the toe claim is a NumericDate, which is defined in Sec 2 RFC7519. But toe has no relation to nbf and no reason to reference nbf.

On Wed, Sep 27, 2017 at 2:53 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
During the OpenID RISC Face to Face meeting a question came up regarding SET’s redefinition of “nbf” and whether that redefinition was appropriate.

The intention of SETs definition is to allow SET Transmitters to indicate that an event may have occurred as early as a specified date — a date which is different from the issuance date of the SET. In particular this is useful in cases where the state change is believed to have occurred earlier than the time of issuance (e.g. because the incident was discovered through an administrative review or data analysis to have occurred in the past).

The definition from JWT is:
4.1.5<https://tools.ietf.org/html/rfc7519#section-4.1.5>.  "nbf" (Not Before) Claim

   The "nbf" (not before) claim identifies the time before which the JWT

   MUST NOT be accepted for processing.  The processing of the "nbf"

   claim requires that the current date/time MUST be after or equal to

   the not-before date/time listed in the "nbf" claim.  Implementers MAY

   provide for some small leeway, usually no more than a few minutes, to

   account for clock skew.  Its value MUST be a number containing a

   NumericDate value.  Use of this claim is OPTIONAL.

As defined in SET:

   nbf

      Defined by Section 4.1.5 [RFC7519]<https://tools.ietf.org/html/rfc7519#section-4.1.5>, a number whose value is a

      NumericDate.  In the context of the SET token it SHALL be

      interpreted to mean a date in which the event is believed to have

      occurred (in the past) or will occur in the future.  Note: there

      MAY be some cases where "nbf" is still smaller than "iat" such as

      when it took an extended time for a SET to be issued (for example

      after some analysis).  This claim is OPTIONAL.

There is an argument that the redefinition will cause confusion.

The proposal is to register a different claim name such as “toe” (time of event). The proposed new
definition:

toe

      Defined by Section 4.1.5 [RFC7519]<https://tools.ietf.org/html/rfc7519#section-4.1.5>, a number whose value is a

      NumericDate.  The value is the date and time in which the event is believed to have

      occurred in the past or will occur in the future. This claim is OPTIONAL.

      When not asserted, the value of “toe” MAY be assumed to be the value of “iat”.

nbf

      This claim is not used in SET Events. If asserted, the value SHOULD

      be ignored.

Are there any objections to the proposed change?

Phil

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

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 23 Oct 2017 17:47:42 -0700

Agreed +1 on Brian's edits. 

Phil

> On Oct 23, 2017, at 5:05 PM, Mike Jones <[email-masked]> wrote:
> 
> On Wed, Sep 27, 2017 at 2:53 PM, Phil Hunt <[email-masked]> wrote:
> 4.1.5.  "nbf" (Not Before) Claim
> 
>  
>  
>       Defined by Section 4.1.5 [RFC7519], a number whose value is a
>       Defined by Section 4.1.5 [RFC7519], a number whose value is a
> www.independentid.com
> [email-masked]
> [email-masked]
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 24 Oct 2017 01:04:11 +0000

Agreed overall. Having reread the proposed text, I suggest striking the last sentence, “When not asserted, the value of “toe” MAY be assumed to be the value of “iat”.” I do not think it is necessary or particularly helpful to standardize the semantics of a missing time-of-event claim at the SET level.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of "Phil Hunt (IDM)" <[email-masked]>
Date: Monday, October 23, 2017 at 5:48 PM
To: Mike Jones <[email-masked]>
Cc: Brian Campbell <[email-masked]>, ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

Phil

On Oct 23, 2017, at 5:05 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Annabelle and I agreed with this proposed change (as correctly wordsmithed by Brian) during our in-person review – as also noted in the reply to Marius’ comments.

                                                                Thanks Phil and all,
                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, September 28, 2017 8:23 AM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

The definition from JWT is:
4.1.5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=>.  "nbf" (Not Before) Claim

As defined in SET:

   nbf

      Defined by Section 4.1.5 [RFC7519]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=>, a number whose value is a

toe

      Defined by Section 4.1.5 [RFC7519]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=>, a number whose value is a

nbf

      be ignored.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=1_Z7OvAyaxlesCdLNC5qsa5Xj9PZQ-LMbCa_hmTo2eM&e=>
[email-masked]<mailto:[email-masked]>

_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 23 Oct 2017 18:15:23 -0700

On Mon, Oct 23, 2017 at 6:04 PM, Richard Backman, Annabelle <
[email-masked]> wrote:

> Agreed overall. Having reread the proposed text, I suggest striking the
> last sentence, “When not asserted, the value of “toe” MAY be assumed to be
> the value of “iat”.” I do not think it is necessary or particularly helpful
> to standardize the semantics of a missing time-of-event claim at the SET
> level.
>

+1

> *From: *Id-event <[email-masked]> on behalf of "Phil Hunt
> (IDM)" <[email-masked]>
> *Date: *Monday, October 23, 2017 at 5:48 PM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Brian Campbell <[email-masked]>, ID Events Mailing List
> <[email-masked]>
>
> *Subject: *Re: [Id-event] Replacing "nbf" claim with a new "toe" claim
>
>
>
> Annabelle and I agreed with this proposed change (as correctly wordsmithed
> by Brian) during our in-person review – as also noted in the reply to
> Marius’ comments.
>
>
>
>                                                                 Thanks
> Phil and all,
>
>                                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Brian Campbell
> *Sent:* Thursday, September 28, 2017 8:23 AM
> *To:* Phil Hunt <[email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Replacing "nbf" claim with a new "toe" claim
>
>
>
> +1 to SET defining a time of event claim rather than trying to redefine a
> standard claim. And who doesn't like a claim named "toe"?
>
> However, the text there for nbf is still effectively redefining it by
> saying it should be ignored, which isn't consistent with the "MUST NOT be
> accepted for processing" from RFC 7519. It would be more appropriate to say
> that nbf should/must not be included in a SET. Or just not mention nbf at
> all. But don't change the meaning.
>
> Also toe would not be "Defined by Section 4.1.5 [RFC7519]", which is the
> nbf section. The value of the toe claim is a NumericDate, which is defined
> in Sec 2 RFC7519. But toe has no relation to nbf and no reason to reference
> nbf.
>
>
>
> During the OpenID RISC Face to Face meeting a question came up regarding
> SET’s redefinition of “nbf” and whether that redefinition was appropriate.
>
>
>
> The intention of SETs definition is to allow SET Transmitters to indicate
> that an event may have occurred as early as a specified date — a date which
> is different from the issuance date of the SET. In particular this is
> useful in cases where the state change is believed to have occurred earlier
> than the time of issuance (e.g. because the incident was discovered through
> an administrative review or data analysis to have occurred in the past).
>
>
>
> 4.1.5
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=>.
> "nbf" (Not Before) Claim
>
>
>
>
>
>       Defined by Section 4.1.5 [RFC7519] <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=>, a number whose value is a
>
>       Defined by Section 4.1.5 [RFC7519] <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=>, a number whose value is a
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=1_Z7OvAyaxlesCdLNC5qsa5Xj9PZQ-LMbCa_hmTo2eM&e=>
>
> [email-masked]
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_
> FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAU
> Txg78kdb0VON8&e=
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Oct 2017 11:09:52 -0700

It is not clear how to revise the document with regards to the suggestion against using “iat” when “toe” is not asserted. 

If I remove this clarification, it seems unclear what the time of the event is defined as.  There seem to be two options:

A. If “iat” can’t be assumed to be the time of event, then “toe” should be a required claim.

B. For the majority of use cases, “iat” is commonly used to mark SET issuance and event time.  “toe” is only needed when the time of the event is different (on an exceptional basis).

Some clarification from the group would be appreciated.  Should we proceed with B, or revise the text to A (or some other proposal).

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Oct 23, 2017, at 6:15 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Mon, Oct 23, 2017 at 6:04 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of "Phil Hunt (IDM)" <[email-masked] <mailto:[email-masked]>>
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Brian Campbell <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> 
> 
> On Oct 23, 2017, at 5:05 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Campbell
> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>
> Cc: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> On Wed, Sep 27, 2017 at 2:53 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 4.1.5 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.5&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=00sEiuefwhWbXeRfJktjoqN6RGOniHiQipxHZiCG62w&e=> <>.  "nbf" (Not Before) Claim
> 
>  
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=1_Z7OvAyaxlesCdLNC5qsa5Xj9PZQ-LMbCa_hmTo2eM&e=>
> [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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=>
>  
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=>
> [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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=>

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Oct 2017 19:33:19 +0000

Thinking about this some more, I’m prone to keep the last sentence, at least for the next draft, since it adds semantic clarity for implementers and profilers that would otherwise be lacking, which can’t help interop.  They’ll be more chances to discuss this in the coming weeks.

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, October 25, 2017 11:10 AM
To: Marius Scurtescu <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; Mike Jones <[email-masked]>; Brian Campbell <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

Thanks,

Phil

On Oct 23, 2017, at 6:15 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 23, 2017 at 6:04 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Agreed overall. Having reread the proposed text, I suggest striking the last sentence, “When not asserted, the value of “toe” MAY be assumed to be the value of “iat”.” I do not think it is necessary or particularly helpful to standardize the semantics of a missing time-of-event claim at the SET level.

+1

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 23, 2017 at 5:48 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Brian Campbell <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Phil

                                                                Thanks Phil and all,
                                                                -- Mike

As defined in SET:

   nbf

toe

nbf

      be ignored.

Phil

_______________________________________________
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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=>

_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 25 Oct 2017 13:46:50 -0700

On Wed, Oct 25, 2017 at 11:09 AM, Phil Hunt <[email-masked]> wrote:

> It is not clear how to revise the document with regards to the suggestion
> against using “iat” when “toe” is not asserted.
>
> If I remove this clarification, it seems unclear what the time of the
> event is defined as.  There seem to be two options:
>

Why? Why can't the Transmitter assert that an account was disabled and not
provide a specific event time? I understand that an event time is
desirable, but why required?

>
> B. For the majority of use cases, “iat” is commonly used to mark SET
> issuance and event time.  “toe” is only needed when the time of the event
> is different (on an exceptional basis).
>

If SET issuance and event time are indeed the same then both claims should
be present. I don't think iat should imply toe.

>
> Some clarification from the group would be appreciated.  Should we proceed
> with B, or revise the text to A (or some other proposal).
>
> Thanks,
>
> Phil
>
>> *Cc: *Brian Campbell <[email-masked]>, ID Events Mailing
>> List <[email-masked]>
>>
>> Annabelle and I agreed with this proposed change (as correctly
>> wordsmithed by Brian) during our in-person review – as also noted in the
>> reply to Marius’ comments.
>>
>>
>>
>>                                                                 Thanks
>> Phil and all,
>>
>>                                                                 -- Mike
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz
>> jWwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61
>> w&s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=>
>>
>>
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM&s=-zJLNs_G_
> PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 25 Oct 2017 13:56:04 -0700

In some cases, ordering of events against a single subject matters. Time is useful for this purpose though limited in the overall stream for ordering events overall. 

For example account locked vs unlocked. Knowing what happened last would seem important no?

Phil

> On Oct 25, 2017, at 1:46 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> Why? Why can't the Transmitter assert that an account was disabled and not provide a specific event time? I understand that an event time is desirable, but why required?
> 
>  
>> 
> If SET issuance and event time are indeed the same then both claims should be present. I don't think iat should imply toe.
>  
>> 
>>>> On Mon, Oct 23, 2017 at 6:04 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=7O5N5qBNGK8GMcarUwHEtSkNgfogFmv_q6_o0qv8axU&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 25 Oct 2017 13:58:25 -0700

As I said, I totally agree it is useful. But why required?

Marius

On Wed, Oct 25, 2017 at 1:56 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> In some cases, ordering of events against a single subject matters. Time
> is useful for this purpose though limited in the overall stream for
> ordering events overall.
>
>> Some clarification from the group would be appreciated.  Should we
>> proceed with B, or revise the text to A (or some other proposal).
>>
>> Thanks,
>>
>> Phil
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=A9761rPXfFdeqzJ4pRN-BQ_x1USlM2bQTXoCNeLFAZA&e=>
>> [email-masked]
>>
>>> +1 to SET defining a time of event claim rather than trying to redefine
>>> a standard claim. And who doesn't like a claim named "toe"?
>>>
>>> The intention of SETs definition is to allow SET Transmitters to
>>> indicate that an event may have occurred as early as a specified date — a
>>> date which is different from the issuance date of the SET. In particular
>>> this is useful in cases where the state change is believed to have occurred
>>> earlier than the time of issuance (e.g. because the incident was discovered
>>> through an administrative review or data analysis to have occurred in the
>>> past).
>>>
>>>
>>>
>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzj
>>> WwlNKe4C_lLIGk&m=NkDo69V_FwylRlHOMCBjUEAvpUjBpZYuCVgHSicH61w
>>> &s=8AooDWY1FwTG3Bj2ELWqpT7XAaUYAUTxg78kdb0VON8&e=
>>>
>>>
>> jWwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_
>> BU0fLL05dXBM&s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=
>>
>>
>>
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_
> TyM3tQ98EeI6-1v8uDSW5PqIw&s=7O5N5qBNGK8GMcarUwHEtSkNgfogFmv_q6_o0qv8axU&e=
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 25 Oct 2017 14:02:05 -0700

If an event doesn't have a time, did it occur?

Phil

> On Oct 25, 2017, at 1:58 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Wed, Oct 25, 2017 at 1:56 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=k17XiXhDcASFiPIa2k868J7D8w8RkO4wx0rjYi8wNow&s=5fyljqOSViRQ9wnyMXUZ_fQ1_nuacoh3xx338FdapSY&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 25 Oct 2017 14:07:23 -0700

> If an event doesn't have a time, did it occur?

At undisclosed time and location :-)

I think it is fine for "toe" to be SHOULD/RECOMMENDED, but not
MUST/REQUIRED.

>>> It is not clear how to revise the document with regards to the
>>> suggestion against using “iat” when “toe” is not asserted.
>>>
>> Why? Why can't the Transmitter assert that an account was disabled and
>> not provide a specific event time? I understand that an event time is
>> If SET issuance and event time are indeed the same then both claims
>> should be present. I don't think iat should imply toe.
>>
>>
>>>
>>>> Also toe would not be "Defined by Section 4.1.5 [RFC7519]", which is
>>>> the nbf section. The value of the toe claim is a NumericDate, which is
>>>> defined in Sec 2 RFC7519. But toe has no relation to nbf and no reason to
>>>> reference nbf.
>>>>
>>>>
>>>>
>>>> During the OpenID RISC Face to Face meeting a question came up
>>>> regarding SET’s redefinition of “nbf” and whether that redefinition was
>>>> appropriate.
>>>>
>>>>
>>>>
>>> WwlNKe4C_lLIGk&m=XFb85vuDk0h3Ygd5qlx4iuR7LR7evV_BU0fLL05dXBM
>>> &s=-zJLNs_G_PXMbtuyAAo5KSnqZau4BHf7-JFfe7mYpBY&e=
>>>
>>>
>>>
>> jWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-
>> 1v8uDSW5PqIw&s=7O5N5qBNGK8GMcarUwHEtSkNgfogFmv_q6_o0qv8axU&e=
>>
>>
> k17XiXhDcASFiPIa2k868J7D8w8RkO4wx0rjYi8wNow&s=5fyljqOSViRQ9wnyMXUZ_fQ1_
> nuacoh3xx338FdapSY&e=
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 25 Oct 2017 14:44:55 -0700

Are you proposing A with a should/recommended?

It is more consistent but adds a lot of duplication in many cases where iat = toe. 

Phil

> On Oct 25, 2017, at 2:07 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Wed, Oct 25, 2017 at 2:02 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> I think it is fine for "toe" to be SHOULD/RECOMMENDED, but not MUST/REQUIRED.
> 
>> 
>> Phil
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3xoRnYeAqgWRqvjmh1fFBHbFqwPo0-S31KYrJ0sZK7g&s=Ogn5vWSJQb1_w6_6zUlq8CPRkegi1x_3G-knlbZk6kE&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 25 Oct 2017 14:52:57 -0700

> Are you proposing A with a should/recommended?

Yes

> It is more consistent but adds a lot of duplication in many cases where

I don't think that should be a problem.

>>>>> Agreed overall. Having reread the proposed text, I suggest striking
>>>>> the last sentence, “When not asserted, the value of “toe” MAY be assumed to
>>>>> be the value of “iat”.” I do not think it is necessary or particularly
>>>>> helpful to standardize the semantics of a missing time-of-event claim at
>>>>> the SET level.
>>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Mike
>>>>> +1 to SET defining a time of event claim rather than trying to
>>>>> redefine a standard claim. And who doesn't like a claim named "toe"?
>>>>>
>>> WwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw
>>> &s=7O5N5qBNGK8GMcarUwHEtSkNgfogFmv_q6_o0qv8axU&e=
>>>
>>>
>> jWwlNKe4C_lLIGk&m=k17XiXhDcASFiPIa2k868J7D8w8RkO4wx0rjYi8wNo
>> w&s=5fyljqOSViRQ9wnyMXUZ_fQ1_nuacoh3xx338FdapSY&e=
>>
>>
> 3xoRnYeAqgWRqvjmh1fFBHbFqwPo0-S31KYrJ0sZK7g&s=Ogn5vWSJQb1_
> w6_6zUlq8CPRkegi1x_3G-knlbZk6kE&e=
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Oct 2017 14:58:44 -0700

OK….unless there is objection, I will revise the draft so that “toe” will become a recommended attribute.

Phil

> On Oct 25, 2017, at 2:52 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Wed, Oct 25, 2017 at 2:44 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Oct 25, 2017, at 2:07 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Wed, Oct 25, 2017 at 2:02 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>> On Oct 25, 2017, at 1:58 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Wed, Oct 25, 2017 at 1:56 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Oct 25, 2017, at 1:46 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> On Wed, Oct 25, 2017 at 11:09 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=A9761rPXfFdeqzJ4pRN-BQ_x1USlM2bQTXoCNeLFAZA&e=>[email-masked] <mailto:[email-masked]>
>>>>> On Oct 23, 2017, at 6:15 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=7O5N5qBNGK8GMcarUwHEtSkNgfogFmv_q6_o0qv8axU&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=7O5N5qBNGK8GMcarUwHEtSkNgfogFmv_q6_o0qv8axU&e=> 
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=k17XiXhDcASFiPIa2k868J7D8w8RkO4wx0rjYi8wNow&s=5fyljqOSViRQ9wnyMXUZ_fQ1_nuacoh3xx338FdapSY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=k17XiXhDcASFiPIa2k868J7D8w8RkO4wx0rjYi8wNow&s=5fyljqOSViRQ9wnyMXUZ_fQ1_nuacoh3xx338FdapSY&e=> 
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3xoRnYeAqgWRqvjmh1fFBHbFqwPo0-S31KYrJ0sZK7g&s=Ogn5vWSJQb1_w6_6zUlq8CPRkegi1x_3G-knlbZk6kE&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3xoRnYeAqgWRqvjmh1fFBHbFqwPo0-S31KYrJ0sZK7g&s=Ogn5vWSJQb1_w6_6zUlq8CPRkegi1x_3G-knlbZk6kE&e=> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=G7gI1TT37IHsNVhTNm8SVkvFsD3lZrMqjkCCQRflMqE&s=zFIfIcUn_tP00p6yc2nLmuvlLZKhAZXv-rJr4iK0d-Y&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=G7gI1TT37IHsNVhTNm8SVkvFsD3lZrMqjkCCQRflMqE&s=zFIfIcUn_tP00p6yc2nLmuvlLZKhAZXv-rJr4iK0d-Y&e=>

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Oct 2017 22:08:56 +0000

I’m OK with this, as long as you also add a clarifying note along these lines:
              NOTE:  Some profiles may choose to omit “toe” and convey event time information with the “iat” or other claims.

                                                       -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, October 25, 2017 2:59 PM
To: Marius Scurtescu <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; Brian Campbell <[email-masked]>; Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

Phil

On Oct 25, 2017, at 2:52 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Oct 25, 2017 at 2:44 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:

Yes

Phil

On Oct 25, 2017, at 2:07 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Oct 25, 2017 at 2:02 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
If an event doesn't have a time, did it occur?

Phil

On Oct 25, 2017, at 1:58 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
As I said, I totally agree it is useful. But why required?

Marius

On Wed, Oct 25, 2017 at 1:56 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
In some cases, ordering of events against a single subject matters. Time is useful for this purpose though limited in the overall stream for ordering events overall.

Phil

On Oct 25, 2017, at 1:46 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Oct 25, 2017 at 11:09 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
It is not clear how to revise the document with regards to the suggestion against using “iat” when “toe” is not asserted.

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=A9761rPXfFdeqzJ4pRN-BQ_x1USlM2bQTXoCNeLFAZA&e=>
[email-masked]<mailto:[email-masked]>

+1

Phil

                                                                Thanks Phil and all,
                                                                -- Mike

As defined in SET:

   nbf

toe

nbf

      be ignored.

Phil

_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=G7gI1TT37IHsNVhTNm8SVkvFsD3lZrMqjkCCQRflMqE&s=zFIfIcUn_tP00p6yc2nLmuvlLZKhAZXv-rJr4iK0d-Y&e=

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 27 Oct 2017 00:08:54 +0000

What does the “MAY” in this sentence mean?
When not asserted, the value of “toe” MAY be assumed to be the value of “iat”.

I can think of a couple ways to read this, neither of which seem appropriate for SET:

  1.  Profiling Specifications can declare that these are the semantics of a missing “toe” claim, but if the Profiling Specification does not do so, then the semantics are still undefined.
     *   Why would this need to be specified at all?
  2.  Unless a Profiling Specification says otherwise, these are the semantics of a missing “toe” claim.
     *   What makes us think that this is an appropriate default? For many RISC events, the time of event will be unknown, or prohibitively expensive to know. Are the semantics of a null “toe” claim allowed to be different from those of a missing claim?

From: Phil Hunt <[email-masked]>
Date: Wednesday, October 25, 2017 at 2:59 PM
To: Marius Scurtescu <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, Brian Campbell <[email-masked]>, Mike Jones <[email-masked]>, ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

Phil

Yes

Phil

Phil

Marius

Phil

Thanks,

Phil

+1

Phil

                                                                Thanks Phil and all,
                                                                -- Mike

As defined in SET:

   nbf

toe

nbf

      be ignored.

Phil

---

From: Phil Hunt <[email-masked]>
Date: Thu, 26 Oct 2017 17:21:16 -0700

MAY is normative permssive option.  “may” is used when you are stating a fact.

So in this case, Mike has changed the text to indicate that a client  may interpret “iat” as the value of “toe” when “toe” is not asserted.  It is phrased this way so that profiling specs can override.

Phil

> On Oct 26, 2017, at 5:08 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Profiling Specifications can declare that these are the semantics of a missing “toe” claim, but if the Profiling Specification does not do so, then the semantics are still undefined.
> Why would this need to be specified at all?
> Unless a Profiling Specification says otherwise, these are the semantics of a missing “toe” claim.
> What makes us think that this is an appropriate default? For many RISC events, the time of event will be unknown, or prohibitively expensive to know. Are the semantics of a null “toe” claim allowed to be different from those of a missing claim?
>  
> -- 
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JqkGG3xeGS2Vi924yJIcOTAL3qMem9DPwMqLZCNnzkQ&s=XORReYS_NF-vNCx27DUk-5wAoDPe4cvG_nkEaPY6-Jk&e=>
>> On Oct 25, 2017, at 2:52 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>>>>>>>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=myl7g4hppkWgdjN9T_TyM3tQ98EeI6-1v8uDSW5PqIw&s=A9761rPXfFdeqzJ4pRN-BQ_x1USlM2bQTXoCNeLFAZA&e=>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 26 Oct 2017 17:24:55 -0700

Apologies… I meant to say, Mike provided some better text describing the optionality.  That should be published shortly.

Phil

> On Oct 26, 2017, at 5:21 PM, Phil Hunt <[email-masked]> wrote:
> 
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=cIteJB5ZijM705Ltaca_lGP4yuQYb6gfsfI9KWczkIA&s=HMiIQmSMu9lfslgKQt0YUYrnTvVW3InpmiC8sPlHMv0&e=>[email-masked] <mailto:[email-masked]>
>> On Oct 26, 2017, at 5:08 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> Cc: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Brian Campbell <[email-masked] <mailto:[email-masked]>>, Mike Jones <[email-masked] <mailto:[email-masked]>>, ID Events 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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=cIteJB5ZijM705Ltaca_lGP4yuQYb6gfsfI9KWczkIA&s=gBMWCs2G910-j4L2BsK3V2ncAc3wjr-TQ05PpTlIzSY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=cIteJB5ZijM705Ltaca_lGP4yuQYb6gfsfI9KWczkIA&s=gBMWCs2G910-j4L2BsK3V2ncAc3wjr-TQ05PpTlIzSY&e=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 27 Oct 2017 18:57:46 +0000

I can accept Mike’s new proposed text.

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Thursday, October 26, 2017 at 5:25 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Mike Jones <[email-masked]>, Brian Campbell <[email-masked]>, ID Events Mailing List <[email-masked]>, Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

Phil

On Oct 26, 2017, at 5:21 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=cIteJB5ZijM705Ltaca_lGP4yuQYb6gfsfI9KWczkIA&s=HMiIQmSMu9lfslgKQt0YUYrnTvVW3InpmiC8sPlHMv0&e=>
[email-masked]<mailto:[email-masked]>

On Oct 26, 2017, at 5:08 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

  1.  Unless a Profiling Specification says otherwise, these are the semantics of a missing “toe” claim.

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 25, 2017 at 2:59 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Brian Campbell <[email-masked]<mailto:[email-masked]>>, Mike Jones <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JqkGG3xeGS2Vi924yJIcOTAL3qMem9DPwMqLZCNnzkQ&s=XORReYS_NF-vNCx27DUk-5wAoDPe4cvG_nkEaPY6-Jk&e=>
[email-masked]<mailto:[email-masked]>

Yes

Phil

Phil

Marius

Phil

Thanks,

Phil

+1

Phil

                                                                Thanks Phil and all,
                                                                -- Mike

As defined in SET:

   nbf

toe

nbf

      be ignored.

Phil

_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=cIteJB5ZijM705Ltaca_lGP4yuQYb6gfsfI9KWczkIA&s=gBMWCs2G910-j4L2BsK3V2ncAc3wjr-TQ05PpTlIzSY&e=