From nobody Fri Sep 1 15:50:39 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E21113443C for ; Fri, 1 Sep 2017 15:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYsVndWQoPx0 for ; Fri, 1 Sep 2017 15:50:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE11132EBD for ; Fri, 1 Sep 2017 15:50:35 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v81MoYSR009531 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 1 Sep 2017 22:50:34 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v81MoXmJ026833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 1 Sep 2017 22:50:34 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v81MoXLc014193 for ; Fri, 1 Sep 2017 22:50:33 GMT Received: from [192.168.1.46] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Sep 2017 15:50:33 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_3A05A191-2AD3-4B9C-AEE9-393A08ACA469" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 1 Sep 2017 15:50:38 -0700 References: To: ID Events Mailing List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] draft-scurtescu-secevent-event-stream-mgmt-api-00 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 22:50:38 -0000 --Apple-Mail=_3A05A191-2AD3-4B9C-AEE9-393A08ACA469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is to provide feedback on the proposal submitted by Marius [0]. I do not believe the draft [0] is close to ready for adoption. I am = concerned that the design unnecessarily complicates and limits = implementation for many tenancy and/or enterprise focused cloud vendors, = as well as enterprise organizations that need to receive or send SETs. = This applies to all of the areas proposed: RISC, OAuth Revocation, OIDC = Backchannel Logout, SCIM, etc. The following is a list of items that are of concern: * Metadata is far from complete - this is to be expected. One of the = items that needs to be worked out is what does a publisher need to know = in order to formulate SETs with the correct signing and encryption. E.g. = should a stream configuration have jwksuris for transmitter (presumably = for signing) and receiver (for encryption)? For each item of meta data = it has to be made clear what the format of the field is and what the = allowances are for defaults, overrides, and updates by parties. * Extension mechanism - for profiling specifications and extension = mechanism is needed to define different forms of stream parameters and = the contents of a stream. For example, the notion of subscription is = narrowly defined and does not apply to SCIM except in one of many = potential methods of management. It doesn=E2=80=99t necessarily work for = Backchannel Logout either. * RESTfullness and Stream documents - AFAIK a REST API uses HTTP methods = to define operations against documents. In the proposed ID, a stream = has no specific resource URI endpoint - it is a shared endpoint where = the configuration is implied by reading a credential. The stateful = management of streams to me *screams* for a resource URL for the stream = object against which a set of simple HTTP methods define update and = query actions. =20 * Multiple endpoints - This spec has many different endpoints to express = different operations. This is not only vastly different from typical = RESTful patterns it also opens us up to the same security configuraiton = problems that OAuth currently has. IOW how does a receiver know that it = has discovered all the correct endpoints? Are they relative to some = root? * No Update method (only replace) - no ability to easily change specific = configuration items like jwks_uris that might change to facilitate key = rotation over time. =20 * Stream status - there is an ability to discover a stream has failed = but no metadata to describe the reason for failure Update - Can a receiver pause or enable recovery? For example, if a = receiver is getting garbage (e.g. because of bad keys) can the receiver = tell the transmitter to stop? * Stream identifier - There is no individual stream identifier. The spec = states=E2=80=A6 > An Event Transmitter MAY use the same URLs as endpoints for multiple > streams, provided that the Event Transmitter has some mechanism > through which they can identify the applicable Event Stream for any > given request, e.g. from authentication credentials. The = definition > of such mechanisms is outside the scope of this specification. This turns out to be overly restrictive. This was discussed at length in = the development of the delivery API. It simply isn=E2=80=99t workable. = It makes it hard to: Allow DevOps systems to independently check operational status of = streams because they must have a copy of the receivers credential It forces receivers to have multiple credentials if they are receiving = multiple streams from a sending organization. For example an RP may = receive events from multiple tenancies The credentials of provisioning entities and administrators are likely = not the same as the receiving entity. The receiver of a SET of SETs for RISC or OIDC should not be restricted = or bound to the Client_ID of the RP. The RP *must* be able to outsource = handling of events to another server entity (with different credential) = or to an external third party such as a CASB vendor. Multiple security entities will need to provision, manage, monitor, and = interact with Stream resources Subject enrolment - The method published really only addressed the RISC = use cases. It does not address broader user cases such as membership as = defined by a group or profile condition. Even within RISC there is no = agreement yet on how clients and IDPs track subjects (e.g. sub, email, = telephone, etc). These capabilities were addressed in the original distribution draft = (section 2 and 4 of the distribution draft [1]) submitted last year to = the WG. They were addressed because of the base protocol (RFC7644) = supports - see the SCIM Use Case document for more discussion on = provisioning protocol capabilities of RFC7644 [2]. It may be worthwhile = reproducing those sections as a separate draft with clear examples on = how all the use cases items are covered in the specs and are in fact = already proven to work well as a provisioning protocol. I can do that = if there is interest.=20 [0] draft-scurtescu-secevent.event-stream-mgmt-ap [1] https://tools.ietf.org/html/draft-hunt-secevent-distribution-01 [2] https://tools.ietf.org/html/draft-hunt-secevent-usecases-00 Going forward, I am working on a new control plane specification = document which I believe covers all of the use cases for RISC, Logout, = and SCIM. It can be used in minimalistic fashion (avoiding much of = RFC7644/43) in a way that looks similar to Marius and Annabelle=E2=80=99s = proposal. I hope to have this done soon and am waiting for a few = comments before publishing. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 11, 2017, at 10:43 AM, Marius Scurtescu = wrote: >=20 > A new version of the management api (aka control plane) draft was = published: > = https://datatracker.ietf.org/doc/draft-scurtescu-secevent-event-stream-mgm= t-api/ = >=20 > The document was renamed and it replaces: > draft-scurtescu-secevent-simple-control-plane >=20 > This new version addresses most of the feedback received at IETF 99 in = Prague: > - stream configuration update operation added > - stream status operation added > - verification event defined in this draft > - 429 HTTP status codes clean up > - added security considerations section > - moved endpoint descriptions to Event Stream Management section > - fixed example URIs and phone numbers > - typos and text changes >=20 > Please read and provide feedback. We would like to see this draft = adopted as a workgroup draft as soon as possible. >=20 > Thanks, > Marius > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D8GQYK59RCc9Z6vA= q3NiokxFhK9W8kVnqk4vcMalYBnU&s=3Dk-N-QlKTDPikiSIcAZfAhA7rrErQ0peqxXzp176jK= oI&e=3D=20 --Apple-Mail=_3A05A191-2AD3-4B9C-AEE9-393A08ACA469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This is to provide feedback on the proposal submitted by = Marius [0].

