From nobody Tue Dec 10 16:36:26 2019 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 0AA9D1200F6; Tue, 10 Dec 2019 16:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 okumJi80NGZS; Tue, 10 Dec 2019 16:36:21 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 475A312008C; Tue, 10 Dec 2019 16:36:21 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBB0aFAF008630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 19:36:17 -0500 Date: Tue, 10 Dec 2019 16:36:14 -0800 From: Benjamin Kaduk To: draft-ietf-secevent-http-push.all@ietf.org Cc: id-event@ietf.org Message-ID: <20191211003614.GW13890@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Id-event] AD review of draft-ietf-secevent-http-push-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 11 Dec 2019 00:36:24 -0000 Hi all, Due to the unfortunate delay in AD evaluation from my personal situation, I ended up being able to review push and poll side-by-side; this results in a couple places where we may want to update push with content from poll. I've tried to keep such comments self-contained in the per-document reviews, though I expect that both authors and I will be consulting both documents during the course of the updates. I think all of these should be fairly straightforward to address, so hopefully we can kick off IETF LC before the new year. While I agree with the note in the shepherd writeup that it's appropriate to reference RFC 5246 specifically for TLS 1.2, we probably also want to reference RFC 8446 as the "current generic TLS reference" at least once. Section 1 A mechanism for exchanging configuration metadata such as endpoint URLs and cryptographic key parameters between the transmitter and recipient is out of scope for this specification. I guess "cryptographic key parameters" was intended to be things like JST signing keys, but we could equally be talking about TLS certificates/CAs/DNS-IDs here as well, if we wanted. Section 2 o The SET is authentic (i.e., it was issued by the issuer specified within the SET). Does "recipient does not have issuer's public key" just get lumped into the "not authentic" bucket? o The SET Issuer is recognized as an issuer that the SET Recipient is willing to receive SETs from (e.g., the issuer is whitelisted by the SET Recipient). o The SET Recipient is willing to accept the SET when transmitted by the SET Transmitter (e.g., the SET Transmitter is expected to send SETs with the subject of the SET in question). We call out that we have to trust the issuer in general, and we have to trust the transmitter to send for a given subject, but we don't explicitly say anything about trusting the issuer to issue for that subject. There are, of course, many scenarios where no such check is possible (e.g., when the subject is identified by the iss/sub pair and not a globally unique 'sub' claim), but perhaps there are cases where such a check is conceivable. Do we want to say anything about it ("no, because it's too complicated to accurately described" is okay)? Section 2.1 The "Content-Type" header of this request MUST be "application/ secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and I think we mean Sections 2.3 and 7.3 of that document. The mechanisms by which the SET Transmitter determines the HTTP endpoint to use when transmitting a SET to a given SET Recipient are not defined by this specification and are deployment specific. Any TLS certificate validation procedures (when HTTPS is used) would also be deployment-specific, of course, but do we think it's worth mentioning them here anyway (to seed the idea of using TLS)? The example in Figure 1 seems to not have an 'events' claim in the transmitted JWT? Section 2.4 Do we want to say anything about generic error-handling behavior when a SET Transmitter receives an error code that it does not know about (e.g., because that code has been allocated after the software was written)? | authentication_failed | The SET Recipient could not authenticate | | | the SET Transmitter from the contents of | | | the request. | Are only the contents of the request allowed to be used for authenticating the Transmitter (as opposed to, say, TLS-layer client-certificate authentication)? (Note that this text also appears in Section 7.1.2.) Section 3 It might be worth some discussion that for push, HTTP authentication authenticates the transmitter, whereas for poll it authenticates the recipient; workflows that need to authenticate the other party would have to rely on TLS, it seems. The SET delivery method described in this specification is based upon HTTP and depends on the use of TLS and/or standard HTTP authentication and authorization schemes, as per [RFC7235]. Maybe reference RFC 2818 for "HTTP over TLS", to get parallelism of references? Because SET Delivery describes a simple function, authorization for the ability to pick-up or deliver SETs can be derived by considering the identity of the SET Issuer, or via other employed authentication Presumably this would involve some comparison/relationship between sender and issuer? Also, I'm not sure I understand what is meant by "the ability to pick up SETs". Is this the implied ability of a non-Issuer Transmitter to obtain the SETs being transmitted? Section 4 Delivery reliability requirements may vary from implementation to implementation. This specification defines the response from the SET Is this more of a per-implementation thing or a per-deployment thing? Implementers SHOULD evaluate their reliability requirements and the (here, too) if any, in order to meet their requirements. SET Transmitters with high reliability requirements may be tempted to always retry failed transmissions, however it should be noted that for many types of SET nit: comma after "however" (as well as the existing one before it). Section 5 We should probably pull in the "HTTP Considerations" subsection from poll. I want to see how the discussion goes on poll's "Access Token Considerations" first, but we may want something like that as well. Section 5.1 In scenarios where HTTP authorization or TLS mutual authentication are not used or are considered weak, JWS signed SETs SHOULD be used (see [RFC7515] and Security Considerations [RFC8417]). This enables nit: I think we want "the Security Considerations of [RFC8417]". Section 5.2 RFC 6125 is great and I'm glad we're referencing it, but it does leave a couple of gaps to be specified for a full picture of application usage. Specifically, we should say what name from the certificate we validate (and, ideally, how the application knows what name it is expecting to see in that name field in the certificate). Most applications these days will be using the DNS-ID, and perhaps something about wildcards and/or revocation info. The last time I was making this comment on a document I pointed to RFC 8461 as a potential example to crib from, at least in terms of the types of things to talk about. Section 6 I would have expected to see some form of reminder to encrypt data that needs confidentiality protection, in a privacy considerations section. If a SET needs to be retained for audit purposes, a JWS signature MAY be used to provide verification of its authenticity. We should probably give the reader a bit more to conect this signature to the privacy considerations in question. Section 7.1 "Security Event Token Delivery Error Codes". Initial values for the Security Event Token Delivery Error Codes registry are given in Table 1. Future assignments are to be made through the First Come It is a little confusing to say here at the top-level that the initial contents are in Table 1, but then also have Section 7.1.2 with the full initial registration (filling out the template). I'd suggest to either mention both the table and Section 7.1.2 here, or just Section 7.1.2. Section 7.1.1 Change Controller For error codes registered by the IETF or its working groups, list "IETF SecEvent Working Group". For all other error codes, list the name of the party responsible for the registration. Contact information such as mailing address, email address, or phone number may also be provided. The current thinking from the IESG is that we don't want to lock the immutable RFC into something that might go stale, and since IANA is good at tracking things, we can have them track the right contact-point within the IETF as well. So, the expected "final state" is that the public registry lists "IETF" as the change controller, with IANA knowing to direct inquiries the WG list (until such time as updated by the IESG). Thus, the document at this point should say something about "IANA is requested to direct inquiries to the id-event@ietf.org mailing list, and the RFC Editor is requested to remove this sentence prior to publication" This is something of a recent change, so we'll probably end up making further tweaks along the way, but that should be a good rough start. Defining Document(s) A reference to the document or documents that define the Security Event Token Delivery Error Code. The definition MUST specify the name and description of the error code, and explain under what circumstances the error code may be used. URIs that can be used to retrieve copies of each document at no cost SHOULD be included. Is a document of some form required? That's not consistent with the FCFS policy (as IANA does not want to be in the business of making the technical decision about whether the document qualifies for this purpose); should we be thinking about a Specification Required policy instead (with guidance to the experts to apply a very low bar)? Section 7.1.2 Error Code: access_denied Description: The SET Transmitter is not authorized to transmit the SET to the SET Recipient. In Table 1 we say "transmit the provided SET" (i.e., "provided" is not present here). We should be consistent, though I don't really care which phrasing gets used. Appendices It looks like we expect Appendices A and C to be removed before publication, but Appendix B (Acknowledgments) to remain. Feel free to add the EDITORS NOTE to Appendix C as well. -Ben From nobody Tue Dec 10 16:37:41 2019 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 67A1C1200F6; Tue, 10 Dec 2019 16:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 OhZx16qn6IdR; Tue, 10 Dec 2019 16:37:36 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8F63112008C; Tue, 10 Dec 2019 16:37:33 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBB0bTPV008978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 19:37:31 -0500 Date: Tue, 10 Dec 2019 16:37:29 -0800 From: Benjamin Kaduk To: draft-ietf-secevent-http-poll.all@ietf.org Cc: id-event@ietf.org Message-ID: <20191211003729.GX13890@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Id-event] AD review of draft-ietf-secevent-http-poll-06 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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, 11 Dec 2019 00:37:39 -0000 Hi all, The changes here are also fairly straightforward, so we should be able to run the IETF LC for push and poll concurrently. As is the case for push, we should probably cite RFC 8446 somewhere in addition to 5246. There's not as clear of a rhetorical need to reference RFC 2818 here, but it's not wrong to do so. Section 1 A mechanism for exchanging configuration metadata such as endpoint URLs and cryptographic key parameters between the transmitter and recipient is out of scope for this specification. How SETs are [my comment about JWT signing key vs. TLS certificate/etc. from push applies here, to] Section 1.1 Throughout this document, all figures MAY contain spaces and extra line wrapping for readability and due to space limitations. I suggest using the lowercase "may", as there's not much point in giving normative guidance to the authors of this document, from within this document. Section 2 When a SET is available for a SET Recipient, the SET Transmitter attempts to deliver the SET by queueing the SET in a buffer so that a SET Recipient can poll for SETs using HTTP/1.1 POST. nit: I expect some other reviewers to want to wordsmith this sentence, so as an effort to forestall it, I suggest s/attempts to delivery/prepares to deliver/ (or similar). The idea being that if you always know you're going to enqueue, that isn't really an "attempt at delivery". [I-D.ietf-secevent-http-push]. The SET Recipient MUST acknowledge receipt to the SET Transmitter. The SET Recipient SHALL NOT use the I expect we'll get some IESG comments about this sentence (e.g., "is there a time bound on when the acknowledgment has to happen?", "is the transmitter expected to bound the length of its queue and drop new events if the recipient fails to acknowledge in a timely manner?"), though I don't have any specific changes I personally propose. That is, if you want to leave it as-is and see what happens, I'm okay with that. (Even a forward-reference to Section 2.4 that has "(e.g., seconds or minutes)" might help.) Section 2.1 more SETs. Requests MAY be made at a periodic interval (short polling) or requests MAY wait, pending availability of new SETs using long polling, per Section 2 of [RFC6202]. Someone who follows the references would probably be able to figure out that in general, short-polling is fairly likely to result in some zero-SET responses, and long-polling is generally likely to result in some SETs being returned. So it's not clear to me whether we want to think about putting a bit more detail inline here, especially since there are no hard guarantees in either case. o after validating previously received SETs, the SET Recipient initiates another poll request using HTTP POST that includes acknowledgement of previous SETs and waits for the next batch of SETs. nit: "waits for the next batch" could be read as implying long-polling, to the exclusion of short-polling. Maybe just using "requests" (as per the previous bullet) again is best. Section 2.2 acknowledgement parameters in the form of JSON objects. The request payloads are delivered in a JSON document, as described in Section 2.4 and Section 2.5. nit: 2.5 covers *response* payloads. I'm not sure whether we want to cover both requests and responses here or just requests, but we should be consistent. ack A JSON array of strings whose values are the "jti" values of successfully received SETs that are being acknowledged. If there are no outstanding SETs to acknowledge, this member is omitted. When acknowledging a SET, the SET Transmitter is released from any obligation to retain the SET. nit: as currently written, this is saying that the Transmitter is acknowledging a SET. So we probably want something like "When the request is acknowledging a SET" or "When a SET has been acknowledged". setErrs A JSON object with one or more members whose keys are the "jti" values of invalid SETs received. The values of these objects are themselves JSON objects that describe the errors detected using the "err" and "description" values specified in Section 2.6. If there are no outstanding SETs with errors to return, this member is omitted. nit: I suggest s/return/report/, as it avoids the misparse "(SETs with errors) to return" of the intended "SETs with (errors to return)". Section 2.3 In response to a poll request, the SET Transmitter checks for available SETs and responds with a JSON document containing the following JSON object members: As written, this seems to require that both 'sets' and 'moreAvailable' are always present, so that we do not need to set a default behavior for the absence of 'moreAvailable'. If that's correct, we might want to specify some error handling for when the response is malformed in that manner. sets A JSON object that contains zero or more nested JSON objects. Each nested JSON object's key corresponds to the "jti" of a SET to be delivered, and its value is a JSON string containing the value of the encoded corresponding SET. If there are no outstanding SETs to be transmitted, the JSON object SHALL be empty. I think the -03 may have been overzealous with its s/attribute/object/ change -- we don't have nested objects within 'sets'. That is, there's the toplevel JSON object for the response, which has a map key "sets", and the value corresponding to the "sets" key is a JSON object. But the contents of that last object is just string/string keys/values, with the keys being "jti" values and the values being the corresponding encoded SETs. So I think this should be "contains zero or more key/value pairs. Each key string is the "jti" value of a SET to be delivered, and the value is the corresponding encoded SET" (or similar). Section 2.4 After a period of time configured between the SET Transmitter and Recipient, a SET Transmitter MAY redeliver SETs it has previously delivered. The SET Recipient SHOULD accept repeat SETs and acknowledge the SETs regardless of whether the Recipient believes it has already acknowledged the SETs previously. A SET Transmitter MAY limit the number of times it attempts to deliver a SET. I'm assuming that "redeliver" here involves using the exact same encoded SET, including 'jti'. On that assumption, I expect to get some IESG comments about this paragraph, regarding what layer "reliability" should be at (since, e.g., we get an HTTP 200 in response to our explicit ack message) and perhaps about the pacing/rate of such retransmits. But it's okay to wait and see what happens; I can't predict sufficiently accurately what comments we might receive to be confident about a preemptive "fix". If the SET Recipient has received SETs from the SET Transmitter, the SET Recipient SHOULD parse and validate received SETs to meet its own requirements and SHOULD acknowledge receipt in a timely fashion (e.g., seconds or minutes) so that the SET Transmitter can mark the SETs as received. SET Recipients SHOULD acknowledge receipt before Section 2 has "MUST acknowledge receipt" but this is just "SHOULD acknowledge receipt in a timely fashion". While technically these are not conflicting requirements, it's awfully close, and it would be good to harmonize them. Section 2.4.4 { "ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"], "setErrs": { "4d3559ec67504aaba65d40b0363faad8": { "err": "jwtAud", "description": "The audience value was invalid." } }, "returnImmediately": true } Figure 5: Example Poll Acknowledgement with Error I don't see "jwtAud" as a to-be-registered value in the "Security Event Token Delivery Error Codes" registry established by the push document, nor do we register it from this document. Section 2.5 In response to a valid poll request, the service provider MAY respond immediately if SETs are available to be delivered. If no SETs are available at the time of the request, the SET Transmitter SHALL delay responding until a SET is available or the timeout interval has elapsed unless the poll request parameter "returnImmediately" is "true". We may get someone asking for us to specify here what the behavior is when "returnImmediately" is "true". I know it's described previously in the document, so may not be strictly required, but it may be helpful to have nonetheless. This would also give an opportunity to reword to "if the poll request parameter 'returnImmediately' is false, the SET transmitter SHALL delay responding until ", as the current formulation is perhaps ambiguous as to whether the statement groups as "until (X or Y) unless Z" or "until (X) or (Y unless Z)". The following is a non-normative example response to the request shown in Section 2.4, which indicates that no new SETs or unacknowledged SETs are available: I think we should pick a subsection (2.4.1?) of Section 2.4, since there's not an example request at the toplevel. Section 2.5.1 The response body for responses to invalid poll requests is left undefined. Can you refresh my memory of the WG discussions where we concluded this should not be defined? This is likely to be a magnet for comments and I'd like to be able to respond properly to them. Section 2.6 If a SET is invalid, error codes from the IANA "Security Event Token Delivery Error Codes" registry established by [I-D.ietf-secevent-http-push] are used in error responses. As I'm not sure if there's a good clean way to remind the reader that these are SET-poll-level responses, not HTTP responses. The rest of the section does help, so maybe we should just leave it as-is for now. When included as part of a batch of SETs, the above JSON is included as part of the "setErrs" member, as defined in Section 2.3 and Section 2.4.4. I think s/2.3/2.2/ Section 3 It might be worth some discussion that for poll, HTTP authentication authenticates the recipient, whereas for push it authenticates the transmitter; workflows that need to authenticate the other party would have to rely on TLS, it seems. Since poll has the TLS server as the SET Transmitter, we could potentially pull in RFC 6125 and talk about validating DNS-IDs to authenticate the Transmitter. Given that the name to be authenticated would be part of the information conveyed out-of-band, though, it's not entirely clear how much value there would be in doing so. As per Section 4.1 of [RFC7235], a SET delivery endpoint SHALL indicate supported HTTP authentication schemes via the "WWW- Authenticate" header. I'm not entirely sure we need this paragraph (but if we keep it, we should probably scope it to "when using HTTP authentication"). Authorization for the ability to pick-up or deliver SETs can be determined by using the identity of the SET issuer, or via other employed authentication methods. Among other benefits, Presumably this would involve some comparison/relationship between sender and issuer? As for push, I'm not sure that "pick-up" will be clear to readers. Section 4 One could perhaps argue that "Authenticating Persisted SETs" from push could apply here as well, though the scenarios are somewhat different. Section 4.1 (see [RFC7515] and Section 5 of [RFC8417]). This enables the SET Recipient to validate that the SET issuer is authorized to deliver the SET. Looking at the diff from push, there's a clear bug in push that I comment on there, but also it seems we want to s/issuer/Transmitter/ here? Section 4.3 SETs may contain sensitive information that is considered Personally Identifiable Information (PII). In such cases, SET Transmitters and The diff from push shows up as s/e.g., subject claims/PII/. Either version is defensible, but we should be consistent. Section 4.4 When using access tokens, such as those issued by OAuth 2.0 [RFC6749], implementers MUST take into account threats and countermeasures documented in Section 8 of [RFC7521]. I think the average reader will need a bit more handholding about what access token usage is relevant here -- my first instinct was about confusability between SET and a JWT-formatted access token, but it seems that the rest of the discussion is more in line with using access tokens for (poll) request authorization. N.B. that we only talk about HTTP authentication and TLS authentication earlier in the document, so this would be the first part that introduces OAuth 2.0 as a possibility. Section 4.4.1 [...] authentication methods. Designating the specific methods of authentication and authorization are out of scope for the delivery of SETs, however this information is provided as a resource to implementers. Indeed, for this whole section it's hard to see a direct connection to SET transmission; is this general sort of advice not already present somewhere else that we could incorporate it by reference? Section 5 [N.B. that these comments are pasted from -push] I would have expected to see some form of reminder to encrypt data that needs confidentiality protection, in a privacy considerations section. If a SET needs to be retained for audit purposes, a JWS signature MAY be used to provide verification of its authenticity. We should probably give the reader a bit more to conect this signature to the privacy considerations in question. Section 5 We have some significant divergence from -push here; I think there's scope for harmonization (in both directions). The propagation of subject identifiers can be perceived as personally identifiable information. Where possible, SET Transmitters and nit: propagation is an action, but PII has to be a concrete thing. Maybe we just want to say that subject identifiers can be perceived as PII (which is what -push does)? Section 7.2 Earlier we say "MUST take into account threats and countermeasures documented in Section 8 of [RFC7521]", which is probably enough to get people demanding that 7521 be listed as Normative. -Ben From nobody Sun Dec 22 08:13:04 2019 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D643112010D; Sun, 22 Dec 2019 08:13:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: secevent-chairs@ietf.org, yaronf.ietf@gmail.com, id-event@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157703118283.11722.3554923121540859266.idtracker@ietfa.amsl.com> Date: Sun, 22 Dec 2019 08:13:02 -0800 Archived-At: Subject: [Id-event] secevent - Not having a session at IETF 107 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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: Sun, 22 Dec 2019 16:13:03 -0000 Yaron Sheffer, a chair of the secevent working group, indicated that the secevent working group does not plan to hold a session at IETF 107. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Dec 23 16:16:58 2019 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 70839120D2B for ; Mon, 23 Dec 2019 16:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=coinbase.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 vYjR72rf5MMz for ; Mon, 23 Dec 2019 16:16:54 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 92967120D27 for ; Mon, 23 Dec 2019 16:16:51 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id y17so18431737wrh.5 for ; Mon, 23 Dec 2019 16:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coinbase.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eWsnUK66/tPfCc4Q5lJNU8gg4OUB+4LwL9Upz4NALkE=; b=UnFTfx9mJjqo3t2X9JtnQKl+01euxw8WI22t7p0Qjlej0k/7YVNIKOn13TvEQ0W+Jk aclyJl0gbggHwNtewG6eVFd6JRzgIJDPt0PKiZBODCK3QoqUXlzq3ZCI1MqecDJUKK9G crQ4AlTR+wgoiINIXSdfDnbs9jrhL4IP+bLOc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eWsnUK66/tPfCc4Q5lJNU8gg4OUB+4LwL9Upz4NALkE=; b=dBYC5NRdEZoNVlX4g3x5oK+W6UKpQA+wpeXsQg3zJRyXe1z9pfbn+AsCxYeDIRivfH VKuGdrrzFtUJ5Ddq2Xdtofb6xeZ1qWqwdZXcfXUEcBmK+z5t5TKR2OjLYLvDwLHKpqTF GzydWKJ9YA4AsXOp5kfdKgFaF4HJZvL1Ov3AfaLrqjXw8CW74bF8vSfevVAhC2O6Rhds /EfDbglQw/6RMCusHTjhg6cc99rei54SJrXiE2SJjHMTsYZSnFOvyXnwbGRp5GORWjcP oxw6//uRKtycOSv6qra/+Rn7EStKZoFDeTb3M0mhGlTtYvYWcux58U2Bn8Q3NprTLJ3W ZF7Q== X-Gm-Message-State: APjAAAXgPZZACGNoyPIMLWj31xJLPMm4UDnz+epBi1kBE8QSNO2qmu35 yCUAsgLaWjqh+AvK3fCM/7s31eF6nOjt5BXHpdsh2RQKN+4= X-Google-Smtp-Source: APXvYqyU455u8xfmGYMx0qhVkxc0egKU7dN/sjwXam9QJ3wgrHC6rqFLtw7/SVKrUF9QvidP2xZrPQSnzuv6hYeZLbs= X-Received: by 2002:a5d:50ce:: with SMTP id f14mr32143949wrt.254.1577146609675; Mon, 23 Dec 2019 16:16:49 -0800 (PST) MIME-Version: 1.0 References: <157703118283.11722.3554923121540859266.idtracker@ietfa.amsl.com> In-Reply-To: <157703118283.11722.3554923121540859266.idtracker@ietfa.amsl.com> From: Marius Scurtescu Date: Mon, 23 Dec 2019 16:16:38 -0800 Message-ID: To: SecEvent Content-Type: multipart/alternative; boundary="0000000000006dd854059a680fd8" Archived-At: Subject: [Id-event] Fwd: secevent - Not having a session at IETF 107 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 24 Dec 2019 00:16:57 -0000 --0000000000006dd854059a680fd8 Content-Type: text/plain; charset="UTF-8" Hi, Was there a discussion and decision to not have a session at IETF 107? What is the rationale? Thanks, Marius ---------- Forwarded message --------- From: IETF Meeting Session Request Tool Date: Sun, Dec 22, 2019 at 8:13 AM Subject: [Id-event] secevent - Not having a session at IETF 107 To: Cc: , , , Yaron Sheffer, a chair of the secevent working group, indicated that the secevent working group does not plan to hold a session at IETF 107. This message was generated and sent by the IETF Meeting Session Request Tool. _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --0000000000006dd854059a680fd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Was there a discussion and de= cision to not have a session at IETF 107? What is the rationale?

