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

From: Phil Hunt <[email-masked]>
Date: Wed, 27 Sep 2017 13:53:11 -0700

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

---

From: William Denniss <[email-masked]>
Date: Wed, 27 Sep 2017 13:55:30 -0700

This change seems to be in line with the semantic meaning of the ID-Event.

And I agree it's better not to redefine a standard claim.

Therefore, +1

On Wed, Sep 27, 2017 at 1:53 PM, Phil Hunt <[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).
>
> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Sep 2017 09:59:11 -0400

+1

On 9/27/2017 4:53 PM, Phil Hunt 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).
>
>        Defined bySection 4.1.5 [RFC7519] 
> <https://tools.ietf.org/html/rfc7519#section-4.1.5>, a number whose value is a
>        Defined bySection 4.1.5 [RFC7519] 
> <https://tools.ietf.org/html/rfc7519#section-4.1.5>, a number whose value is a
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Sep 2017 09:22:36 -0600

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

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