I do not = believe the draft [0] is close to ready for adoption. I am concerned = that the design unnecessarily complicates and limits implementation for = many tenancy and/or enterprise focused cloud vendors, as well as = enterprise organizations that need to receive or send SETs. This applies = to all of the areas proposed:  RISC, OAuth Revocation, OIDC = Backchannel Logout, SCIM, etc.

The following is a list of items that = are of concern:

* Metadata is far from complete - this is to be expected. One = of the items that needs to be worked out is what does a publisher need = to know in order to formulate SETs with the correct signing and = encryption. E.g. should a stream configuration have jwksuris for = transmitter (presumably for signing) and receiver (for encryption)? =  For each item of meta data it has to be made clear what the format = of the field is and what the allowances are for defaults, overrides, and = updates by parties.

* Extension mechanism - for profiling specifications and = extension mechanism is needed to define different forms of stream = parameters and the contents of a stream.  For example, the notion = of subscription is narrowly defined and does not apply to SCIM except in = one of many potential methods of management. It doesn=E2=80=99t = necessarily work for Backchannel Logout either.

* RESTfullness and Stream documents - = AFAIK a REST API uses HTTP methods to define operations against = documents.  In the proposed ID, a stream has no specific resource = URI endpoint - it is a shared endpoint where the configuration is = implied by reading a credential.  The stateful management of = streams to me *screams* for a resource URL for the stream object against = which a set of simple HTTP methods define update and query actions. =  

* = Multiple endpoints - This spec has many different endpoints to express = different operations.  This is not only vastly different from = typical RESTful patterns it also opens us up to the same security = configuraiton problems that OAuth currently has.  IOW how does a = receiver know that it has discovered all the correct endpoints? =  Are they relative to some root?

* No Update method (only replace) - no = ability to easily change specific configuration items like jwks_uris = that might change to facilitate key rotation over time.  

* Stream status - there = is an ability to discover a stream has failed but no metadata to = describe the reason for failure
   Update = - Can a receiver pause or enable recovery? For example, if a receiver is = getting garbage (e.g. because of bad keys) can the receiver tell the = transmitter to stop?