Thanks,
Marius


---------- Forwarded message ----= -----
From: IETF Meeting= Session Request Tool <session-request@ietf.org>
Date: Sun= , Dec 22, 2019 at 8:13 AM
Subject: [Id-event] secevent - Not having a se= ssion at IETF 107
To: <s= ession-request@ietf.org>
Cc: <secevent-chairs@ietf.org>, <yaronf.ietf@gmail.com>, <id-event@ietf.org>, <kaduk@mit.edu>




Yaron Sheffer, a chair of the secevent working group, indicated that the se= cevent working group does not plan to hold a session at IETF 107.

This message was generated and sent by the IETF Meeting Session Request Too= l.


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--0000000000006dd854059a680fd8-- From nobody Mon Dec 23 16:44:28 2019 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 EEA54120052 for ; Mon, 23 Dec 2019 16:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZGLAwyq33pI4 for ; Mon, 23 Dec 2019 16:44:24 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 9C6FB120020 for ; Mon, 23 Dec 2019 16:44:23 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id m26so16918121ljc.13 for ; Mon, 23 Dec 2019 16:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GWzJZwbc2EDgk/ctayPZie1mbKvm5EjOQsBSxM9EKbA=; b=jNhjVHERl6+Q+mzKGk8I94GdIYAAxtD9OLKYVoD84nfjBQeh8zdLcX9DX/efky6eM3 DvuP8SF5BQ6jvryUrDHT0poKyNB32te9o8l+IBU9yQy7Dvnk8raLkzinHRhwpGPjt6VM Gqe4Fn/9A1mZExt3MJVXo9Zyd4DCXDiTpbZSuiLc482q4DS6FptrACl8YzhAhOFl9NJ9 0az+J5OrLSWt52Xilxf1oFS+rq8kaS3jjobLm9PW4k5TaPjIWNFX1mGWBQMi92rgqc6B /4+IinotP7vXCLaXQ2PGn0V/C8W4LxIJAoNgoe19NFo8G9rDqkNmlgj2YR1/kQLQjLVm UT3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GWzJZwbc2EDgk/ctayPZie1mbKvm5EjOQsBSxM9EKbA=; b=QqSoP0CvXWmK7wS6e6SnCvQzoP9cT+joDPG9/V+f9fhJCaewj7GCeI54s/9WPI326O OJaiH24gCDS6hTWnZZzPorrr08iSJZ453dUPwqHMb/aY2XU/r41DZXeNRaVaaqUQx8kl r8UfKNbTV+TLK2Qe1+98C4Gr2Ewm5+WLmP8my3Er0HmhQ8N83oXTd+XW8+vribW2AxzW SXMr+SzT7hWcoGS4nHD6JCc8vsEiEcKP/1c4f3Pfonxg3z7yvuDY61ChYu3AiEEPnqtE zgiPDfqlNnA3GH0XWAuQGlIHwaz8zPKB50v+gnwKcrNuPHlYcS3w5jdQbacy/Mywrabs XPFw== X-Gm-Message-State: APjAAAWhznPqI87g4V1FlkqEoSkjiMP6nHREYzbJmMWkPpUR8rRPMPfD W9PwP2ueLF/4GIF4Cnf1hYA2H2GJMz2aAHpSEdmmb4FxC+g= X-Google-Smtp-Source: APXvYqxRvRb3d9zVNUY4IQhzGJW0gre77oMkdDHsifQuBKfJMiLGsjU9u8zwfpzJXH62ojg1fwz6AExl3bMJCxv1niA= X-Received: by 2002:a2e:a48a:: with SMTP id h10mr19465199lji.254.1577148261791; Mon, 23 Dec 2019 16:44:21 -0800 (PST) MIME-Version: 1.0 References: <157703118283.11722.3554923121540859266.idtracker@ietfa.amsl.com> In-Reply-To: From: Dick Hardt Date: Mon, 23 Dec 2019 16:44:10 -0800 Message-ID: To: Marius Scurtescu Cc: SecEvent Content-Type: multipart/alternative; boundary="000000000000e6fc50059a687147" Archived-At: Subject: Re: [Id-event] Fwd: secevent - Not having a session at IETF 107 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 24 Dec 2019 00:44:26 -0000 --000000000000e6fc50059a687147 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is no new work going on. There has been no discussion on the mail list. Ergo -> there is no reason to have a session. We had no session at IETF 107 either. =E1=90=A7 On Mon, Dec 23, 2019 at 4:17 PM Marius Scurtescu wrote: > Hi, > > Was there a discussion and decision to not have a session at IETF 107? > What is the rationale? > > Thanks, > Marius > > > ---------- Forwarded message --------- > From: IETF Meeting Session Request Tool > Date: Sun, Dec 22, 2019 at 8:13 AM > Subject: [Id-event] secevent - Not having a session at IETF 107 > To: > Cc: , , < > id-event@ietf.org>, > > > > > > Yaron Sheffer, a chair of the secevent working group, indicated that the > secevent working group does not plan to hold a session at IETF 107. > > This message was generated and sent by the IETF Meeting Session Request > Tool. > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --000000000000e6fc50059a687147 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is no new work going on. There has been no discussio= n on the mail list. Ergo -> there is no reason to have a session.=C2=A0<= div>
We had no session at IETF 107 either.=C2=A0
3D""=E1=90=A7

On Mon, Dec 23, 2019 at 4:17 PM Marius Scurte= scu <marius.scurtescu=3D40coinbase.com@dmarc.ietf.org> wrote:
Hi,

Was there a discussion and decision to not have a session at IETF 107? Wha= t is the rationale?

Thanks,
Marius
<= br>
---= ------- Forwarded message ---------
From: IETF Meeting Session Request Tool <sess= ion-request@ietf.org>
Date: Sun, Dec 22, 2019 at 8:13 AMSubject: [Id-event] secevent - Not having a session at IETF 107
To: &= lt;session-re= quest@ietf.org>
Cc: <secevent-chairs@ietf.org>, <yaronf.ietf@gmail.com>,= <id-event@ietf.= org>, <kaduk= @mit.edu>




Yaron Sheffer, a chair of the secevent working group, indicated that the se= cevent working group does not plan to hold a session at IETF 107.

This message was generated and sent by the IETF Meeting Session Request Too= l.


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