* Stream identifier - There is no individual stream = identifier. The spec states=E2=80=A6
An =
Event Transmitter MAY use the same URLs as endpoints for multiple
   streams, provided that the Event =
Transmitter has some mechanism
   through which they can identify the applicable =
Event Stream for any
   given request, e.g. from authentication =
credentials.  The definition
   of such mechanisms is outside the scope of this =
specification.
This turns out = to be overly restrictive. This was discussed at length in the = development of the delivery API. It simply isn=E2=80=99t workable. It = makes it hard to:
  • Allow= DevOps systems to independently check operational status of streams = because they must have a copy of the receivers credential
  • It forces receivers to have multiple credentials if they are = receiving multiple streams from a sending organization.  For = example an RP may receive events from multiple tenancies
  • The credentials of provisioning entities and administrators = are likely not the same as the receiving entity.
  • The = receiver of a SET of SETs for RISC or OIDC should not be restricted or = bound to the Client_ID of the RP.  The RP *must* be able to = outsource handling of events to another server entity (with different = credential) or to an external third party such as a CASB vendor.
  • Multiple security entities will need to = provision, manage, monitor, and interact with Stream resources

Subject = enrolment - The method published really only addressed the RISC use = cases. It does not address broader user cases such as membership as = defined by a group or profile condition.  Even within RISC there is = no agreement yet on how clients and IDPs track subjects (e.g. sub, = email, telephone, etc).

These capabilities were addressed in the original = distribution draft (section 2 and 4 of the distribution draft [1]) = submitted last year to the WG. They were addressed because of the base = protocol (RFC7644) supports - see the SCIM Use Case document for more = discussion on provisioning protocol capabilities of RFC7644 [2]. It may = be worthwhile reproducing those sections as a separate draft with clear = examples on how all the use cases items are covered in the specs and are = in fact already proven to work well as a provisioning protocol.  I = can do that if there is interest. 

[0] =  draft-scurtescu-secevent.event-stream-mgmt-ap
[1] https://tools.ietf.org/html/draft-hunt-secevent-distribution-01=
[2] https://tools.ietf.org/html/draft-hunt-secevent-usecases-00=

Going = forward, I am working on a new control plane specification document = which I believe covers all of the use cases for RISC, Logout, and SCIM. = It can be used in minimalistic fashion (avoiding much of RFC7644/43) in = a way that looks similar to Marius and Annabelle=E2=80=99s proposal. I = hope to have this done soon and am waiting for a few comments before = publishing.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 11, 2017, at 10:43 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

A new version of = the management api (aka control plane) draft was published:
https://datatracker.ietf.org/doc/draft-scurtescu-secevent-event-stream-mgmt-api/

The document was renamed and it replaces:
draft-scurtescu-secevent-simple-control-plane

This new version addresses most of = the feedback received at IETF 99 in Prague:
- stream configuration update = operation added
- stream status operation = added
- verification event defined in = this draft
- 429 HTTP status = codes clean up
- = added security considerations section
- moved endpoint descriptions to Event Stream Management = section
- fixed example = URIs and phone numbers
- = typos and text changes
Please read = and provide feedback. We would like to see this draft adopted as a = workgroup draft as soon as possible.

Thanks,
Marius
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3D8GQYK59RCc9Z6vAq3NiokxFhK9W8kVnqk4vcMalYBnU&s=3Dk-N-QlKTDP= ikiSIcAZfAhA7rrErQ0peqxXzp176jKoI&e=3D

= --Apple-Mail=_3A05A191-2AD3-4B9C-AEE9-393A08ACA469-- From nobody Wed Sep 27 13:53:20 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9B91350C3 for ; Wed, 27 Sep 2017 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47EWtONLHaqV for ; Wed, 27 Sep 2017 13:53:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBAE1350BF for ; Wed, 27 Sep 2017 13:53:17 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8RKrF4L011030 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 27 Sep 2017 20:53:15 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8RKrEeH012158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 27 Sep 2017 20:53:15 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8RKrESW011326 for ; Wed, 27 Sep 2017 20:53:14 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Sep 2017 13:53:14 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D18EF52D-AB13-4F5B-B67F-6D19B69AF21C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com> Date: Wed, 27 Sep 2017 13:53:11 -0700 To: ID Events Mailing List X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [Id-event] Replacing "nbf" claim with a new "toe" claim X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:53:19 -0000 --Apple-Mail=_D18EF52D-AB13-4F5B-B67F-6D19B69AF21C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 During the OpenID RISC Face to Face meeting a question came up regarding = SET=E2=80=99s redefinition of =E2=80=9Cnbf=E2=80=9D 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 = =E2=80=94 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 . "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=C2=A04.1.5 [RFC7519] = , 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.=20 The proposal is to register a different claim name such as =E2=80=9Ctoe=E2= =80=9D (time of event). The proposed new definition: toe Defined by Section=C2=A04.1.5 [RFC7519] = , 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 =E2=80=9Ctoe=E2=80=9D MAY be = assumed to be the value of =E2=80=9Ciat=E2=80=9D. nbf This claim is not used in SET Events. If asserted, the value = SHOULD be ignored. Are there any objections to the proposed change? =20 Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_D18EF52D-AB13-4F5B-B67F-6D19B69AF21C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 During the OpenID RISC Face to Face meeting a question came = up regarding SET=E2=80=99s redefinition of =E2=80=9Cnbf=E2=80=9D 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 =E2=80=94 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.  "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], 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 =E2=80=9Ctoe=E2=80=9D (time of = event). The proposed new
definition:

toe
      Defined by Section 4.1.5 [RFC7519], 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 =E2=80=9Ctoe=E2=80=9D MAY =
be assumed to be the value of =E2=80=9Ciat=E2=80=9D.

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
phil.hunt@oracle.com

= --Apple-Mail=_D18EF52D-AB13-4F5B-B67F-6D19B69AF21C-- From nobody Wed Sep 27 13:55:57 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB207135098 for ; Wed, 27 Sep 2017 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4LIphG-2vJl for ; Wed, 27 Sep 2017 13:55:52 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0471350AC for ; Wed, 27 Sep 2017 13:55:52 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id t127so10190745ywg.4 for ; Wed, 27 Sep 2017 13:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bhi3b67GWALLXypMJg76QS4fGc/mG527Q+t1KtYRx+U=; b=Z8pqwKwSTMX4pCFW5Naie6tW9I2w1Sj3qoia2zWj52dGwT1pjz+dpeFrkYE6g27rrR Rmic1QZ1ATs3hLr5oZx9af6j3haNFKTlv6bd26qs8q8JaaFrjlwn842Rxja6HfuBZ+hF JpXMZ0nwE4ESL1QeCYLTpgWk/oZi0TcT5UekTof03z6ZRBu2YzsZHyNucuhHmcAL5UxI AV3G1PTT9ZHOTSzMZQxh84ijVdoTlBBNTrKiV+HR7Hz/VwRHB+oZ39KxTsNN0Y0ty8tk bdypc4xzEsqFXr6QjSzrlBN2wSoKXXINOXFfANACXmkk6X9akzVaVz9kf3LL9ZUPZ6CC /gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bhi3b67GWALLXypMJg76QS4fGc/mG527Q+t1KtYRx+U=; b=HClSdzvLhcwBdEvkiDsMOINQoa3dIn3N5c+p3Yz/GrV8bkbRV/E9OpE6UPyxvbLHPt 8CXdR1SUs5ejej+iWNM37TRK7xn8pSweEy8bwz7r6/LmQjtuek6YREGgp0bFVjdztWij Igw209MAhQXfs3WMsTs+yckVQ/tJvNQQi1TIUH2iftzBot0bVUsUNl+9LIPprucoDJXX Iq9eIMDUbtO7h9sKAVMCDARDSfsyZKp6Q0vLYVXAWlu7B4BFcBR0ywUHbeqnnciavHSV XFk/jc8X4dc7lWNSAodMWZd118nyOaalPu1Z2TsuynNkDKJWOaZrxDoFaLRgb8kQPZl8 UmUQ== X-Gm-Message-State: AHPjjUitH6WgWGOZaOY+425AUXFNKINIadH4Yw30gQQNwhXlXhIZGhc4 OgFnb3JEOGZmAouzMjqzCeS+0NbHJihOR0V5gtzDHK2r X-Google-Smtp-Source: AOwi7QCvXlVpHMpQ5lN64SpkSvkIeJDim8q7fMPYaKImpwMtF7F0rJIhIMXz0gbA7pPNDvpU8HjnrpDUFyixoYU29L0= X-Received: by 10.13.231.65 with SMTP id q62mr1868530ywe.324.1506545751331; Wed, 27 Sep 2017 13:55:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.165.74 with HTTP; Wed, 27 Sep 2017 13:55:30 -0700 (PDT) In-Reply-To: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com> References: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com> From: William Denniss Date: Wed, 27 Sep 2017 13:55:30 -0700 Message-ID: To: Phil Hunt Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c07bc92591ad1055a3204ed" Archived-At: Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:55:55 -0000 --94eb2c07bc92591ad1055a3204ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > During the OpenID RISC Face to Face meeting a question came up regarding > SET=E2=80=99s redefinition of =E2=80=9Cnbf=E2=80=9D and whether that rede= finition 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 =E2=80=94 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 earli= er > than the time of issuance (e.g. because the incident was discovered throu= gh > an administrative review or data analysis to have occurred in the past). > > The definition from JWT is: > > 4.1.5 . "nbf" (Not Be= fore) 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] , 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 =E2=80=9Ctoe= =E2=80=9D (time of > event). The proposed new > definition: > > toe > Defined by Section 4.1.5 [RFC7519] , 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 OPT= IONAL. > > When not asserted, the value of =E2=80=9Ctoe=E2=80=9D MAY be assume= d to be the value of =E2=80=9Ciat=E2=80=9D. > > > 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 > phil.hunt@oracle.com > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c07bc92591ad1055a3204ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This change seems to be in line with the semantic meaning = of the ID-Event.

And I agree it's better not to rede= fine a standard claim.

Therefore, +1

On Wed, Sep 27, 2017 at 1:53 P= M, Phil Hunt <phil.hunt@oracle.com> wrote:
During the OpenID R= ISC Face to Face meeting a question came up regarding SET=E2=80=99s redefin= ition of =E2=80=9Cnbf=E2=80=9D and whether that redefinition was appropriat= e.

The intention of SETs definition is to allow SET Tran= smitters to indicate that an event may have occurred as early as a specifie= d date =E2=80=94 a date which is different from the issuance date of the SE= T. 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 incid= ent was discovered through an administrative review or data analysis to hav= e occurred in the past).

The definition from JWT i= s:
4.1.5.  &qu=
ot;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&qu=
ot;
   claim requires that the current date/time MUST be after or equal to
   the not-before date/time listed in the "nbf" claim.  Implement=
ers 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.

<= /div>

As defined in SET:
   nbf
      Defined by Section=C2=A04.1.5 [RFC7519], a number whose valu=
e 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 "i=
at" 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.= =C2=A0

The proposal is to register a different cla= im name such as =E2=80=9Ctoe=E2=80=9D (time of event). The proposed new
definition:

toe
      Defined by Section=C2=A04.1.5 [RFC7519], a number whose valu=
e is a
      NumericDate.  The value is the date and time in which the event is be=
lieved to have
      occurred in the past or will occur in the future. This claim is OPTIO=
NAL.
      When not asserte=
d, the value of =E2=80=9Ctoe=E2=80=9D MAY be assumed to be the value of =E2=
=80=9Ciat=E2=80=9D.

nbf
      This claim is not used in SET Events. If asse=
rted, the value SHOULD
    =
  be ignored.


Are there any o= bjections to the proposed change?
=C2=A0
=
Phil

Oracle Corporation, Identity Cloud Services Architect
@inde= pendentid
phil.hunt@oracle.com


_______________________________________________ Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--94eb2c07bc92591ad1055a3204ed-- From nobody Thu Sep 28 06:59:26 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1603D1320DC for ; Thu, 28 Sep 2017 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkfvYFytDElh for ; Thu, 28 Sep 2017 06:59:23 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8328133090 for ; Thu, 28 Sep 2017 06:59:22 -0700 (PDT) X-AuditID: 12074422-77bff70000003825-1c-59cd0039d292 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.96.14373.9300DC95; Thu, 28 Sep 2017 09:59:21 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v8SDxKKq025555 for ; Thu, 28 Sep 2017 09:59:20 -0400 Received: from [192.168.1.3] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8SDxId1031159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 28 Sep 2017 09:59:19 -0400 To: id-event@ietf.org References: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com> From: Justin Richer Message-ID: Date: Thu, 28 Sep 2017 09:59:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com> Content-Type: multipart/alternative; boundary="------------06FC708E0C5AB2195E2E04B6" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrWvJcDbS4Ng/EYuOBd1MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaJzynLVgZytjxdU5IQ2Mm8K6GDk5JARMJL79a2cFsYUEFjNJ nN6s0MXIBWSfZJS4sOkOO4TzjkniYsc1dpAqYQEXicPtP5lBbBEBUYl9E1dDddtKnDjcwwRi swmoSkxf0wJm8wpYSWx9u4mxi5GDgwUovuqhL0hYVCBG4uelRywQJYISJ2c+AbM5Bewkfk9Y BzaeWSBM4vjrBVC2uMStJ/OZJjDyz0LSMgtJ2SwkZRC2mcS8zQ+h4vISzVtnA9kcQLaaxLJW JWThBYzsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3MYICm91FaQfjxH9ehxgF OBiVeHgvLDgdKcSaWFZcmXuIUZKDSUmU99y3M5FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgT /wPleFMSK6tSi/JhUtIcLErivNuCdkUKCaQnlqRmp6YWpBbBZGU4OJQkeN1BGgWLUtNTK9Iy c0oQ0kwcnCDDeYCGZ4ENLy5IzC3OTIfIn2I05thw8+4fJo59IFKIJS8/L1VKnNccpFQApDSj NA9uGig5ua+zs3jFKA70nDBvEEgVDzCxwc17BbSKCWjV5Ilgq0oSEVJSDYyabhWZ9z8m5alI 53u33jhj6NGq4FnYF2Nq4HaE1WniLKuuto8LPwi+ycphc/i+1sHkz6Y94qlOeYoHzu7ze61s pKSqHdR1sK26221bxuEL2y/k77nkcpNJ9Fu81j7ZWTyJhzvOu96qM7CzvRUx6xuDw7qEd9eY zi1T+ttsdHTz05PW3x5UnFBiKc5INNRiLipOBADOzkKUKQMAAA== Archived-At: Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:59:25 -0000 This is a multi-part message in MIME format. --------------06FC708E0C5AB2195E2E04B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +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). > > The definition from JWT is: > > > 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 bySection 4.1.5 [RFC7519] > , 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 bySection 4.1.5 [RFC7519] > , 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 > phil.hunt@oracle.com > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------06FC708E0C5AB2195E2E04B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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

The definition from JWT is:
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], 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], 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

                                            
                                          

                                        

                                      

                                    phil.hunt@oracle.com

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

        

      

      

      

      

      
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


    

    

  


--------------06FC708E0C5AB2195E2E04B6--


From nobody Thu Sep 28 08:23:19 2017
Return-Path: 
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC9133344 for ; Thu, 28 Sep 2017 08:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XXJN_mRhK8v for ; Thu, 28 Sep 2017 08:23:08 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47407134237 for ; Thu, 28 Sep 2017 08:23:08 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id y138so1823085itc.5 for ; Thu, 28 Sep 2017 08:23:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EiNcOeFfdlclHw2ie93OPU0HkyqNZ3ldhyaAsFSQEGI=; b=JFCyfwUk2fAWpKRXjWrxdfvNkHflJ5osQc+ufPVKfcA1ASyagR2+hbQ3Vk6swazDbu SMtH61s+1a0Ym4/aRe0X4+lM6nT5NRHMmg74k4h1QQWRM6PbFGu3VkhEP90iWpwiy7dk 7U23afZsPwBEE9+Xrdl8HE5TN3aANOsgXgJfM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EiNcOeFfdlclHw2ie93OPU0HkyqNZ3ldhyaAsFSQEGI=; b=bO1XYrOGGtUSgw+8ZvRBODcWdYluYx0iH59RSEpfn5Qfc19vb96ekptMS/Og+JyEG6 4/GOVLAFqxcBDAoHIkUZVYev8mk6nL30se5vHfXOGbhjs4cQBhhKiHwCGz0MjJPE348X ddDeG09Av4etLvy5ctM3nVq9b0KGDNltcpcvO2WvhnBB0KvBcK3Kg7yelHlBmN+2xW+s 42Vu/YPHwZYeeJzMCZeFWuL17XzOXZBz3OtVFBgwunXP+uVKH7iL25vFdn1H+9I/eMkc 91/+svCR908JMwBijhec+JVqyc/M+g7AQMJio9u9SDRWhvd5Y2AUUy67GOqS2eoHbJYP kZAg==
X-Gm-Message-State: AHPjjUjTOd822iUEg5M/g94tyfuJmfKBMEoB6xKpu/43M9yuU41+J+aN 0D/vdYjhvRam9PLGzjWAjAc2eVBoT2UIODesoebAfiA/8FbLhM3v8nqNeP5lXaaICMtOJOb2JwX fbGzmfscd+ApADSdpfQ==
X-Google-Smtp-Source: AOwi7QDZ7/mDfFPsqaXsqu574JSWZUm/FWh2TYTptVhyVkjjyq48tBxwHsvK3vsW8YvBfILTrUk86gPf5CqDQb3xtcI=
X-Received: by 10.36.178.1 with SMTP id u1mr2299425ite.120.1506612187577; Thu, 28 Sep 2017 08:23:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.1.206 with HTTP; Thu, 28 Sep 2017 08:22:36 -0700 (PDT)
In-Reply-To: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com>
References: <872C6059-123B-431C-9C6B-EBAAE3D6A3DA@oracle.com>
From: Brian Campbell 
Date: Thu, 28 Sep 2017 09:22:36 -0600
Message-ID: 
To: Phil Hunt 
Cc: ID Events Mailing List 
Content-Type: multipart/alternative; boundary="f403045d9c0e4163bc055a417c0d"
Archived-At: 
Subject: Re: [Id-event] Replacing "nbf" claim with a new "toe" claim
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 15:23:16 -0000

--f403045d9c0e4163bc055a417c0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+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  wrote:

> During the OpenID RISC Face to Face meeting a question came up regarding
> SET=E2=80=99s redefinition of =E2=80=9Cnbf=E2=80=9D and whether that rede=
finition 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 =E2=80=94 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 earli=
er
> than the time of issuance (e.g. because the incident was discovered throu=
gh
> an administrative review or data analysis to have occurred in the past).
>
> The definition from JWT is:
>
> 4.1.5 .  "nbf" (Not Be=
fore) 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] , 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 =E2=80=9Ctoe=
=E2=80=9D (time of
> event). The proposed new
> definition:
>
> toe
>       Defined by Section 4.1.5 [RFC7519] , 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 OPT=
IONAL.
>
>       When not asserted, the value of =E2=80=9Ctoe=E2=80=9D MAY be assume=
d to be the value of =E2=80=9Ciat=E2=80=9D.
>
>
> 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
> phil.hunt@oracle.com
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
>

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

--f403045d9c0e4163bc055a417c0d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+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 sti=
ll 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 i=
ncluded 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.=C2=A0  

On Wed, Sep 27, 2017 at 2:53 PM, Phil Hunt=
 <phil.hunt@oracle.com> wrote:
During the OpenID RISC Face to =
Face meeting a question came up regarding SET=E2=80=99s redefinition of =E2=
=80=9Cnbf=E2=80=9D and whether that redefinition was appropriate.

<=
/div>
The intention of SETs definition is to allow SET Transmitters to =
indicate that an event may have occurred as early as a specified date =E2=
=80=94 a date which is different from the issuance date of the SET. In part=
icular this is useful in cases where the state change is believed to have o=
ccurred earlier than the time of issuance (e.g. because the incident was di=
scovered through an administrative review or data analysis to have occurred=
 in the past).

The definition from JWT is:
4.1.5.  "nbf&quo=
t; (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&qu=
ot;
   claim requires that the current date/time MUST be after or equal to
   the not-before date/time listed in the "nbf" claim.  Implement=
ers 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.

<=
/div>

As defined in SET:
   nbf
      Defined by Section=C2=A04.1.5 [RFC7519], a number whose valu=
e 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 "i=
at" 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.=
=C2=A0

The proposal is to register a different cla=
im name such as =E2=80=9Ctoe=E2=80=9D (time of event). The proposed new
definition:

toe
      Defined by Section=C2=A04.1.5 [RFC7519], a number whose valu=
e is a
      NumericDate.  The value is the date and time in which the event is be=
lieved to have
      occurred in the past or will occur in the future. This claim is OPTIO=
NAL.
      When not asserte=
d, the value of =E2=80=9Ctoe=E2=80=9D MAY be assumed to be the value of =E2=
=80=9Ciat=E2=80=9D.

nbf
      This claim is not used in SET Events. If asse=
rted, the value SHOULD
    =
  be ignored.


Are there any o=
bjections to the proposed change?
=C2=A0


=

Phil

Oracle Corporation, Identity Cloud Services Architect
@inde=
pendentid
phil.hunt@oracle.com






_______________________________________________
Id-event mailing list

Id-event@ietf.org

https://www.ietf.org/mailman/listinfo/id-event







<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--f403045d9c0e4163bc055a417c0d--