From nobody Thu Oct 6 07:56:48 2016 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 A9D5E1296A8 for ; Thu, 6 Oct 2016 07:56:46 -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, FREEMAIL_FROM=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=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 xzfhbRoubrsN for ; Thu, 6 Oct 2016 07:56:42 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 350331296AD for ; Thu, 6 Oct 2016 07:56:42 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id 192so20112368vkl.2 for ; Thu, 06 Oct 2016 07:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xY6scnF9APG6IzekVZkfG2fHkBNYlTA3QQaGDTaKpuc=; b=LPEbxUBmVvsevcPk5TeF/I5AkLQz67nLYA72ekGdEWCvCFQQziyHwZrUQ8JD5Xr3rV 24scBFWPb6hjUFNcu5e0u9ParzMefFRraZxVaDASTxJRevT/OXHsCfM65zT4CObGUvnH FX9ely6WhThJkRGTK/QqAoAoV4xevwzzXLmva+l3axNMir3/mj6ug/YI0upAqw+aC/lL yE/0bwJmd3DCseQ+C9da+v3/uPggbq5grxGt58Tmsp2C1/v+PR9pXdd9mK4swqCxrVCD dFwJsKU6WZ0jGN27Z7TvWL6GqcEfTRn5dUnluqpExved75d5xVC6xcS5/D7WxX3v2sLq pwiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xY6scnF9APG6IzekVZkfG2fHkBNYlTA3QQaGDTaKpuc=; b=KqaaWTL2juFXTxYy5hOUd3IHxWLyUlPlEzInzMX0ra8onGlEHLfvNC/rh12mFpKLdP bUrxb1ES5gFvhw6Z/wCMKUYpyJ/niZc+4LYOsSgPn2e3STne0TsgWm01nN8AuttL99Vu NhCEC1jWRYcxJBF/AUUnvn1qxSwddWIHSUWxwlURY4f8eQFVU2t5m6BcdmGHqF53TL/h /7zBL61bd8jT0H3MHb6MZyWcA4C1todqVgaLemkbsE6bGl5Wd2uNIELnoxIEv+zspPw8 16/HuzS13zNZuA/xsij6TDt5TVSdDWlx0+NJNDPAQDzvfUMy3EOAAa5+9qTps8gagy4M 14dw== X-Gm-Message-State: AA6/9RkVUL+KaSYV0zTvdAXIzm3O6ny9VFu6QBBmTIeR73Jzdam1SiYABIjxwxZLM23GbmiS+ergQwH8dNmocQ== X-Received: by 10.31.168.145 with SMTP id r139mr11415459vke.124.1475765801222; Thu, 06 Oct 2016 07:56:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 6 Oct 2016 07:56:40 -0700 (PDT) In-Reply-To: References: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> <1474715073.2319843.735650465.3C69F11E@webmail.messagingengine.com> <1474718187.2329006.735672633.371888A0@webmail.messagingengine.com> From: Kathleen Moriarty Date: Thu, 6 Oct 2016 10:56:40 -0400 Message-ID: To: "Morteza Ansari (moransar)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: William Denniss , Mike Jones , Alexey Melnikov , "id-event@ietf.org" , "Phil Hunt \(IDM\)" Subject: Re: [Id-event] Chartering of Security Events WG X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 14:56:46 -0000 To confirm, do you plan to meet in Seoul and if so, how much time is needed= ? Thanks, Kathleen On Mon, Sep 26, 2016 at 9:20 PM, Kathleen Moriarty wrote: > Hi Morteza, > > On Mon, Sep 26, 2016 at 4:21 PM, Morteza Ansari (moransar) > wrote: >> Hi Kathleen, >> >> Great idea and hopefully it will get us some fresh blood in the WG for >> contribution and reviews. I can=C2=B9t think of anything else to include= beyond >> what you suggested. We can do a complete review of the drafts in the wor= ks >> in Seoul to catch up any new folks interested in participating (I won=C2= =B9t be >> there in person, but will join the meeting remotely). >> >> I assume you or Alexey will send the note, but if you want one of us to >> send it just let us know. > > I don't mind sending it, but will wait to chat with Alexey first so we > are all coordinated. Hopefully it will bring some new interest. > > Thanks, > Kathleen > >> >> >> Cheers, >> Morteza >> >> On 9/26/16, 6:44 AM, "Kathleen Moriarty" >> wrote: >> >>>Hi, >>> >>>It would be good to get a mail message to the SAAG list to announce >>>this, that it crosses areas and that I'll be the AD along with the >>>charter and other information. Is there any other information that >>>should be in such an announcement? >>> >>>Thanks, >>>Kathleen >>> >>>On Sat, Sep 24, 2016 at 11:56 AM, Phil Hunt (IDM) >>>wrote: >>>> Alexy, >>>> >>>> Thanks for helping this forwards. >>>> >>>> The name is fine. >>>> >>>> Phil >>>> >>>> On Sep 24, 2016, at 4:56 AM, Alexey Melnikov >>>>wrote: >>>> >>>> This also reminded me: how much time does this group want to request f= or >>>> face-to-face meeting in Seoul? >>>> >>>> On Sat, Sep 24, 2016, at 12:27 PM, Morteza Ansari (moransar) wrote: >>>> >>>> This is great, thanks for helping speed up the process! Name is a name= , >>>>so >>>> no comment on naming. >>>> >>>> >>>> >>>> Cheers, >>>> Morteza >>>> >>>> On Sep 24, 2016, at 4:04 AM, Alexey Melnikov >>>>wrote: >>>> >>>> Hi, >>>> Just to let everyone know: I started chartering of the WG. The WG will >>>>be in >>>> the Security Area (it was a borderline between ART and Security) and >>>>your >>>> responsible AD is going to be Kathleen Moriarty. >>>> >>>> Best Regards, >>>> Alexey >>>> >>>> P.S. I picked "SECEVENT" as the short WG name, but if you have better >>>> suggestions, please let me know. >>>> >>>> On Wed, Sep 7, 2016, at 01:04 AM, William Denniss wrote: >>>> >>>> Thank you Mike for revising the charter. >>>> >>>> I support it, and hope we can form a WG with this charter to continue >>>>our >>>> work. >>>> >>>> On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones >>>> wrote: >>>> >>>> An updated and simplified charter is attached. This draft has been >>>>reviewed >>>> by Phil Hunt, William Denniss, Marius Scurtescu. >>>> >>>> >>>> >>>> Input from Alexey Melnikov is that we should probably charter a workin= g >>>> group, rather than try to go the AD-sponsored route. Therefore, pleas= e >>>> review this draft charter and let us know if you think it=C2=B9s ready= to go. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -- Mike >>>> >>>> >>>> >>>> >>>> From: Sarah Squire [mailto:sarah@engageidentity.com] >>>> Sent: Thursday, July 14, 2016 10:59 PM >>>> To: Phil Hunt (IDM) >>>> Cc: Mike Jones ; Alan Karp >>>> ; Vivek Biswas ; Morteza >>>>Ansari >>>> (moransar) ; id-event@ietf.org >>>> >>>> >>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>> >>>> >>>> >>>> >>>> Just submitting my two cents in writing before we hopefully have a >>>>chance to >>>> meet about this next week... >>>> >>>> >>>> >>>> Looking at this charter from the perspective of the OIDF HEART working >>>> group, I think it's going down a good path. In terms of the data forma= t, >>>> this is less structured than what I was envisioning, but we could >>>>easily do >>>> a healthcare-specific profile of whatever data format comes out in the >>>>end, >>>> so it's better to be too broad than too narrow as far as our interests >>>>are >>>> concerned. >>>> >>>> >>>> >>>> The transport layer however, has some added complexity. In our context= , >>>> we're shooting for interoperability, so we'd prefer something >>>>constrained. I >>>> appreciate Mike's input that these are application layer decisions. >>>>However, >>>> if we're talking about cloud provider-to-cloud provider communication, >>>>that >>>> certainly is facilitated by a well-defined transport layer. Again, we'= re >>>> willing to profile whatever the group comes up with for our own ends, >>>>but I >>>> don't really see the benefit of having a loosely defined transport >>>>layer - >>>> it just seems like more work for all the implementers to actually agre= e >>>>on >>>> endpoints on a case-by-case basis. >>>> >>>> >>>> >>>> Looking forward to discussing further in Berlin! >>>> >>>> >>>> >>>> Sarah >>>> >>>> >>>> Sarah Squire >>>> >>>> Engage Identity >>>> >>>> http://engageidentity.com >>>> >>>> >>>> >>>> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) >>>> wrote: >>>> >>>> We also set things up so even a domain specific event can be extended. >>>> >>>> >>>> >>>> Eg on a password reset event, so event publishers may want to add >>>>security >>>> domain specific attributes. The spec lets them do that while avoiding >>>> interop issues. >>>> >>>> >>>> >>>> I believe in the spec we had the example of an account reset and the >>>> publisher adds reset count as an extension. >>>> >>>> Phil >>>> >>>> >>>> >>>> On May 7, 2016, at 13:31, Mike Jones >>>>wrote: >>>> >>>> >>>> Indeed, that=C2=B9s why there=C2=B9s a claims registry =C2=AD so commo= n claims can be >>>> defined once and then reused. >>>> >>>> >>>> >>>> >>>> From: Vivek Biswas >>>> Sent: Saturday, May 7, 2016 1:24 PM >>>> To: Mike Jones >>>> Cc: Alan Karp; Morteza Ansari (moransar); id-event@ietf.org >>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>> >>>> >>>> >>>> >>>> Yes, I agree that the claims can be application specific, however ther= e >>>>is a >>>> possibility to define claims which are domain specific. Thereby claims >>>> generated in one application could be understood by another applicati= on >>>> within the same domain. >>>> >>>> >>>> >>>> With microservices based architecture getting lot of attention, if two >>>> different micro services defining different claims for the same claim, >>>>it >>>> can create confusion. >>>> >>>> >>>> >>>> Nevertheless this well defined claims for a particular domain can be a= n >>>> extension to the core specification. >>>> >>>> >>>> >>>> -Vivek Biswas >>>> >>>> >>>> Consulting Member, Oracle >>>> >>>> Sent from my iPhone >>>> >>>> >>>> >>>> >>>> On May 7, 2016, at 1:04 PM, Mike Jones >>>>wrote: >>>> >>>> >>>> Thanks Alan, >>>> >>>> >>>> >>>> Interoperability will be on a per-application basis, just like JWT >>>> interoperability. The claims needed in an identity event are >>>> application-specific, just like claims are for JWTs. This is the same >>>> standards posture and JWTs are a huge success =C2=AD including for >>>> interoperability, even if I do say so myself. >>>> >>>> >>>> >>>> Best wishes, >>>> >>>> -- Mike >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: Alan Karp >>>> Sent: Saturday, May 7, 2016 10:23 AM >>>> To: Mike Jones >>>> Cc: Morteza Ansari (moransar); id-event@ietf.org >>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>> >>>> >>>> >>>> >>>> As one who proposed doing more, I believe that your position is valid. >>>>My >>>> only question is whether or not that will be enough for >>>>interoperability. >>>> >>>> >>>> >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> >>>> >>>> On Thu, May 5, 2016 at 10:00 PM, Mike Jones >>>> >>>> wrote: >>>> >>>> Thanks guys, for writing the initial charter text. Reading it now, I = am >>>> extremely worried by the scope creep evident in the proposal. >>>> >>>> >>>> >>>> I strongly support a working group to define an ID Events data format. >>>>I >>>> just as strongly believe that specific event delivery mechanisms will >>>> necessarily be application-specific and therefore MUST be explicitly b= e >>>> stated as being out of scope in the working group charter. Attempting >>>>to >>>> specify a particular event delivery mechanism will take something that >>>>could >>>> be simple and quick to approve and bog it down in necessarily >>>> application-specific debates. >>>> >>>> >>>> >>>> Should event delivery be reliable? That=C2=B9s an application-specifi= c >>>>decision. >>>> >>>> Should events be idempotent? That=C2=B9s an application-specific deci= sion. >>>> >>>> Should events be unicast, multicast, or broadcast? That=C2=B9s an >>>> application-specific decision. >>>> >>>> Should events have categories with category-specific subscriptions? >>>>That=C2=B9s >>>> an application-specific decision. >>>> >>>> Should only one party at a time be able to register for delivery of >>>>events >>>> or should multiple parties be able to request delivery? That=C2=B9s a= n >>>> application-specific decision. >>>> >>>> I could continue with this list, but I think you all get the point=C5= =A0 >>>> >>>> >>>> >>>> If we start debating application-specific event delivery mechanisms, >>>>we=C2=B9ll >>>> please almost no one, since nearly all applications have different eve= nt >>>> delivery requirements. We MUST explicitly rule all delivery mechanism= s >>>>as >>>> being out of scope. >>>> >>>> >>>> >>>> If we define only a data format, we can quickly produce a very useful >>>> specification. If we don=C2=B9t, we=C2=B9ll get bogged down in the mu= d of >>>>debating >>>> which applications we=C2=B9re catering to and which we aren=C2=B9t =C2= =AD an exercise >>>>of >>>> picking favorites and limiting applicability of the specification. >>>>That way >>>> is a slow, painful descent into standards quicksand =C2=AD something w= e must >>>> avoid. Having a standard ID events representation is far too importan= t >>>>to >>>> tie to a particular limited event delivery mechanism. >>>> >>>> >>>> >>>> Sincerely, >>>> >>>> -- Mike >>>> >>>> >>>> >>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Ka= rp >>>> Sent: Thursday, May 5, 2016 9:43 PM >>>> To: Morteza Ansari (moransar) >>>> Cc: id-event@ietf.org >>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>> >>>> >>>> >>>> I don't see anything about access control for publishing events and >>>> subscribing to them. I also think the spec should allow filters on >>>> subscriptions. >>>> >>>> >>>> >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> >>>> >>>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) >>>> wrote: >>>> >>>> Hi folks, >>>> >>>> >>>> >>>> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and >>>>put >>>> together the attached as a straw man charter proposal to start the >>>> discussion. Please send your comments and suggestions for any changes = or >>>> propose a new one if you think its necessary. >>>> >>>> >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Morteza >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>>-- >>> >>>Best regards, >>>Kathleen >> > > > > -- > > Best regards, > Kathleen --=20 Best regards, Kathleen From nobody Thu Oct 6 08:01:20 2016 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 5974F1296AB for ; Thu, 6 Oct 2016 08:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=PmE+VAuM; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=QvcWAwx4 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 0AzKXJuuzhI2 for ; Thu, 6 Oct 2016 08:01:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E04F1296B1 for ; Thu, 6 Oct 2016 08:01:11 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E074720A3C; Thu, 6 Oct 2016 11:01:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 06 Oct 2016 11:01:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=2f3HbiLrgqjgvOYdsrzkbwVLCBw=; b=PmE+VA uMidfgbkZfS6Moyhms1by8atpCDI/WjJ+ESmaxmqISbbOkL3q9hBmNF1DFTr5ddc eY6ZZjeI8f+RvH2PmpNjorbmj6Ole/WQOiklMCVAuFZN7GcSH8IRrNK4RGoAzNKZ GEqI9IniX6J+yQhabBv1Y0vQWbA4Me2V8g8JU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=2f3HbiLrgqjgvOY dsrzkbwVLCBw=; b=QvcWAwx45drVPWEfvxE4DOb0MlrKjfonHi/KhaDUF3BFzcr Ee0km9f8282sumzHV8SMvD6bRTrQa1gw7E5lzvAKCLDK+9sVgI61t+h1+N1SFN/1 +2LQtErrgE5iNouUlI/LZGpUszxshak2NdOxNRwOhpENxdSgjQKh9rP30DZM= X-Sasl-enc: nZoVV3BWrVuQcWXCuDlfSY27vHGp1Jg2CjjhakdnSH16 1475766069 Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 33C76CC07E; Thu, 6 Oct 2016 11:01:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 6 Oct 2016 16:04:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DBF45B9-49C0-4846-8D44-44128AEFFAC8@fastmail.fm> References: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> <1474715073.2319843.735650465.3C69F11E@webmail.messagingengine.com> <1474718187.2329006.735672633.371888A0@webmail.messagingengine.com> To: "Phil Hunt (IDM)" , "Morteza Ansari (moransar)" Archived-At: Cc: William Denniss , Kathleen Moriarty , Mike Jones , "id-event@ietf.org" Subject: Re: [Id-event] Chartering of Security Events WG X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 15:01:18 -0000 > On 6 Oct 2016, at 15:56, Kathleen Moriarty wrote: >=20 > To confirm, do you plan to meet in Seoul and if so, how much time is neede= d? Also, if people can tell Kathleen who volunteered to chair it, that would be= great. > Thanks, > Kathleen >=20 > On Mon, Sep 26, 2016 at 9:20 PM, Kathleen Moriarty > wrote: >> Hi Morteza, >>=20 >> On Mon, Sep 26, 2016 at 4:21 PM, Morteza Ansari (moransar) >> wrote: >>> Hi Kathleen, >>>=20 >>> Great idea and hopefully it will get us some fresh blood in the WG for >>> contribution and reviews. I can=C2=B9t think of anything else to include= beyond >>> what you suggested. We can do a complete review of the drafts in the wor= ks >>> in Seoul to catch up any new folks interested in participating (I won=C2= =B9t be >>> there in person, but will join the meeting remotely). >>>=20 >>> I assume you or Alexey will send the note, but if you want one of us to >>> send it just let us know. >>=20 >> I don't mind sending it, but will wait to chat with Alexey first so we >> are all coordinated. Hopefully it will bring some new interest. >>=20 >> Thanks, >> Kathleen >>=20 >>>=20 >>>=20 >>> Cheers, >>> Morteza >>>=20 >>> On 9/26/16, 6:44 AM, "Kathleen Moriarty" >>> wrote: >>>=20 >>>> Hi, >>>>=20 >>>> It would be good to get a mail message to the SAAG list to announce >>>> this, that it crosses areas and that I'll be the AD along with the >>>> charter and other information. Is there any other information that >>>> should be in such an announcement? >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>> On Sat, Sep 24, 2016 at 11:56 AM, Phil Hunt (IDM) >>>> wrote: >>>>> Alexy, >>>>>=20 >>>>> Thanks for helping this forwards. >>>>>=20 >>>>> The name is fine. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Sep 24, 2016, at 4:56 AM, Alexey Melnikov >>>>> wrote: >>>>>=20 >>>>> This also reminded me: how much time does this group want to request f= or >>>>> face-to-face meeting in Seoul? >>>>>=20 >>>>> On Sat, Sep 24, 2016, at 12:27 PM, Morteza Ansari (moransar) wrote: >>>>>=20 >>>>> This is great, thanks for helping speed up the process! Name is a name= , >>>>> so >>>>> no comment on naming. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Morteza >>>>>=20 >>>>> On Sep 24, 2016, at 4:04 AM, Alexey Melnikov >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>> Just to let everyone know: I started chartering of the WG. The WG will= >>>>> be in >>>>> the Security Area (it was a borderline between ART and Security) and >>>>> your >>>>> responsible AD is going to be Kathleen Moriarty. >>>>>=20 >>>>> Best Regards, >>>>> Alexey >>>>>=20 >>>>> P.S. I picked "SECEVENT" as the short WG name, but if you have better >>>>> suggestions, please let me know. >>>>>=20 >>>>> On Wed, Sep 7, 2016, at 01:04 AM, William Denniss wrote: >>>>>=20 >>>>> Thank you Mike for revising the charter. >>>>>=20 >>>>> I support it, and hope we can form a WG with this charter to continue >>>>> our >>>>> work. >>>>>=20 >>>>> On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones >>>>> wrote: >>>>>=20 >>>>> An updated and simplified charter is attached. This draft has been >>>>> reviewed >>>>> by Phil Hunt, William Denniss, Marius Scurtescu. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Input from Alexey Melnikov is that we should probably charter a workin= g >>>>> group, rather than try to go the AD-sponsored route. Therefore, pleas= e >>>>> review this draft charter and let us know if you think it=C2=B9s ready= to go. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Sarah Squire [mailto:sarah@engageidentity.com] >>>>> Sent: Thursday, July 14, 2016 10:59 PM >>>>> To: Phil Hunt (IDM) >>>>> Cc: Mike Jones ; Alan Karp >>>>> ; Vivek Biswas ; Morteza >>>>> Ansari >>>>> (moransar) ; id-event@ietf.org >>>>>=20 >>>>>=20 >>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Just submitting my two cents in writing before we hopefully have a >>>>> chance to >>>>> meet about this next week... >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Looking at this charter from the perspective of the OIDF HEART working= >>>>> group, I think it's going down a good path. In terms of the data forma= t, >>>>> this is less structured than what I was envisioning, but we could >>>>> easily do >>>>> a healthcare-specific profile of whatever data format comes out in the= >>>>> end, >>>>> so it's better to be too broad than too narrow as far as our interests= >>>>> are >>>>> concerned. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The transport layer however, has some added complexity. In our context= , >>>>> we're shooting for interoperability, so we'd prefer something >>>>> constrained. I >>>>> appreciate Mike's input that these are application layer decisions. >>>>> However, >>>>> if we're talking about cloud provider-to-cloud provider communication,= >>>>> that >>>>> certainly is facilitated by a well-defined transport layer. Again, we'= re >>>>> willing to profile whatever the group comes up with for our own ends, >>>>> but I >>>>> don't really see the benefit of having a loosely defined transport >>>>> layer - >>>>> it just seems like more work for all the implementers to actually agre= e >>>>> on >>>>> endpoints on a case-by-case basis. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Looking forward to discussing further in Berlin! >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sarah >>>>>=20 >>>>>=20 >>>>> Sarah Squire >>>>>=20 >>>>> Engage Identity >>>>>=20 >>>>> http://engageidentity.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) = >>>>> wrote: >>>>>=20 >>>>> We also set things up so even a domain specific event can be extended.= >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Eg on a password reset event, so event publishers may want to add >>>>> security >>>>> domain specific attributes. The spec lets them do that while avoiding >>>>> interop issues. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I believe in the spec we had the example of an account reset and the >>>>> publisher adds reset count as an extension. >>>>>=20 >>>>> Phil >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On May 7, 2016, at 13:31, Mike Jones >>>>> wrote: >>>>>=20 >>>>>=20 >>>>> Indeed, that=C2=B9s why there=C2=B9s a claims registry =C2=AD so commo= n claims can be >>>>> defined once and then reused. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Vivek Biswas >>>>> Sent: Saturday, May 7, 2016 1:24 PM >>>>> To: Mike Jones >>>>> Cc: Alan Karp; Morteza Ansari (moransar); id-event@ietf.org >>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Yes, I agree that the claims can be application specific, however ther= e >>>>> is a >>>>> possibility to define claims which are domain specific. Thereby claims= >>>>> generated in one application could be understood by another applicati= on >>>>> within the same domain. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> With microservices based architecture getting lot of attention, if two= >>>>> different micro services defining different claims for the same claim,= >>>>> it >>>>> can create confusion. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Nevertheless this well defined claims for a particular domain can be a= n >>>>> extension to the core specification. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -Vivek Biswas >>>>>=20 >>>>>=20 >>>>> Consulting Member, Oracle >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On May 7, 2016, at 1:04 PM, Mike Jones >>>>> wrote: >>>>>=20 >>>>>=20 >>>>> Thanks Alan, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Interoperability will be on a per-application basis, just like JWT >>>>> interoperability. The claims needed in an identity event are >>>>> application-specific, just like claims are for JWTs. This is the same= >>>>> standards posture and JWTs are a huge success =C2=AD including for >>>>> interoperability, even if I do say so myself. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Best wishes, >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Alan Karp >>>>> Sent: Saturday, May 7, 2016 10:23 AM >>>>> To: Mike Jones >>>>> Cc: Morteza Ansari (moransar); id-event@ietf.org >>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> As one who proposed doing more, I believe that your position is valid.= >>>>> My >>>>> only question is whether or not that will be enough for >>>>> interoperability. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, May 5, 2016 at 10:00 PM, Mike Jones >>>>> >>>>> wrote: >>>>>=20 >>>>> Thanks guys, for writing the initial charter text. Reading it now, I a= m >>>>> extremely worried by the scope creep evident in the proposal. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I strongly support a working group to define an ID Events data format.= >>>>> I >>>>> just as strongly believe that specific event delivery mechanisms will >>>>> necessarily be application-specific and therefore MUST be explicitly b= e >>>>> stated as being out of scope in the working group charter. Attempting= >>>>> to >>>>> specify a particular event delivery mechanism will take something that= >>>>> could >>>>> be simple and quick to approve and bog it down in necessarily >>>>> application-specific debates. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Should event delivery be reliable? That=C2=B9s an application-specifi= c >>>>> decision. >>>>>=20 >>>>> Should events be idempotent? That=C2=B9s an application-specific deci= sion. >>>>>=20 >>>>> Should events be unicast, multicast, or broadcast? That=C2=B9s an >>>>> application-specific decision. >>>>>=20 >>>>> Should events have categories with category-specific subscriptions? >>>>> That=C2=B9s >>>>> an application-specific decision. >>>>>=20 >>>>> Should only one party at a time be able to register for delivery of >>>>> events >>>>> or should multiple parties be able to request delivery? That=C2=B9s a= n >>>>> application-specific decision. >>>>>=20 >>>>> I could continue with this list, but I think you all get the point=C5=A0= >>>>>=20 >>>>>=20 >>>>>=20 >>>>> If we start debating application-specific event delivery mechanisms, >>>>> we=C2=B9ll >>>>> please almost no one, since nearly all applications have different eve= nt >>>>> delivery requirements. We MUST explicitly rule all delivery mechanism= s >>>>> as >>>>> being out of scope. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> If we define only a data format, we can quickly produce a very useful >>>>> specification. If we don=C2=B9t, we=C2=B9ll get bogged down in the mu= d of >>>>> debating >>>>> which applications we=C2=B9re catering to and which we aren=C2=B9t =C2= =AD an exercise >>>>> of >>>>> picking favorites and limiting applicability of the specification. >>>>> That way >>>>> is a slow, painful descent into standards quicksand =C2=AD something w= e must >>>>> avoid. Having a standard ID events representation is far too importan= t >>>>> to >>>>> tie to a particular limited event delivery mechanism. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sincerely, >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan Ka= rp >>>>> Sent: Thursday, May 5, 2016 9:43 PM >>>>> To: Morteza Ansari (moransar) >>>>> Cc: id-event@ietf.org >>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I don't see anything about access control for publishing events and >>>>> subscribing to them. I also think the spec should allow filters on >>>>> subscriptions. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------------- >>>>> Alan Karp >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) >>>>> wrote: >>>>>=20 >>>>> Hi folks, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and >>>>> put >>>>> together the attached as a straw man charter proposal to start the >>>>> discussion. Please send your comments and suggestions for any changes o= r >>>>> propose a new one if you think its necessary. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Morteza >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Thu Oct 6 08:08:49 2016 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 212A2129688 for ; Thu, 6 Oct 2016 08:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.198 X-Spam-Level: X-Spam-Status: No, score=-7.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 26trgvTtESLe for ; Thu, 6 Oct 2016 08:08:43 -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 B25591296B6 for ; Thu, 6 Oct 2016 08:08:36 -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 u96F8S4d029230 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Oct 2016 15:08:29 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u96F8SQK030096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Oct 2016 15:08:28 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u96F8Sq8022028; Thu, 6 Oct 2016 15:08:28 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Oct 2016 08:08:27 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A456) In-Reply-To: <8DBF45B9-49C0-4846-8D44-44128AEFFAC8@fastmail.fm> Date: Thu, 6 Oct 2016 08:08:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> <1474715073.2319843.735650465.3C69F11E@webmail.messagingengine.com> <1474718187.2329006.735672633.371888A0@webmail.messagingengine.com> <8DBF45B9-49C0-4846-8D44-44128AEFFAC8@fastmail.fm> To: Alexey Melnikov X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: William Denniss , Kathleen Moriarty , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" , Mike Jones Subject: Re: [Id-event] Chartering of Security Events WG X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 15:08:48 -0000 Kathleen, It would be good if we can meet for an hour for this first session.=20 Phil > On Oct 6, 2016, at 8:04 AM, Alexey Melnikov wrote= : >=20 >=20 >> On 6 Oct 2016, at 15:56, Kathleen Moriarty wrote: >>=20 >> To confirm, do you plan to meet in Seoul and if so, how much time is need= ed? >=20 > Also, if people can tell Kathleen who volunteered to chair it, that would b= e great. >=20 >> Thanks, >> Kathleen >>=20 >> On Mon, Sep 26, 2016 at 9:20 PM, Kathleen Moriarty >> wrote: >>> Hi Morteza, >>>=20 >>> On Mon, Sep 26, 2016 at 4:21 PM, Morteza Ansari (moransar) >>> wrote: >>>> Hi Kathleen, >>>>=20 >>>> Great idea and hopefully it will get us some fresh blood in the WG for >>>> contribution and reviews. I can=C2=B9t think of anything else to includ= e beyond >>>> what you suggested. We can do a complete review of the drafts in the wo= rks >>>> in Seoul to catch up any new folks interested in participating (I won=C2= =B9t be >>>> there in person, but will join the meeting remotely). >>>>=20 >>>> I assume you or Alexey will send the note, but if you want one of us to= >>>> send it just let us know. >>>=20 >>> I don't mind sending it, but will wait to chat with Alexey first so we >>> are all coordinated. Hopefully it will bring some new interest. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>> Morteza >>>>=20 >>>> On 9/26/16, 6:44 AM, "Kathleen Moriarty" >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> It would be good to get a mail message to the SAAG list to announce >>>>> this, that it crosses areas and that I'll be the AD along with the >>>>> charter and other information. Is there any other information that >>>>> should be in such an announcement? >>>>>=20 >>>>> Thanks, >>>>> Kathleen >>>>>=20 >>>>> On Sat, Sep 24, 2016 at 11:56 AM, Phil Hunt (IDM) >>>>> wrote: >>>>>> Alexy, >>>>>>=20 >>>>>> Thanks for helping this forwards. >>>>>>=20 >>>>>> The name is fine. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Sep 24, 2016, at 4:56 AM, Alexey Melnikov = >>>>>> wrote: >>>>>>=20 >>>>>> This also reminded me: how much time does this group want to request f= or >>>>>> face-to-face meeting in Seoul? >>>>>>=20 >>>>>> On Sat, Sep 24, 2016, at 12:27 PM, Morteza Ansari (moransar) wrote: >>>>>>=20 >>>>>> This is great, thanks for helping speed up the process! Name is a nam= e, >>>>>> so >>>>>> no comment on naming. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>> Morteza >>>>>>=20 >>>>>> On Sep 24, 2016, at 4:04 AM, Alexey Melnikov = >>>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>> Just to let everyone know: I started chartering of the WG. The WG wil= l >>>>>> be in >>>>>> the Security Area (it was a borderline between ART and Security) and >>>>>> your >>>>>> responsible AD is going to be Kathleen Moriarty. >>>>>>=20 >>>>>> Best Regards, >>>>>> Alexey >>>>>>=20 >>>>>> P.S. I picked "SECEVENT" as the short WG name, but if you have better= >>>>>> suggestions, please let me know. >>>>>>=20 >>>>>> On Wed, Sep 7, 2016, at 01:04 AM, William Denniss wrote: >>>>>>=20 >>>>>> Thank you Mike for revising the charter. >>>>>>=20 >>>>>> I support it, and hope we can form a WG with this charter to continue= >>>>>> our >>>>>> work. >>>>>>=20 >>>>>> On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones >>>>>> wrote: >>>>>>=20 >>>>>> An updated and simplified charter is attached. This draft has been >>>>>> reviewed >>>>>> by Phil Hunt, William Denniss, Marius Scurtescu. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Input from Alexey Melnikov is that we should probably charter a worki= ng >>>>>> group, rather than try to go the AD-sponsored route. Therefore, plea= se >>>>>> review this draft charter and let us know if you think it=C2=B9s read= y to go. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Sarah Squire [mailto:sarah@engageidentity.com] >>>>>> Sent: Thursday, July 14, 2016 10:59 PM >>>>>> To: Phil Hunt (IDM) >>>>>> Cc: Mike Jones ; Alan Karp >>>>>> ; Vivek Biswas ; Morteza= >>>>>> Ansari >>>>>> (moransar) ; id-event@ietf.org >>>>>>=20 >>>>>>=20 >>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Just submitting my two cents in writing before we hopefully have a >>>>>> chance to >>>>>> meet about this next week... >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Looking at this charter from the perspective of the OIDF HEART workin= g >>>>>> group, I think it's going down a good path. In terms of the data form= at, >>>>>> this is less structured than what I was envisioning, but we could >>>>>> easily do >>>>>> a healthcare-specific profile of whatever data format comes out in th= e >>>>>> end, >>>>>> so it's better to be too broad than too narrow as far as our interest= s >>>>>> are >>>>>> concerned. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The transport layer however, has some added complexity. In our contex= t, >>>>>> we're shooting for interoperability, so we'd prefer something >>>>>> constrained. I >>>>>> appreciate Mike's input that these are application layer decisions. >>>>>> However, >>>>>> if we're talking about cloud provider-to-cloud provider communication= , >>>>>> that >>>>>> certainly is facilitated by a well-defined transport layer. Again, we= 're >>>>>> willing to profile whatever the group comes up with for our own ends,= >>>>>> but I >>>>>> don't really see the benefit of having a loosely defined transport >>>>>> layer - >>>>>> it just seems like more work for all the implementers to actually agr= ee >>>>>> on >>>>>> endpoints on a case-by-case basis. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Looking forward to discussing further in Berlin! >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Sarah >>>>>>=20 >>>>>>=20 >>>>>> Sarah Squire >>>>>>=20 >>>>>> Engage Identity >>>>>>=20 >>>>>> http://engageidentity.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) >>>>>> wrote: >>>>>>=20 >>>>>> We also set things up so even a domain specific event can be extended= . >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Eg on a password reset event, so event publishers may want to add >>>>>> security >>>>>> domain specific attributes. The spec lets them do that while avoiding= >>>>>> interop issues. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I believe in the spec we had the example of an account reset and the >>>>>> publisher adds reset count as an extension. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On May 7, 2016, at 13:31, Mike Jones >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>> Indeed, that=C2=B9s why there=C2=B9s a claims registry =C2=AD so comm= on claims can be >>>>>> defined once and then reused. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Vivek Biswas >>>>>> Sent: Saturday, May 7, 2016 1:24 PM >>>>>> To: Mike Jones >>>>>> Cc: Alan Karp; Morteza Ansari (moransar); id-event@ietf.org >>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Yes, I agree that the claims can be application specific, however the= re >>>>>> is a >>>>>> possibility to define claims which are domain specific. Thereby claim= s >>>>>> generated in one application could be understood by another applicat= ion >>>>>> within the same domain. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> With microservices based architecture getting lot of attention, if tw= o >>>>>> different micro services defining different claims for the same claim= , >>>>>> it >>>>>> can create confusion. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Nevertheless this well defined claims for a particular domain can be a= n >>>>>> extension to the core specification. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -Vivek Biswas >>>>>>=20 >>>>>>=20 >>>>>> Consulting Member, Oracle >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On May 7, 2016, at 1:04 PM, Mike Jones >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>> Thanks Alan, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Interoperability will be on a per-application basis, just like JWT >>>>>> interoperability. The claims needed in an identity event are >>>>>> application-specific, just like claims are for JWTs. This is the sam= e >>>>>> standards posture and JWTs are a huge success =C2=AD including for >>>>>> interoperability, even if I do say so myself. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Best wishes, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Alan Karp >>>>>> Sent: Saturday, May 7, 2016 10:23 AM >>>>>> To: Mike Jones >>>>>> Cc: Morteza Ansari (moransar); id-event@ietf.org >>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> As one who proposed doing more, I believe that your position is valid= . >>>>>> My >>>>>> only question is whether or not that will be enough for >>>>>> interoperability. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Thu, May 5, 2016 at 10:00 PM, Mike Jones >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>> Thanks guys, for writing the initial charter text. Reading it now, I= am >>>>>> extremely worried by the scope creep evident in the proposal. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I strongly support a working group to define an ID Events data format= . >>>>>> I >>>>>> just as strongly believe that specific event delivery mechanisms will= >>>>>> necessarily be application-specific and therefore MUST be explicitly b= e >>>>>> stated as being out of scope in the working group charter. Attemptin= g >>>>>> to >>>>>> specify a particular event delivery mechanism will take something tha= t >>>>>> could >>>>>> be simple and quick to approve and bog it down in necessarily >>>>>> application-specific debates. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Should event delivery be reliable? That=C2=B9s an application-specif= ic >>>>>> decision. >>>>>>=20 >>>>>> Should events be idempotent? That=C2=B9s an application-specific dec= ision. >>>>>>=20 >>>>>> Should events be unicast, multicast, or broadcast? That=C2=B9s an >>>>>> application-specific decision. >>>>>>=20 >>>>>> Should events have categories with category-specific subscriptions? >>>>>> That=C2=B9s >>>>>> an application-specific decision. >>>>>>=20 >>>>>> Should only one party at a time be able to register for delivery of >>>>>> events >>>>>> or should multiple parties be able to request delivery? That=C2=B9s a= n >>>>>> application-specific decision. >>>>>>=20 >>>>>> I could continue with this list, but I think you all get the point=C5= =A0 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> If we start debating application-specific event delivery mechanisms, >>>>>> we=C2=B9ll >>>>>> please almost no one, since nearly all applications have different ev= ent >>>>>> delivery requirements. We MUST explicitly rule all delivery mechanis= ms >>>>>> as >>>>>> being out of scope. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> If we define only a data format, we can quickly produce a very useful= >>>>>> specification. If we don=C2=B9t, we=C2=B9ll get bogged down in the m= ud of >>>>>> debating >>>>>> which applications we=C2=B9re catering to and which we aren=C2=B9t an= exercise >>>>>> of >>>>>> picking favorites and limiting applicability of the specification. >>>>>> That way >>>>>> is a slow, painful descent into standards quicksand =C2=AD something w= e must >>>>>> avoid. Having a standard ID events representation is far too importa= nt >>>>>> to >>>>>> tie to a particular limited event delivery mechanism. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Sincerely, >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan K= arp >>>>>> Sent: Thursday, May 5, 2016 9:43 PM >>>>>> To: Morteza Ansari (moransar) >>>>>> Cc: id-event@ietf.org >>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I don't see anything about access control for publishing events and >>>>>> subscribing to them. I also think the spec should allow filters on >>>>>> subscriptions. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -------------- >>>>>> Alan Karp >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) >>>>>> wrote: >>>>>>=20 >>>>>> Hi folks, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and= >>>>>> put >>>>>> together the attached as a straw man charter proposal to start the >>>>>> discussion. Please send your comments and suggestions for any changes= or >>>>>> propose a new one if you think its necessary. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Morteza >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event From nobody Thu Oct 6 08:53:48 2016 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 245E31296F3 for ; Thu, 6 Oct 2016 08:53:47 -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, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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=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 AwDc609FHE77 for ; Thu, 6 Oct 2016 08:53:44 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 483D81296EF for ; Thu, 6 Oct 2016 08:53:44 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o68so19634717qkf.3 for ; Thu, 06 Oct 2016 08:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e13FdYIns9ryZDOGvu6eC9qP6OiH5h4YS6DbXre1cLg=; b=QRiA6cnYHwYf3S1l+w6wxyvJBb4EZ1cQnYFvgSmqeBFXOkJr4Fc5vQktiSfTyo+jHk GuJSWoEVAk69Y8/JAEsqyjG1PlbGNey3tUpvNeB3juytv3P0fnTaE5NZZM3nEQrzojCF CZhdlp5zp1chkhOqfYxaCW6qo6JjW5fVN/wbH20cfyq0i0VdaJqrvdnv5yRDvG3d32JI Me0F1YZci2ByrvDNRCR4jIYcInjI6MDpeg498Sq5cuSulJMEw9CO33/LO6r2W6fRM4Qq yxkmAPM2pG8uFnOlGKYXtpZgNSJtK0ljJ5x0eUPX3DecPzAwdYKcy5WdmiZv0r+Rclz8 XjtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e13FdYIns9ryZDOGvu6eC9qP6OiH5h4YS6DbXre1cLg=; b=SeXm+r7fIXGb7TfIhMj4spzk/bhG/HyOlZzqgTTaG1RSZ6GKgSLYyuLuSyu+gQGB0n bNQnC4kt7Q4OPdgh/UgmjQ6kXL6G3ZYWatkty7KvQgFZKmxqk//nIfYKIY9K/CmnvBJo YQoNi1+g7lbwz7PNHXuWa+tn9GDtoxHYSukLOujBOOLltrqB73S86+1LuWAcG0N2pVOw k8tSsc/ys6+wsHDpiw1/qpQ0VobiG33OrGECbuZ2MaWAeqCUCxfEBmebJ99Ql9b6jf0w jfU/DL1TqmeDpGyd8/UXF9+G5wK14bzFxdkEZRnBMPdFW8EYCAPCu4dWBdG507eeH4yK EBUg== X-Gm-Message-State: AA6/9RlBCc8EBkiL/vsvIorOM9BIU+8vsVNo72CNIkrtSsofVVv0hkBR3A3vJXenyYIN7A== X-Received: by 10.55.6.145 with SMTP id 139mr15668483qkg.246.1475769223113; Thu, 06 Oct 2016 08:53:43 -0700 (PDT) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id q68sm5372969qka.1.2016.10.06.08.53.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Oct 2016 08:53:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Thu, 6 Oct 2016 11:53:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> <1474715073.2319843.735650465.3C69F11E@webmail.messagingengine.com> <1474718187.2329006.735672633.371888A0@webmail.messagingengine.com> <8DBF45B9-49C0-4846-8D44-44128AEFFAC8@fastmail.fm> To: "Phil Hunt (IDM)" Archived-At: Cc: William Denniss , Mike Jones , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" , Alexey Melnikov Subject: Re: [Id-event] Chartering of Security Events WG X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 15:53:47 -0000 Hi Phil, Great, that's what I requested. Volunteers to be chair should send a messag= e to Alexey, Stephen, and I or at least me. Thank you, Kathleen Please excuse typos, sent from handheld device=20 > On Oct 6, 2016, at 11:08 AM, Phil Hunt (IDM) wrote:= >=20 > Kathleen, >=20 > It would be good if we can meet for an hour for this first session.=20 >=20 > Phil >=20 >> On Oct 6, 2016, at 8:04 AM, Alexey Melnikov wrot= e: >>=20 >>=20 >>> On 6 Oct 2016, at 15:56, Kathleen Moriarty wrote: >>>=20 >>> To confirm, do you plan to meet in Seoul and if so, how much time is nee= ded? >>=20 >> Also, if people can tell Kathleen who volunteered to chair it, that would= be great. >>=20 >>> Thanks, >>> Kathleen >>>=20 >>> On Mon, Sep 26, 2016 at 9:20 PM, Kathleen Moriarty >>> wrote: >>>> Hi Morteza, >>>>=20 >>>> On Mon, Sep 26, 2016 at 4:21 PM, Morteza Ansari (moransar) >>>> wrote: >>>>> Hi Kathleen, >>>>>=20 >>>>> Great idea and hopefully it will get us some fresh blood in the WG for= >>>>> contribution and reviews. I can=C2=B9t think of anything else to inclu= de beyond >>>>> what you suggested. We can do a complete review of the drafts in the w= orks >>>>> in Seoul to catch up any new folks interested in participating (I won=C2= =B9t be >>>>> there in person, but will join the meeting remotely). >>>>>=20 >>>>> I assume you or Alexey will send the note, but if you want one of us t= o >>>>> send it just let us know. >>>>=20 >>>> I don't mind sending it, but will wait to chat with Alexey first so we >>>> are all coordinated. Hopefully it will bring some new interest. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Morteza >>>>>=20 >>>>> On 9/26/16, 6:44 AM, "Kathleen Moriarty" >>>>> wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> It would be good to get a mail message to the SAAG list to announce >>>>>> this, that it crosses areas and that I'll be the AD along with the >>>>>> charter and other information. Is there any other information that >>>>>> should be in such an announcement? >>>>>>=20 >>>>>> Thanks, >>>>>> Kathleen >>>>>>=20 >>>>>> On Sat, Sep 24, 2016 at 11:56 AM, Phil Hunt (IDM) >>>>>> wrote: >>>>>>> Alexy, >>>>>>>=20 >>>>>>> Thanks for helping this forwards. >>>>>>>=20 >>>>>>> The name is fine. >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Sep 24, 2016, at 4:56 AM, Alexey Melnikov >>>>>>> wrote: >>>>>>>=20 >>>>>>> This also reminded me: how much time does this group want to request= for >>>>>>> face-to-face meeting in Seoul? >>>>>>>=20 >>>>>>> On Sat, Sep 24, 2016, at 12:27 PM, Morteza Ansari (moransar) wrote: >>>>>>>=20 >>>>>>> This is great, thanks for helping speed up the process! Name is a na= me, >>>>>>> so >>>>>>> no comment on naming. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Morteza >>>>>>>=20 >>>>>>> On Sep 24, 2016, at 4:04 AM, Alexey Melnikov >>>>>>> wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>> Just to let everyone know: I started chartering of the WG. The WG wi= ll >>>>>>> be in >>>>>>> the Security Area (it was a borderline between ART and Security) and= >>>>>>> your >>>>>>> responsible AD is going to be Kathleen Moriarty. >>>>>>>=20 >>>>>>> Best Regards, >>>>>>> Alexey >>>>>>>=20 >>>>>>> P.S. I picked "SECEVENT" as the short WG name, but if you have bette= r >>>>>>> suggestions, please let me know. >>>>>>>=20 >>>>>>> On Wed, Sep 7, 2016, at 01:04 AM, William Denniss wrote: >>>>>>>=20 >>>>>>> Thank you Mike for revising the charter. >>>>>>>=20 >>>>>>> I support it, and hope we can form a WG with this charter to continu= e >>>>>>> our >>>>>>> work. >>>>>>>=20 >>>>>>> On Tue, Sep 6, 2016 at 5:01 PM, Mike Jones >>>>>>> wrote: >>>>>>>=20 >>>>>>> An updated and simplified charter is attached. This draft has been >>>>>>> reviewed >>>>>>> by Phil Hunt, William Denniss, Marius Scurtescu. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Input from Alexey Melnikov is that we should probably charter a work= ing >>>>>>> group, rather than try to go the AD-sponsored route. Therefore, ple= ase >>>>>>> review this draft charter and let us know if you think it=C2=B9s rea= dy to go. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Sarah Squire [mailto:sarah@engageidentity.com] >>>>>>> Sent: Thursday, July 14, 2016 10:59 PM >>>>>>> To: Phil Hunt (IDM) >>>>>>> Cc: Mike Jones ; Alan Karp >>>>>>> ; Vivek Biswas ; Mortez= a >>>>>>> Ansari >>>>>>> (moransar) ; id-event@ietf.org >>>>>>>=20 >>>>>>>=20 >>>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Just submitting my two cents in writing before we hopefully have a >>>>>>> chance to >>>>>>> meet about this next week... >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Looking at this charter from the perspective of the OIDF HEART worki= ng >>>>>>> group, I think it's going down a good path. In terms of the data for= mat, >>>>>>> this is less structured than what I was envisioning, but we could >>>>>>> easily do >>>>>>> a healthcare-specific profile of whatever data format comes out in t= he >>>>>>> end, >>>>>>> so it's better to be too broad than too narrow as far as our interes= ts >>>>>>> are >>>>>>> concerned. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The transport layer however, has some added complexity. In our conte= xt, >>>>>>> we're shooting for interoperability, so we'd prefer something >>>>>>> constrained. I >>>>>>> appreciate Mike's input that these are application layer decisions. >>>>>>> However, >>>>>>> if we're talking about cloud provider-to-cloud provider communicatio= n, >>>>>>> that >>>>>>> certainly is facilitated by a well-defined transport layer. Again, w= e're >>>>>>> willing to profile whatever the group comes up with for our own ends= , >>>>>>> but I >>>>>>> don't really see the benefit of having a loosely defined transport >>>>>>> layer - >>>>>>> it just seems like more work for all the implementers to actually ag= ree >>>>>>> on >>>>>>> endpoints on a case-by-case basis. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Looking forward to discussing further in Berlin! >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Sarah >>>>>>>=20 >>>>>>>=20 >>>>>>> Sarah Squire >>>>>>>=20 >>>>>>> Engage Identity >>>>>>>=20 >>>>>>> http://engageidentity.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (IDM) >>>>>>> wrote: >>>>>>>=20 >>>>>>> We also set things up so even a domain specific event can be extende= d. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Eg on a password reset event, so event publishers may want to add >>>>>>> security >>>>>>> domain specific attributes. The spec lets them do that while avoidin= g >>>>>>> interop issues. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I believe in the spec we had the example of an account reset and the= >>>>>>> publisher adds reset count as an extension. >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On May 7, 2016, at 13:31, Mike Jones >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Indeed, that=C2=B9s why there=C2=B9s a claims registry =C2=AD so com= mon claims can be >>>>>>> defined once and then reused. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Vivek Biswas >>>>>>> Sent: Saturday, May 7, 2016 1:24 PM >>>>>>> To: Mike Jones >>>>>>> Cc: Alan Karp; Morteza Ansari (moransar); id-event@ietf.org >>>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Yes, I agree that the claims can be application specific, however th= ere >>>>>>> is a >>>>>>> possibility to define claims which are domain specific. Thereby clai= ms >>>>>>> generated in one application could be understood by another applica= tion >>>>>>> within the same domain. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> With microservices based architecture getting lot of attention, if t= wo >>>>>>> different micro services defining different claims for the same clai= m, >>>>>>> it >>>>>>> can create confusion. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Nevertheless this well defined claims for a particular domain can be= an >>>>>>> extension to the core specification. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -Vivek Biswas >>>>>>>=20 >>>>>>>=20 >>>>>>> Consulting Member, Oracle >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On May 7, 2016, at 1:04 PM, Mike Jones = >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks Alan, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Interoperability will be on a per-application basis, just like JWT >>>>>>> interoperability. The claims needed in an identity event are >>>>>>> application-specific, just like claims are for JWTs. This is the sa= me >>>>>>> standards posture and JWTs are a huge success =C2=AD including for >>>>>>> interoperability, even if I do say so myself. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Best wishes, >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Alan Karp >>>>>>> Sent: Saturday, May 7, 2016 10:23 AM >>>>>>> To: Mike Jones >>>>>>> Cc: Morteza Ansari (moransar); id-event@ietf.org >>>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> As one who proposed doing more, I believe that your position is vali= d. >>>>>>> My >>>>>>> only question is whether or not that will be enough for >>>>>>> interoperability. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, May 5, 2016 at 10:00 PM, Mike Jones >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>> Thanks guys, for writing the initial charter text. Reading it now, I= am >>>>>>> extremely worried by the scope creep evident in the proposal. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I strongly support a working group to define an ID Events data forma= t. >>>>>>> I >>>>>>> just as strongly believe that specific event delivery mechanisms wil= l >>>>>>> necessarily be application-specific and therefore MUST be explicitly= be >>>>>>> stated as being out of scope in the working group charter. Attempti= ng >>>>>>> to >>>>>>> specify a particular event delivery mechanism will take something th= at >>>>>>> could >>>>>>> be simple and quick to approve and bog it down in necessarily >>>>>>> application-specific debates. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Should event delivery be reliable? That=C2=B9s an application-speci= fic >>>>>>> decision. >>>>>>>=20 >>>>>>> Should events be idempotent? That=C2=B9s an application-specific de= cision. >>>>>>>=20 >>>>>>> Should events be unicast, multicast, or broadcast? That=C2=B9s an >>>>>>> application-specific decision. >>>>>>>=20 >>>>>>> Should events have categories with category-specific subscriptions? >>>>>>> That=C2=B9s >>>>>>> an application-specific decision. >>>>>>>=20 >>>>>>> Should only one party at a time be able to register for delivery of >>>>>>> events >>>>>>> or should multiple parties be able to request delivery? That=C2=B9s= an >>>>>>> application-specific decision. >>>>>>>=20 >>>>>>> I could continue with this list, but I think you all get the point=C5= =A0 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> If we start debating application-specific event delivery mechanisms,= >>>>>>> we=C2=B9ll >>>>>>> please almost no one, since nearly all applications have different e= vent >>>>>>> delivery requirements. We MUST explicitly rule all delivery mechani= sms >>>>>>> as >>>>>>> being out of scope. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> If we define only a data format, we can quickly produce a very usefu= l >>>>>>> specification. If we don=C2=B9t, we=C2=B9ll get bogged down in the m= ud of >>>>>>> debating >>>>>>> which applications we=C2=B9re catering to and which we aren=C2=B9t a= n exercise >>>>>>> of >>>>>>> picking favorites and limiting applicability of the specification. >>>>>>> That way >>>>>>> is a slow, painful descent into standards quicksand =C2=AD something= we must >>>>>>> avoid. Having a standard ID events representation is far too import= ant >>>>>>> to >>>>>>> tie to a particular limited event delivery mechanism. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Sincerely, >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Alan K= arp >>>>>>> Sent: Thursday, May 5, 2016 9:43 PM >>>>>>> To: Morteza Ansari (moransar) >>>>>>> Cc: id-event@ietf.org >>>>>>> Subject: Re: [Id-event] Straw man text for proposed charter >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I don't see anything about access control for publishing events and >>>>>>> subscribing to them. I also think the spec should allow filters on >>>>>>> subscriptions. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------------- >>>>>>> Alan Karp >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (moransar) >>>>>>> wrote: >>>>>>>=20 >>>>>>> Hi folks, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit an= d >>>>>>> put >>>>>>> together the attached as a straw man charter proposal to start the >>>>>>> discussion. Please send your comments and suggestions for any change= s or >>>>>>> propose a new one if you think its necessary. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Morteza >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 From nobody Thu Oct 6 11:51:46 2016 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 8742B1293D8; Thu, 6 Oct 2016 11:51:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147577990451.23910.11676605796279583861.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 11:51:44 -0700 Archived-At: Cc: secevent-chairs@ietf.org, id-event@ietf.org, smccammon@amsl.com, aamelnikov@fastmail.fm Subject: [Id-event] secevent - New Meeting Session Request for IETF 97 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 18:51:44 -0000 A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the secevent working group. --------------------------------------------------------- Working Group Name: Security Events Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: saag jsonbis httpbis dispatch oauth tokbind Special Requests: --------------------------------------------------------- From nobody Thu Oct 13 02:45:48 2016 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 AEBC612971B; Thu, 13 Oct 2016 02:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 KSTEWtCjyJlb; Thu, 13 Oct 2016 02:45:39 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA0512971A; Thu, 13 Oct 2016 02:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1476351937; d=isode.com; s=june2016; i=@isode.com; bh=9FCqx6aNmEg/rouWzGqJIP6btwfXixfOfM1K5fSm2/o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=McB7pqt7YV1y6dO4IyOcoDKSloTP7vgfq8k1Xwtd6bm1e529Zp/PhZIEUJVuhGDnVxNXbZ /x5CMZYICtDO/4UWQ8dM89eAdgC2G0ahU9PyZ3HaFaACfTNR93+X4bCbHHjJsbSmnzTVmv Kxjdf+Na0mTug8UHP/MXT8BTzbr/QeM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 13 Oct 2016 10:45:37 +0100 To: Alissa Cooper , Kathleen Moriarty References: <147499538530.4539.17647914860327036397.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <1a005eea-efc5-400e-43ea-674e8cf02c39@isode.com> Date: Thu, 13 Oct 2016 10:45:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <147499538530.4539.17647914860327036397.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org Subject: Re: [Id-event] Alissa Cooper's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 09:45:41 -0000 Hi Alissa, On 27/09/2016 17:56, Alissa Cooper wrote: > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-secevent/ > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think this charter is missing a note about other WGs or groups that it > is going to coordinate with. I will add OAUTH. Any other WG I should mention? Thank you, Alexey From nobody Thu Oct 13 06:24:07 2016 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 649D0129779; Thu, 13 Oct 2016 06:24:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 06:24:05 -0700 Archived-At: Cc: secevent-chairs@ietf.org, id-event@ietf.org Subject: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:24:05 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-secevent-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-secevent/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few things I'd like to see improved before this WG is approved. It's fine that that's done during external evaluation though. - What is an "identity related protocol"? I think it'd be way better to be as specific as possible about what's meant here. - I'm concerned that this bit is overly generic and will lead to delays. It'd be better if the set of relevant events was better characterised in the charter before we start I think. "The Security Events working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed" - I agree with Kathleen that only secure transports make sense here and that can and should be in the charter. - I think there's some missing text on privacy - we don't want this work to end up helping e.g. advertisers track people across web sites. And we don't want exchange of event information to lead to two co-operating partners being able to build up databases of each others' employees. I'm not sure what'd be right to put in the charter though. From nobody Thu Oct 13 06:25:31 2016 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 72AE0129742; Thu, 13 Oct 2016 06:25:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 06:25:27 -0700 Archived-At: Cc: secevent-chairs@ietf.org, id-event@ietf.org Subject: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:25:27 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-secevent-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-secevent/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Shouldn't the method for delivering the event be a secure method? How about adding on a sentence after the following section: The Security Events working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed This Event Token specification will be event transport independent. Adding: A secure transport will be specified. From nobody Thu Oct 13 06:29:22 2016 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 6419D129791; Thu, 13 Oct 2016 06:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=iFXx12o3; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=EZNlZMMO 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 lfw1IX9VPFJE; Thu, 13 Oct 2016 06:29:13 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DEE129783; Thu, 13 Oct 2016 06:29:13 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 957A620675; Thu, 13 Oct 2016 09:29:12 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 13 Oct 2016 09:29:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=9ggg/ZwIva3CX6q4d4US8X05+Hg=; b=iFXx12 o3jlZGLuGj7jPIcu23I1sY1aadjFht9F4F6m0wrpe92UcWP0PZrBR754BSx9vPW2 VdsPWhqE6FyIfvS/u02QfGle17RO00ZZ4TC1m6lKaWOYzs+QLI20WNZpy64ciZDH pIKSJzJ+2legE3cF1vQPm7lcJIhDNAtLjA0pQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=9ggg/ZwIva3CX6q 4d4US8X05+Hg=; b=EZNlZMMO+sgRffF+ba80BsN4nw92iTErAsxAa0NoKeBsEP3 5JMWpgKSk5Z6GzF53ZsHqxfV8brBmcbjiF0FEOcMf1hrBCao0+MKiRE3BjlOswur nA/klbxlpvhA4B0wqjERFQZESjVwlIwF2wZnT8qo1IQs++n/31GPTZSGAL8w= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6998D96EAB; Thu, 13 Oct 2016 09:29:12 -0400 (EDT) Message-Id: <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> X-Sasl-Enc: cbhRTobrmZkc08iFtN1XyAaQk0So9S0b8csjDBHB0dSJ 1476365352 From: Alexey Melnikov To: Kathleen Moriarty , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 In-Reply-To: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 14:29:12 +0100 Archived-At: Cc: secevent-chairs@ietf.org, id-event@ietf.org Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:29:15 -0000 Hi Kathleen, On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > charter-ietf-secevent-00-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-secevent/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Shouldn't the method for delivering the event be a secure method? > > How about adding on a sentence after the following section: > The Security Events working group will produce a standards-track Event > Token > specification that includes: > - A JWT extension for expressing security events > - A syntax that enables event-specific data to be conveyed > This Event Token specification will be event transport independent. > > Adding: A secure transport will be specified. I think the charter is saying that work on a specific transport is out of scope. I would rather this WG not work on any transport, but I agree that a secure transport should be recommended. From nobody Thu Oct 13 06:32:17 2016 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 3401D129762; Thu, 13 Oct 2016 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=oq2PYJsY; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=FUH5gluV 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 63GtoUByfvgi; Thu, 13 Oct 2016 06:32:05 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEDB129796; Thu, 13 Oct 2016 06:32:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 84EA82067D; Thu, 13 Oct 2016 09:32:03 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 13 Oct 2016 09:32:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=s0Zf/t2n2xlY5rsHHVsKDdBwFcE=; b=oq2PYJ sY2++zxJXc0+h7XsMZYjb46MJs834pFHi5CoHTgHjiEw27jqiOr5SfqzzeI0k7UP HVseMZJ+hpYx7zuX1vU7EGdCEWPmonOGKkmCw2SwmbTOY6Ufv35RH0tTIdW7k0EL L4S07B7TCWBxdebbwZth4KH0NZOkvB6LW0Cag= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=s0Zf/t2n2xlY5rs HHVsKDdBwFcE=; b=FUH5gluVaGYX0hAt9EqkvzSi6dBQ3DMLIy1ueLVj9YM5t5S VUqqcGrJTan1iH+snuRvzQDGFanZ5RPaXYnJ/q2Q/dZei9vfazr4bUyjNUI5ohBy ZnathXlyntYpf1yBgyZCMgx7d7mxi5jfUSRDmCs9kwe/AUepl5UUFsRkSNeI= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4CAEB96EAC; Thu, 13 Oct 2016 09:32:03 -0400 (EDT) Message-Id: <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> X-Sasl-Enc: aNxWgO5DA0GKX/f0lvr/Rq6vx4xcdQgsYd9/VbNX0qRN 1476365523 From: Alexey Melnikov To: Stephen Farrell , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 Date: Thu, 13 Oct 2016 14:32:03 +0100 In-Reply-To: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:32:11 -0000 Hi Stephen, On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-secevent-00-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-secevent/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I have a few things I'd like to see improved before this WG is > approved. It's fine that that's done during external evaluation > though. Thank you. Let's do this while the charter is out for External Review. > - What is an "identity related protocol"? I think it'd be way better > to be as specific as possible about what's meant here. > > - I'm concerned that this bit is overly generic and will lead to > delays. It'd be better if the set of relevant events was better > characterised in the charter before we start I think. > > "The Security Events working group will produce a standards-track > Event Token > specification that includes: > - A JWT extension for expressing security events > - A syntax that enables event-specific data to be conveyed" Agreed. > - I agree with Kathleen that only secure transports make sense > here and that can and should be in the charter. I am not convinced, see my reply to Kathleen. > - I think there's some missing text on privacy - we don't want this > work to end up helping e.g. advertisers track people across web > sites. And we don't want exchange of event information to lead > to two co-operating partners being able to build up databases of > each others' employees. I'm not sure what'd be right to put in > the charter though. If you can suggest some text, I can try to reword and find some place for it. From nobody Thu Oct 13 06:37:42 2016 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 2D11D1293F4; Thu, 13 Oct 2016 06:37:38 -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, FREEMAIL_FROM=0.001, 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=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 DgKyNS_Z8exZ; Thu, 13 Oct 2016 06:37:35 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 BFA841294FC; Thu, 13 Oct 2016 06:37:27 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id 83so54631039vkd.0; Thu, 13 Oct 2016 06:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xl0YBn2JnXvb25mQ6N4HyadCugD/JYiMPy3WK2Oz5uI=; b=RrnVSo2yRR/yvI8bXdIpQQhR/fJnrvLKdgXwSgaE0mblr+7ZLfwkDdevdypcTr3YxD EW54v8+PdekUVJNipFb0Jo8hZY1h+h52IShRNbk2HArH9qmC4TGC1JTJfr6rtAZyYJY2 LqPgKJg7GuQqFT2RVlSuSx48MFjsUMI2ONayQzSUa4J0fCrWpLAd66BbLAq7Z7E7olTY RyJ+LX70vxV+vPhsrKbY8RfdEAUbzz7YSG/3+HIAj9qAnOFEnSLvJCZ428BAR5PZSRVR DytrVeCSxYAtD2teNQFuIf+n3l28zIBlGF2BayR98kaFPsKU+jci+Jwm5t8xLanGWXYA 492Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xl0YBn2JnXvb25mQ6N4HyadCugD/JYiMPy3WK2Oz5uI=; b=dgTql8ckUmhEoa7RlQoMu/IFj5I4FatLx6dgg9oX9qiv8aiNy9Sg6UKjttOzpTu9Kf +qkNaSP+nUA9IEFa7aYdHTr+k4ULbq1DpvqRgMnKY24JOANHo27zrkZ3jOdYwUuTvM5x AeM8EWryBzGVX9HZLvOdKx/qZGtW95CCgkXCpjt5iThwQPSljytoJnA1gQ3isIH/m0K/ 2zqJX820+gERyCnGOVKhlvfxz57JSUe7DL79Dr7t0jLCf6gTc/qzGLeXzfDErU5NdUv1 AbRnK6c/YI/YY2lJRdLo2Lycnqh0gGm+2cDGKHikCSoaN3FGyd5H7ZAJmNw9x7J4MLuw ZqBw== X-Gm-Message-State: AA6/9RnWA3hQfibAQOhMFzI7o/fI27RMIHIopsH1yDYjDUzOYhDc/P1j6qfdzmbzcV/axwmFKqyHDazFaB2dpw== X-Received: by 10.31.151.78 with SMTP id z75mr4693722vkd.41.1476365846869; Thu, 13 Oct 2016 06:37:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 13 Oct 2016 06:37:26 -0700 (PDT) In-Reply-To: <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> From: Kathleen Moriarty Date: Thu, 13 Oct 2016 09:37:26 -0400 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a1140e662dc82db053ebf3570 Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:37:38 -0000 --001a1140e662dc82db053ebf3570 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov wrote: > Hi Kathleen, > > On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > charter-ietf-secevent-00-00: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-secevent/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Shouldn't the method for delivering the event be a secure method? > > > > How about adding on a sentence after the following section: > > The Security Events working group will produce a standards-track Event > > Token > > specification that includes: > > - A JWT extension for expressing security events > > - A syntax that enables event-specific data to be conveyed > > This Event Token specification will be event transport independent. > > > > Adding: A secure transport will be specified. > > I think the charter is saying that work on a specific transport is out > of scope. I would rather this WG not work on any transport, but I agree > that a secure transport should be recommended. > Yes, that's what I meant by specified, but haven't had any caffeine yet and should not have used that word. Recommended is a good choice. Thank you. -- Best regards, Kathleen --001a1140e662dc82db053ebf3570 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov <= aamelnikov@fast= mail.fm> wrote:
Hi Kathleen= ,

On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> charter-ietf-secevent-00-00: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/ch= arter-ietf-secevent/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Shouldn't the method for delivering the event be a secure method?<= br> >
> How about adding on a sentence after the following section:
> The Security Events working group will produce a standards-track Event=
> Token
> specification that includes:
>=C2=A0 - A JWT extension for expressing security events
>=C2=A0 - A syntax that enables event-specific data to be conveyed
> This Event Token specification will be event transport independent. >
> Adding: A secure transport will be specified.

I think the charter is saying that work on a specific transport= is out
of scope. I would rather this WG not work on any transport, but I agree
that a secure transport should be recommended.

Yes, that's what I meant by specified, but haven't had any = caffeine yet and should not have used that word. Recommended is a good choi= ce.=C2=A0 Thank you.



--

Best regards,
Kathleen
--001a1140e662dc82db053ebf3570-- From nobody Thu Oct 13 06:41:51 2016 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 568D1129798; Thu, 13 Oct 2016 06:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 SmgtJq9GRsqE; Thu, 13 Oct 2016 06:41:41 -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 14761129783; Thu, 13 Oct 2016 06:41:41 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DDfavh002923 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 13:41:36 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9DDfaD4003561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 13:41:36 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9DDfZeE027434; Thu, 13 Oct 2016 13:41:35 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 06:41:35 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E4F5755A-7A31-4D17-8504-A5D549D723C8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 13 Oct 2016 09:40:52 -0400 Message-Id: <1BFB9696-B45D-4F98-9F1F-BA2D64BD4EB5@oracle.com> References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:41:44 -0000 --Apple-Mail=_E4F5755A-7A31-4D17-8504-A5D549D723C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Maybe I am reading the charter wrong. But the charter should indicate = that we will develop one secure transport based on HTTP POST. With that said, it is entirely possible that SETs could be delivered = over insecure (depending on what is meant) channels. We chose JWT = because they can themselves be signed and encrypted. I have initially = suggested a registry be defined that would help shape future transport = specs by alerting profiling authors to cover a minimum set of security = issues either in transport or within the token itself. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty = wrote: >=20 >=20 >=20 > On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov = > wrote: > Hi Kathleen, >=20 > On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > charter-ietf-secevent-00-00: No Objection > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-secevent/ = > > > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > Shouldn't the method for delivering the event be a secure method? > > > > How about adding on a sentence after the following section: > > The Security Events working group will produce a standards-track = Event > > Token > > specification that includes: > > - A JWT extension for expressing security events > > - A syntax that enables event-specific data to be conveyed > > This Event Token specification will be event transport independent. > > > > Adding: A secure transport will be specified. >=20 > I think the charter is saying that work on a specific transport is out > of scope. I would rather this WG not work on any transport, but I = agree > that a secure transport should be recommended. >=20 > Yes, that's what I meant by specified, but haven't had any caffeine = yet and should not have used that word. Recommended is a good choice. = Thank you. >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_E4F5755A-7A31-4D17-8504-A5D549D723C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Maybe I am reading the charter wrong. But the charter should = indicate that we will develop one secure transport based on HTTP = POST.

With that = said, it is entirely possible that SETs could be delivered over insecure = (depending on what is meant) channels. We chose JWT because they can = themselves be signed and encrypted.  I have initially suggested a = registry be defined that would help shape future transport specs by = alerting profiling authors to cover a minimum set of security issues = either in transport or within the token itself.




On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:


On Thu, Oct 13, 2016 at 9:29 AM, Alexey = Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Kathleen,

On Thu, Oct = 13, 2016, at 02:25 PM, Kathleen Moriarty wrote:
> = Kathleen Moriarty has entered the following ballot position for
> charter-ietf-secevent-00-00: No Objection
>
> When responding, please keep the = subject line intact and reply to all
> email addresses = included in the To and CC lines. (Feel free to cut this
>= introductory paragraph, however.)
>
>
>
> The document, = along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-secevent/
>
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> Shouldn't the method for delivering = the event be a secure method?
>
> How = about adding on a sentence after the following section:
>= The Security Events working group will produce a standards-track = Event
> Token
> specification that = includes:
>  - A JWT extension for expressing = security events
>  - A syntax that enables = event-specific data to be conveyed
> This Event Token = specification will be event transport independent.
>
> Adding: A secure transport will be specified.

I think the charter is saying that = work on a specific transport is out
of scope. I would = rather this WG not work on any transport, but I agree
that = a secure transport should be recommended.

Yes, that's what I meant = by specified, but haven't had any caffeine yet and should not have used = that word. Recommended is a good choice.  Thank you.



-- 

Best regards,
Kathleen
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_E4F5755A-7A31-4D17-8504-A5D549D723C8-- From nobody Thu Oct 13 06:51:30 2016 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 4CD061298BB; Thu, 13 Oct 2016 06:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 QfFz5CRpxwBU; Thu, 13 Oct 2016 06:51:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97421298B2; Thu, 13 Oct 2016 06:51:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46DBFBE83; Thu, 13 Oct 2016 14:51:17 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUbC1WpXDqeG; Thu, 13 Oct 2016 14:51:17 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8D1F3BEB3; Thu, 13 Oct 2016 14:51:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476366677; bh=rpln4sNsm17/qYsdXo5d1Ud6PTdRdfRud78cfVJicew=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=CRB1hd/20WeGdXQ8Ko/5Isgp2Rui9yviDosE5IEi9TIwGz1IonEes2LufbSJR29ZJ y8gr0OrJz6z9kprAnQehj0tEXD53qGQkWnIkZEmbT6iuSqTiiSwpPMixylL1lNElcA G6d1dLzc06HkSvbN6xFg8mQDAhcDZD3LYO9hw/qk= To: Alexey Melnikov , The IESG References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 13 Oct 2016 14:51:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030102010208080003000509" Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:51:28 -0000 This is a cryptographically signed message in MIME format. --------------ms030102010208080003000509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/10/16 14:32, Alexey Melnikov wrote: > Hi Stephen, >=20 > On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> charter-ietf-secevent-00-00: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-secevent/ >> >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> I have a few things I'd like to see improved before this WG is >> approved. It's fine that that's done during external evaluation >> though. >=20 > Thank you. Let's do this while the charter is out for External Review. Right, I hope it'll not be hard. >=20 >> - What is an "identity related protocol"? I think it'd be way better >> to be as specific as possible about what's meant here. >> >> - I'm concerned that this bit is overly generic and will lead to >> delays. It'd be better if the set of relevant events was better=20 >> characterised in the charter before we start I think. >> >> "The Security Events working group will produce a standards-track >> Event Token >> specification that includes: >> - A JWT extension for expressing security events >> - A syntax that enables event-specific data to be conveyed" >=20 > Agreed. >=20 >> - I agree with Kathleen that only secure transports make sense >> here and that can and should be in the charter. >=20 > I am not convinced, see my reply to Kathleen. Well, the protocol payload may be signed or encrypted, sure and there may be non-standard ways to communicate that say between two processes on the same host, but I don't see why there's a need for e.g. sending on port 80 ever. If there is then it'd be good to have the WG justify that explicitly maybe. >=20 >> - I think there's some missing text on privacy - we don't want this >> work to end up helping e.g. advertisers track people across web >> sites. And we don't want exchange of event information to lead=20 >> to two co-operating partners being able to build up databases of >> each others' employees. I'm not sure what'd be right to put in >> the charter though. >=20 > If you can suggest some text, I can try to reword and find some place > for it. TBH, I'm not sure. I think it depends on the better characterising the set of events issue. If this is mainly for inter-enterprise stuff about employees that's one thing. If it's mainly for something else on the public Internet then different considerations may apply. But since I'm not clear on that (yet) I don't know what'd make sense to put in the charter. Cheers, S. >=20 --------------ms030102010208080003000509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTMx MzUxMTZaMC8GCSqGSIb3DQEJBDEiBCAoxkyJ9uK7HvKBm63+1G2KNM2ov3MrlXjbYFAN7L1W 2zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBf8FK+ke6xnx4oYtwZjhJ0rrwbaqj2Ox6yB1UyN01b70U9QwK0gnFh 8CwwZRXEf2HhFjfaaOMVmS+RukTwi30UOEEtw/OPFwoGyvph+uCi7HFJITGvlJ8bEaJycCMe 17anBGXns3iTfFuMjGqH+7wrlSg8zyX/HaG3BtHJRK7tpLHpOpD56HxUig9IX+u/PGn7x22+ v14SSMEsaD767O4vzAX+ftj4FpnmIJYj4ZP5a05HJjCQNfHC6u/hXSTm5Bz/+xKIMjvCtT8W fWZOVeUA1mMS/WRYAkRYpl5y2XUeTO2KN+bMpLQSv0rVOgR0Z+1Z+eaha7E2S53iwetbnFkL AAAAAAAA --------------ms030102010208080003000509-- From nobody Thu Oct 13 06:57:22 2016 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 AD8651298CD; Thu, 13 Oct 2016 06:57: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, FREEMAIL_FROM=0.001, 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=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 GnLDoOzRWW6q; Thu, 13 Oct 2016 06:57:13 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 9C6361298CA; Thu, 13 Oct 2016 06:57:13 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id 83so55423123vkd.0; Thu, 13 Oct 2016 06:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sh0up4MVCrXUrgUtCuFRhpkQCDoVSNHvANOamBwxEMM=; b=UpqSEvtSCIUntxRneL0alogycF2811VRg47wqrx1MOervYBdXHY3yS+hF+BhjUaJHZ mmPfFvSnDgmacva4sf20pDLK9SExrTX8cpNKrRB9mj2aQZ8S1wYHw5HvY/8CITCjCp1q W9xqttM3ylv0M1pn3Akg+PBGzObMdnOS1phtY6hhi8TiZBY03GF8lyIk3bLR47FcSHEU ADYTArFc6jT9Dzx72L4yAXwSt16kLJ8UEnW5YKzzpfaEL0iPEO8bw+6CIst+YQYLjAPR envmB8LEYTlh12MJd1w04r0mdU/PFaUcwkTFLHvX4aFJ6oENgPukbWLlBl/6hc9e0jYa +VaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sh0up4MVCrXUrgUtCuFRhpkQCDoVSNHvANOamBwxEMM=; b=DcrrN39s0i/g3swWRZIQ28tMcmYEh3CWkbDM/Ue2Z9ptPgJTWutnAqS5jyeNC+QH6S Trm8DtZ9Y1jtvSZ76KXuhZeVZWL2ZN6Kfq2Yd0ASMZmHGu9sJ5F3lCGZAe7uvUYIcy9l h2rU6mAXQDRJsox3qOb5CCIq2fPprpY7/SxOEh2ga97Jyc4xqG1zExt4HdppK10xo4B4 dRIGhGF0JQqvl87DbfoZKNGRsH1XsM8faS+KHlherg2LvRlaY0nmf9Rb5pQCFeC90gjY YkKCuOYhG2k48ZhViigACg+8Iiap4aBuQwEfKYmgn9D6R32CsRmhBPe/+Z+6dR25dgVj /Nyg== X-Gm-Message-State: AA6/9RmSnOB42hCp6a7oVEuU+f447fPJifiIQ4b7Fh0poy9jq7DRoNKPREIitw/1WSv+kgKVUW4bOInZIU5D8w== X-Received: by 10.31.215.67 with SMTP id o64mr4491184vkg.92.1476367032588; Thu, 13 Oct 2016 06:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 13 Oct 2016 06:57:12 -0700 (PDT) In-Reply-To: References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> From: Kathleen Moriarty Date: Thu, 13 Oct 2016 09:57:12 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c07c972892a87053ebf7c22 Archived-At: Cc: The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 13:57:17 -0000 --94eb2c07c972892a87053ebf7c22 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 13, 2016 at 9:51 AM, Stephen Farrell wrote: > > Hiya, > > On 13/10/16 14:32, Alexey Melnikov wrote: > > Hi Stephen, > > > > On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for > >> charter-ietf-secevent-00-00: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/charter-ietf-secevent/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> I have a few things I'd like to see improved before this WG is > >> approved. It's fine that that's done during external evaluation > >> though. > > > > Thank you. Let's do this while the charter is out for External Review. > > Right, I hope it'll not be hard. > > > > >> - What is an "identity related protocol"? I think it'd be way better > >> to be as specific as possible about what's meant here. > >> > >> - I'm concerned that this bit is overly generic and will lead to > >> delays. It'd be better if the set of relevant events was better > >> characterised in the charter before we start I think. > >> > >> "The Security Events working group will produce a standards-track > >> Event Token > >> specification that includes: > >> - A JWT extension for expressing security events > >> - A syntax that enables event-specific data to be conveyed" > > > > Agreed. > > > >> - I agree with Kathleen that only secure transports make sense > >> here and that can and should be in the charter. > > > > I am not convinced, see my reply to Kathleen. > > Well, the protocol payload may be signed or encrypted, sure > and there may be non-standard ways to communicate that say > between two processes on the same host, but I don't see why > there's a need for e.g. sending on port 80 ever. If there > is then it'd be good to have the WG justify that explicitly > maybe. > In case my response wasn't clear, I would like to see something in the charter - recommendations on how it is secured for transport and/or a secure transport is used. > > > >> - I think there's some missing text on privacy - we don't want this > >> work to end up helping e.g. advertisers track people across web > >> sites. And we don't want exchange of event information to lead > >> to two co-operating partners being able to build up databases of > >> each others' employees. I'm not sure what'd be right to put in > >> the charter though. > > > > If you can suggest some text, I can try to reword and find some place > > for it. > > TBH, I'm not sure. I think it depends on the better > characterising the set of events issue. If this is > mainly for inter-enterprise stuff about employees > that's one thing. If it's mainly for something else > on the public Internet then different considerations > may apply. But since I'm not clear on that (yet) I > don't know what'd make sense to put in the charter. > > Cheers, > S. > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > -- Best regards, Kathleen --94eb2c07c972892a87053ebf7c22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 13, 2016 at 9:51 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 13/10/16 14:32, Alexey Melnikov wrote:
> Hi Stephen,
>
> On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote:
>> Stephen Farrell has entered the following ballot position for
>> charter-ietf-secevent-00-00: No Objection
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://datatracker.ietf.org/do= c/charter-ietf-secevent/
>>
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>>
>> I have a few things I'd like to see improved before this WG is=
>> approved. It's fine that that's done during external evalu= ation
>> though.
>
> Thank you. Let's do this while the charter is out for External Rev= iew.

Right, I hope it'll not be hard.

>
>> - What is an "identity related protocol"? I think it'= ;d be way better
>> to be as specific as possible about what's meant here.
>>
>> - I'm concerned that this bit is overly generic and will lead = to
>> delays. It'd be better if the set of relevant events was bette= r
>> characterised in the charter before we start I think.
>>
>>=C2=A0 =C2=A0 "The Security Events working group will produce = a standards-track
>> Event Token
>>=C2=A0 =C2=A0 specification that includes:
>>=C2=A0 =C2=A0 =C2=A0- A JWT extension for expressing security event= s
>>=C2=A0 =C2=A0 =C2=A0- A syntax that enables event-specific data to = be conveyed"
>
> Agreed.
>
>> - I agree with Kathleen that only secure transports make sense
>> here and that can and should be in the charter.
>
> I am not convinced, see my reply to Kathleen.

Well, the protocol payload may be signed or encrypted, sure
and there may be non-standard ways to communicate that say
between two processes on the same host, but I don't see why
there's a need for e.g. sending on port 80 ever. If there
is then it'd be good to have the WG justify that explicitly
maybe.

In case my response wasn't c= lear, I would like to see something in the charter - recommendations on how= it is secured for transport and/or a secure transport is used.
<= br>

>
>> - I think there's some missing text on privacy - we don't = want this
>> work to end up helping e.g. advertisers track people across web >> sites. And we don't want exchange of event information to lead=
>> to two co-operating partners being able to build up databases of >> each others' employees. I'm not sure what'd be right t= o put in
>> the charter though.
>
> If you can suggest some text, I can try to reword and find some place<= br> > for it.

TBH, I'm not sure. I think it depends on the better
characterising the set of events issue. If this is
mainly for inter-enterprise stuff about employees
that's one thing. If it's mainly for something else
on the public Internet then different considerations
may apply. But since I'm not clear on that (yet) I
don't know what'd make sense to put in the charter.

Cheers,
S.


>


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




--
=
Best regards,
Kathleen
--94eb2c07c972892a87053ebf7c22-- From nobody Thu Oct 13 07:07:44 2016 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 1FEFF1294EB; Thu, 13 Oct 2016 07:07:38 -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, FREEMAIL_FROM=0.001, 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=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 S90j3Sg8L38k; Thu, 13 Oct 2016 07:07:34 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 B75F91298CD; Thu, 13 Oct 2016 07:07:32 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id q126so26199831vkd.2; Thu, 13 Oct 2016 07:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I5TtOn3PEsw+j8y31f+eMiJTEjlMLe3gVga+gzgXbQA=; b=hBGGvKxXNgTL3r8XUG5cskxvvD04N34/kBXoJnJlrofann8iZvx0+aAiosb1iotXrl 58KNkr2vadbizeATfHlbmLAy3pqYnZNoZsP+Lh4pY2l0TDvozVoNoEsF0DMuWvQEs19E 9zCEXx1oOznq6q3GDLSnv63mDI44J81NrN66Y8QySfXaKT85YKKYK9hBvcigTxtgSa0F R1dNj+q6fe6x7fG9lhzQkCz1US15uGdn2Obn9nzrl4SihBt4XEyjmKLRzmeSZQsB8Emq xX+YKtSq5mNRsKTgiqdJw0MVjaCtBKgonhiPRX9yQ7yBn3q4E2zY6Q9DPrN6/CLt0F6b YImw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I5TtOn3PEsw+j8y31f+eMiJTEjlMLe3gVga+gzgXbQA=; b=C9AB+znZ3X/ytjmhqA77zDP547J0YnYqVVaN7azpIU7k1ryUb02KTU4Z4AHUUeuzFu Js60w1T9KyzsAgZbjkJrxcsyfGd3iqakGtGmOY+5eAdC9MGewHdW2EXsybdwWFeWqdhH yF3uzizFGHGVvv5wx+8LJ9mM/8kW6Msb+aBy9RqiF9A+M+zwG7WdvXLH1E5mMQ5z8vuo +TzgClCFEoU0mNBrQEMBYWQLU3GUDJsspezZpBdoPLRIL0FP8fF4d8qD0qy+d4fJMk2l HeIeNaHDPRgb8kidslL/2KbL4VK6nR5ibDtRNnjv3h5j0OWHFLdwrluw6pUbWliAQCSu YuZg== X-Gm-Message-State: AA6/9RkQ/nsZ17xP9lwiPQuEL8WeVNOYrwfCbEnhZWQ55lBx9tUalP9pZskA1MSn8726eU1mlmC1AyJ3R/i26A== X-Received: by 10.31.228.3 with SMTP id b3mr4718307vkh.49.1476367646196; Thu, 13 Oct 2016 07:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 13 Oct 2016 07:07:25 -0700 (PDT) In-Reply-To: <1BFB9696-B45D-4F98-9F1F-BA2D64BD4EB5@oracle.com> References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> <1BFB9696-B45D-4F98-9F1F-BA2D64BD4EB5@oracle.com> From: Kathleen Moriarty Date: Thu, 13 Oct 2016 10:07:25 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=94eb2c0960541c0ba6053ebfa14b Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:07:38 -0000 --94eb2c0960541c0ba6053ebfa14b Content-Type: text/plain; charset=UTF-8 Hi Phil, On Thu, Oct 13, 2016 at 9:40 AM, Phil Hunt wrote: > Maybe I am reading the charter wrong. But the charter should indicate that > we will develop one secure transport based on HTTP POST. > Can you point out where in the charter you see it already covered as I'm missing it and it seems others are too. > > With that said, it is entirely possible that SETs could be delivered over > insecure (depending on what is meant) channels. We chose JWT because they > can themselves be signed and encrypted. I have initially suggested a > registry be defined that would help shape future transport specs by > alerting profiling authors to cover a minimum set of security issues either > in transport or within the token itself. > Yes, Stephen mentioned this as well and I agree, but some mention of security methods should be in the charter. I tried to make as simple a statement as possible to not restrict it, but feel free to propose something else that encompasses the possible acceptable solutions. Thank you, Kathleen > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov > wrote: > >> Hi Kathleen, >> >> On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: >> > Kathleen Moriarty has entered the following ballot position for >> > charter-ietf-secevent-00-00: No Objection >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-secevent/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > Shouldn't the method for delivering the event be a secure method? >> > >> > How about adding on a sentence after the following section: >> > The Security Events working group will produce a standards-track Event >> > Token >> > specification that includes: >> > - A JWT extension for expressing security events >> > - A syntax that enables event-specific data to be conveyed >> > This Event Token specification will be event transport independent. >> > >> > Adding: A secure transport will be specified. >> >> I think the charter is saying that work on a specific transport is out >> of scope. I would rather this WG not work on any transport, but I agree >> that a secure transport should be recommended. >> > > Yes, that's what I meant by specified, but haven't had any caffeine yet > and should not have used that word. Recommended is a good choice. Thank > you. > > > > -- > > Best regards, > Kathleen > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- Best regards, Kathleen --94eb2c0960541c0ba6053ebfa14b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,

On Thu, Oct 13, 2016 at 9:40 AM, Phil Hunt <phil.hunt@oracle.co= m> wrote:
Maybe I am reading the charter wrong. But the charter sh= ould indicate that we will develop one secure transport based on HTTP POST.=

Can you point out where in the chart= er you see it already covered as I'm missing it and it seems others are= too.
=C2=A0

With that said, it is entirely poss= ible that SETs could be delivered over insecure (depending on what is meant= ) channels. We chose JWT because they can themselves be signed and encrypte= d.=C2=A0 I have initially suggested a registry be defined that would help s= hape future transport specs by alerting profiling authors to cover a minimu= m set of security issues either in transport or within the token itself.

Yes, Stephen mentioned this as we= ll and I agree, but some mention of security methods should be in the chart= er.=C2=A0 I tried to make as simple a statement as possible to not restrict= it, but feel free to propose something else that encompasses the possible = acceptable solutions.

Thank you,
Kathlee= n
=C2=A0




On Oct 13, 2= 016, at 9:37 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com= > wrote:



On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov=C2=A0<aamelnikov@fastmail.fm>=C2=A0wrote:
Hi Kathl= een,

On Thu, Oct 13, 201= 6, at 02:25 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has ente= red the following ballot position for
> charter-ietf-secevent-00-00: = No Objection
>
> When responding, please keep the subject line = intact and reply to all
> email addresses included in the To and CC l= ines. (Feel free to cut this
> introductory paragraph, however.)
&= gt;
>
>
> The document, along with other ballot positions= , can be found here:
>=C2=A0https://datatracker.= ietf.org/doc/charter-ietf-secevent/
>
>
>
>= ; ---------------------------------------------------------------= -------
> COMMENT:
> -------------------------------------= ---------------------------------
>
> Shouldn't the me= thod for delivering the event be a secure method?
>
> How about= adding on a sentence after the following section:
> The Security Eve= nts working group will produce a standards-track Event
> Token
>= ; specification that includes:
>=C2=A0 - A JWT extension for expressi= ng security events
>=C2=A0 - A syntax that enables event-specific dat= a to be conveyed
> This Event Token specification will be event trans= port independent.
>
> Adding: A secure transport will be specif= ied.

I think the charter is saying that work on a specif= ic transport is out
of scope. I would rather this WG not work on any tra= nsport, but I agree
that a secure transport should be recommended.

Yes, that's what I meant by specified, b= ut haven't had any caffeine yet and should not have used that word. Rec= ommended is a good choice.=C2=A0 Thank you.



--=C2=A0

Best regards,
Kathleen
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.i= etf.org/mailman/listinfo/id-event




--

Best regards,
Kathleen
--94eb2c0960541c0ba6053ebfa14b-- From nobody Thu Oct 13 07:24:39 2016 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 C67FE1298E0; Thu, 13 Oct 2016 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 g4EPfoqPOtCP; Thu, 13 Oct 2016 07:24:35 -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 399F21298D4; Thu, 13 Oct 2016 07:24:35 -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 u9DEOUeI011627 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:24:31 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.14.4) with ESMTP id u9DEOU5W012275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:24:30 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9DEOSiU022092; Thu, 13 Oct 2016 14:24:29 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 07:24:27 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_88AF9099-06E5-4CDB-ADFD-60245BFEB785" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 13 Oct 2016 10:23:18 -0400 Message-Id: References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> <1BFB9696-B45D-4F98-9F1F-BA2D64BD4EB5@oracle.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: secevent-chairs@ietf.org, Alexey Melnikov , The IESG , id-event@ietf.org Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:24:38 -0000 --Apple-Mail=_88AF9099-06E5-4CDB-ADFD-60245BFEB785 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Right here (first bullet): The working group will also develop a simple standards-track Event = Delivery specification that includes: - A method for delivering events using HTTP POST (push) - Metadata for describing event feeds - Methods for subscribing to and managing event feeds - Methods for validating event feed subscriptions Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 10:07 AM, Kathleen Moriarty = wrote: >=20 > Hi Phil, >=20 > On Thu, Oct 13, 2016 at 9:40 AM, Phil Hunt > wrote: > Maybe I am reading the charter wrong. But the charter should indicate = that we will develop one secure transport based on HTTP POST. >=20 > Can you point out where in the charter you see it already covered as = I'm missing it and it seems others are too. > =20 >=20 > With that said, it is entirely possible that SETs could be delivered = over insecure (depending on what is meant) channels. We chose JWT = because they can themselves be signed and encrypted. I have initially = suggested a registry be defined that would help shape future transport = specs by alerting profiling authors to cover a minimum set of security = issues either in transport or within the token itself. >=20 > Yes, Stephen mentioned this as well and I agree, but some mention of = security methods should be in the charter. I tried to make as simple a = statement as possible to not restrict it, but feel free to propose = something else that encompasses the possible acceptable solutions. >=20 > Thank you, > Kathleen > =20 >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty = > wrote: >>=20 >>=20 >>=20 >> On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov = > wrote: >> Hi Kathleen, >>=20 >> On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: >> > Kathleen Moriarty has entered the following ballot position for >> > charter-ietf-secevent-00-00: No Objection >> > >> > When responding, please keep the subject line intact and reply to = all >> > email addresses included in the To and CC lines. (Feel free to cut = this >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-secevent/ = >> > >> > >> > >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> > >> > Shouldn't the method for delivering the event be a secure method? >> > >> > How about adding on a sentence after the following section: >> > The Security Events working group will produce a standards-track = Event >> > Token >> > specification that includes: >> > - A JWT extension for expressing security events >> > - A syntax that enables event-specific data to be conveyed >> > This Event Token specification will be event transport independent. >> > >> > Adding: A secure transport will be specified. >>=20 >> I think the charter is saying that work on a specific transport is = out >> of scope. I would rather this WG not work on any transport, but I = agree >> that a secure transport should be recommended. >>=20 >> Yes, that's what I meant by specified, but haven't had any caffeine = yet and should not have used that word. Recommended is a good choice. = Thank you. >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_88AF9099-06E5-4CDB-ADFD-60245BFEB785 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Right here (first bullet):
The working group will also =
develop a simple standards-track Event Delivery
specification that includes:
 - A method for delivering events using HTTP POST (push)
 - Metadata for describing event feeds
 - Methods for subscribing to and managing event feeds
 - Methods for validating event feed subscriptions




On Oct 13, 2016, at 10:07 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi Phil,

On Thu, = Oct 13, 2016 at 9:40 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Maybe I am reading the = charter wrong. But the charter should indicate that we will develop one = secure transport based on HTTP POST.
Can you point out where in the charter = you see it already covered as I'm missing it and it seems others are = too.
 

With that said, it is = entirely possible that SETs could be delivered over insecure (depending = on what is meant) channels. We chose JWT because they can themselves be = signed and encrypted.  I have initially suggested a registry be = defined that would help shape future transport specs by alerting = profiling authors to cover a minimum set of security issues either in = transport or within the token itself.

Yes, Stephen mentioned = this as well and I agree, but some mention of security methods should be = in the charter.  I tried to make as simple a statement as possible = to not restrict it, but feel free to propose something else that = encompasses the possible acceptable solutions.

Thank you,
Kathleen
 

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On Oct 13, 2016, at 9:37 = AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:



On Thu, Oct 13, 2016 at 9:29 AM, = Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Kathleen,

On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty = wrote:
> Kathleen Moriarty has entered the following = ballot position for
> charter-ietf-secevent-00-00: No = Objection
>
> When responding, please = keep the subject line intact and reply to all
> email = addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, = along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-secevent/
>
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> Shouldn't the method for delivering = the event be a secure method?
>
> How = about adding on a sentence after the following section:
>= The Security Events working group will produce a standards-track = Event
> Token
> specification that = includes:
>  - A JWT extension for expressing = security events
>  - A syntax that enables = event-specific data to be conveyed
> This Event Token = specification will be event transport independent.
>
> Adding: A secure transport will be specified.

I think the charter is saying that = work on a specific transport is out
of scope. I would = rather this WG not work on any transport, but I agree
that = a secure transport should be recommended.

Yes, that's what I meant = by specified, but haven't had any caffeine yet and should not have used = that word. Recommended is a good choice.  Thank you.



-- 

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




-- 

Best = regards,
Kathleen
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_88AF9099-06E5-4CDB-ADFD-60245BFEB785-- From nobody Thu Oct 13 07:31:17 2016 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 D6E9F1294B9; Thu, 13 Oct 2016 07:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 oCiFTJ6vGTn8; Thu, 13 Oct 2016 07:31:10 -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 835B3129467; Thu, 13 Oct 2016 07:31:10 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DEV4dn023166 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 14:31:04 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9DEV4LC010149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 14:31:04 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9DEV3sl000803; Thu, 13 Oct 2016 14:31:03 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 07:31:02 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_253BCC55-B89F-4D26-A331-DF6944F773AB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 13 Oct 2016 10:28:00 -0400 Message-Id: <427EB3A8-2BE4-4EDA-B8FE-9538243B8D27@oracle.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:31:15 -0000 --Apple-Mail=_253BCC55-B89F-4D26-A331-DF6944F773AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why move a web protocol off the web? You would want it to be HTTP but = on another port? These events are co-ordinating security events between web based = systems. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 9:51 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 13/10/16 14:32, Alexey Melnikov wrote: >> Hi Stephen, >>=20 >> On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> charter-ietf-secevent-00-00: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-secevent/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> I have a few things I'd like to see improved before this WG is >>> approved. It's fine that that's done during external evaluation >>> though. >>=20 >> Thank you. Let's do this while the charter is out for External = Review. >=20 > Right, I hope it'll not be hard. >=20 >>=20 >>> - What is an "identity related protocol"? I think it'd be way better >>> to be as specific as possible about what's meant here. >>>=20 >>> - I'm concerned that this bit is overly generic and will lead to >>> delays. It'd be better if the set of relevant events was better=20 >>> characterised in the charter before we start I think. >>>=20 >>> "The Security Events working group will produce a standards-track >>> Event Token >>> specification that includes: >>> - A JWT extension for expressing security events >>> - A syntax that enables event-specific data to be conveyed" >>=20 >> Agreed. >>=20 >>> - I agree with Kathleen that only secure transports make sense >>> here and that can and should be in the charter. >>=20 >> I am not convinced, see my reply to Kathleen. >=20 > Well, the protocol payload may be signed or encrypted, sure > and there may be non-standard ways to communicate that say > between two processes on the same host, but I don't see why > there's a need for e.g. sending on port 80 ever. If there > is then it'd be good to have the WG justify that explicitly > maybe. >=20 >>=20 >>> - I think there's some missing text on privacy - we don't want this >>> work to end up helping e.g. advertisers track people across web >>> sites. And we don't want exchange of event information to lead=20 >>> to two co-operating partners being able to build up databases of >>> each others' employees. I'm not sure what'd be right to put in >>> the charter though. >>=20 >> If you can suggest some text, I can try to reword and find some place >> for it. >=20 > TBH, I'm not sure. I think it depends on the better > characterising the set of events issue. If this is > mainly for inter-enterprise stuff about employees > that's one thing. If it's mainly for something else > on the public Internet then different considerations > may apply. But since I'm not clear on that (yet) I > don't know what'd make sense to put in the charter. >=20 > Cheers, > S. >=20 >=20 >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_253BCC55-B89F-4D26-A331-DF6944F773AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Why move a web protocol off the web? =  You would want it to be HTTP but on another port?

These events are = co-ordinating security events between web based systems.





On Oct 13, 2016, at 9:51 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 13/10/16 14:32, Alexey Melnikov = wrote:
Hi = Stephen,

On Thu, Oct 13, 2016, at 02:24 PM, = Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position = for
charter-ietf-secevent-00-00: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)



The document, along with other ballot positions, can be found = here:
https://datatracker.ietf.org/doc/charter-ietf-secevent/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------


I have a few things = I'd like to see improved before this WG is
approved. It's = fine that that's done during external evaluation
though.

Thank you. Let's do this while = the charter is out for External Review.

Right, I hope it'll = not be hard.


- What is an "identity related protocol"? I = think it'd be way better
to be as specific as possible = about what's meant here.

- I'm concerned = that this bit is overly generic and will lead to
delays. = It'd be better if the set of relevant events was better 
characterised = in the charter before we start I think.

  "The Security Events working group will produce a = standards-track
Event Token
  specification that includes:
   - A JWT extension for expressing security = events
   - A syntax that enables = event-specific data to be conveyed"

Agreed.

- I agree with Kathleen that only secure transports make = sense
here and that can and should be in the charter.

I am not convinced, see my reply = to Kathleen.

Well, the protocol payload may be signed = or encrypted, sure
and there may be non-standard ways to = communicate that say
between two processes on the same host, = but I don't see why
there's a need for e.g. sending on port = 80 ever. If there
is then it'd be good to have the WG justify that = explicitly
maybe.


- I think there's some = missing text on privacy - we don't want this
work to end = up helping e.g. advertisers track people across web
sites. = And we don't want exchange of event information to lead 
to two = co-operating partners being able to build up databases of
each others' employees. I'm not sure what'd be right to put = in
the charter though.

If you can suggest some text, I can try to reword and find = some place
for it.

TBH, I'm not sure. = I think it depends on the better
characterising the set of events issue. = If this is
mainly for inter-enterprise stuff about = employees
that's one thing. If it's mainly for something = else
on the public Internet then different = considerations
may apply. But since I'm not clear on that (yet) = I
don't know what'd make sense to put in the = charter.

Cheers,
S.




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

= --Apple-Mail=_253BCC55-B89F-4D26-A331-DF6944F773AB-- From nobody Thu Oct 13 07:31:35 2016 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 961E01294B9; Thu, 13 Oct 2016 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 N5YpciciadjK; Thu, 13 Oct 2016 07:31:11 -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 B37AB129480; Thu, 13 Oct 2016 07:31:10 -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 u9DEV5CZ025395 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:31:05 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.14.4) with ESMTP id u9DEV5iZ001816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:31:05 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9DEV4iC025966; Thu, 13 Oct 2016 14:31:04 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 07:31:04 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A145767A-F908-43B0-B567-0AE509F20770" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> Date: Thu, 13 Oct 2016 10:29:44 -0400 Message-Id: <14DA16AA-8341-4C53-8E33-9006B0A9FF48@oracle.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: The IESG , id-event@ietf.org, Stephen Farrell Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:31:15 -0000 --Apple-Mail=_A145767A-F908-43B0-B567-0AE509F20770 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All lot of this has been discussed on the id-events mailing list. But I = think it is worth sharing what I think might be some of the collective = conclusions so far. Starting as far back in Prague and in Yokahama, many of us began to = realize that there were many different async approaches emerging that = did almost the same thing to share events. SCIM provisioning events, = OAuth Token Revocation, OpenID Connect Logout, RISC Security Events, = HEART Consents, were just s few all developing event formats. It was informally agreed that this did not make sense and that = leveraging JWT and its inherent JOSE signing and encryption was = something we all wanted to achieve. =20 Why Generic? (important question!) The specs so far, are intentionally generic. In extensive discussions = we have observed that events have a lot of contextual specialization -- = meaning that different subscribers care about different data points = around seemingly similar events. Past XML approaches like Cybox/STIX = tend to build a single rich event format that results in large payloads = and complexity. While they have more portability they are more complex. = Neither of these traits was viewed as desirable. In contrast, SET is more like a =E2=80=9Cweb=E2=80=9D of pub/sub = relationships where specific information is shared on a need to know = basis. Because there is often a lot of =E2=80=9Ccontext=E2=80=9D between = pair-wise relationships, the amount of data transmitted is very minimal. = The actual transfer can be very RESTy event though it may be delivered = asynchronously from the perspective of some other RESTful state change = initiating action. E.g. a user=E2=80=99s account resource is altered = (e.g. suspended), causing the need to co-ordinate security components. As an example of specialization, compare that a user account reset event = might express many different things within SCIM (a provisioning = protocols), RISC (a peer-wise security incident system), and Security = Logging might all have a notion of an account =E2=80=9Creset=E2=80=9D = event: * The SCIM event, tracks this from a provisioning protocol letting = subscribers know that the reset may need to be propagated. The * RISC = event signals that a provider has noted that an account has been reset, = but the account might be under attack (password reset is an operational = attack vector). The RISC event lets the receiver know that the user = in-common should be treated with a higher level of risk concern.=20 * Security Logging: tracks that a user was reset, but also captures the = conditions around the reset (IP address, etc) much like a web access = log. In this scenario we actually did make it possible in SET to express all = 3 event types simultaneously. However the pragmatic consensus in the = group seems to be that likely subscribers will be specialized and that = hybrid events would probably almost never be used and probably not = desirable. RISC subscribes are probably not interested in getting other = claims there are only interest in assessing risk around subjects. = Provisioning systems meanwhile are trying to specifically co-ordinate = state between domains. Logging systems tend to care about who did what. Regarding Identity Related Protocol: I think this wording could be improved. As with the name change from = id-tokens to security tokens, I think the phrasing should be broadened = slightly. While a lot of SET event types are emerging from the contexts = of specific protocols like OAuth (e.g. token revocation event), I think = there is a higher level notion of =E2=80=9Csystems=E2=80=9D rather than = =E2=80=9Cprotocols=E2=80=9D that are relevant. The reason why =E2=80=9Cidentity=E2=80=9D is important in the = discussion, is that any system that contains personalization or personal = data will eventually share common attack risks. You can devise many = independent systems with no intension to share or co-ordinate data (e.g. = a social network and a financial system), but even in these cases, users = are often in common. A user of a financial system may use their = personal email as an account recovery vector, etc. Amazingly, real users have a tendency to share their real names, their = demographics data, their emails, and yes even passwords. This has set up = the need for security =E2=80=9Csystems=E2=80=9D to build relationships = (in the case of RISC) that span business service providers that may have = previously had no real need for a relationship. Unfortunately, I haven=E2=80=99t got a suggestion. So far, this is an I = know it when I see it situation. Hopefully someone can do better? Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 9:32 AM, Alexey Melnikov = wrote: >=20 > Hi Stephen, >=20 > On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> charter-ietf-secevent-00-00: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-secevent/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >>=20 >> I have a few things I'd like to see improved before this WG is >> approved. It's fine that that's done during external evaluation >> though. >=20 > Thank you. Let's do this while the charter is out for External Review. >=20 >> - What is an "identity related protocol"? I think it'd be way better >> to be as specific as possible about what's meant here. >>=20 >> - I'm concerned that this bit is overly generic and will lead to >> delays. It'd be better if the set of relevant events was better=20 >> characterised in the charter before we start I think. >>=20 >> "The Security Events working group will produce a standards-track >> Event Token >> specification that includes: >> - A JWT extension for expressing security events >> - A syntax that enables event-specific data to be conveyed" >=20 > Agreed. >=20 >> - I agree with Kathleen that only secure transports make sense >> here and that can and should be in the charter. >=20 > I am not convinced, see my reply to Kathleen. >=20 >> - I think there's some missing text on privacy - we don't want this >> work to end up helping e.g. advertisers track people across web >> sites. And we don't want exchange of event information to lead=20 >> to two co-operating partners being able to build up databases of >> each others' employees. I'm not sure what'd be right to put in >> the charter though. >=20 > If you can suggest some text, I can try to reword and find some place > for it. >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_A145767A-F908-43B0-B567-0AE509F20770 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
All lot of this has been discussed on the = id-events mailing list.  But I think it is worth sharing what I = think might be some of the collective conclusions so far.

Starting as far back in Prague and in = Yokahama, many of us began to realize that there were many different = async approaches emerging that did almost the same thing to share = events. SCIM provisioning events, OAuth Token Revocation, OpenID Connect = Logout, RISC Security Events, HEART Consents, were just s few all = developing event formats.

It was informally agreed that this did not make sense and = that leveraging JWT and its inherent JOSE signing and encryption was = something we all wanted to achieve.  

Why Generic? (important = question!)

The = specs so far, are intentionally generic.  In extensive discussions = we have observed that events have a lot of contextual specialization -- = meaning that different subscribers care about different data points = around seemingly similar events. Past XML approaches like Cybox/STIX = tend to build a single rich event format that results in large payloads = and complexity. While they have more portability they are more complex. = Neither of these traits was viewed as desirable.

In contrast, SET is more like a = =E2=80=9Cweb=E2=80=9D of pub/sub relationships where specific = information is shared on a need to know basis. Because there is often a = lot of =E2=80=9Ccontext=E2=80=9D between pair-wise relationships, the = amount of data transmitted is very minimal.  The actual transfer = can be very RESTy event though it may be delivered asynchronously from = the perspective of some other RESTful state change initiating action. =  E.g. a user=E2=80=99s account resource is altered (e.g. = suspended), causing the need to co-ordinate security = components.

As = an example of specialization, compare that a user account reset event = might express many different things within SCIM (a provisioning = protocols), RISC (a peer-wise security incident system), and Security = Logging might all have a notion of an account =E2=80=9Creset=E2=80=9D = event:
* The SCIM event, tracks this from a = provisioning protocol letting subscribers know that the reset may need = to be propagated.  The * RISC event signals that a provider has = noted that an account has been reset, but the account might be under = attack (password reset is an operational attack vector).  The RISC = event lets the receiver know that the user in-common should be treated = with a higher level of risk concern. 
* = Security Logging:  tracks that a user was reset, but also captures = the conditions around the reset (IP address, etc) much like a web access = log.

In this = scenario we actually did make it possible in SET to express all 3 event = types simultaneously. However the pragmatic consensus in the group seems = to be that likely subscribers will be specialized and that hybrid events = would probably almost never be used and probably not desirable. RISC = subscribes are probably not interested in getting other claims there are = only interest in assessing risk around subjects. Provisioning systems = meanwhile are trying to specifically co-ordinate state between domains. = Logging systems tend to care about who did what.

Regarding Identity Related = Protocol:

I = think this wording could be improved. As with the name change from = id-tokens to security tokens, I think the phrasing should be broadened = slightly.  While a lot of SET event types are emerging from the = contexts of specific protocols like OAuth (e.g. token revocation event), = I think there is a higher level notion of =E2=80=9Csystems=E2=80=9D = rather than =E2=80=9Cprotocols=E2=80=9D that are relevant.

The reason why = =E2=80=9Cidentity=E2=80=9D is important in the discussion, is that any = system that contains personalization or personal data will eventually = share common attack risks. You can devise many independent systems with = no intension to share or co-ordinate data (e.g. a social network and a = financial system), but even in these cases, users are often in common. =  A user of a financial system may use their personal email as an = account recovery vector, etc.

Amazingly, real users = have a tendency to share their real names, their demographics data, = their emails, and yes even passwords. This has set up the need for = security =E2=80=9Csystems=E2=80=9D to build relationships (in the case = of RISC) that span business service providers that may have previously = had no real need for a relationship.

Unfortunately, I haven=E2=80=99t got a = suggestion. So far, this is an I know it when I see it situation. = Hopefully someone can do better?




On Oct 13, 2016, at 9:32 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi = Stephen,

On Thu, Oct 13, 2016, at 02:24 PM, = Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position = for
charter-ietf-secevent-00-00: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)



The document, along with other ballot positions, can be found = here:
https://datatracker.ietf.org/doc/charter-ietf-secevent/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------


I have a few things = I'd like to see improved before this WG is
approved. It's = fine that that's done during external evaluation
though.

Thank you. Let's do this while = the charter is out for External Review.

- What is an "identity = related protocol"? I think it'd be way better
to be as = specific as possible about what's meant here.

- I'm concerned that this bit is overly generic and will lead = to
delays. It'd be better if the set of relevant events = was better
characterised in the charter before we start I = think.

  "The Security Events = working group will produce a standards-track
Event = Token
  specification that includes:
   - A JWT extension for expressing security = events
   - A syntax that enables = event-specific data to be conveyed"

Agreed.

- I agree with Kathleen that only secure transports make = sense
here and that can and should be in the charter.

I am not convinced, see my reply = to Kathleen.

- I think there's some missing text on privacy - we don't = want this
work to end up helping e.g. advertisers track = people across web
sites. And we don't want exchange of = event information to lead
to two co-operating partners = being able to build up databases of
each others' = employees. I'm not sure what'd be right to put in
the = charter though.

If you can = suggest some text, I can try to reword and find some place
for it.

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

= --Apple-Mail=_A145767A-F908-43B0-B567-0AE509F20770-- From nobody Thu Oct 13 07:43:48 2016 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 DCB711294CD; Thu, 13 Oct 2016 07:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 6tbuIw1pwFsx; Thu, 13 Oct 2016 07:43:39 -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 573EC1293FF; Thu, 13 Oct 2016 07:43:39 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DEhW7i011342 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:43:32 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u9DEhVYF014452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:43:32 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9DEhPBX001228; Thu, 13 Oct 2016 14:43:31 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 07:43:25 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_83E78443-9673-4034-AC65-2D8BE567916E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 13 Oct 2016 10:43:23 -0400 Message-Id: <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:43:42 -0000 --Apple-Mail=_83E78443-9673-4034-AC65-2D8BE567916E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > Well, the protocol payload may be signed or encrypted, sure > and there may be non-standard ways to communicate that say > between two processes on the same host, but I don't see why > there's a need for e.g. sending on port 80 ever. If there > is then it'd be good to have the WG justify that explicitly > maybe. I am a bit confused. We=E2=80=99re talking about co-ordinated event = security typically between HTTP based (e.g. web) systems. JWT was designed to be transported using HTTP. Not sure I see why there is an issue with using HTTP port 80.=20 Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 9:51 AM, Stephen Farrell = > wrote: >=20 >=20 > Hiya, >=20 > On 13/10/16 14:32, Alexey Melnikov wrote: >> Hi Stephen, >>=20 >> On Thu, Oct 13, 2016, at 02:24 PM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> charter-ietf-secevent-00-00: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-secevent/ = >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> I have a few things I'd like to see improved before this WG is >>> approved. It's fine that that's done during external evaluation >>> though. >>=20 >> Thank you. Let's do this while the charter is out for External = Review. >=20 > Right, I hope it'll not be hard. >=20 >>=20 >>> - What is an "identity related protocol"? I think it'd be way better >>> to be as specific as possible about what's meant here. >>>=20 >>> - I'm concerned that this bit is overly generic and will lead to >>> delays. It'd be better if the set of relevant events was better=20 >>> characterised in the charter before we start I think. >>>=20 >>> "The Security Events working group will produce a standards-track >>> Event Token >>> specification that includes: >>> - A JWT extension for expressing security events >>> - A syntax that enables event-specific data to be conveyed" >>=20 >> Agreed. >>=20 >>> - I agree with Kathleen that only secure transports make sense >>> here and that can and should be in the charter. >>=20 >> I am not convinced, see my reply to Kathleen. >=20 > Well, the protocol payload may be signed or encrypted, sure > and there may be non-standard ways to communicate that say > between two processes on the same host, but I don't see why > there's a need for e.g. sending on port 80 ever. If there > is then it'd be good to have the WG justify that explicitly > maybe. >=20 >>=20 >>> - I think there's some missing text on privacy - we don't want this >>> work to end up helping e.g. advertisers track people across web >>> sites. And we don't want exchange of event information to lead=20 >>> to two co-operating partners being able to build up databases of >>> each others' employees. I'm not sure what'd be right to put in >>> the charter though. >>=20 >> If you can suggest some text, I can try to reword and find some place >> for it. >=20 > TBH, I'm not sure. I think it depends on the better > characterising the set of events issue. If this is > mainly for inter-enterprise stuff about employees > that's one thing. If it's mainly for something else > on the public Internet then different considerations > may apply. But since I'm not clear on that (yet) I > don't know what'd make sense to put in the charter. >=20 > Cheers, > S. >=20 >=20 >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_83E78443-9673-4034-AC65-2D8BE567916E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Well, the protocol payload may be signed or = encrypted, sure
and there may be non-standard ways to = communicate that say
between two processes on the same = host, but I don't see why
there's a need for = e.g. sending on port 80 ever. If there
is then = it'd be good to have the WG justify that explicitly
maybe.

I am a bit confused. = We=E2=80=99re talking about co-ordinated event security typically = between HTTP  based (e.g. web) systems.

JWT was designed to be transported = using HTTP.

Not = sure I see why there is an issue with using HTTP port = 80. 





On Oct 13, 2016, at 9:51 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 13/10/16 14:32, Alexey Melnikov = wrote:
Hi = Stephen,

On Thu, Oct 13, 2016, at 02:24 PM, = Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position = for
charter-ietf-secevent-00-00: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)



The document, along with other ballot positions, can be found = here:
https://datatracker.ietf.org/doc/charter-ietf-secevent/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------


I have a few things = I'd like to see improved before this WG is
approved. It's = fine that that's done during external evaluation
though.

Thank you. Let's do this while = the charter is out for External Review.

Right, I hope it'll = not be hard.


- What is an "identity related protocol"? I = think it'd be way better
to be as specific as possible = about what's meant here.

- I'm concerned = that this bit is overly generic and will lead to
delays. = It'd be better if the set of relevant events was better 
characterised = in the charter before we start I think.

  "The Security Events working group will produce a = standards-track
Event Token
  specification that includes:
   - A JWT extension for expressing security = events
   - A syntax that enables = event-specific data to be conveyed"

Agreed.

- I agree with Kathleen that only secure transports make = sense
here and that can and should be in the charter.

I am not convinced, see my reply = to Kathleen.

Well, the protocol payload may be signed = or encrypted, sure
and there may be non-standard ways to = communicate that say
between two processes on the same host, = but I don't see why
there's a need for e.g. sending on port = 80 ever. If there
is then it'd be good to have the WG justify that = explicitly
maybe.


- I think there's some = missing text on privacy - we don't want this
work to end = up helping e.g. advertisers track people across web
sites. = And we don't want exchange of event information to lead 
to two = co-operating partners being able to build up databases of
each others' employees. I'm not sure what'd be right to put = in
the charter though.

If you can suggest some text, I can try to reword and find = some place
for it.

TBH, I'm not sure. = I think it depends on the better
characterising the set of events issue. = If this is
mainly for inter-enterprise stuff about = employees
that's one thing. If it's mainly for something = else
on the public Internet then different = considerations
may apply. But since I'm not clear on that (yet) = I
don't know what'd make sense to put in the = charter.

Cheers,
S.




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

= --Apple-Mail=_83E78443-9673-4034-AC65-2D8BE567916E-- From nobody Thu Oct 13 07:49:03 2016 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 4B9E41294DF; Thu, 13 Oct 2016 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Ku99Wes2CdMT; Thu, 13 Oct 2016 07:48:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EE71294D5; Thu, 13 Oct 2016 07:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9939FBEBB; Thu, 13 Oct 2016 15:48:53 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1_63c8mNhV7; Thu, 13 Oct 2016 15:48:53 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 02438BE83; Thu, 13 Oct 2016 15:48:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476370133; bh=RVlm3iTXa7Sx0jdtewSNXD9DCPJG5uDLdEs1eif+fVQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=j2197wyaygxVJSAyN+PdB4V5bwg1cbiLfP9/Wwamix+G4BFduCsjG3g+lgssCzU6G 7YmNESQtaznBNJnfRNOkMrkYz/M0vccgR/TCbPWCBpKUZJmtxZfk8BKfYIwf56tHhj GPFveUufUVRCH1qm3SpqJ9OTCW6mchx2Yf+Kkpko= To: Phil Hunt References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> Date: Thu, 13 Oct 2016 15:48:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000708060401060801080403" Archived-At: Cc: The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:48:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000708060401060801080403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/10/16 15:43, Phil Hunt wrote: > Not sure I see why there is an issue with using HTTP port 80.=20 Well, if we're transporting sensitive information then I'm not clear why that'd even be sent on port 80 unless there's a specific need for that. Is there? S. --------------ms000708060401060801080403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTMx NDQ4NTNaMC8GCSqGSIb3DQEJBDEiBCB7UoA233SaFHEpLOnBGPbgpX7tzbuN1P2exyPtmmgW QzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBR7+tAlSnfjAKOJ8q4jvDzX0AarKdXkD4eBOAwrGsCPKRVXrHZ2SjY g6JE5A6ocs/KuHnI/bNal+/U5+YY63klYp+slmD4H2A/XDa6cCFxFDrWfP08U2ZdK7kX8gy7 Mq5A1KoKy2LRPNAQQiCh8SPvSXNIOyuKVJaYnBArmmShHsJRSoFXFTcKG6kqKh5XiW9POvDI yhxqnVfz0Z7yYBbpm3b/npQOuAS/76G5aHAYeFReRqbWbuDloOXlERxohd2K3mjgoyWo/Rh3 WmZWrMPGyb+ODK1REZkur8RHW490VeCbcMq4xvstjtfzLVYvL5vPsRyOMc7psy40ImFYcE2U AAAAAAAA --------------ms000708060401060801080403-- From nobody Thu Oct 13 07:52:38 2016 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 A115F1294CB; Thu, 13 Oct 2016 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 ZwVyZInapUaW; Thu, 13 Oct 2016 07:52:29 -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 C3225129449; Thu, 13 Oct 2016 07:52:29 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DEqOiL027278 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 14:52:24 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9DEqOit020679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 14:52:24 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9DEqLv4007478; Thu, 13 Oct 2016 14:52:23 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 07:52:21 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_77DFE702-7B86-49D3-AAF7-4DBE916381FD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> Date: Thu, 13 Oct 2016 10:52:19 -0400 Message-Id: References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:52:31 -0000 --Apple-Mail=_77DFE702-7B86-49D3-AAF7-4DBE916381FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 These are all web protocols. JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems = prudent to build on that. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 10:48 AM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 13/10/16 15:43, Phil Hunt wrote: >> Not sure I see why there is an issue with using HTTP port 80.=20 >=20 > Well, if we're transporting sensitive information > then I'm not clear why that'd even be sent on port > 80 unless there's a specific need for that. Is > there? >=20 > S. >=20 --Apple-Mail=_77DFE702-7B86-49D3-AAF7-4DBE916381FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 These are all web protocols.

JWT itself is secure enough to be URL = safe. So, it=E2=80=99s seems prudent to build on that.




On Oct 13, 2016, at 10:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 13/10/16 15:43, Phil Hunt wrote:
Not sure I see why there = is an issue with using HTTP port 80.

Well, if we're transporting sensitive information
then I'm not clear why that'd even be sent on port
80 unless there's a specific need for that. Is
there?

S.


= --Apple-Mail=_77DFE702-7B86-49D3-AAF7-4DBE916381FD-- From nobody Thu Oct 13 07:54:14 2016 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 BF1311294CB; Thu, 13 Oct 2016 07:54:13 -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, FREEMAIL_FROM=0.001, 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=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 Yc-yvnruryb1; Thu, 13 Oct 2016 07:54:11 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 298D1129480; Thu, 13 Oct 2016 07:54:11 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id q126so28050725vkd.2; Thu, 13 Oct 2016 07:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZHXC9kADVnXb7n8tuh4Iik/CTk+H3Kka4bwuX56KiOA=; b=LHjGJ93AulOs5HVZOw/uwAYWc4QCas/1QavWNeGaHaAFjVpQlkYHOKHLakyGHZVWDB GKJdcFJ6XKzqLVMLOmg1w8BQS2yGINqV9NSceGqWZEIY1TaQb0LMwR8S3PAo1DM/y3tP IhyvKEh0/hxWhQVY77sTxRI6EMGV/9rvZbHUgS5rtkMRA2pFaOs6DjXKp99PEKGgeS4b Zqd6E+lqggjAtBsQqrIlCKkX8JlLOMzd3f/DBXMgnMrIGtiyw3mmxkweMQ19Z9QEZqsG u/IursCvo9uSWVQwg2iwRn7qcLri8cHV555jrxltPyO4V1Fk/Un37Q1hds5VtMH4JchE fAtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZHXC9kADVnXb7n8tuh4Iik/CTk+H3Kka4bwuX56KiOA=; b=l7ICNCkXqOvh29/zE71HWsDyeEYIqpB7L1/FovFdfa89CWM1yWpGnubhDnI1cq5yet dQLxgLGfeencj1jJG/3rkvT+M/CdcIKrR5468dvn5fs2wkK5+Cj7XMt//Y7XfyEsyph3 a0mLpCbs5wzWJEXwAsK0E295InqQSge2A3x41jj9uWkvRIDU3ajX/UaXk7T+v1vmWQaa +bh/7bH5CiDIYeCeR0RMs0ueSX7VETtjP2FGasUXyyTaLZURHWYONau+LW+HM/9heL1s WdE7rBp0ykyJkdV227o6EaAGYPtEYoOdikX5jgh8NlAO2YSNnyUCisN8Gds4SYYYWAhp s/WQ== X-Gm-Message-State: AA6/9Rn1e8N6vN8Brsj4Xh527zsHhiNvw7qiaxpFWDpOuXebXUIrxH+ObVvb3G9v6UoRhvcgQxWRBDZeowH5Gw== X-Received: by 10.31.69.16 with SMTP id s16mr4994635vka.115.1476370442659; Thu, 13 Oct 2016 07:54:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 13 Oct 2016 07:54:02 -0700 (PDT) In-Reply-To: References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> <1BFB9696-B45D-4F98-9F1F-BA2D64BD4EB5@oracle.com> From: Kathleen Moriarty Date: Thu, 13 Oct 2016 10:54:02 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a114db3cecaaeac053ec047b3 Archived-At: Cc: secevent-chairs@ietf.org, Alexey Melnikov , The IESG , id-event@ietf.org Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 14:54:13 -0000 --001a114db3cecaaeac053ec047b3 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 13, 2016 at 10:23 AM, Phil Hunt wrote: > Right here (first bullet): > > The working group will also develop a simple standards-track Event Delivery > specification that includes: > - A method for delivering events using HTTP POST (push) > - Metadata for describing event feeds > - Methods for subscribing to and managing event feeds > - Methods for validating event feed subscriptions > > > Hmm, I don't think that's clear enough. Can you expand on it a bit? Thanks, Kathleen > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Oct 13, 2016, at 10:07 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Hi Phil, > > On Thu, Oct 13, 2016 at 9:40 AM, Phil Hunt wrote: > >> Maybe I am reading the charter wrong. But the charter should indicate >> that we will develop one secure transport based on HTTP POST. >> > > Can you point out where in the charter you see it already covered as I'm > missing it and it seems others are too. > > >> >> With that said, it is entirely possible that SETs could be delivered over >> insecure (depending on what is meant) channels. We chose JWT because they >> can themselves be signed and encrypted. I have initially suggested a >> registry be defined that would help shape future transport specs by >> alerting profiling authors to cover a minimum set of security issues either >> in transport or within the token itself. >> > > Yes, Stephen mentioned this as well and I agree, but some mention of > security methods should be in the charter. I tried to make as simple a > statement as possible to not restrict it, but feel free to propose > something else that encompasses the possible acceptable solutions. > > Thank you, > Kathleen > > >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> >> >> On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov >> wrote: >> >>> Hi Kathleen, >>> >>> On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: >>> > Kathleen Moriarty has entered the following ballot position for >>> > charter-ietf-secevent-00-00: No Objection >>> > >>> > When responding, please keep the subject line intact and reply to all >>> > email addresses included in the To and CC lines. (Feel free to cut this >>> > introductory paragraph, however.) >>> > >>> > >>> > >>> > The document, along with other ballot positions, can be found here: >>> > https://datatracker.ietf.org/doc/charter-ietf-secevent/ >>> > >>> > >>> > >>> > ---------------------------------------------------------------------- >>> > COMMENT: >>> > ---------------------------------------------------------------------- >>> > >>> > Shouldn't the method for delivering the event be a secure method? >>> > >>> > How about adding on a sentence after the following section: >>> > The Security Events working group will produce a standards-track Event >>> > Token >>> > specification that includes: >>> > - A JWT extension for expressing security events >>> > - A syntax that enables event-specific data to be conveyed >>> > This Event Token specification will be event transport independent. >>> > >>> > Adding: A secure transport will be specified. >>> >>> I think the charter is saying that work on a specific transport is out >>> of scope. I would rather this WG not work on any transport, but I agree >>> that a secure transport should be recommended. >>> >> >> Yes, that's what I meant by specified, but haven't had any caffeine yet >> and should not have used that word. Recommended is a good choice. Thank >> you. >> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- Best regards, Kathleen --001a114db3cecaaeac053ec047b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 13, 2016 at 10:23 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Right here (first bullet):
The working group will also develop a simple standards-track Event Deliv=
ery
specification that includes:
 - A method for delivering events using HTTP POST (push)
 - Metadata for describing event feeds
 - Methods for subscribing to and managing event feeds
 - Methods for validating event feed subscriptions

Hmm, I don't think that's clear enough.= =C2=A0 Can you expand on it a bit?

Thanks,
Kathleen

On Oct 13, 2016, at 10:07 AM, Kathl= een Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi= Phil,

On Thu, Oct= 13, 2016 at 9:40 AM, Phil Hunt=C2=A0<phil.hunt@oracle.com>=C2=A0wrote= :
Maybe I am readin= g the charter wrong. But the charter should indicate that we will develop o= ne secure transport based on HTTP POST.

Can you point out where in the charter you see it already covered as I&#= 39;m missing it and it seems others are too.
=C2=A0

With that = said, it is entirely possible that SETs could be delivered over insecure (d= epending on what is meant) channels. We chose JWT because they can themselv= es be signed and encrypted.=C2=A0 I have initially suggested a registry be = defined that would help shape future transport specs by alerting profiling = authors to cover a minimum set of security issues either in transport or wi= thin the token itself.

Yes, Ste= phen mentioned this as well and I agree, but some mention of security metho= ds should be in the charter.=C2=A0 I tried to make as simple a statement as= possible to not restrict it, but feel free to propose something else that = encompasses the possible acceptable solutions.

Tha= nk you,
Kathleen
=C2=A0

Phil

@independentid
<= a href=3D"http://www.independentid.com/" target=3D"_blank">www.independenti= d.com
phil.hunt@oracle.com

<= br class=3D"m_8349212625766749166m_8591322407383362262Apple-interchange-new= line">



On Oct 13, 2016, at 9:37 AM, Kathl= een Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

=


On Thu, Oc= t 13, 2016 at 9:29 AM, Alexey Melnikov=C2=A0&= lt;aamelnikov@f= astmail.fm>=C2=A0wrote:
= Hi Kathleen,

On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote:
&g= t; Kathleen Moriarty has entered the following ballot position for
> = charter-ietf-secevent-00-00: No Objection
>
> When responding, = please keep the subject line intact and reply to all
> email addresse= s included in the To and CC lines. (Feel free to cut this
> introduct= ory paragraph, however.)
>
>
>
> The document, alon= g with other ballot positions, can be found here:
>=C2=A0= https://datatracker.ietf.org/doc/charter= -ietf-secevent/
>
>
>
> -----------------------= -----------------------------------------------
> COMMENT:<= br>> ----------------------------------------------------------------------
>
> Shouldn't the method for delivering the e= vent be a secure method?
>
> How about adding on a sentence aft= er the following section:
> The Security Events working group will pr= oduce a standards-track Event
> Token
> specification that incl= udes:
>=C2=A0 - A JWT extension for expressing security events
>= ;=C2=A0 - A syntax that enables event-specific data to be conveyed
> = This Event Token specification will be event transport independent.
>=
> Adding: A secure transport will be specified.

I= think the charter is saying that work on a specific transport is out
of= scope. I would rather this WG not work on any transport, but I agree
th= at a secure transport should be recommended.

Yes, that's what I meant by specified, but haven't had any ca= ffeine yet and should not have used that word. Recommended is a good choice= .=C2=A0 Thank you.



--= =C2=A0

Best regards,
Kathleen
= _________________________________= ______________
Id-event mailing l= ist
Id-event@ietf.or= g
https://www.ietf.org/mailman/listinfo/id-event
=



<= br>
--=C2= =A0

Best regards,
Kathleen
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/l= istinfo/id-event



--

Best regards,
Kathleen
--001a114db3cecaaeac053ec047b3-- From nobody Thu Oct 13 08:03:25 2016 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 211B012946E; Thu, 13 Oct 2016 08:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 aTlWeM-PrjJD; Thu, 13 Oct 2016 08:03:16 -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 E86CE1294CB; Thu, 13 Oct 2016 08:03:15 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DF3A4h018355 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 15:03:10 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u9DF39FM031263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 15:03:09 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9DF37T2015547; Thu, 13 Oct 2016 15:03:08 GMT Received: from [10.141.118.192] (/72.38.99.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 08:03:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC76E5FB-705F-4414-A30B-5740B14864C4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 13 Oct 2016 11:03:03 -0400 Message-Id: References: <147636512746.2878.8097517648775239072.idtracker@ietfa.amsl.com> <1476365352.1637484.754780065.6D2DCAB4@webmail.messagingengine.com> <1BFB9696-B45D-4F98-9F1F-BA2D64BD4EB5@oracle.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Kathleen Moriarty's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 15:03:21 -0000 --Apple-Mail=_FC76E5FB-705F-4414-A30B-5740B14864C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kathleen, My apologies. I wonder if you, Stephen and I, are all in different = places on transport. :) If it helps, here is the distribution draft I was going to propose for = consideration in Seoul that covers this: https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 I understand if that it too much detail. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 10:54 AM, Kathleen Moriarty = wrote: >=20 >=20 >=20 > On Thu, Oct 13, 2016 at 10:23 AM, Phil Hunt > wrote: > Right here (first bullet): > The working group will also develop a simple standards-track Event = Delivery > specification that includes: > - A method for delivering events using HTTP POST (push) > - Metadata for describing event feeds > - Methods for subscribing to and managing event feeds > - Methods for validating event feed subscriptions >=20 > Hmm, I don't think that's clear enough. Can you expand on it a bit? >=20 > Thanks, > Kathleen > =20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Oct 13, 2016, at 10:07 AM, Kathleen Moriarty = > wrote: >>=20 >> Hi Phil, >>=20 >> On Thu, Oct 13, 2016 at 9:40 AM, Phil Hunt > wrote: >> Maybe I am reading the charter wrong. But the charter should indicate = that we will develop one secure transport based on HTTP POST. >>=20 >> Can you point out where in the charter you see it already covered as = I'm missing it and it seems others are too. >> =20 >>=20 >> With that said, it is entirely possible that SETs could be delivered = over insecure (depending on what is meant) channels. We chose JWT = because they can themselves be signed and encrypted. I have initially = suggested a registry be defined that would help shape future transport = specs by alerting profiling authors to cover a minimum set of security = issues either in transport or within the token itself. >>=20 >> Yes, Stephen mentioned this as well and I agree, but some mention of = security methods should be in the charter. I tried to make as simple a = statement as possible to not restrict it, but feel free to propose = something else that encompasses the possible acceptable solutions. >>=20 >> Thank you, >> Kathleen >> =20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty = > wrote: >>>=20 >>>=20 >>>=20 >>> On Thu, Oct 13, 2016 at 9:29 AM, Alexey Melnikov = > wrote: >>> Hi Kathleen, >>>=20 >>> On Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote: >>> > Kathleen Moriarty has entered the following ballot position for >>> > charter-ietf-secevent-00-00: No Objection >>> > >>> > When responding, please keep the subject line intact and reply to = all >>> > email addresses included in the To and CC lines. (Feel free to cut = this >>> > introductory paragraph, however.) >>> > >>> > >>> > >>> > The document, along with other ballot positions, can be found = here: >>> > https://datatracker.ietf.org/doc/charter-ietf-secevent/ = >>> > >>> > >>> > >>> > = ---------------------------------------------------------------------- >>> > COMMENT: >>> > = ---------------------------------------------------------------------- >>> > >>> > Shouldn't the method for delivering the event be a secure method? >>> > >>> > How about adding on a sentence after the following section: >>> > The Security Events working group will produce a standards-track = Event >>> > Token >>> > specification that includes: >>> > - A JWT extension for expressing security events >>> > - A syntax that enables event-specific data to be conveyed >>> > This Event Token specification will be event transport = independent. >>> > >>> > Adding: A secure transport will be specified. >>>=20 >>> I think the charter is saying that work on a specific transport is = out >>> of scope. I would rather this WG not work on any transport, but I = agree >>> that a secure transport should be recommended. >>>=20 >>> Yes, that's what I meant by specified, but haven't had any caffeine = yet and should not have used that word. Recommended is a good choice. = Thank you. >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_FC76E5FB-705F-4414-A30B-5740B14864C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kathleen,

My apologies. I wonder if you, Stephen and I, are all in = different places on transport.  :)

If it helps, here is the distribution = draft I was going to propose for consideration in Seoul that covers = this:
https://tools.ietf.org/html/draft-hunt-idevent-distribution-01<= /a>

I = understand if that it too much detail.




On Oct 13, 2016, at 10:54 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:


On Thu, Oct 13, 2016 at 10:23 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Right here (first = bullet):
The working group will also develop a simple standards-track =
Event Delivery
specification that includes:
 - A method for delivering events using HTTP POST (push)
 - Metadata for describing event feeds
 - Methods for subscribing to and managing event feeds
 - Methods for validating event feed subscriptions

Hmm, I don't think that's clear enough.  Can you expand = on it a bit?

Thanks,
Kathleen
 
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On Oct 13, 2016, at 10:07 AM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hi Phil,

On Thu, Oct 13, 2016 at 9:40 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Maybe= I am reading the charter wrong. But the charter should indicate that we = will develop one secure transport based on HTTP = POST.

Can you point out where in the charter you see it already = covered as I'm missing it and it seems others are too.
 

With that said, it is entirely possible = that SETs could be delivered over insecure (depending on what is meant) = channels. We chose JWT because they can themselves be signed and = encrypted.  I have initially suggested a registry be defined that = would help shape future transport specs by alerting profiling authors to = cover a minimum set of security issues either in transport or within the = token itself.

Yes, Stephen mentioned this as well and = I agree, but some mention of security methods should be in the = charter.  I tried to make as simple a statement as possible to not = restrict it, but feel free to propose something else that encompasses = the possible acceptable solutions.

Thank you,
Kathleen
 

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On Oct 13, 2016, at 9:37 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:



On Thu, Oct 13, 2016 at = 9:29 AM, Alexey Melnikov=  <aamelnikov@fastmail.fm>=  wrote:
Hi Kathleen,

On = Thu, Oct 13, 2016, at 02:25 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot = position for
> charter-ietf-secevent-00-00: No = Objection
>
> When responding, please = keep the subject line intact and reply to all
> email = addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, = along with other ballot positions, can be found here:
>=  https://datatracker.ietf.org/doc/charter-ietf-secevent/
>
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> Shouldn't the method for delivering = the event be a secure method?
>
> How = about adding on a sentence after the following section:
>= The Security Events working group will produce a standards-track = Event
> Token
> specification that = includes:
>  - A JWT extension for expressing = security events
>  - A syntax that enables = event-specific data to be conveyed
> This Event Token = specification will be event transport independent.
>
> Adding: A secure transport will be specified.

I think the charter is saying that = work on a specific transport is out
of scope. I would = rather this WG not work on any transport, but I agree
that = a secure transport should be recommended.

Yes, that's what I meant = by specified, but haven't had any caffeine yet and should not have used = that word. Recommended is a good choice.  Thank you.



--=  

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




-- 

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




-- 

Best = regards,
Kathleen
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_FC76E5FB-705F-4414-A30B-5740B14864C4-- From nobody Thu Oct 13 12:11:11 2016 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 ED72C129513; Thu, 13 Oct 2016 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.696 X-Spam-Level: X-Spam-Status: No, score=-6.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, 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 LIpg8UBUrRHz; Thu, 13 Oct 2016 12:11:03 -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 260A41294C1; Thu, 13 Oct 2016 12:11:03 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DJAtYe026124 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 19:10:56 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u9DJAqJW021077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 19:10:55 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9DJAeCe026988; Thu, 13 Oct 2016 19:10:46 GMT Received: from [10.26.162.67] (/184.151.114.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 12:10:40 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-537B14F0-CBAC-4E65-9EE0-B58844059483 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Thu, 13 Oct 2016 15:10:25 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> To: Stephen Farrell X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Kathleen Moriarty , Alexey Melnikov , The IESG , id-event@ietf.org Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 19:11:05 -0000 --Apple-Mail-537B14F0-CBAC-4E65-9EE0-B58844059483 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen, I think I see my disconnect. I thought you were suggesting we should not use= http at all and do a new protocol.=20 Assuming you mean use 443 as in HTTPS this makes sense for most implementati= ons. The initial distribution draft requires it.=20 Phil > On Oct 13, 2016, at 10:52 AM, Phil Hunt wrote: >=20 > These are all web protocols. >=20 > JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems prudent= to build on that. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >> On Oct 13, 2016, at 10:48 AM, Stephen Farrell = wrote: >>=20 >>=20 >>=20 >> On 13/10/16 15:43, Phil Hunt wrote: >>> Not sure I see why there is an issue with using HTTP port 80.=20 >>=20 >> Well, if we're transporting sensitive information >> then I'm not clear why that'd even be sent on port >> 80 unless there's a specific need for that. Is >> there? >>=20 >> S. >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-537B14F0-CBAC-4E65-9EE0-B58844059483 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Stephen,

I think I see my disconnect.= I thought you were suggesting we should not use http at all and do a new pr= otocol. 

Assuming you mean use 443 as in HTTPS this makes sense for mo= st implementations. The initial distribution draft requires it. 
<= div id=3D"AppleMailSignature">
Phil<= /div>

On Oct 13, 2016, at 10:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

These are all web protocols.

JWT itself is secure enough to be URL safe. So, it=E2= =80=99s seems prudent to build on that.

<= div class=3D"">Phil

@independentid
www.independentid.com

<= br class=3D"Apple-interchange-newline">



On O= ct 13, 2016, at 10:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 13/10/16 15:43, Phil Hunt wrote:
Not sure I see why there is an issue with us= ing HTTP port 80.

Well, if we're t= ransporting sensitive information
then I'm not clear why that'= d even be sent on port
80 unless there's a specific need for t= hat. Is
there?

S.
<= br class=3D"">

________________________= _______________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf= .org/mailman/listinfo/id-event
= --Apple-Mail-537B14F0-CBAC-4E65-9EE0-B58844059483-- From nobody Thu Oct 13 12:19:10 2016 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 1BF801296A7; Thu, 13 Oct 2016 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_MESSAGE=0.001, MIME_QP_LONG_LINE=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=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 k1T_f_VxUVqT; Thu, 13 Oct 2016 12:19:06 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 9139112960C; Thu, 13 Oct 2016 12:19:06 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id f128so103326974qkb.1; Thu, 13 Oct 2016 12:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WT+9mOhqF8UsPjXXLCVpmup22BnYey7waFcbxiY4ATU=; b=WIxuMaYmqmCV3Wcl7ZWscRtYOSLfa6BvGqpTTUjZ5JLgs2vwmzSocZUvkswiSMl6OU TPcvMELgcO8z4RBdTuZYj0g2iGtkPX9pjiL4WbEImJKIp47CkLpbNuW0xzVmDlUh4x3z w1NEt9iUQ3Ennm/o2cdUM6zmv4UWPvXb/F4YUQ4MTz+q/XkcYt3BavDMVC84KsojLnUm jT4R9PJmkQ8GyOgxlHNaFhJKB2RQTex9v7MEkc51rPtYIQll68vDBDKWodoH1RhA2aOj h7fH1tEWP/2patAqfmq0RMLxFj8jbHywFjZOGovNeGUh1w352qKo0vnTL93bOYAW3DoG atTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WT+9mOhqF8UsPjXXLCVpmup22BnYey7waFcbxiY4ATU=; b=R+EXM6DlW+4a/GDd6jQtALypWoLkhhRutdj0j6q0pNntMpx92TLLyK83WHN/PUVhG4 DhGjksoWtrMkYEtB2wd4czr9qQKvWHllsHdQbR0AL2pi/m7YetELH0bpiX392JZ2pqCL OximhQUDE2Yvj7nwz2L+HMKlyfVElxsEkkPfPtzdy/kKDEt50q8TgtRW+QIqSns9+lex xfssg/AZV9YjMybQpq2i4V27QSH7bHTChjNCIatqAz9XeUaxcno2B3Kha0wzOX1+qwln vYNi2pUYLnXE6S2lqLZJn8RBI0zbabwKnr8ZnZm92CnNe1GsNGqGIZ68g4W9IIQ+Z5bX WcMg== X-Gm-Message-State: AA6/9Rkw8fRXWhjrQpqhH+LgOh0nAPReOEvflfrm6Mn50DuqJvA8jDOVedimzq+2GDT45Q== X-Received: by 10.55.203.213 with SMTP id u82mr7590120qkl.311.1476386345017; Thu, 13 Oct 2016 12:19:05 -0700 (PDT) Received: from [192.168.1.4] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id l8sm5546536qtl.18.2016.10.13.12.19.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 12:19:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-062F012E-976C-49F2-B212-320A71EE4AD0 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> Date: Thu, 13 Oct 2016 15:18:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> To: "Phil Hunt (IDM)" Archived-At: Cc: Alexey Melnikov , The IESG , id-event@ietf.org, Stephen Farrell Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 19:19:09 -0000 --Apple-Mail-062F012E-976C-49F2-B212-320A71EE4AD0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please excuse typos, sent from handheld device=20 > On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) wrote:= >=20 > Stephen, >=20 > I think I see my disconnect. I thought you were suggesting we should not u= se http at all and do a new protocol.=20 >=20 > Assuming you mean use 443 as in HTTPS this makes sense for most implementa= tions. The initial distribution draft requires it.=20 That's good. We are just looking for some statement on security in the char= ter as well. I think you didn't like the suggestions so far. As such, coul= d you come up with an appropriate sentence to add that addresses this concer= n? Thanks, Kathleen=20 >=20 > Phil >=20 >> On Oct 13, 2016, at 10:52 AM, Phil Hunt wrote: >>=20 >> These are all web protocols. >>=20 >> JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems pruden= t to build on that. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Oct 13, 2016, at 10:48 AM, Stephen Farrell wrote: >>>=20 >>>=20 >>>=20 >>> On 13/10/16 15:43, Phil Hunt wrote: >>>> Not sure I see why there is an issue with using HTTP port 80. >>>=20 >>> Well, if we're transporting sensitive information >>> then I'm not clear why that'd even be sent on port >>> 80 unless there's a specific need for that. Is >>> there? >>>=20 >>> S. >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-062F012E-976C-49F2-B212-320A71EE4AD0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Please excuse typos, sent from= handheld device 

On Oct 13, 2016, at 3:10 PM, Phil Hunt (= IDM) <phil.hunt@oracle.com>= ; wrote:

Stephen,

I think I s= ee my disconnect. I thought you were suggesting we should not use http at al= l and do a new protocol. 

Assuming you mean use 443 as in HTTPS this m= akes sense for most implementations. The initial distribution draft requires= it. 

That's good.  We are j= ust looking for some statement on security in the charter as well.  I t= hink you didn't like the suggestions so far.  As such, could you come u= p with an appropriate sentence to add that addresses this concern?
=
Thanks,
Kathleen 

Phil

On Oct 13, 2016, at 10:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

These are all web protocols.

JWT itself is secure enough to be URL safe. S= o, it=E2=80=99s seems prudent to build on that.

<= div class=3D"">Phil

@independentid
www.independentid.com

<= br class=3D"Apple-interchange-newline">



On O= ct 13, 2016, at 10:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 13/10/16 15:43, Phil Hunt wrote:
Not sure I see why there is an issue with us= ing HTTP port 80.

Well, if we're t= ransporting sensitive information
then I'm not clear why that'= d even be sent on port
80 unless there's a specific need for t= hat. Is
there?

S.
<= br class=3D"">

________________________= _______________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf= .org/mailman/listinfo/id-event
= --Apple-Mail-062F012E-976C-49F2-B212-320A71EE4AD0-- From nobody Thu Oct 13 12:42:20 2016 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 ECD31129629; Thu, 13 Oct 2016 12:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 rRNIQDiLzlzS; Thu, 13 Oct 2016 12:42:09 -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 62940129556; Thu, 13 Oct 2016 12:42:09 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DJg1DJ016168 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 19:42:01 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u9DJg1lK019177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 19:42:01 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9DJg0xJ025577; Thu, 13 Oct 2016 19:42:00 GMT Received: from [10.26.162.67] (/184.151.114.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Oct 2016 12:42:00 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-7DC6EB8E-0A15-44A2-9076-517A1A178236 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A456) In-Reply-To: <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> Date: Thu, 13 Oct 2016 15:41:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> To: kathleen.moriarty.ietf@gmail.com X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Alexey Melnikov , The IESG , id-event@ietf.org, Stephen Farrell Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 19:42:19 -0000 --Apple-Mail-7DC6EB8E-0A15-44A2-9076-517A1A178236 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok will do.=20 Phil > On Oct 13, 2016, at 3:18 PM, kathleen.moriarty.ietf@gmail.com wrote: >=20 >=20 >=20 > Please excuse typos, sent from handheld device=20 >=20 >> On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) wrote= : >>=20 >> Stephen, >>=20 >> I think I see my disconnect. I thought you were suggesting we should not u= se http at all and do a new protocol.=20 >>=20 >> Assuming you mean use 443 as in HTTPS this makes sense for most implement= ations. The initial distribution draft requires it.=20 >=20 > That's good. We are just looking for some statement on security in the ch= arter as well. I think you didn't like the suggestions so far. As such, co= uld you come up with an appropriate sentence to add that addresses this conc= ern? >=20 > Thanks, > Kathleen=20 >>=20 >> Phil >>=20 >>> On Oct 13, 2016, at 10:52 AM, Phil Hunt wrote: >>>=20 >>> These are all web protocols. >>>=20 >>> JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems prude= nt to build on that. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Oct 13, 2016, at 10:48 AM, Stephen Farrell wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 13/10/16 15:43, Phil Hunt wrote: >>>>> Not sure I see why there is an issue with using HTTP port 80.=20 >>>>=20 >>>> Well, if we're transporting sensitive information >>>> then I'm not clear why that'd even be sent on port >>>> 80 unless there's a specific need for that. Is >>>> there? >>>>=20 >>>> S. >>>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-7DC6EB8E-0A15-44A2-9076-517A1A178236 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok will do. 

Phil

On Oct 13, 2016, at 3:18 PM, kathleen.moriarty.ietf@gmail.com wrote:



Please excuse typos, sent from handheld dev= ice 

On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
<= br>
Stephen,

I think I see my disconn= ect. I thought you were suggesting we should not use http at all and do a ne= w protocol. 

Assuming you mean use 443 as in HTTPS this makes sense fo= r most implementations. The initial distribution draft requires it. 

That's good.  We are just looking f= or some statement on security in the charter as well.  I think you didn= 't like the suggestions so far.  As such, could you come up with an app= ropriate sentence to add that addresses this concern?

Thanks,
Kathleen 

Phil
<= div>
On Oct 13, 2016, at 10:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

These are all web protocols.

<= /div>
JWT itself is secure enough to be URL safe. So, it=E2=80= =99s seems prudent to build on that.

<= div class=3D"">Phil

@independentid
www.independentid.com

<= br class=3D"Apple-interchange-newline">



On O= ct 13, 2016, at 10:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 13/10/16 15:43, Phil Hunt wrote:
Not sure I see why there is an issue with us= ing HTTP port 80.

Well, if we're t= ransporting sensitive information
then I'm not clear why that'= d even be sent on port
80 unless there's a specific need for t= hat. Is
there?

S.
<= br class=3D"">

________________________= _______________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf= .org/mailman/listinfo/id-event
= --Apple-Mail-7DC6EB8E-0A15-44A2-9076-517A1A178236-- From nobody Fri Oct 14 04:34:25 2016 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 84C401294C0; Fri, 14 Oct 2016 04:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 g4QOMNxb_LIC; Fri, 14 Oct 2016 04:34:22 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75631294AF; Fri, 14 Oct 2016 04:34:18 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9EBYDKe019108; Fri, 14 Oct 2016 12:34:13 +0100 Received: from 950129200 (dsl-dp-81-140-107-38.in-addr.broadbandscope.com [81.140.107.38]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9EBXg55018296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2016 12:33:54 +0100 From: "Adrian Farrel" To: , "'Kathleen Moriarty'" Date: Fri, 14 Oct 2016 12:33:41 +0100 Message-ID: <012b01d2260e$e24fbd80$a6ef3880$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdImDj3cf9Mh3RX4TyOdaZKPR07bUQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22636.006 X-TM-AS-Result: No--0.675-10.0-31-10 X-imss-scan-details: No--0.675-10.0-31-10 X-TMASE-MatchedRID: +PvIBZ5h0JC/Y1/vmrr7/uEbUg4xvs+wJPNIV6GF8mu0rcU5V/oSe3pt C95MCcU3DLKeRlYjfrF5OPD8XJFfpE1+zyfzlN7y/sToY2qzpx5q8/xv2Um1avoLR4+zsDTtuVf c976pNyr7b20pBLgCyNnIk7Lhd0SMqWHZFRU2/9wJixBtCGeKcfQux9xRavdYfUBvnGWEm8DsfY LwCuSNLNwp2WIuB2xwChQaDv/URg2Hx/3593XRE+S+ZTuCPZ+tPifujgI13do9uJNyHSmbfg== Archived-At: Cc: i2nsf@ietf.org, Id-event@ietf.org Subject: [Id-event] An I-D just for your information X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 14 Oct 2016 11:34:24 -0000 Hi, Just wanted to flag https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info-model-monitoring/ in the context of the Security Event BoF/WG. Not sure where this sits with the Security Event work, but I2NSF seems to see the draft as fairly important. Cheers, Adrian From nobody Fri Oct 14 06:24:35 2016 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 F414F1293FD; Fri, 14 Oct 2016 06:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 6i2vHokcp-Oh; Fri, 14 Oct 2016 06:24:31 -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 939AD129684; Fri, 14 Oct 2016 06:24:30 -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 u9EDONrx025720 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 13:24:23 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.14.4) with ESMTP id u9EDOMEj025979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 13:24:22 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9EDOIEu021506; Fri, 14 Oct 2016 13:24:20 GMT Received: from [192.168.2.26] (/76.64.214.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Oct 2016 06:24:18 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C83F081-CBCE-49DB-84BA-5507BA2F881C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <012b01d2260e$e24fbd80$a6ef3880$@olddog.co.uk> Date: Fri, 14 Oct 2016 09:24:18 -0400 Message-Id: <2E322FA9-1D55-4038-A270-DB349662AAFA@oracle.com> References: <012b01d2260e$e24fbd80$a6ef3880$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: i2nsf@ietf.org, Kathleen Moriarty , Id-event@ietf.org, aamelnikov@fastmail.fm Subject: Re: [Id-event] An I-D just for your information X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 13:24:34 -0000 --Apple-Mail=_4C83F081-CBCE-49DB-84BA-5507BA2F881C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, So where this might fit together is that SET simply profiles JWT so that = an event can be expressed in secureable JSON format. We define only a = set of attributes necessary to validate and secure events, but pretty = much leave the data of the event up to =E2=80=9Cprofiling=E2=80=9D = specifications that build on it. A number of us ended up bringing this together because there was a = number of independent efforts to express very different events doing = almost the same thing. =46rom my quick scan, one of the options would be that these events = could be expressed as a profile of SET. I plan to do the same for SCIM, as does RISC, etc. The OpenID Logout = specs already use SET. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 14, 2016, at 7:33 AM, Adrian Farrel = wrote: >=20 > Hi, >=20 > Just wanted to flag > = https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info-model-monitoring/ = in the > context of the Security Event BoF/WG. >=20 > Not sure where this sits with the Security Event work, but I2NSF seems = to see > the draft as fairly important. >=20 > Cheers, > Adrian >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_4C83F081-CBCE-49DB-84BA-5507BA2F881C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

So = where this might fit together is that SET simply profiles JWT so that an = event can be expressed in secureable JSON format. We define only a set = of attributes necessary to validate and secure events, but pretty much = leave the data of the event up to =E2=80=9Cprofiling=E2=80=9D = specifications that build on it.

A number of us ended up bringing this = together because there was a number of independent efforts to express = very different events doing almost the same thing.

=46rom my quick scan, = one of the options would be that these events could be expressed as a = profile of SET.

I plan to do the same for SCIM, as does RISC, etc.  The = OpenID Logout specs already use SET.





On Oct 14, 2016, at 7:33 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Hi,

Just wanted to flag
https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info-model-m= onitoring/ in the
context of the Security Event = BoF/WG.

Not sure where this sits with the = Security Event work, but I2NSF seems to see
the draft as = fairly important.

Cheers,
Adrian

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

= --Apple-Mail=_4C83F081-CBCE-49DB-84BA-5507BA2F881C-- From nobody Fri Oct 14 07:47:24 2016 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 59A2F1297B7; Fri, 14 Oct 2016 07:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 yzIJtcTYdfiT; Fri, 14 Oct 2016 07:47:17 -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 3F6D51297B5; Fri, 14 Oct 2016 07:47:17 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9EEl8oO015599 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 14 Oct 2016 14:47:08 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9EEl7LC002107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 14:47:08 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9EEl57x000362; Fri, 14 Oct 2016 14:47:06 GMT Received: from [192.168.2.26] (/76.64.214.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Oct 2016 07:47:05 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4E42FD8-A82E-4E9B-8EE0-4A5D4557B977" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> Date: Fri, 14 Oct 2016 10:47:00 -0400 Message-Id: <17179EEC-0387-4E97-A390-9A5FD52C136A@oracle.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> To: kathleen.moriarty.ietf@gmail.com X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Stephen Farrell , The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 14:47:23 -0000 --Apple-Mail=_F4E42FD8-A82E-4E9B-8EE0-4A5D4557B977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, How about we change the line from (new text underlined): A method for delivering events using HTTP POST (push) To: A secure method for assured delivery of events using HTTPS POST (push) Regarding Stephen=E2=80=99s Concern about identity related protocols how = about changing: From: Many identity related protocols require a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary. For example, an OAuth = authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform = another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying = party. To: Many HTTP Web Services and APIs depend on a web security infrastructures = that: * identifies security subjects and regulates their access to services,=20= * and provides profile and rights information to application.=20 Examples are systems that leverage user-agent session cookies (RFC6265), = and OAuth2 (RFC6749). In order to prevent or mitigate security risks, or = to provide out-of-band information as necessary, these systems need to = share security event messages. For example, an OAuth authorization = server, having received a token revocation request (RFC7009) may need to = inform affected resource servers; a cloud provider may wish to inform = another cloud provider of suspected fraudulent use of identity = information; an identity provider may wish to signal a session logout to = a relying party and does not wish to rely solely upon clearing a session = cookie. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 13, 2016, at 3:18 PM, kathleen.moriarty.ietf@gmail.com wrote: >=20 >=20 >=20 > Please excuse typos, sent from handheld device=20 >=20 > On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) > wrote: >=20 >> Stephen, >>=20 >> I think I see my disconnect. I thought you were suggesting we should = not use http at all and do a new protocol.=20 >>=20 >> Assuming you mean use 443 as in HTTPS this makes sense for most = implementations. The initial distribution draft requires it.=20 >=20 > That's good. We are just looking for some statement on security in = the charter as well. I think you didn't like the suggestions so far. = As such, could you come up with an appropriate sentence to add that = addresses this concern? >=20 > Thanks, > Kathleen=20 >>=20 >> Phil >>=20 >> On Oct 13, 2016, at 10:52 AM, Phil Hunt > wrote: >>=20 >>> These are all web protocols. >>>=20 >>> JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems = prudent to build on that. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Oct 13, 2016, at 10:48 AM, Stephen Farrell = > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 13/10/16 15:43, Phil Hunt wrote: >>>>> Not sure I see why there is an issue with using HTTP port 80.=20 >>>>=20 >>>> Well, if we're transporting sensitive information >>>> then I'm not clear why that'd even be sent on port >>>> 80 unless there's a specific need for that. Is >>>> there? >>>>=20 >>>> S. >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 = --Apple-Mail=_F4E42FD8-A82E-4E9B-8EE0-4A5D4557B977 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Kathleen,

How about we change the line from (new = text underlined):
A method for delivering events using HTTP POST =
(push)

To:
A secure method for assured =
delivery of events using HTTPS POST =
(push)

Regarding= Stephen=E2=80=99s Concern about identity related protocols how about = changing:

From:
Many identity related protocols require a mechanism to convey =
messages
between
systems in order to prevent or mitigate security risks, or to provide
out-of-band information as necessary. For example, an OAuth =
authorization
server, having received a token revocation request (RFC7009) may need to
inform affected resource servers; a cloud provider may wish to inform =
another
cloud provider of suspected fraudulent use of identity information; an
identity provider may wish to signal a session logout to a relying =
party.
To:

Many =
HTTP Web Services and APIs depend on a web security infrastructures =
that:
* =
identifies security subjects and regulates their access to =
services, 
* and provides profile and =
rights information to application. 
Examples are systems that =
leverage user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In =
order to prevent or mitigate security risks, or to provide out-of-band =
information as necessary, these systems need to share security event =
messages. For example, an OAuth authorization server, having =
received a token revocation request (RFC7009) may need to inform =
affected resource servers; a cloud provider may wish to inform another =
cloud provider of suspected fraudulent use of identity information; an =
identity provider may wish to signal a session logout to a relying party =
and does not wish to rely solely upon clearing a session =
cookie.





On Oct 13, 2016, at 3:18 PM, kathleen.moriarty.ietf@gmail.com wrote:



Please excuse typos, sent from handheld = device 

On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Stephen,

I think I see my = disconnect. I thought you were suggesting we should not use http at all = and do a new protocol. 

Assuming you mean use 443 as in HTTPS = this makes sense for most implementations. The initial distribution = draft requires it. 

That's good.  We are just looking for some = statement on security in the charter as well.  I think you didn't = like the suggestions so far.  As such, could you come up with an = appropriate sentence to add that addresses this concern?

Thanks,
Kathleen 

Phil

On Oct 13, 2016, at = 10:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

These are all web protocols.

JWT itself is secure enough to be URL = safe. So, it=E2=80=99s seems prudent to build on that.




On Oct = 13, 2016, at 10:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 13/10/16 15:43, Phil Hunt wrote:
Not sure I see why there = is an issue with using HTTP port 80. 

Well, if we're transporting = sensitive information
then I'm not clear why that'd even = be sent on port
80 unless there's a specific need for = that. Is
there?

S.


_______________________________________________
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

= --Apple-Mail=_F4E42FD8-A82E-4E9B-8EE0-4A5D4557B977-- From nobody Fri Oct 14 08:06:10 2016 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 97B2E12982B; Fri, 14 Oct 2016 08:06:04 -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, FREEMAIL_FROM=0.001, 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=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 z0C3yfQ1FmO5; Fri, 14 Oct 2016 08:05:59 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c: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 8943F129760; Fri, 14 Oct 2016 08:05:59 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id q126so64461317vkd.2; Fri, 14 Oct 2016 08:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i944QgPLQ6kNbI8TIwk6xLJxIN1ebRDyCWtLa9P+7+g=; b=F0LXtJkZEBn18r35fWaQsCe8Z97uUFcheoW/f07iVJ8s5fQENfhaGpJ/iPiT8gsDrS W2jj0LvpW+4/PALXP4SJ8qROO9yCki1VW5hpUngKyA5mH5zjUXVePRa2sBxlAQFqShsZ jjWRzy3Z9LBQ4wwKLwTMdiOyltu1YiO3OzOuTnwQiXC3cgREf3Z77st436cb2LDRjq+U 6/WH7to2K40+R/urq6rFnEAXfytNhKW5kk/H/h1M7FmtgT2JgTpwGtP2eZENErXMmHR9 754KZ32opUc7QYhPs/h/v3amlTYX6mgcdMoSipAmLhDuRslZSTzBRDzNj9jdtvDBpfFV VeVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i944QgPLQ6kNbI8TIwk6xLJxIN1ebRDyCWtLa9P+7+g=; b=XqYGuZ+N1T8TZBkY5SKOyHaUdH0iTS3rslMSmfan02iBfiAbTtLjycndYI97w95OZZ ljqtVxIYHaN4tUs0U8s7+MXQZZpLvocODji5S9apsNjc1wWThldi7s2+1YF4IjiW9Zgf M7QNzYFNtWRCkt7AEKMNty5+2fBn6NUlzUiQgjTfIu8rPBU4sRGOGdfxrwpbiqDGNk2H 7LcLOLt44kbW6yLAKT/P76eeTwaJ4XY1vGkTw1p7AYCfEey4eU9vuXNLvlsIWLcdLm0k aTwG/WDIHQgN6OhrrwCqC7NFiaexquRFZ+WTsaBv6P2UBirgFeapaB/ANTzP3nGuWt7U D/Nw== X-Gm-Message-State: AA6/9RlZPW/iopPQuuoXicaTPEQDb5T4X1LCBrN7jtyRdqHVLkD6cjxVEYb/VyvOrpK1lLWoIBCO/PDwaNdFEQ== X-Received: by 10.31.183.134 with SMTP id h128mr8375142vkf.124.1476457558627; Fri, 14 Oct 2016 08:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Fri, 14 Oct 2016 08:05:58 -0700 (PDT) In-Reply-To: <17179EEC-0387-4E97-A390-9A5FD52C136A@oracle.com> References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> <17179EEC-0387-4E97-A390-9A5FD52C136A@oracle.com> From: Kathleen Moriarty Date: Fri, 14 Oct 2016 11:05:58 -0400 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113bee224edca1053ed49029 Archived-At: Cc: Stephen Farrell , The IESG , id-event@ietf.org, Alexey Melnikov Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 15:06:04 -0000 --001a113bee224edca1053ed49029 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That looks better. If STephen agrees, I'll update the text. Thanks, Kathleen On Fri, Oct 14, 2016 at 10:47 AM, Phil Hunt wrote: > Kathleen, > > How about we change the line from (new text underlined): > > A method for delivering events using HTTP POST (push) > > > To: > > A *secure* method for *assured delivery of* events using HTTP*S* POST (pu= sh) > > > Regarding Stephen=E2=80=99s Concern about identity related protocols how = about > changing: > > From: > > Many identity related protocols require a mechanism to convey messages > between > systems in order to prevent or mitigate security risks, or to provide > out-of-band information as necessary. For example, an OAuth authorization > server, having received a token revocation request (RFC7009) may need to > inform affected resource servers; a cloud provider may wish to inform ano= ther > cloud provider of suspected fraudulent use of identity information; an > identity provider may wish to signal a session logout to a relying party. > > To: > > *Many HTTP Web Services and APIs depend on a web security infrastructures= that:* > > ** identifies security subjects and regulates their access to services, * > > ** and provides profile and rights information to application. * > > *Examples are systems that leverage user-agent session cookies (RFC6265),= and OAuth2 (RFC6749). In order to prevent or mitigate security risks, or t= o provide out-of-band information as necessary, these systems need to share= security event messages. *For example, an OAuth authorization server, havi= ng received a token revocation request (RFC7009) may need to inform affecte= d resource servers; a cloud provider may wish to inform another cloud provi= der of suspected fraudulent use of identity information; an identity provid= er may wish to signal a session logout to a relying party *and does not wis= h to rely solely upon clearing a session cookie.* > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Oct 13, 2016, at 3:18 PM, kathleen.moriarty.ietf@gmail.com wrote: > > > > Please excuse typos, sent from handheld device > > On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) wrote= : > > Stephen, > > I think I see my disconnect. I thought you were suggesting we should not > use http at all and do a new protocol. > > Assuming you mean use 443 as in HTTPS this makes sense for most > implementations. The initial distribution draft requires it. > > > That's good. We are just looking for some statement on security in the > charter as well. I think you didn't like the suggestions so far. As suc= h, > could you come up with an appropriate sentence to add that addresses this > concern? > > Thanks, > Kathleen > > > Phil > > On Oct 13, 2016, at 10:52 AM, Phil Hunt wrote: > > These are all web protocols. > > JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems pruden= t to > build on that. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Oct 13, 2016, at 10:48 AM, Stephen Farrell > wrote: > > > > On 13/10/16 15:43, Phil Hunt wrote: > > Not sure I see why there is an issue with using HTTP port 80. > > > Well, if we're transporting sensitive information > then I'm not clear why that'd even be sent on port > 80 unless there's a specific need for that. Is > there? > > S. > > > _______________________________________________ > 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 > > > --=20 Best regards, Kathleen --001a113bee224edca1053ed49029 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That looks better.=C2=A0 If STephen agrees, I'll updat= e the text.

Thanks,
Kathleen

On Fri, Oct 14, 2016 at= 10:47 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Kathle= en,

How about we change the line from (new text un= derlined):
A method for delivering=
 events using HTTP POST (push)

To:
A secure method for assured deliv=
ery of events using HTTPS POST (push)

R= egarding Stephen=E2=80=99s Concern about identity related protocols how abo= ut changing:

From:
Many identity related protocols require a mechanism to convey mes=
sages
between
systems in order to prevent or mitigate security risks, or to provide
out-of-band information as necessary. For example, an OAuth authorization
server, having received a token revocation request (RFC7009) may need to
inform affected resource servers; a cloud provider may wish to inform anoth=
er
cloud provider of suspected fraudulent use of identity information; an
identity provider may wish to signal a session logout to a relying party.
To:

Many HTTP Web Services and APIs depen=
d on a web security infrastructures that:
=
* identifies secur=
ity subjects and regulates their access to services,=C2=A0
*=
 and provides profile and rights information to application.=C2=A0
Examples are systems that leverage user-agent session cookies (RFC62=
65), and OAuth2 (RFC6749). In order to prevent or mitigate security risks, =
or to provide out-of-band information as necessary, these systems need to s=
hare security event messages. For example, an OAuth authorization serve=
r, having received a token revocation request (RFC7009) may need to inform =
affected resource servers; a cloud provider may wish to inform another clou=
d provider of suspected fraudulent use of identity information; an identity=
 provider may wish to signal a session logout to a relying party and doe=
s not wish to rely solely upon clearing a session cookie.=




On Oct 13, 2016, a= t 3:18 PM, kathleen.moriarty.ietf@gmail.com wrote:



Please excuse typos, sent from handheld device=C2=A0
On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Stephen,

I t= hink I see my disconnect. I thought you were suggesting we should not use h= ttp at all and do a new protocol.=C2=A0

Assuming y= ou mean use 443 as in HTTPS this makes sense for most implementations. The = initial distribution draft requires it.=C2=A0

<= /div>That's good.=C2=A0 We are jus= t looking for some statement on security in the charter as well.=C2=A0 I th= ink you didn't like the suggestions so far.=C2=A0 As such, could you co= me up with an appropriate sentence to add that addresses this concern?

Thanks,
Kathleen=C2=A0

Phil

On Oct 13, 2016, at 1= 0:52 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

These are all web protocols.

JWT itself is se= cure enough to be URL safe. So, it=E2=80=99s seems prudent to build on that= .
On Oct 13, 2016, at 10:48 AM, Stephen = Farrell <= stephen.farrell@cs.tcd.ie> wrote:



On 13/10/16 15:43, Phil H= unt wrote:
Not sure I see why there is an issu= e with using HTTP port 80.=C2=A0

Well, if we're transporting= sensitive information
then I'm not clear why that'd even be sen= t on port
80 unless there's a specific need for that. Is
there?
S.


______________________________<= wbr>_________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
____________________________________________= ___
Id-event mailing list<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Id-event@ietf.org
https://ww= w.ietf.org/mailman/listinfo/id-event




--

Best regards,
Kathleen
--001a113bee224edca1053ed49029-- From nobody Fri Oct 14 08:22:18 2016 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 33530129845; Fri, 14 Oct 2016 08:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 lVOxx3HtZ3oC; Fri, 14 Oct 2016 08:22:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636A81294B9; Fri, 14 Oct 2016 08:22:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B52C1BE39; Fri, 14 Oct 2016 16:22:09 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji5C3-5ppqMT; Fri, 14 Oct 2016 16:22:09 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FB94BE32; Fri, 14 Oct 2016 16:22:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476458529; bh=Q54rqD8kUBn5z31gyNDlCc2J9f7KVTGhrfWOThTgOrM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=znPSr5xfnLUjItwIIYQQu80dJ5ppzpaW4Dl/Xy2qEYCHQBU8lllkD2IgYGK+D2IU5 uP4HSx2yuAN/Qz+k1Tg7ebF5Q9MZWrBMTXmkHseoBekvMyUMnnIvKl5xHZ8bdLZDgJ jLZUHBEDBzwLHX9MbM+5f0cnk8mxSfP+rBYZLTlY= To: Phil Hunt , kathleen.moriarty.ietf@gmail.com References: <147636504540.2834.8802143326030980613.idtracker@ietfa.amsl.com> <1476365523.1638397.754781881.4B56CB03@webmail.messagingengine.com> <983F84DD-F1F8-42D8-8C55-EC13F2923ED8@oracle.com> <25a1d8f9-3522-207a-3ece-7ec94747498d@cs.tcd.ie> <3AFA764C-B99A-4357-B1EA-330D19BE1F89@oracle.com> <729B0BBA-1684-4B8D-8F2F-577263A23BCA@gmail.com> <17179EEC-0387-4E97-A390-9A5FD52C136A@oracle.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <550f0bda-91fb-dcad-450d-b2956b2d225b@cs.tcd.ie> Date: Fri, 14 Oct 2016 16:22:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <17179EEC-0387-4E97-A390-9A5FD52C136A@oracle.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020300080407080206020106" Archived-At: Cc: Alexey Melnikov , The IESG , id-event@ietf.org Subject: Re: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 15:22:16 -0000 This is a cryptographically signed message in MIME format. --------------ms020300080407080206020106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/10/16 15:47, Phil Hunt wrote: > Kathleen, >=20 > How about we change the line from (new text underlined): A method for > delivering events using HTTP POST (push) >=20 > To: A secure method for assured delivery of events using HTTPS POST > (push) >=20 > Regarding Stephen=E2=80=99s Concern about identity related protocols ho= w > about changing: >=20 > From: Many identity related protocols require a mechanism to convey > messages between systems in order to prevent or mitigate security > risks, or to provide out-of-band information as necessary. For > example, an OAuth authorization server, having received a token > revocation request (RFC7009) may need to inform affected resource > servers; a cloud provider may wish to inform another cloud provider > of suspected fraudulent use of identity information; an identity > provider may wish to signal a session logout to a relying party.=20 > > To: >=20 > Many HTTP Web Services and APIs depend on a web security > infrastructures that: * identifies security subjects and regulates > their access to services, * and provides profile and rights > information to application. Examples are systems that leverage > user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In order > to prevent or mitigate security risks, or to provide out-of-band > information as necessary, these systems need to share security event > messages. For example, an OAuth authorization server, having received > a token revocation request (RFC7009) may need to inform affected > resource servers; a cloud provider may wish to inform another cloud > provider of suspected fraudulent use of identity information; an > identity provider may wish to signal a session logout to a relying > party and does not wish to rely solely upon clearing a session > cookie. Yes, that's better thanks. S >=20 > Phil >=20 > @independentid www.independentid.com > phil.hunt@oracle.com > >=20 >=20 >=20 >=20 >=20 >> On Oct 13, 2016, at 3:18 PM, kathleen.moriarty.ietf@gmail.com >> wrote: >>=20 >>=20 >>=20 >> Please excuse typos, sent from handheld device >>=20 >> On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) > > wrote: >>=20 >>> Stephen, >>>=20 >>> I think I see my disconnect. I thought you were suggesting we >>> should not use http at all and do a new protocol. >>>=20 >>> Assuming you mean use 443 as in HTTPS this makes sense for most >>> implementations. The initial distribution draft requires it. >>=20 >> That's good. We are just looking for some statement on security in >> the charter as well. I think you didn't like the suggestions so >> far. As such, could you come up with an appropriate sentence to >> add that addresses this concern? >>=20 >> Thanks, Kathleen >>>=20 >>> Phil >>>=20 >>> On Oct 13, 2016, at 10:52 AM, Phil Hunt >> > wrote: >>>=20 >>>> These are all web protocols. >>>>=20 >>>> JWT itself is secure enough to be URL safe. So, it=E2=80=99s seems >>>> prudent to build on that. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Oct 13, 2016, at 10:48 AM, Stephen Farrell >>>>> >>>> > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 13/10/16 15:43, Phil Hunt wrote: >>>>>> Not sure I see why there is an issue with using HTTP port >>>>>> 80. >>>>>=20 >>>>> Well, if we're transporting sensitive information then I'm >>>>> not clear why that'd even be sent on port 80 unless there's a >>>>> specific need for that. Is there? >>>>>=20 >>>>> S. >>>>>=20 >>>>=20 >>>> _______________________________________________ Id-event >>>> mailing list Id-event@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >> _______________________________________________ Id-event mailing >> list Id-event@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/id-event >> >=20 --------------ms020300080407080206020106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTQx NTIyMDhaMC8GCSqGSIb3DQEJBDEiBCCe0UR9mxhLNDc/PcpZLFdSZKgUJ7h+NKcO2SjC2nGI YzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBYpCp/cxU0duyQ4duYSTMUVf+TNYEGGAnoepfB22tAjOIl0GbPTYvn w+jqqsANmws4P1BR2hmMcNYULocEEQ5FnPbNDbXLSuTu7Y6aOH1lI3GFzEVcZKucjBl2oUHW AgqxgEMKQww02+EQxSAosxqIxO3XstFhdvQt2U3k43ysdlr6byYwZXPpEHndXpJGJ010hwsy lp18ebROdfzm4zWhUkj2Bcj8uT/DlbwcuLXjJyi5y9PvFoASYjeBpgKS9naM5zApQLpPoRAX OXxVU5PHOuy0drnicV9Igld/l1IlztCL+X47v2bYyhRTYMQ+e9kJFCsgK8fPCMQXYkrmNgQZ AAAAAAAA --------------ms020300080407080206020106-- From nobody Fri Oct 14 09:04:30 2016 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 5BDA6129649; Fri, 14 Oct 2016 09:04:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147646106836.18628.5879657405384489718.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 09:04:28 -0700 Archived-At: Cc: id-event@ietf.org Subject: [Id-event] WG Review: Security Events (secevent) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 14 Oct 2016 16:04:28 -0000 A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-24. Security Events (secevent) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: id-event@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/id-event Archive: https://mailarchive.ietf.org/arch/browse/id-event/ Charter: https://datatracker.ietf.org/doc/charter-ietf-secevent/ Many identity related protocols require a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary. For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party. It is expected that several identity and security working groups and organizations will use Identity Event Tokens to describe area-specific events such as: SCIM Provisioning Events, OpenID RISC Events, and OpenID Connect Backchannel Logout, among others. The Security Events working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed This Event Token specification will be event transport independent. The working group will also develop a simple standards-track Event Delivery specification that includes: - A method for delivering events using HTTP POST (push) - Metadata for describing event feeds - Methods for subscribing to and managing event feeds - Methods for validating event feed subscriptions Milestones: Oct 2016 - Initial adoption of event token and event delivery drafts Feb 2017 - WG last call of event token draft Apr 2017 - Event token draft to IESG as a Proposed Standard Jul 2017 - WG last call of event delivery draft Sep 2017 - Event delivery draft to IESG as a Proposed Standard Nov 2017 - Recharter or Conclude From nobody Fri Oct 21 16:24:00 2016 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 0CF15129842; Fri, 21 Oct 2016 16:21:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207104.28214.12928706244556934830.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:11 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, id-event@ietf.org Subject: [Id-event] secevent - Requested session has been scheduled for IETF 97 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 21 Oct 2016 23:21:11 -0000 Dear Stephanie McCammon, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secevent Session 1 (1:00:00) Wednesday, Morning Session II 1110-1210 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Security Events Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: saag jsonbis httpbis dispatch oauth tokbind Special Requests: --------------------------------------------------------- From nobody Sat Oct 22 04:33:37 2016 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 E1594129688; Sat, 22 Oct 2016 04:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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 Mwdgz6NTm491; Sat, 22 Oct 2016 04:33:34 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10120.outbound.protection.outlook.com [40.107.1.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77838129450; Sat, 22 Oct 2016 04:33:33 -0700 (PDT) Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com (10.167.123.150) by AM4PR0601MB2162.eurprd06.prod.outlook.com (10.167.123.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sat, 22 Oct 2016 11:33:31 +0000 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) by AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) with mapi id 15.01.0659.028; Sat, 22 Oct 2016 11:33:31 +0000 From: "Diego R. Lopez" To: Phil Hunt Thread-Topic: [I2nsf] [Id-event] An I-D just for your information Thread-Index: AQHSJh59wHOxgnJFxUOdG5Sln3qsuaC0Y/uA Date: Sat, 22 Oct 2016 11:33:30 +0000 Message-ID: <1A98B8E0-3189-4C93-89A2-FCD37D2F8F6F@telefonica.com> References: <012b01d2260e$e24fbd80$a6ef3880$@olddog.co.uk> <2E322FA9-1D55-4038-A270-DB349662AAFA@oracle.com> In-Reply-To: <2E322FA9-1D55-4038-A270-DB349662AAFA@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [37.158.85.85] x-ms-office365-filtering-correlation-id: aaae5ec9-7b1c-4806-b3eb-08d3fa6f3ff6 x-microsoft-exchange-diagnostics: 1; AM4PR0601MB2162; 7:bQ3xUgVIPxlAh1CblX5+rY9b4LcfCM5rPTHeoqpchDopZrU6x5bw3v1eCqDj95T1Iliw6/CeTAhzRhXtbw0eOvwZKq2zFrSjKOICU16gHiHBgnD2xFpyPl3YyIUTz1AHUTZDqX4nMcHz5PH7KIdAa3NjGfBnQTdj4COvNNZq1w28qT2KywpTx4CRXSL8mLnOg8rP9xx+MyBlCYnxzTtvQa0QnThS/LEEB0tY651pJ/TfLMjq7gZx6/BELISIXc7EfMjo8l1vnxxSnG/xUHmRm5LdYjjOjtxa8aL9lEiIqK9a54x8vDlAfsEZes46/jGn2gFodZuZgdPCPMKfw0H0JE/FRj5/irIJQcYkTuT9z54= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0601MB2162; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(120809045254105)(192374486261705)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:AM4PR0601MB2162; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0601MB2162; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(51694002)(189002)(199003)(24454002)(252514010)(377454003)(6916009)(7906003)(7846002)(77096005)(8666005)(3660700001)(2950100002)(87936001)(19580405001)(82746002)(4326007)(19580395003)(76176999)(54356999)(3846002)(50986999)(122556002)(92566002)(110136003)(83716003)(2906002)(66066001)(102836003)(7736002)(10400500002)(11100500001)(6116002)(86362001)(5660300001)(2900100001)(33656002)(106356001)(106116001)(101416001)(97736004)(3280700002)(36756003)(586003)(8936002)(189998001)(81156014)(5002640100001)(105586002)(15975445007)(19617315012)(68736007)(16236675004)(81166006)(8676002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0601MB2162; H:AM4PR0601MB2161.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_1A98B8E031894C9389A2FCD37D2F8F6Ftelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2016 11:33:30.8976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2162 Archived-At: Cc: "i2nsf@ietf.org" , "adrian@olddog.co.uk" , Kathleen Moriarty , "Id-event@ietf.org" , "aamelnikov@fastmail.fm" Subject: Re: [Id-event] [I2nsf] An I-D just for your information X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 22 Oct 2016 11:33:36 -0000 --_000_1A98B8E031894C9389A2FCD37D2F8F6Ftelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCwNCg0KQ2FuIHlvdSBwcm92aWRlIGEgbGluayBmb3IgdGhlIFNFVCBwcm9maWxlcz8g SnVzdCBsb29raW5nIGZvciDigJxzZXTigJ0gZ2l2ZXMgYSBob3JyaWJseSB1bm1hbmFnZWFibGUg bGlzdCBvZiByZWZlcmVuY2Vz4oCmDQoNClRoYW5rcywNCg0KT24gMTQgT2N0IDIwMTYsIGF0IDE1 OjI0ICwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+PiB3cm90ZToNCg0KQWRyaWFuLA0KDQpTbyB3aGVyZSB0aGlzIG1pZ2h0IGZpdCB0 b2dldGhlciBpcyB0aGF0IFNFVCBzaW1wbHkgcHJvZmlsZXMgSldUIHNvIHRoYXQgYW4gZXZlbnQg Y2FuIGJlIGV4cHJlc3NlZCBpbiBzZWN1cmVhYmxlIEpTT04gZm9ybWF0LiBXZSBkZWZpbmUgb25s eSBhIHNldCBvZiBhdHRyaWJ1dGVzIG5lY2Vzc2FyeSB0byB2YWxpZGF0ZSBhbmQgc2VjdXJlIGV2 ZW50cywgYnV0IHByZXR0eSBtdWNoIGxlYXZlIHRoZSBkYXRhIG9mIHRoZSBldmVudCB1cCB0byDi gJxwcm9maWxpbmfigJ0gc3BlY2lmaWNhdGlvbnMgdGhhdCBidWlsZCBvbiBpdC4NCg0KQSBudW1i ZXIgb2YgdXMgZW5kZWQgdXAgYnJpbmdpbmcgdGhpcyB0b2dldGhlciBiZWNhdXNlIHRoZXJlIHdh cyBhIG51bWJlciBvZiBpbmRlcGVuZGVudCBlZmZvcnRzIHRvIGV4cHJlc3MgdmVyeSBkaWZmZXJl bnQgZXZlbnRzIGRvaW5nIGFsbW9zdCB0aGUgc2FtZSB0aGluZy4NCg0KRnJvbSBteSBxdWljayBz Y2FuLCBvbmUgb2YgdGhlIG9wdGlvbnMgd291bGQgYmUgdGhhdCB0aGVzZSBldmVudHMgY291bGQg YmUgZXhwcmVzc2VkIGFzIGEgcHJvZmlsZSBvZiBTRVQuDQoNCkkgcGxhbiB0byBkbyB0aGUgc2Ft ZSBmb3IgU0NJTSwgYXMgZG9lcyBSSVNDLCBldGMuICBUaGUgT3BlbklEIExvZ291dCBzcGVjcyBh bHJlYWR5IHVzZSBTRVQuDQoNCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5k ZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIE9jdCAxNCwg MjAxNiwgYXQgNzozMyBBTSwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWls dG86YWRyaWFuQG9sZGRvZy5jby51az4+IHdyb3RlOg0KDQpIaSwNCg0KSnVzdCB3YW50ZWQgdG8g ZmxhZw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctaTJuc2Yt aW5mby1tb2RlbC1tb25pdG9yaW5nLyBpbiB0aGUNCmNvbnRleHQgb2YgdGhlIFNlY3VyaXR5IEV2 ZW50IEJvRi9XRy4NCg0KTm90IHN1cmUgd2hlcmUgdGhpcyBzaXRzIHdpdGggdGhlIFNlY3VyaXR5 IEV2ZW50IHdvcmssIGJ1dCBJMk5TRiBzZWVtcyB0byBzZWUNCnRoZSBkcmFmdCBhcyBmYWlybHkg aW1wb3J0YW50Lg0KDQpDaGVlcnMsDQpBZHJpYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSTJuc2YgbWFpbGluZyBsaXN0DQpJMm5zZkBpZXRmLm9yZzxt YWlsdG86STJuc2ZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5v Ig0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlk LmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20N ClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= --_000_1A98B8E031894C9389A2FCD37D2F8F6Ftelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5B72478E0079F5498C720CBAB262A735@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgUGhpbCwNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNhbiB5b3UgcHJvdmlkZSBh IGxpbmsgZm9yIHRoZSBTRVQgcHJvZmlsZXM/IEp1c3QgbG9va2luZyBmb3Ig4oCcc2V04oCdIGdp dmVzIGEgaG9ycmlibHkgdW5tYW5hZ2VhYmxlIGxpc3Qgb2YgcmVmZXJlbmNlc+KApjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtz LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDE0IE9jdCAyMDE2LCBhdCAx NToyNCAsIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiBjbGFzcz0iIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQWRyaWFu LA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U28g d2hlcmUgdGhpcyBtaWdodCBmaXQgdG9nZXRoZXIgaXMgdGhhdCBTRVQgc2ltcGx5IHByb2ZpbGVz IEpXVCBzbyB0aGF0IGFuIGV2ZW50IGNhbiBiZSBleHByZXNzZWQgaW4gc2VjdXJlYWJsZSBKU09O IGZvcm1hdC4gV2UgZGVmaW5lIG9ubHkgYSBzZXQgb2YgYXR0cmlidXRlcyBuZWNlc3NhcnkgdG8g dmFsaWRhdGUgYW5kIHNlY3VyZSBldmVudHMsIGJ1dCBwcmV0dHkgbXVjaCBsZWF2ZSB0aGUgZGF0 YSBvZiB0aGUgZXZlbnQNCiB1cCB0byDigJxwcm9maWxpbmfigJ0gc3BlY2lmaWNhdGlvbnMgdGhh dCBidWlsZCBvbiBpdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkEgbnVtYmVyIG9mIHVzIGVuZGVkIHVwIGJyaW5naW5nIHRoaXMgdG9n ZXRoZXIgYmVjYXVzZSB0aGVyZSB3YXMgYSBudW1iZXIgb2YgaW5kZXBlbmRlbnQgZWZmb3J0cyB0 byBleHByZXNzIHZlcnkgZGlmZmVyZW50IGV2ZW50cyBkb2luZyBhbG1vc3QgdGhlIHNhbWUgdGhp bmcuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5Gcm9tIG15IHF1aWNrIHNjYW4sIG9uZSBvZiB0aGUgb3B0aW9ucyB3b3VsZCBiZSB0aGF0 IHRoZXNlIGV2ZW50cyBjb3VsZCBiZSBleHByZXNzZWQgYXMgYSBwcm9maWxlIG9mIFNFVC48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkg cGxhbiB0byBkbyB0aGUgc2FtZSBmb3IgU0NJTSwgYXMgZG9lcyBSSVNDLCBldGMuICZuYnNwO1Ro ZSBPcGVuSUQgTG9nb3V0IHNwZWNzIGFscmVhZHkgdXNlIFNFVC48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJv cmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGJvcmRlci1zcGFj aW5nOiAwcHg7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ UGhpbDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+QGluZGVwZW5kZW50aWQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDov L3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iIGNsYXNzPSIiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwv YT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20iIGNsYXNzPSIiIHN0eWxlPSJvcnBoYW5zOiAyOyB3aWRvd3M6 IDI7Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPk9uIE9jdCAxNCwgMjAxNiwgYXQgNzozMyBBTSwgQWRyaWFuIEZhcnJlbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiIGNsYXNzPSIiPmFkcmlhbkBv bGRkb2cuY28udWs8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpKdXN0IHdhbnRlZCB0byBmbGFnPGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctaTJu c2YtaW5mby1tb2RlbC1tb25pdG9yaW5nLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctaTJuc2YtaW5mby1tb2RlbC1tb25pdG9yaW5nLzwvYT4g aW4gdGhlPGJyIGNsYXNzPSIiPg0KY29udGV4dCBvZiB0aGUgU2VjdXJpdHkgRXZlbnQgQm9GL1dH LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdCBzdXJlIHdoZXJlIHRoaXMgc2l0cyB3 aXRoIHRoZSBTZWN1cml0eSBFdmVudCB3b3JrLCBidXQgSTJOU0Ygc2VlbXMgdG8gc2VlPGJyIGNs YXNzPSIiPg0KdGhlIGRyYWZ0IGFzIGZhaXJseSBpbXBvcnRhbnQuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KQ2hlZXJzLDxiciBjbGFzcz0iIj4NCkFkcmlhbjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiBjbGFzcz0iIj5JZC1ldmVudEBpZXRmLm9y ZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCkky bnNmIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpJMm5zZkBpZXRm Lm9yZyIgY2xhc3M9IiI+STJuc2ZAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGFwcGxlLWNvbnRlbnQt ZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K LS08YnIgY2xhc3M9IiI+DQomcXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5m aWVybm8mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEciBEaWVnbyBSLiBMb3Bl ejxiciBjbGFzcz0iIj4NClRlbGVmb25pY2EgSSYjNDM7RDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LyIgY2xhc3M9IiI+aHR0cDovL3Blb3Bs ZS50aWQuZXMvZGllZ28ubG9wZXovPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmUt bWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxiciBjbGFzcz0iIj4NClRlbDogJm5i c3A7ICZuYnNwOyYjNDM7MzQgOTEzIDEyOSAwNDE8YnIgY2xhc3M9IiI+DQpNb2JpbGU6ICYjNDM7 MzQgNjgyIDA1MSAwOTE8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_1A98B8E031894C9389A2FCD37D2F8F6Ftelefonicacom_-- From nobody Sat Oct 22 07:47:23 2016 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 E1BE0129731; Sat, 22 Oct 2016 07:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 XUzRgVanVIC3; Sat, 22 Oct 2016 07:47:20 -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 BD2311296EE; Sat, 22 Oct 2016 07:47:18 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9MElDG1015299 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2016 14:47:13 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u9MElCd8005976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Oct 2016 14:47:12 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9MElBFU003100; Sat, 22 Oct 2016 14:47:11 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Oct 2016 14:47:11 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-3ABC02B1-CF30-4489-A814-9F0B4A4FDF5A Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A456) In-Reply-To: <1A98B8E0-3189-4C93-89A2-FCD37D2F8F6F@telefonica.com> Date: Sat, 22 Oct 2016 07:47:08 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <012b01d2260e$e24fbd80$a6ef3880$@olddog.co.uk> <2E322FA9-1D55-4038-A270-DB349662AAFA@oracle.com> <1A98B8E0-3189-4C93-89A2-FCD37D2F8F6F@telefonica.com> To: "Diego R. Lopez" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "i2nsf@ietf.org" , "adrian@olddog.co.uk" , Kathleen Moriarty , "Id-event@ietf.org" , "aamelnikov@fastmail.fm" Subject: Re: [Id-event] [I2nsf] An I-D just for your information X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 22 Oct 2016 14:47:22 -0000 --Apple-Mail-3ABC02B1-CF30-4489-A814-9F0B4A4FDF5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-hunt-idevent-token-06 https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 Phil > On Oct 22, 2016, at 4:33 AM, Diego R. Lopez = wrote: >=20 > Hi Phil, >=20 > Can you provide a link for the SET profiles? Just looking for =E2=80=9Cset= =E2=80=9D gives a horribly unmanageable list of references=E2=80=A6 >=20 > Thanks, >=20 >> On 14 Oct 2016, at 15:24 , Phil Hunt wrote: >>=20 >> Adrian, >>=20 >> So where this might fit together is that SET simply profiles JWT so that a= n event can be expressed in secureable JSON format. We define only a set of a= ttributes necessary to validate and secure events, but pretty much leave the= data of the event up to =E2=80=9Cprofiling=E2=80=9D specifications that bui= ld on it. >>=20 >> A number of us ended up bringing this together because there was a number= of independent efforts to express very different events doing almost the sa= me thing. >>=20 >> =46rom my quick scan, one of the options would be that these events could= be expressed as a profile of SET. >>=20 >> I plan to do the same for SCIM, as does RISC, etc. The OpenID Logout spe= cs already use SET. >>=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Oct 14, 2016, at 7:33 AM, Adrian Farrel wrote: >>>=20 >>> Hi, >>>=20 >>> Just wanted to flag >>> https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info-model-monitoring= / in the >>> context of the Security Event BoF/WG. >>>=20 >>> Not sure where this sits with the Security Event work, but I2NSF seems t= o see >>> the draft as fairly important. >>>=20 >>> Cheers, >>> Adrian >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ >=20 > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-3ABC02B1-CF30-4489-A814-9F0B4A4FDF5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Oct 22,= 2016, at 4:33 AM, Diego R. Lopez <diego.r.lopez@telefonica.com> wrote:

Hi Phil,

Can you provide a link for the SET profiles? Just looking fo= r =E2=80=9Cset=E2=80=9D gives a horribly unmanageable list of references=E2=80= =A6

Thanks,

On 14 Oct 2016, at 15:24 , Phil Hunt <phil.hunt@oracle.com> wrote:

Adrian,

So where this might fit together is that SET simply profiles= JWT so that an event can be expressed in secureable JSON format. We define o= nly a set of attributes necessary to validate and secure events, but pretty m= uch leave the data of the event up to =E2=80=9Cprofiling=E2=80=9D specifications that build on it.

A number of us ended up bringing this together because there= was a number of independent efforts to express very different events doing a= lmost the same thing.

=46rom my quick scan, one of the options would be that these= events could be expressed as a profile of SET.

I plan to do the same for SCIM, as does RISC, etc.  The= OpenID Logout specs already use SET.


Phil

@independentid
www.ind= ependentid.com
phil.hunt@oracle.com





On Oct 14, 2016, at 7:33 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Just wanted to flag
https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info= -model-monitoring/ in the
context of the Security Event BoF/WG.

Not sure where this sits with the Security Event work, but I2NSF seems to se= e
the draft as fairly important.

Cheers,
Adrian

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

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org= /mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.e= s/diego.lopez/

e-mail: diego.r.lopez@telefo= nica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-3ABC02B1-CF30-4489-A814-9F0B4A4FDF5A-- From nobody Sat Oct 22 09:14:37 2016 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 10A0912960E; Sat, 22 Oct 2016 09:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 xgIMNYX3TO4d; Sat, 22 Oct 2016 09:14:32 -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 5F5D61295BC; Sat, 22 Oct 2016 09:14:31 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9MGEQ0q015094 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Oct 2016 16:14:27 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u9MGEQSj023846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Oct 2016 16:14:26 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9MGEPep009805; Sat, 22 Oct 2016 16:14:25 GMT Received: from [10.0.1.4] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Oct 2016 09:14:25 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-2A8309B5-D0FB-4622-8966-258ACE32B542 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Sat, 22 Oct 2016 09:14:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <012b01d2260e$e24fbd80$a6ef3880$@olddog.co.uk> <2E322FA9-1D55-4038-A270-DB349662AAFA@oracle.com> <1A98B8E0-3189-4C93-89A2-FCD37D2F8F6F@telefonica.com> To: "Diego R. Lopez" X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "i2nsf@ietf.org" , "adrian@olddog.co.uk" , Kathleen Moriarty , "Id-event@ietf.org" , "aamelnikov@fastmail.fm" Subject: Re: [Id-event] [I2nsf] An I-D just for your information X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 22 Oct 2016 16:14:34 -0000 --Apple-Mail-2A8309B5-D0FB-4622-8966-258ACE32B542 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not sure why, but since the recent IETF web changes earlier this year, googl= e has not been picking up doc revisions. Since SET came later it might expla= in the poor search results.=20 Anybody know who at IETF handles SRO stuff? Phil > On Oct 22, 2016, at 7:47 AM, Phil Hunt (IDM) wrote:= >=20 > https://tools.ietf.org/html/draft-hunt-idevent-token-06 >=20 > https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 >=20 > Phil >=20 >> On Oct 22, 2016, at 4:33 AM, Diego R. Lopez wrote: >>=20 >> Hi Phil, >>=20 >> Can you provide a link for the SET profiles? Just looking for =E2=80=9Cse= t=E2=80=9D gives a horribly unmanageable list of references=E2=80=A6 >>=20 >> Thanks, >>=20 >>> On 14 Oct 2016, at 15:24 , Phil Hunt wrote: >>>=20 >>> Adrian, >>>=20 >>> So where this might fit together is that SET simply profiles JWT so that= an event can be expressed in secureable JSON format. We define only a set o= f attributes necessary to validate and secure events, but pretty much leave t= he data of the event up to =E2=80=9Cprofiling=E2=80=9D specifications that b= uild on it. >>>=20 >>> A number of us ended up bringing this together because there was a numbe= r of independent efforts to express very different events doing almost the s= ame thing. >>>=20 >>> =46rom my quick scan, one of the options would be that these events coul= d be expressed as a profile of SET. >>>=20 >>> I plan to do the same for SCIM, as does RISC, etc. The OpenID Logout sp= ecs already use SET. >>>=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Oct 14, 2016, at 7:33 AM, Adrian Farrel wrote:= >>>>=20 >>>> Hi, >>>>=20 >>>> Just wanted to flag >>>> https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info-model-monitorin= g/ in the >>>> context of the Security Event BoF/WG. >>>>=20 >>>> Not sure where this sits with the Security Event work, but I2NSF seems t= o see >>>> the draft as fairly important. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf >>=20 >> -- >> "Esta vez no fallaremos, Doctor Infierno" >>=20 >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >>=20 >> e-mail: diego.r.lopez@telefonica.com >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ---------------------------------- >>=20 >> _______________________________________________ >> 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 --Apple-Mail-2A8309B5-D0FB-4622-8966-258ACE32B542 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not sure why, but since the recent IET= F web changes earlier this year, google has not been picking up doc revision= s. Since SET came later it might explain the poor search results. 

Any= body know who at IETF handles SRO stuff?

Phil

On Oct 22= , 2016, at 7:47 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:


=

On Oct 22, 2016, at 4:33 AM, Diego R. L= opez <diego.r.lopez@telef= onica.com> wrote:

Hi Phil,

Can you provide a link for the SET profiles? Just looking fo= r =E2=80=9Cset=E2=80=9D gives a horribly unmanageable list of references=E2=80= =A6

Thanks,

On 14 Oct 2016, at 15:24 , Phil Hunt <phil.hunt@oracle.com> wrote:

Adrian,

So where this might fit together is that SET simply profiles= JWT so that an event can be expressed in secureable JSON format. We define o= nly a set of attributes necessary to validate and secure events, but pretty m= uch leave the data of the event up to =E2=80=9Cprofiling=E2=80=9D specifications that build on it.

A number of us ended up bringing this together because there= was a number of independent efforts to express very different events doing a= lmost the same thing.

=46rom my quick scan, one of the options would be that these= events could be expressed as a profile of SET.

I plan to do the same for SCIM, as does RISC, etc.  The= OpenID Logout specs already use SET.


Phil

@independentid
www.ind= ependentid.com
phil.hunt@oracle.com





On Oct 14, 2016, at 7:33 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Just wanted to flag
https://datatracker.ietf.org/doc/draft-zhang-i2nsf-info= -model-monitoring/ in the
context of the Security Event BoF/WG.

Not sure where this sits with the Security Event work, but I2NSF seems to se= e
the draft as fairly important.

Cheers,
Adrian

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

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org= /mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.e= s/diego.lopez/

e-mail: diego.r.lopez@telefo= nica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
____________________________= ___________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/= mailman/listinfo/id-event
= --Apple-Mail-2A8309B5-D0FB-4622-8966-258ACE32B542-- From nobody Mon Oct 24 13:12:50 2016 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 B468D128E18; Mon, 24 Oct 2016 13:12:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147733996573.20066.8681469880315449769.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 13:12:45 -0700 Archived-At: Cc: secevent-chairs@ietf.org, id-event@ietf.org Subject: [Id-event] Kathleen Moriarty's Yes on charter-ietf-secevent-00-01: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 24 Oct 2016 20:12:45 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-secevent-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-secevent/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Still pending some edits from discussion with Stephen. From nobody Tue Oct 25 12:27:08 2016 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 A1F4D1294FB; Tue, 25 Oct 2016 12:27:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147742362662.1444.3312175604537298660.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 12:27:06 -0700 Archived-At: Cc: secevent-chairs@ietf.org, id-event@ietf.org Subject: [Id-event] Spencer Dawkins' No Objection on charter-ietf-secevent-00-01: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 25 Oct 2016 19:27:06 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-secevent-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-secevent/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm sorry for not noticing this sooner. In - A method for delivering events using HTTP POST (push) POST is an HTTP "method", but I bet that's not what you mean by "method" in this bullet - but either way, this is confusing. Could this be "mechanism", or, really, almost anything that's not "method"? From nobody Tue Oct 25 14:56:12 2016 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 A78D31294D0; Tue, 25 Oct 2016 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.132 X-Spam-Level: X-Spam-Status: No, score=-4.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, 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 1PqV-nEVhZ-r; Tue, 25 Oct 2016 14:56:05 -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 4B4FE129457; Tue, 25 Oct 2016 14:56:05 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9PLu3WZ021811 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Oct 2016 21:56:03 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9PLu3HK031507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Oct 2016 21:56:03 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9PLtxp7026756; Tue, 25 Oct 2016 21:56:02 GMT Received: from [10.255.134.149] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Oct 2016 14:55:59 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A08F9472-3FDE-4E20-91B9-E144270009E0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <147742362662.1444.3312175604537298660.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 14:55:57 -0700 Message-Id: <29FFE4AA-BF99-4576-8059-B6E5C50DEC0C@oracle.com> References: <147742362662.1444.3312175604537298660.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org Subject: Re: [Id-event] Spencer Dawkins' No Objection on charter-ietf-secevent-00-01: (with COMMENT) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 25 Oct 2016 21:56:07 -0000 --Apple-Mail=_A08F9472-3FDE-4E20-91B9-E144270009E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No objection to Spencer=E2=80=99s comment.=20 Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 25, 2016, at 12:27 PM, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > charter-ietf-secevent-00-01: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-secevent/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm sorry for not noticing this sooner. In=20 >=20 > - A method for delivering events using HTTP POST (push) >=20 > POST is an HTTP "method", but I bet that's not what you mean by = "method" > in this bullet - but either way, this is confusing. Could this be > "mechanism", or, really, almost anything that's not "method"? >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_A08F9472-3FDE-4E20-91B9-E144270009E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No objection to Spencer=E2=80=99s comment. 




On Oct 25, 2016, at 12:27 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

Spencer Dawkins has entered the following ballot position = for
charter-ietf-secevent-00-01: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)



The document, along with other ballot positions, can be found = here:
https://datatracker.ietf.org/doc/charter-ietf-secevent/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I'm sorry for not noticing this = sooner. In

- A method for delivering = events using HTTP POST (push)

POST is an = HTTP "method", but I bet that's not what you mean by "method"
in this bullet - but either way, this is confusing. Could = this be
"mechanism", or, really, almost anything that's = not "method"?


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

= --Apple-Mail=_A08F9472-3FDE-4E20-91B9-E144270009E0-- From nobody Wed Oct 26 07:32:49 2016 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 94BEF12947B for ; Wed, 26 Oct 2016 07:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, 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 yqx7pVXCSXyy for ; Wed, 26 Oct 2016 07:32:45 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 8F578129493 for ; Wed, 26 Oct 2016 07:32:44 -0700 (PDT) X-AuditID: 12074423-80fff70000007a10-d2-5810be8a0e6c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id DF.99.31248.A8EB0185; Wed, 26 Oct 2016 10:32:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u9QEWgHb012183 for ; Wed, 26 Oct 2016 10:32:42 -0400 Received: from [192.168.1.22] (c-73-222-228-244.hsd1.ca.comcast.net [73.222.228.244]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u9QEWdc7021586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2016 10:32:42 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9246396C-3007-498D-8824-F68A41733653@mit.edu> Date: Wed, 26 Oct 2016 07:32:39 -0700 To: id-event@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrNu9TyDC4PBjcYuOBd1MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmL5kJnNBj0zFw6bDrA2M/0S7GDk5JARMJOZf+sgIYgsJtDFJ dM2P7WLkArJPMkosPLeCDcJ5xSQx+VAzWBWbgKrE/JW3mEBsZgF1iT/zLjFD2NoSyxa+BrOF BaQlDn1vZwOxeQWsJFa97AOrZwHq3bd3EguILSIgKrFv4mpWiBo9iU3r3zJBXCQr8eTkIpYJ jLyzkKyYhWTFLCQtCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgQFE7uL 8g7Gl33ehxgFOBiVeHgNNglECLEmlhVX5h5ilORgUhLlrd4BFOJLyk+pzEgszogvKs1JLT7E KMHBrCTCW7AXKMebklhZlVqUD5OS5mBREuf97/Y1XEggPbEkNTs1tSC1CCYrw8GhJMHbC9Io WJSanlqRlplTgpBm4uAEGc4DNPwo2PDigsTc4sx0iPwpRkUpcd7Pe4ASAiCJjNI8uF5QtHve e/LlFaM40CvCvP9BqniAiQKu+xXQYCagwdPTwQaXJCKkpBoYS81+8kr/mXj/Wb20MIcsQ91J /eOsbvPzp2y9WuTCGuRax3wq8f/R5Y4vV927P3ma1JmJjcL6SZvv7N17q/lXHdOl3Ex3Jzmx wMbG+YvW5khoP1ass/h64Px5lhMxD09+qPk0xdVwQ2X2r52e37JWbZVTX6dQwHasb+PxG9Iv cuZKFJQ+j5Cfq8RSnJFoqMVcVJwIAN1ZnPDRAgAA Archived-At: Subject: [Id-event] Syntax of an event X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 26 Oct 2016 14:32:48 -0000 In the session at IIW yesterday, there was a discussion on the event = syntax in the current proposed draft. A few of us (myself included) = questioned the current structure which is something like this: { "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "events":[ "urn:ietf:params:scim:event:passwordReset", "https://example.com/scim/event/passwordResetExt" ], "iat": 1458496025, "iss": "https://scim.example.com", "aud":[ "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" ], "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", "urn:ietf:params:scim:event:passwordReset":{ "id":"44f6142df96bd6ab61e7521d9" }, "https://example.com/scim/event/passwordResetExt":{ "resetAttempts":5 } } To get the above information, I need to walk through the values in the = =E2=80=9Cevents=E2=80=9D array and then look for those values as members = of the root JSON object to see if they have data. Instead, I=E2=80=99d = like to raise an alternative way to codify the same event in a way that = I believe will be more easily understandable by implementors and easier = to parse by both humans and code. Namely, skip the array definition and = build out the event above like so: { "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "events=E2=80=9D: { "urn:ietf:params:scim:event:passwordReset":{ "id":"44f6142df96bd6ab61e7521d9" }, "https://example.com/scim/event/passwordResetExt":{ "resetAttempts":5 } }, "iat": 1458496025, "iss": "https://scim.example.com", "aud":[ "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" ], "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9" } With this syntax, I need to loop through the keys of the =E2=80=9Cevents=E2= =80=9D object and don=E2=80=99t need to reference anything else in the = root object. This is *much* easier to code, and it enforces that each = event key appear only once. Plus it keeps event information out of the = root of the JWT, which has been shown (with JAR, dynamic = registration=E2=80=99s software statements, and a couple others) to be = problematic at times. An argument for the current syntax is that it can handle event types = that don=E2=80=99t have any additional payload. While I don=E2=80=99t = think I=E2=80=99ve seen a concrete example of one yet (I might just be = missing it), we can still handle that in this syntax in a number of = ways. First, we could just use an empty object when there are no = arguments. "events=E2=80=9D: { "urn:ietf:params:scim:event:passwordReset":{} }, Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect = uses in the =E2=80=9Cclaims=E2=80=9D object: "events=E2=80=9D: { "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null }, Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean: "events=E2=80=9D: { "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true }, I prefer the first as it doesn=E2=80=99t change the expected object = model for all claims, and it also takes fewer characters on the wire = (not by much, so that=E2=80=99s not a driving factor, but with a lot of = these saving a couple bytes won=E2=80=99t hurt).=20 =E2=80=94 Justin From nobody Wed Oct 26 09:51:27 2016 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 B1D8C12965F for ; Wed, 26 Oct 2016 09:51:26 -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 (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 Fzvu1GL_VqAW for ; Wed, 26 Oct 2016 09:51:24 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 506E21295BB for ; Wed, 26 Oct 2016 09:51:24 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id q124so44491687itd.1 for ; Wed, 26 Oct 2016 09:51:24 -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=dt4jgecwxy7OVU3VxP792kiRooRQxFggN1AMgpARS3Q=; b=YYjn7Cp9pyDITVyH6WIDeeHpP3Z9s+i9N6RosK/UK0+gsez6R2d2o/UxD9lWHwO6B5 363W0Zx7mvUUXOLS3I/VVLaH1BSRL5F9kNMRX6nW5cCp5/MocGybVw9XwO+ez1HEI2DE 71I5zYpc1GmWidki9DALs+9cfLSY0YoDiriP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dt4jgecwxy7OVU3VxP792kiRooRQxFggN1AMgpARS3Q=; b=J5BLlV/DqFMkmctV+nRcHmrjrmVSzrQ2nE2F8F/fbdfjKrUltUq8NIqWaW5wkRhxV2 oNLo2skIJhr8ZLk1T8XPI2G6TN4vMVPsEBFHje9x/A2YWZIiy926LeET0m2Uw6ulstlB zaV5EORM3hbMtYhQppTD2F4ZWTxyWp/2ubNhFKsZc0lDNWA+TzO3miSjKpRVsCV9OQmT HwhCQ/bJEe1atwMgDbQ1DO8rmOVMhQ0fY0xcdJaEqef/jeWlJ+ZGKK1viJhvb0ft5moa wbseDLggctuzVA8/WtIPuIlXM33ZFmnyS8cHEU46pqrL6DSsgyKQOZ7wliI30PeFyD2W orSw== X-Gm-Message-State: ABUngvfCB53lihzx2yn0Job56tBML8SBRBX90/pRDA8fWwf6xr7tu2C3wqONGYPlI0KatocRSSDBfGIwn6ep5atq X-Received: by 10.107.13.194 with SMTP id 185mr3338173ion.122.1477500683346; Wed, 26 Oct 2016 09:51:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.156.74 with HTTP; Wed, 26 Oct 2016 09:50:52 -0700 (PDT) In-Reply-To: <9246396C-3007-498D-8824-F68A41733653@mit.edu> References: <9246396C-3007-498D-8824-F68A41733653@mit.edu> From: Brian Campbell Date: Wed, 26 Oct 2016 11:50:52 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a113a2b0463004a053fc76f7a Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Syntax of an event X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 26 Oct 2016 16:51:27 -0000 --001a113a2b0463004a053fc76f7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've just been loosely following the id event stuff but must admit I've previously wondered why there was the events array that referenced other claims/entries at the root. Nesting the related event information alongside the event as Justin has suggested seems more natural and straightforward. It's more compact too as the URI for each event isn't duplicated. Was there some specific reasoning behind the current syntax? On Wed, Oct 26, 2016 at 9:32 AM, Justin Richer wrote: > In the session at IIW yesterday, there was a discussion on the event > syntax in the current proposed draft. A few of us (myself included) > questioned the current structure which is something like this: > > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "events":[ > "urn:ietf:params:scim:event:passwordReset", > "https://example.com/scim/event/passwordResetExt" > ], > "iat": 1458496025, > "iss": "https://scim.example.com", > "aud":[ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > "urn:ietf:params:scim:event:passwordReset":{ > "id":"44f6142df96bd6ab61e7521d9" > }, > "https://example.com/scim/event/passwordResetExt":{ > "resetAttempts":5 > } > } > > To get the above information, I need to walk through the values in the > =E2=80=9Cevents=E2=80=9D array and then look for those values as members = of the root JSON > object to see if they have data. Instead, I=E2=80=99d like to raise an al= ternative > way to codify the same event in a way that I believe will be more easily > understandable by implementors and easier to parse by both humans and cod= e. > Namely, skip the array definition and build out the event above like so: > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset":{ > "id":"44f6142df96bd6ab61e7521d9" > }, > "https://example.com/scim/event/passwordResetExt":{ > "resetAttempts":5 > } > }, > "iat": 1458496025, > "iss": "https://scim.example.com", > "aud":[ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9" > } > With this syntax, I need to loop through the keys of the =E2=80=9Cevents= =E2=80=9D object > and don=E2=80=99t need to reference anything else in the root object. Thi= s is > *much* easier to code, and it enforces that each event key appear only > once. Plus it keeps event information out of the root of the JWT, which h= as > been shown (with JAR, dynamic registration=E2=80=99s software statements,= and a > couple others) to be problematic at times. > > An argument for the current syntax is that it can handle event types that > don=E2=80=99t have any additional payload. While I don=E2=80=99t think I= =E2=80=99ve seen a concrete > example of one yet (I might just be missing it), we can still handle that > in this syntax in a number of ways. First, we could just use an empty > object when there are no arguments. > > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset":{} > }, > > Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect us= es in the > =E2=80=9Cclaims=E2=80=9D object: > > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null > }, > > Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean: > > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true > }, > > I prefer the first as it doesn=E2=80=99t change the expected object model= for all > claims, and it also takes fewer characters on the wire (not by much, so > that=E2=80=99s not a driving factor, but with a lot of these saving a cou= ple bytes > won=E2=80=99t hurt). > > =E2=80=94 Justin > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --001a113a2b0463004a053fc76f7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've just been loosely following the id event stu= ff but must admit I've previously wondered why there was the events arr= ay that referenced other claims/entries at the root. Nesting the related ev= ent information alongside the event as Justin has suggested seems more natu= ral and straightforward. It's more compact too as the URI for each even= t isn't duplicated.

Was there some specific reasoning beh= ind the current syntax?=C2=A0

On Wed, Oct 26, 2016 at 9:32 AM, Justin Richer <jrich= er@mit.edu> wrote:
In the s= ession at IIW yesterday, there was a discussion on the event syntax in the = current proposed draft. A few of us (myself included) questioned the curren= t structure which is something like this:


=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0"jti": "3d0c3cf797584bd193bd0fb1bd4= e7d30",
=C2=A0 =C2=A0 =C2=A0"events":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0"urn:ietf:params:scim:event:passwordRe= set",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://example.com/= scim/event/passwordResetExt"
=C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0"iat": 1458496025,
=C2=A0 =C2=A0 =C2=A0"iss": "https://scim.example.com"= ;,
=C2=A0 =C2=A0 =C2=A0"aud":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/98d52461fa5bbc879593b7754",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/5d7604516b1d08641d7676ee7"
=C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0"sub":"ht= tps://scim.example.com/Users/44f6142df96bd6ab61e7521d9",=
=C2=A0 =C2=A0 =C2=A0"urn:ietf:params:scim:event:passwordReset&quo= t;:{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e752= 1d9"
=C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0"https://example.com/scim/event/passwordResetExt":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "resetAttempts":5
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

To get the above information, I need to walk through the values in the =E2= =80=9Cevents=E2=80=9D array and then look for those values as members of th= e root JSON object to see if they have data. Instead, I=E2=80=99d like to r= aise an alternative way to codify the same event in a way that I believe wi= ll be more easily understandable by implementors and easier to parse by bot= h humans and code. Namely, skip the array definition and build out the even= t above like so:

=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0"jti": "3d0c3cf797584bd193bd0fb1bd4= e7d30",
=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id":"44f6142df96bd6= ab61e7521d9"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com= /scim/event/passwordResetExt":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0"iat": 1458496025,
=C2=A0 =C2=A0 =C2=A0"iss": "https://scim.example.com"= ;,
=C2=A0 =C2=A0 =C2=A0"aud":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/98d52461fa5bbc879593b7754",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/5d7604516b1d08641d7676ee7"
=C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0"sub":"ht= tps://scim.example.com/Users/44f6142df96bd6ab61e7521d9"<= br> =C2=A0 =C2=A0}
With this syntax, I need to loop through the keys of the =E2=80=9Cevents=E2= =80=9D object and don=E2=80=99t need to reference anything else in the root= object. This is *much* easier to code, and it enforces that each event key= appear only once. Plus it keeps event information out of the root of the J= WT, which has been shown (with JAR, dynamic registration=E2=80=99s software= statements, and a couple others) to be problematic at times.

An argument for the current syntax is that it can handle event types that d= on=E2=80=99t have any additional payload. While I don=E2=80=99t think I=E2= =80=99ve seen a concrete example of one yet (I might just be missing it), w= e can still handle that in this syntax in a number of ways. First, we could= just use an empty object when there are no arguments.

=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset":{}
=C2=A0 =C2=A0 =C2=A0},

Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect uses= in the =E2=80=9Cclaims=E2=80=9D object:

=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset=E2=80=9D:null
=C2=A0 =C2=A0 =C2=A0},

Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean:

=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset=E2=80=9D:true
=C2=A0 =C2=A0 =C2=A0},

I prefer the first as it doesn=E2=80=99t change the expected object model f= or all claims, and it also takes fewer characters on the wire (not by much,= so that=E2=80=99s not a driving factor, but with a lot of these saving a c= ouple bytes won=E2=80=99t hurt).

=C2=A0=E2=80=94 Justin

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

--001a113a2b0463004a053fc76f7a-- From nobody Wed Oct 26 10:06:10 2016 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 77F0C1295D9 for ; Wed, 26 Oct 2016 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.132 X-Spam-Level: X-Spam-Status: No, score=-4.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, 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 3YlW1Yadc6Hr for ; Wed, 26 Oct 2016 10:05:52 -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 CBDAB12970F for ; Wed, 26 Oct 2016 10:05:51 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9QH5oKo018914 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Oct 2016 17:05:51 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9QH5onv010707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Oct 2016 17:05:50 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id u9QH5nGi003089; Wed, 26 Oct 2016 17:05:49 GMT Received: from [10.255.134.149] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Oct 2016 10:05:49 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_79A8C76D-EE70-4E70-BE4D-6527B3A6EFF3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 26 Oct 2016 10:05:48 -0700 Message-Id: References: <9246396C-3007-498D-8824-F68A41733653@mit.edu> To: Brian Campbell X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: id-event@ietf.org, Justin Richer Subject: Re: [Id-event] Syntax of an event X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 26 Oct 2016 17:06:05 -0000 --Apple-Mail=_79A8C76D-EE70-4E70-BE4D-6527B3A6EFF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The history was evolved from SCIM which was trying to maintain some = backwards compatibility when extensions were introduced. I must confess I hadn=E2=80=99t really thought of the optimization and = open to changing it if the group thinks a new format would be better. It = would be helpful if some could check with issues with JWT libraries and = any limitations that might be present - with any design including the = current one. The one concern I do have is I believe *most* events *should* just have = a type and a =E2=80=9Csub=E2=80=9D value. Having to use a =E2=80=9Cnull=E2= =80=9D to make this work, seems awkward. We *really* want to encourage event designers to keep payload data to a = minimum (ideally none). The objective is not to enable RPC functionality = AND to avoid PII problems that would ensue. =E2=80=9CLess is more=E2=80=9D= is my thinking. =20 Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 26, 2016, at 9:50 AM, Brian Campbell = wrote: >=20 > I've just been loosely following the id event stuff but must admit = I've previously wondered why there was the events array that referenced = other claims/entries at the root. Nesting the related event information = alongside the event as Justin has suggested seems more natural and = straightforward. It's more compact too as the URI for each event isn't = duplicated.=20 >=20 > Was there some specific reasoning behind the current syntax? =20 >=20 > On Wed, Oct 26, 2016 at 9:32 AM, Justin Richer > wrote: > In the session at IIW yesterday, there was a discussion on the event = syntax in the current proposed draft. A few of us (myself included) = questioned the current structure which is something like this: >=20 >=20 > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "events":[ > "urn:ietf:params:scim:event:passwordReset", > "https://example.com/scim/event/passwordResetExt = " > ], > "iat": 1458496025, > "iss": "https://scim.example.com ", > "aud":[ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " > ], > "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = ", > "urn:ietf:params:scim:event:passwordReset":{ > "id":"44f6142df96bd6ab61e7521d9" > }, > "https://example.com/scim/event/passwordResetExt = ":{ > "resetAttempts":5 > } > } >=20 > To get the above information, I need to walk through the values in the = =E2=80=9Cevents=E2=80=9D array and then look for those values as members = of the root JSON object to see if they have data. Instead, I=E2=80=99d = like to raise an alternative way to codify the same event in a way that = I believe will be more easily understandable by implementors and easier = to parse by both humans and code. Namely, skip the array definition and = build out the event above like so: >=20 > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset":{ > "id":"44f6142df96bd6ab61e7521d9" > }, > "https://example.com/scim/event/passwordResetExt = ":{ > "resetAttempts":5 > } > }, > "iat": 1458496025, > "iss": "https://scim.example.com ", > "aud":[ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " > ], > "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = " > } > With this syntax, I need to loop through the keys of the =E2=80=9Cevents= =E2=80=9D object and don=E2=80=99t need to reference anything else in = the root object. This is *much* easier to code, and it enforces that = each event key appear only once. Plus it keeps event information out of = the root of the JWT, which has been shown (with JAR, dynamic = registration=E2=80=99s software statements, and a couple others) to be = problematic at times. >=20 > An argument for the current syntax is that it can handle event types = that don=E2=80=99t have any additional payload. While I don=E2=80=99t = think I=E2=80=99ve seen a concrete example of one yet (I might just be = missing it), we can still handle that in this syntax in a number of = ways. First, we could just use an empty object when there are no = arguments. >=20 > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset":{} > }, >=20 > Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect = uses in the =E2=80=9Cclaims=E2=80=9D object: >=20 > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null > }, >=20 > Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean: >=20 > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true > }, >=20 > I prefer the first as it doesn=E2=80=99t change the expected object = model for all claims, and it also takes fewer characters on the wire = (not by much, so that=E2=80=99s not a driving factor, but with a lot of = these saving a couple bytes won=E2=80=99t hurt). >=20 > =E2=80=94 Justin >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_79A8C76D-EE70-4E70-BE4D-6527B3A6EFF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The history was evolved from SCIM which was trying to = maintain some backwards compatibility when extensions were = introduced.

I must = confess I hadn=E2=80=99t really thought of the optimization and open to = changing it if the group thinks a new format would be better. It would = be helpful if some could check with issues with JWT libraries and any = limitations that might be present - with any design including the = current one.

The= one concern I do have is I believe *most* events *should* just have a = type and a =E2=80=9Csub=E2=80=9D value. Having to use a =E2=80=9Cnull=E2=80= =9D to make this work, seems awkward.

We *really* want to encourage event = designers to keep payload data to a minimum (ideally none). The = objective is not to enable RPC functionality AND to avoid PII problems = that would ensue.  =E2=80=9CLess is more=E2=80=9D is my thinking. =   




On Oct 26, 2016, at 9:50 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I've just been loosely following the id event = stuff but must admit I've previously wondered why there was the events = array that referenced other claims/entries at the root. Nesting the = related event information alongside the event as Justin has suggested = seems more natural and straightforward. It's more compact too as the URI = for each event isn't duplicated.

Was = there some specific reasoning behind the current syntax? 

On Wed, Oct 26, 2016 at 9:32 AM, Justin Richer = <jricher@mit.edu> wrote:
In the session at IIW = yesterday, there was a discussion on the event syntax in the current = proposed draft. A few of us (myself included) questioned the current = structure which is something like this:


   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "events":[
       "urn:ietf:params:scim:event:passwordReset",
       "https://example.com/scim/event/passwordResetExt"
     ],
     "iat": 1458496025,
     "iss": "https://scim.example.com",
     "aud":[
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
     "urn:ietf:params:scim:event:passwordReset":{
       "id":"44f6142df96bd6ab61e7521d9"
     },
     "https://example.com/scim/event/passwordResetExt":{
        "resetAttempts":5
     }
   }

To get the above information, I need to walk through the values in the = =E2=80=9Cevents=E2=80=9D array and then look for those values as members = of the root JSON object to see if they have data. Instead, I=E2=80=99d = like to raise an alternative way to codify the same event in a way that = I believe will be more easily understandable by implementors and easier = to parse by both humans and code. Namely, skip the array definition and = build out the event above like so:

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "events=E2=80=9D: {
        "urn:ietf:params:scim:event:passwordReset":{
          "id":"44f6142df96bd6ab61e7521d9"
        },
        "https://example.com/scim/event/passwordResetExt":{
           "resetAttempts":5
        }
     },
     "iat": 1458496025,
     "iss": "https://scim.example.com",
     "aud":[
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9"
   }
With this syntax, I need to loop through the keys of the =E2=80=9Cevents=E2= =80=9D object and don=E2=80=99t need to reference anything else in the = root object. This is *much* easier to code, and it enforces that each = event key appear only once. Plus it keeps event information out of the = root of the JWT, which has been shown (with JAR, dynamic = registration=E2=80=99s software statements, and a couple others) to be = problematic at times.

An argument for the current syntax is that it can handle event types = that don=E2=80=99t have any additional payload. While I don=E2=80=99t = think I=E2=80=99ve seen a concrete example of one yet (I might just be = missing it), we can still handle that in this syntax in a number of = ways. First, we could just use an empty object when there are no = arguments.

     "events=E2=80=9D: {
        "urn:ietf:params:scim:event:passwordReset":{}
     },

Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect = uses in the =E2=80=9Cclaims=E2=80=9D object:

     "events=E2=80=9D: {
        "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null
     },

Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean:

     "events=E2=80=9D: {
        "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true
     },

I prefer the first as it doesn=E2=80=99t change the expected object = model for all claims, and it also takes fewer characters on the wire = (not by much, so that=E2=80=99s not a driving factor, but with a lot of = these saving a couple bytes won=E2=80=99t hurt).

 =E2=80=94 Justin

_______________________________________________
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

= --Apple-Mail=_79A8C76D-EE70-4E70-BE4D-6527B3A6EFF3-- From nobody Wed Oct 26 10:14:03 2016 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 94E95129BD0 for ; Wed, 26 Oct 2016 10:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, 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 Y4YYxYFF02-r for ; Wed, 26 Oct 2016 10:13:55 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 52627129BED for ; Wed, 26 Oct 2016 10:13:55 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id d128so95730624wmf.1 for ; Wed, 26 Oct 2016 10:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5QMHy0qs36zdjqhAnhFGfkXkNGwHnbsCyR0VlzSMDBw=; b=d5vlUjcnVgmCzDq5lqQxpSgPpqzkX0E6L1M1OoGATxXcW5nUtL+Z/KMOTIA6F15yVf IdVPMfxooi4QtEXeJ6XpzgsuTXV7/adDVXP5yac4tlrIpIN5DUZfyEodHz2RLgFeblSU WV3L4Bkh4EJ8pBo9dX6of9xUxY5o4xklMn+D9QBnpnO3qQjA/VnE/V8SoaObD40XvqyJ U+w4AtfHCqbC9Qdn5OC6c+sHxO3aVYGwDvJ6/NtU5CqMHY6VDXDyFdIf6vIdKt+p0FFx 3SqJlrlSBN2z8dkgiHCRRoksxVx6iNwSZK3Ioo9c+0975IFYSMSVAXKDuuxHl+cMGEFF Zfbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5QMHy0qs36zdjqhAnhFGfkXkNGwHnbsCyR0VlzSMDBw=; b=QSz/iBPbyvT8h6INtJ1IM/+tSMCYhTs/nfZbre/aCYrarsOgyOo9lk197O3fB98f9s x8z/cCR/hyfnTa9wG/r4YXYWa+aD/S7LYbSmQN9BVnIqLY3pSMxdi4t896mys1QGV1PO DXKMjsBHkCym4a0tmzJDbueqP7V7clqM4Yn2PD8Ca9bCqq6t4hyaauM+CA2SbfwjHq/H UGQGwIKe21qDjlyQMBIgmSmN2O3CIzAqrBU8suneBoNazS/S9MFD59m96lfidPSvx6wS HhzSRX9dEH9Vx32JwEfTnL6KKhEnpIzjZ1erzqoMk2T90rLhcVRSAP8ASok4r9dM8e9x 8unw== X-Gm-Message-State: ABUngvekRivjxo7Mux88p2ymSIVOoHD99gGl77mS/V5hEUEnkDXZmEN7L0rdX7JsBgAk6w6TytvhgkORibEme7lG X-Received: by 10.194.104.168 with SMTP id gf8mr3164724wjb.31.1477502033668; Wed, 26 Oct 2016 10:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.104.67 with HTTP; Wed, 26 Oct 2016 10:13:33 -0700 (PDT) In-Reply-To: References: <9246396C-3007-498D-8824-F68A41733653@mit.edu> From: Marius Scurtescu Date: Wed, 26 Oct 2016 10:13:33 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=089e0102ee06df7566053fc7bf92 Archived-At: Cc: Brian Campbell , id-event@ietf.org, Justin Richer Subject: Re: [Id-event] Syntax of an event X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 26 Oct 2016 17:14:00 -0000 --089e0102ee06df7566053fc7bf92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We are working on an early implementation and we looked at several events (password change, session revoked, token revoked, account suspended, account restored) and so far only the event type was needed, If this turns out to be the norm then the current design is the less verbose one. That being said, I don't see a big issue with the solutions proposed by Justin, other than the concern raised by Phil that encouraging rich payloads may not be a good idea. Marius On Wed, Oct 26, 2016 at 10:05 AM, Phil Hunt wrote: > The history was evolved from SCIM which was trying to maintain some > backwards compatibility when extensions were introduced. > > I must confess I hadn=E2=80=99t really thought of the optimization and op= en to > changing it if the group thinks a new format would be better. It would be > helpful if some could check with issues with JWT libraries and any > limitations that might be present - with any design including the current > one. > > The one concern I do have is I believe *most* events *should* just have a > type and a =E2=80=9Csub=E2=80=9D value. Having to use a =E2=80=9Cnull=E2= =80=9D to make this work, seems > awkward. > > We *really* want to encourage event designers to keep payload data to a > minimum (ideally none). The objective is not to enable RPC functionality > AND to avoid PII problems that would ensue. =E2=80=9CLess is more=E2=80= =9D is my thinking. > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Oct 26, 2016, at 9:50 AM, Brian Campbell > wrote: > > I've just been loosely following the id event stuff but must admit I've > previously wondered why there was the events array that referenced other > claims/entries at the root. Nesting the related event information alongsi= de > the event as Justin has suggested seems more natural and straightforward. > It's more compact too as the URI for each event isn't duplicated. > > Was there some specific reasoning behind the current syntax? > > On Wed, Oct 26, 2016 at 9:32 AM, Justin Richer wrote: > >> In the session at IIW yesterday, there was a discussion on the event >> syntax in the current proposed draft. A few of us (myself included) >> questioned the current structure which is something like this: >> >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "events":[ >> "urn:ietf:params:scim:event:passwordReset", >> "https://example.com/scim/event/passwordResetExt" >> ], >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud":[ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", >> "urn:ietf:params:scim:event:passwordReset":{ >> "id":"44f6142df96bd6ab61e7521d9" >> }, >> "https://example.com/scim/event/passwordResetExt":{ >> "resetAttempts":5 >> } >> } >> >> To get the above information, I need to walk through the values in the >> =E2=80=9Cevents=E2=80=9D array and then look for those values as members= of the root JSON >> object to see if they have data. Instead, I=E2=80=99d like to raise an a= lternative >> way to codify the same event in a way that I believe will be more easily >> understandable by implementors and easier to parse by both humans and co= de. >> Namely, skip the array definition and build out the event above like so: >> >> { >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "events=E2=80=9D: { >> "urn:ietf:params:scim:event:passwordReset":{ >> "id":"44f6142df96bd6ab61e7521d9" >> }, >> "https://example.com/scim/event/passwordResetExt":{ >> "resetAttempts":5 >> } >> }, >> "iat": 1458496025, >> "iss": "https://scim.example.com", >> "aud":[ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> ], >> "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9" >> } >> With this syntax, I need to loop through the keys of the =E2=80=9Cevents= =E2=80=9D object >> and don=E2=80=99t need to reference anything else in the root object. Th= is is >> *much* easier to code, and it enforces that each event key appear only >> once. Plus it keeps event information out of the root of the JWT, which = has >> been shown (with JAR, dynamic registration=E2=80=99s software statements= , and a >> couple others) to be problematic at times. >> >> An argument for the current syntax is that it can handle event types tha= t >> don=E2=80=99t have any additional payload. While I don=E2=80=99t think I= =E2=80=99ve seen a concrete >> example of one yet (I might just be missing it), we can still handle tha= t >> in this syntax in a number of ways. First, we could just use an empty >> object when there are no arguments. >> >> "events=E2=80=9D: { >> "urn:ietf:params:scim:event:passwordReset":{} >> }, >> >> Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect u= ses in the >> =E2=80=9Cclaims=E2=80=9D object: >> >> "events=E2=80=9D: { >> "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null >> }, >> >> Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean: >> >> "events=E2=80=9D: { >> "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true >> }, >> >> I prefer the first as it doesn=E2=80=99t change the expected object mode= l for all >> claims, and it also takes fewer characters on the wire (not by much, so >> that=E2=80=99s not a driving factor, but with a lot of these saving a co= uple bytes >> won=E2=80=99t hurt). >> >> =E2=80=94 Justin >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --089e0102ee06df7566053fc7bf92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are working on an early implementation and we looked at= several events (password change, session revoked, token revoked, account s= uspended, account restored) and so far only the event type was needed, If t= his turns out to be the norm then the current design is the less verbose on= e.

That being said, I don't see a big issue with the= solutions proposed by Justin, other than the concern raised by Phil that e= ncouraging rich payloads may not be a good idea.

=

Marius

On Wed, Oct 26, 2016 at 10:05 AM, Phil Hunt = <phil.hunt@oracle.com> wrote:
The history was evolved from SCI= M which was trying to maintain some backwards compatibility when extensions= were introduced.

I must confess I hadn=E2=80=99t really= thought of the optimization and open to changing it if the group thinks a = new format would be better. It would be helpful if some could check with is= sues with JWT libraries and any limitations that might be present - with an= y design including the current one.

The one concer= n I do have is I believe *most* events *should* just have a type and a =E2= =80=9Csub=E2=80=9D value. Having to use a =E2=80=9Cnull=E2=80=9D to make th= is work, seems awkward.

We *really* want to encour= age event designers to keep payload data to a minimum (ideally none). The o= bjective is not to enable RPC functionality AND to avoid PII problems that = would ensue. =C2=A0=E2=80=9CLess is more=E2=80=9D is my thinking. =C2=A0=C2= =A0


On Oct 26, 2016, at 9:50 AM, Brian = Campbell <bcampbell@pingidentity.com> wrote:

I've jus= t been loosely following the id event stuff but must admit I've previou= sly wondered why there was the events array that referenced other claims/en= tries at the root. Nesting the related event information alongside the even= t as Justin has suggested seems more natural and straightforward. It's = more compact too as the URI for each event isn't duplicated.

Was there some specific reasoning behind the current syntax?=C2=A0
=

On Wed, Oct 26, 2016 at 9:32 AM, Justin Richer <jricher@mit.edu<= /a>> wrote:
In the session at I= IW yesterday, there was a discussion on the event syntax in the current pro= posed draft. A few of us (myself included) questioned the current structure= which is something like this:


=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
=C2=A0 =C2=A0 =C2=A0"events":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0"urn:ietf:params:scim:event:passwordRe= set",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://example.com/= scim/event/passwordResetExt"
=C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0"iat": 1458496025,
=C2=A0 =C2=A0 =C2=A0"iss": "https://scim.example.com&quo= t;,
=C2=A0 =C2=A0 =C2=A0"aud":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/98d52461fa5bbc879593b7754",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/5d7604516b1d08641d7676ee7"
=C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0"sub":"ht= tps://scim.example.com/Users/44f6142df96bd6ab61e7521d9",=
=C2=A0 =C2=A0 =C2=A0"urn:ietf:params:scim:event:passwordReset&quo= t;:{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"id":"44f6142df96bd6ab61e7521d9"
=C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0"https://example.com/scim/ev= ent/passwordResetExt":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "resetAttempts":5
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

To get the above information, I need to walk through the values in the =E2= =80=9Cevents=E2=80=9D array and then look for those values as members of th= e root JSON object to see if they have data. Instead, I=E2=80=99d like to r= aise an alternative way to codify the same event in a way that I believe wi= ll be more easily understandable by implementors and easier to parse by bot= h humans and code. Namely, skip the array definition and build out the even= t above like so:

=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id":"44f6142df96bd6ab61e= 7521d9"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com= /scim/event/passwordResetExt":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"resetAttempts":5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0"iat": 1458496025,
=C2=A0 =C2=A0 =C2=A0"iss": "https://scim.example.com&quo= t;,
=C2=A0 =C2=A0 =C2=A0"aud":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/98d52461fa5bbc879593b7754",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"https://jhu= b.example.com/Feeds/5d7604516b1d08641d7676ee7"
=C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0"sub":"ht= tps://scim.example.com/Users/44f6142df96bd6ab61e7521d9"<= br> =C2=A0 =C2=A0}
With this syntax, I need to loop through the keys of the =E2=80=9Cevents=E2= =80=9D object and don=E2=80=99t need to reference anything else in the root= object. This is *much* easier to code, and it enforces that each event key= appear only once. Plus it keeps event information out of the root of the J= WT, which has been shown (with JAR, dynamic registration=E2=80=99s software= statements, and a couple others) to be problematic at times.

An argument for the current syntax is that it can handle event types that d= on=E2=80=99t have any additional payload. While I don=E2=80=99t think I=E2= =80=99ve seen a concrete example of one yet (I might just be missing it), w= e can still handle that in this syntax in a number of ways. First, we could= just use an empty object when there are no arguments.

=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset":{}
=C2=A0 =C2=A0 =C2=A0},

Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect uses= in the =E2=80=9Cclaims=E2=80=9D object:

=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset=E2=80=9D:null
=C2=A0 =C2=A0 =C2=A0},

Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean:

=C2=A0 =C2=A0 =C2=A0"events=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:params:scim:event:passwordR= eset=E2=80=9D:true
=C2=A0 =C2=A0 =C2=A0},

I prefer the first as it doesn=E2=80=99t change the expected object model f= or all claims, and it also takes fewer characters on the wire (not by much,= so that=E2=80=99s not a driving factor, but with a lot of these saving a c= ouple bytes won=E2=80=99t hurt).

=C2=A0=E2=80=94 Justin

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

_______________________________________________
Id-event mailing li= st
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


--089e0102ee06df7566053fc7bf92-- From nobody Thu Oct 27 08:12:50 2016 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 88054129532 for ; Thu, 27 Oct 2016 08:12:48 -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, FREEMAIL_FROM=0.001, 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=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 CXm2SSSjOj_9 for ; Thu, 27 Oct 2016 08:12:47 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 518BA12950B for ; Thu, 27 Oct 2016 08:12:47 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id c126so17826147vkd.1 for ; Thu, 27 Oct 2016 08:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=ljd4PzCxn8F/fEc5/iDAGc0kuH7YGHtKLU/gh9514u4=; b=INwcIFIeVLFdIDjCNk5kucIirx49SSJOiihvl2evmGCoDUyAXNv0U8NILfixhkd0hX NHXfYW1ZSs8bjPnU4znWgQ8EnuAeeW1SO9bcdFmAX/ifK6CU07TrII0OUe5p3YI7/k2Z Mi1qQL270qV/UPl8INNg9DKwVmhdJ+FklHL+LNFlEvNnGGwBXmJ3bIwIBpn1faSIDi8J o6L0CKInOQwXpBf00J/UFbaCDc9Tt9IrcUhSsBMrQ1v8VSE+GTp7kkdZZcMQHbfEHSBa JvJC4djkmTmkE92j/X6egBgiNk53/9jyqb52PLXgaTDsAtT1b2lY7eEbISZFmYdC06jt Zqag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ljd4PzCxn8F/fEc5/iDAGc0kuH7YGHtKLU/gh9514u4=; b=O8dVt8KiDd3+RpB8+mUEAczlJFl2IvNWOCj4mU1tWArWppt6/Z0db/jeUk8Ok1PiSm ejzCU32D0DalpbsCDPaQzN1Ccprssc/uIeIcW1Gw9hUg+yLdkB6zQpOghW4S4iX4JUYu Zhh/OgPau48C7ZG3GBAZKytBFIZuI82SEyhqHd7TMMkMcbegNvoDE9bnV/EiPkI5xISV d+9RAw6iKiJ1V90Ta05w4VfGIz0Un228Tak60eoXck4ABbagbSUdkaKSg83G++0OdzHm YvkFlMEW1dU5HNbjIaMIXORM03mpSxKtiYlbc075s54ahnHlENqNOL8A8qd/a3cybnq5 6TIw== X-Gm-Message-State: ABUngvds8tGYgecsUnmf9rBk8giYwfgt0ms0fB/ou/i/vUtf8SVwy96kfDXLCezgieAToVqcr9zC0KsnWXaBRw== X-Received: by 10.31.59.1 with SMTP id i1mr6788229vka.115.1477581166343; Thu, 27 Oct 2016 08:12:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Thu, 27 Oct 2016 08:12:45 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 27 Oct 2016 11:12:45 -0400 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary=001a11440c1e8c10e2053fda2c88 Archived-At: Cc: Yoav Nir Subject: [Id-event] Acting chair X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 27 Oct 2016 15:12:48 -0000 --001a11440c1e8c10e2053fda2c88 Content-Type: text/plain; charset=UTF-8 Hello, Yoav Nir has agreed to step in as an acting chair through the Korea meeting while we sort out chairs. Due to a positive family event for one of the volunteers, the decision has been delayed. This will also help give me a little more time to figure out what might help this WG more since I am new to it. Thanks, Yoav! -- Best regards, Kathleen --001a11440c1e8c10e2053fda2c88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Yoav Nir has agreed to step in a= s an acting chair through the Korea meeting while we sort out chairs.=C2=A0= Due to a positive family event for one of the volunteers, the decision has= been delayed.=C2=A0 This will also help give me a little more time to figu= re out what might help this WG more since I am new to it.

Thanks, Yoav!

--

Best regards,
Kathleen
--001a11440c1e8c10e2053fda2c88-- From nobody Thu Oct 27 09:30:07 2016 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 D00BB129565 for ; Thu, 27 Oct 2016 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 20Z2A97JAgYr for ; Thu, 27 Oct 2016 09:30:03 -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 6E356129480 for ; Thu, 27 Oct 2016 09:30:03 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9RGU0QP025090 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Oct 2016 16:30:02 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u9RGU0hQ023679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Oct 2016 16:30:00 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9RGTwS6028726 for ; Thu, 27 Oct 2016 16:29:59 GMT Received: from [10.255.134.149] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Oct 2016 09:29:58 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_92E25C60-8341-4755-BC39-0A28D3892F77" Date: Thu, 27 Oct 2016 09:29:57 -0700 References: To: id-event@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [Id-event] Fwd: Tuesday Session 5 - Room A - Security Event Token 101 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 27 Oct 2016 16:30:06 -0000 --Apple-Mail=_92E25C60-8341-4755-BC39-0A28D3892F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This was a presentation that Marius and I made at IIW this week. This = presentation covers the basic SET format and some of the reasoning = around the evolution of security architecture driving the need for = events. There are also some notes from the discussion. There is also some comments from Justin about proposed changes to the = token format (previously posted on the list). Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: Marius Scurtescu > Subject: Tuesday Session 5 - Room A - Security Event Token 101 > Date: October 26, 2016 at 10:55:26 AM PDT > To: iiwnotes@gmail.com > Cc: Phillip Hunt , Justin Richer = >=20 > Presentation link: > = https://github.com/independentid/Identity-Events/raw/master/SecurityEvents= 101-IIW23.pdf = >=20 > - clarification if SET only describes events or also deals with = distribution > - both, session for distribution tomorrow > - is JWT signature really optional? probably not > - query interface use case, around registration, pub/sub does not work > - account suspended event should also have a corresponding account = restored event > - event order can be mittigated by adding event time stamps > - VM time is not reliable > - sequence numbers are not feasible with move towards = decentralization > - pointing to previous evnets when current one is issued is also = problematic, leads to graph of events > - why numtiple identifier for user in password reset example > - sub is in name space of issuer, other identifier nested in event = sub-message > - is batching supported? > - some changes could generate a massive ammount of evnets, this is = when batching would be useful > - batching at event level vs transport level > - logout example, nested iss > - real world use cases > - care with session identifiers, may not be useful > - multiple devices use case > - why not nest event detaisl in the "events" attribute? > - events could be an object, keys are event URIs, values are event = sub-objects > - events could be an array, each element is an event sub-object > - current solution popular and inspired by SCIM > - what prevents these SETs from being used for authentication as Id = Tokens? >=20 >=20 > Syntax change proposal from Justin Richer: >=20 > In the session at IIW yesterday, there was a discussion on the event = syntax in the current proposed draft. A few of us (myself included) = questioned the current structure which is something like this: >=20 >=20 > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "events":[ > "urn:ietf:params:scim:event:passwordReset", > "https://example.com/scim/event/passwordResetExt = " > ], > "iat": 1458496025, > "iss": "https://scim.example.com ", > "aud":[ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " > ], > "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = ", > "urn:ietf:params:scim:event:passwordReset":{ > "id":"44f6142df96bd6ab61e7521d9" > }, > "https://example.com/scim/event/passwordResetExt = ":{ > "resetAttempts":5 > } > } >=20 > To get the above information, I need to walk through the values in the = =E2=80=9Cevents=E2=80=9D array and then look for those values as members = of the root JSON object to see if they have data. Instead, I=E2=80=99d = like to raise an alternative way to codify the same event in a way that = I believe will be more easily understandable by implementors and easier = to parse by both humans and code. Namely, skip the array definition and = build out the event above like so: >=20 > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset":{ > "id":"44f6142df96bd6ab61e7521d9" > }, > "https://example.com/scim/event/passwordResetExt = ":{ > "resetAttempts":5 > } > }, > "iat": 1458496025, > "iss": "https://scim.example.com ", > "aud":[ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " > ], > "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = " > } > With this syntax, I need to loop through the keys of the =E2=80=9Cevents= =E2=80=9D object and don=E2=80=99t need to reference anything else in = the root object. This is *much* easier to code, and it enforces that = each event key appear only once. Plus it keeps event information out of = the root of the JWT, which has been shown (with JAR, dynamic = registration=E2=80=99s software statements, and a couple others) to be = problematic at times. >=20 > An argument for the current syntax is that it can handle event types = that don=E2=80=99t have any additional payload. While I don=E2=80=99t = think I=E2=80=99ve seen a concrete example of one yet (I might just be = missing it), we can still handle that in this syntax in a number of = ways. First, we could just use an empty object when there are no = arguments. >=20 > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset":{} > }, >=20 > Second, we could just use =E2=80=9Cnull=E2=80=9D, which OpenID Connect = uses in the =E2=80=9Cclaims=E2=80=9D object: >=20 > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null > }, >=20 > Or a stand-in value like the =E2=80=9Ctrue=E2=80=9D boolean: >=20 > "events=E2=80=9D: { > "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true > }, >=20 > I prefer the first as it doesn=E2=80=99t change the expected object = model for all claims, and it also takes fewer characters on the wire = (not by much, so that=E2=80=99s not a driving factor, but with a lot of = these saving a couple bytes won=E2=80=99t hurt). >=20 > =E2=80=94 Justin >=20 > Full thread at: > = https://mailarchive.ietf.org/arch/search/?email_list=3Did-event&gbt=3D1&in= dex=3DEZJO2uiOOF0MZgbLBzkUWuNITkE = --Apple-Mail=_92E25C60-8341-4755-BC39-0A28D3892F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This was a presentation that Marius and I made at IIW this = week.  This presentation covers the basic SET format and some of = the reasoning around the evolution of security architecture driving the = need for events.  There are also some notes from the = discussion.

There is = also some comments from Justin about proposed changes to the token = format (previously posted on the list).




Begin forwarded message:

From: = Marius Scurtescu <mscurtescu@google.com>
Subject: = Tuesday Session 5 = - Room A - Security Event Token 101
Date: = October 26, 2016 at 10:55:26 AM = PDT
To: = iiwnotes@gmail.com
Cc: = Phillip Hunt <phil.hunt@oracle.com>, Justin Richer <jricher@mit.edu>

Presentation link:
https://github.com/independentid/Identity-Events/raw/master/Sec= urityEvents101-IIW23.pdf

- clarification if SET only describes = events or also deals with distribution
  - = both, session for distribution tomorrow
- is JWT = signature really optional? probably not
- query = interface use case, around registration, pub/sub does not work
- account suspended event should also have a corresponding = account restored event
- event order can be = mittigated by adding event time stamps
  - VM = time is not reliable
  - sequence numbers are = not feasible with move towards decentralization
  - pointing to previous evnets when current one is = issued is also problematic, leads to graph of events
- why numtiple identifier for user in password reset = example
  - sub is in name space of issuer, = other identifier nested in event sub-message
- is = batching supported?
  - some changes could = generate a massive ammount of evnets, this is when batching would be = useful
  - batching at event level vs = transport level
- logout example, nested = iss
  - real world use cases
  - care with session identifiers, may not be = useful
  - multiple devices use case
- why not nest event detaisl in the "events" = attribute?
  - events could be an object, keys = are event URIs, values are event sub-objects
  = - events could be an array, each element is an event = sub-object
  - current solution popular and = inspired by SCIM
- what prevents these SETs from = being used for authentication as Id Tokens?


Syntax change proposal from Justin Richer:

In the = session at IIW yesterday, there was a discussion on the event syntax in = the current proposed draft. A few of us (myself included) questioned the = current structure which is something like this:


   {
    =  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "events":[
  =     =  "urn:ietf:params:scim:event:passwordReset",
       "https://example.com/scim/event/passwordResetExt"
     ],
    =  "iat": 1458496025,
     "iss": = "https://scim.example.com",
  =    "aud":[
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /div>
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
  =    "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",<= /div>
    =  "urn:ietf:params:scim:event:passwordReset":{
      =  "id":"44f6142df96bd6ab61e7521d9"
  =    },
     "https://example.com/scim/event/passwordResetExt":{
        "resetAttempts":5
     }
  =  }

To get = the above information, I need to walk through the values in the = =E2=80=9Cevents=E2=80=9D array and then look for those values as members = of the root JSON object to see if they have data. Instead, I=E2=80=99d = like to raise an alternative way to codify the same event in a way that = I believe will be more easily understandable by implementors and easier = to parse by both humans and code. Namely, skip the array definition and = build out the event above like so:

   {
     "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
    =  "events=E2=80=9D: {
      =   "urn:ietf:params:scim:event:passwordReset":{
          = "id":"44f6142df96bd6ab61e7521d9"
    =     },
        "https://example.com/scim/event/passwordResetExt":{
          =  "resetAttempts":5
        = }
     },
  =    "iat": 1458496025,
    =  "iss": "https://scim.example.com",
  =    "aud":[
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /div>
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
  =    "sub":"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9"
   }
With this = syntax, I need to loop through the keys of the =E2=80=9Cevents=E2=80=9D = object and don=E2=80=99t need to reference anything else in the root = object. This is *much* easier to code, and it enforces that each event = key appear only once. Plus it keeps event information out of the root of = the JWT, which has been shown (with JAR, dynamic registration=E2=80=99s = software statements, and a couple others) to be problematic at = times.

An = argument for the current syntax is that it can handle event types that = don=E2=80=99t have any additional payload. While I don=E2=80=99t think = I=E2=80=99ve seen a concrete example of one yet (I might just be missing = it), we can still handle that in this syntax in a number of ways. First, = we could just use an empty object when there are no arguments.

    =  "events=E2=80=9D: {
      =   "urn:ietf:params:scim:event:passwordReset":{}
     },

Second, we could just use =E2=80=9Cnull=E2= =80=9D, which OpenID Connect uses in the =E2=80=9Cclaims=E2=80=9D = object:

  =    "events=E2=80=9D: {
    =     = "urn:ietf:params:scim:event:passwordReset=E2=80=9D:null
     },

Or a stand-in value like the =E2=80=9Ctru= e=E2=80=9D boolean:

     "events=E2=80=9D: {
        = "urn:ietf:params:scim:event:passwordReset=E2=80=9D:true
     },

I prefer the first as it doesn=E2=80=99t = change the expected object model for all claims, and it also takes fewer = characters on the wire (not by much, so that=E2=80=99s not a driving = factor, but with a lot of these saving a couple bytes won=E2=80=99t = hurt).

 =E2= =80=94 Justin

Full thread at:
https://mailarchive.ietf.org/arch/search/?email_list=3Did-event= &gbt=3D1&index=3DEZJO2uiOOF0MZgbLBzkUWuNITkE

= --Apple-Mail=_92E25C60-8341-4755-BC39-0A28D3892F77-- From nobody Thu Oct 27 09:31:20 2016 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 BE581129480 for ; Thu, 27 Oct 2016 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 cFJb8eUUP4lT for ; Thu, 27 Oct 2016 09:31:16 -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 DD524129565 for ; Thu, 27 Oct 2016 09:31:15 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9RGVEPR004511 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 27 Oct 2016 16:31:15 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9RGVE9q011570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 27 Oct 2016 16:31:14 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9RGVEmY029665 for ; Thu, 27 Oct 2016 16:31:14 GMT Received: from [10.255.134.149] (/64.71.18.60) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Oct 2016 09:31:13 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_FDE4AED1-AF16-4C61-A9FC-6EAE85808E66" Date: Thu, 27 Oct 2016 09:31:12 -0700 References: To: id-event@ietf.org Message-Id: <6B384E15-AC3F-4265-BF9D-228E7BDC47DF@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Id-event] Fwd: Wednesday Session 3 - Room A - Security Event Distribution X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 27 Oct 2016 16:31:18 -0000 --Apple-Mail=_FDE4AED1-AF16-4C61-A9FC-6EAE85808E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii These are some notes from a follow-up presentation that Marius and I = gave on SET Distribution. In particular there was another discussion on = batching based on some new cases that Any brought from the security = analytics/shared signals perspective. Thanks, Phil @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: Marius Scurtescu > Subject: Wednesday Session 3 - Room A - Security Event Distribution > Date: October 26, 2016 at 2:41:02 PM PDT > To: iiwnotes@gmail.com > Cc: Phillip Hunt >=20 > Presentation link: > = https://github.com/independentid/Identity-Events/raw/master/SET-Distributi= on-IIW23.pdf = >=20 > - how does this relate to OpenID RISC? > - OpenID RISC can use this, same for SCIM, each can profile SETs for = their own use cases > - email header deliver was also proposed, this presentation focuses on = HTTP POST > - what does an accepted message mean? > - that it was parsed > - provisioning needs guaranteed delivery, for example > - acceptance also means the right message was delivered to the right = endpoint > - who is the publisher and the subcriber? IdP to RP? > - depends on the context and profile, could flow both ways > - abuse signals may go from RP to IdP > - logout signals mostly from IdP to RP, but depends, up to OpenID = Connect to define > - 80% IdP to RP, 20% RP to IdP > - event specifies a state change, which can come later than the user = action that triggered the state change > - no event specific error messages > - "no account for this user" might be an example of event specific = error code > - a SET message going the opposite direction (if both channels are = set up) could convey the same information > - how to show interest in a spcific user account (register to receive = events for that user)? > - error handling difficuly with batching > - we should keep distribution simple, no batching, unless there is a = real need for it, can be revisited in next version > - can this be extended to other use case, like sending a logout event = to an IdP based on hardware proximity? > - CISCO had a similar use case for WebEx, feed definition is complex = in this case > - should we anticipate both way communication > - well known endpoints would help automate this, there could be = different well known URLs for RISC and SCIM > - some notifications, related to registrations, may work only with a = query interface and not pub/sub > - don't accept email address without verifying it, as an RP >=20 --Apple-Mail=_FDE4AED1-AF16-4C61-A9FC-6EAE85808E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii These are some notes from a follow-up presentation that = Marius and I gave on SET Distribution. In particular there was another = discussion on batching based on some new cases that Any brought from the = security analytics/shared signals perspective.

Thanks,




Begin forwarded message:

From: = Marius Scurtescu <mscurtescu@google.com>
Subject: = Wednesday Session = 3 - Room A - Security Event Distribution
Date: = October 26, 2016 at 2:41:02 PM = PDT
To: = iiwnotes@gmail.com
Cc: = Phillip Hunt <phil.hunt@oracle.com>

Presentation link:
https://github.com/independentid/Identity-Events/raw/master/SET= -Distribution-IIW23.pdf

- how does this relate to OpenID RISC?
  - OpenID RISC can use this, same for SCIM, each can = profile SETs for their own use cases
- email header = deliver was also proposed, this presentation focuses on HTTP = POST
- what does an accepted message = mean?
  - that it was parsed
  - provisioning needs guaranteed delivery, for = example
  - acceptance also means the right = message was delivered to the right endpoint
- who = is the publisher and the subcriber? IdP to RP?
 = - depends on the context and profile, could flow both ways
  - abuse signals may go from RP to IdP
  - logout signals mostly from IdP to RP, but depends, = up to OpenID Connect to define
  - 80% IdP to = RP, 20% RP to IdP
- event specifies a state change, = which can come later than the user action that triggered the state = change
- no event specific error messages
  - "no account for this user" might be an example of = event specific error code
    - a SET = message going the opposite direction (if both channels are set up) could = convey the same information
- how to show interest = in a spcific user account (register to receive events for that = user)?
- error handling difficuly with = batching
- we should keep distribution simple, no = batching, unless there is a real need for it, can be revisited in next = version
- can this be extended to other use case, = like sending a logout event to an IdP based on hardware = proximity?
  - CISCO had a similar use case = for WebEx, feed definition is complex in this case
- = should we anticipate both way communication
  = - well known endpoints would help automate this, there could be = different well known URLs for RISC and SCIM
- some = notifications, related to registrations, may work only with a query = interface and not pub/sub
- don't accept email = address without verifying it, as an RP


= --Apple-Mail=_FDE4AED1-AF16-4C61-A9FC-6EAE85808E66-- From nobody Fri Oct 28 08:55:28 2016 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 D09F2129408; Fri, 28 Oct 2016 08:55:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147767012684.24900.10442335675929662512.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 08:55:26 -0700 Archived-At: Cc: secevent-chairs@ietf.org, The IESG , id-event@ietf.org Subject: [Id-event] WG Action: Formed Security Events (secevent) X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 15:55:27 -0000 A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chair. Security Events (secevent) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Yoav Nir Assigned Area Director: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: id-event@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/id-event Archive: https://mailarchive.ietf.org/arch/browse/id-event/ Charter: https://datatracker.ietf.org/doc/charter-ietf-secevent/ Many HTTP web services and APIs depend on a web security infrastructure that: * identifies security subjects and regulates their access to services * and provides profile and rights information to applications. Examples are systems that leverage user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In order to prevent or mitigate security risks, or to provide out-of-band information as necessary, these systems need to share security event messages. For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party and does not wish to rely solely upon clearing a session cookie. It is expected that several identity and security working groups and organizations will use Identity Event Tokens to describe area-specific events such as: SCIM Provisioning Events, OpenID RISC Events, and OpenID Connect Backchannel Logout, among others. The Security Events working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed This Event Token specification will be event transport independent. The working group will also develop a simple standards-track Event Delivery specification that includes: - A mechanism for delivering events using HTTP POST (push) - Metadata for describing event feeds - Methods for subscribing to and managing event feeds - Methods for validating event feed subscriptions Milestones: Feb 2017 - Initial adoption of event token and event delivery drafts Jun 2017 - WG last call of event token draft Aug 2017 - Event token draft to IESG as a Proposed Standard Nov 2017 - WG last call of event delivery draft Jan 2018 - Event delivery draft to IESG as a Proposed Standard Mar 2018 - Recharter or Conclude From nobody Fri Oct 28 12:57:09 2016 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 A46621295B0 for ; Fri, 28 Oct 2016 12:57:08 -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, FREEMAIL_FROM=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=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 Zy5TU6HjTpLj for ; Fri, 28 Oct 2016 12:57:07 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 62226129505 for ; Fri, 28 Oct 2016 12:57:06 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 140so90933139wmv.0 for ; Fri, 28 Oct 2016 12:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=46YXYjosPi0M2N/xDWQU3zF9ZmLyKBDAk3GjMKBAIFk=; b=ZP2iyDVomeJdUuSfsfRI1vklsQP8gCMn0cfljbu/vgvbzoQrAyj7GYWL2L4yeNN+FT 9KcX6y9Txzh/B3xLYQNNwFKwA1jO+J6TJVD612wfBTE4SsG8ExGYPmuQzJoQLI1Sqof5 KxtvJTOgH1ohaDxylKAbj95bUR1qMhjhUjLGhRshCjm50xwl34htr0aIf9WFggvnU4VR MuEVPkruSS5KW4qYPek9YVFtL8J3Q736eatG4X/8VlNOZihPcAJ/hNiOyLJVZCBJ1RYa Od5R9Q/nBjEdxzUnz2CuKABzKfT5DeLhhS6KMYnvc0ma9Ukv+LvRmOIMxGHwoA2M5j0p 3JwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=46YXYjosPi0M2N/xDWQU3zF9ZmLyKBDAk3GjMKBAIFk=; b=h4vEJYz1cG6EN0ufR6bmRgpVTMUM1ThszTcBeuQMOBOS0X7ydjVsR6eQcGWyqScGSq Za+O/sBLLGApMreYC1s2oa8TXksLm19mr0oySq146t2tXwffKw4MbC2beX14miI+dtOI kVu/tWW2dB26umLm96xgeSwkGk15RqAEunEbZfI+Xn7iDKUCAUkNVvTyXiBLW3IXCjQl U8isGwzQQHCxcs3gjmSmdZI3OR1ZesnzeO5JhIQbelk7mwf411YES+4Cr/bvQ/D7Nb1P 4k1KktCEJSwgir30VAxHU2BZomxzUPRe4SxRoCsCNJoD93gZ2ShXzS1HTR584zAgssSd 09Iw== X-Gm-Message-State: ABUngveqDUCNyzV5ZT8u90qW3q8vmnPK/If3aSkvGeK6Azw5ucO87/dkF+80Wm7ic58H9Q== X-Received: by 10.194.238.162 with SMTP id vl2mr12733909wjc.39.1477684624564; Fri, 28 Oct 2016 12:57:04 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r72sm10537668wmd.21.2016.10.28.12.57.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 12:57:04 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Fri, 28 Oct 2016 22:57:02 +0300 To: id-event@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Id-event] Meeting in Seoul X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 19:57:08 -0000 Hi, folks So we have formed a working group, and we have a tools page ([1]) and a = charter ([2]). This acting chair gig happened rather suddenly, so I will use the next = week to catch up on the mailing list archives. In the meantime, the tools page looks rather empty, and our charter has = us adopting an event token draft and an event delivery draft by = February. So if anyone has a private draft that may be a starting point = for either of those, please send me a note and I=E2=80=99ll make it = appear on the tools page. To be clear, this is not WG adoption, just the = =E2=80=9Crelated active drafts=E2=80=9D section of the page. Similarly, if someone has a draft that is related to this group=E2=80=99s = work in some other way, send me a note as well. In other news, we have a single 1-hour slot in Seoul. We=E2=80=99ll be = meeting on Wednesday, 16-Nov at 11:10 AM in Studio 3. We still don=E2=80=99= t have an agenda. Anyone who wants a (short!) slot on that agenda, = please send me a note as well. Having a relevant draft as described two = paragraphs ago will help. So I hope to see you all in Seoul Yoav=20 (as acting chair) [1] https://tools.ietf.org/wg/secevent/ [2] = https://tools.ietf.org/wg/secevent/charters?item=3Dcharter-secevent-2016-1= 0-28.txt= From nobody Fri Oct 28 13:16:09 2016 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 92C86129655 for ; Fri, 28 Oct 2016 13:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 H5fjgNCtIRF5 for ; Fri, 28 Oct 2016 13:16:02 -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 1BFEA1295AE for ; Fri, 28 Oct 2016 13:16:02 -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 u9SKFxVq018681 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Oct 2016 20:16:00 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 u9SKFxAc029506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Oct 2016 20:15:59 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id u9SKFxag005816; Fri, 28 Oct 2016 20:15:59 GMT Received: from [100.110.237.250] (/104.132.1.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Oct 2016 13:15:59 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E8A5AE8-CF8C-41F7-8970-E2218848F574" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Fri, 28 Oct 2016 13:15:57 -0700 Message-Id: References: To: Yoav Nir X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Meeting in Seoul X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 20:16:07 -0000 --Apple-Mail=_5E8A5AE8-CF8C-41F7-8970-E2218848F574 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yoav, Thanks for pitching in as chair!=20 These are the current drafts we have been discussing. While the SET = Token is further along, both are expecting some discussion and change. = For example, there was a recent proposal from Justin to optimize parsing = structure. https://tools.ietf.org/html/draft-hunt-idevent-token-06 https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 I also propose to review these drafts in that meeting and am available = to work offline during the week to those interested. We may even want to = book an informal working room if there is interest. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 28, 2016, at 12:57 PM, Yoav Nir wrote: >=20 > Hi, folks >=20 > So we have formed a working group, and we have a tools page ([1]) and = a charter ([2]). >=20 > This acting chair gig happened rather suddenly, so I will use the next = week to catch up on the mailing list archives. >=20 > In the meantime, the tools page looks rather empty, and our charter = has us adopting an event token draft and an event delivery draft by = February. So if anyone has a private draft that may be a starting point = for either of those, please send me a note and I=E2=80=99ll make it = appear on the tools page. To be clear, this is not WG adoption, just the = =E2=80=9Crelated active drafts=E2=80=9D section of the page. >=20 > Similarly, if someone has a draft that is related to this group=E2=80=99= s work in some other way, send me a note as well. >=20 > In other news, we have a single 1-hour slot in Seoul. We=E2=80=99ll be = meeting on Wednesday, 16-Nov at 11:10 AM in Studio 3. We still don=E2=80=99= t have an agenda. Anyone who wants a (short!) slot on that agenda, = please send me a note as well. Having a relevant draft as described two = paragraphs ago will help. >=20 > So I hope to see you all in Seoul >=20 > Yoav=20 > (as acting chair) >=20 > [1] https://tools.ietf.org/wg/secevent/ > [2] = https://tools.ietf.org/wg/secevent/charters?item=3Dcharter-secevent-2016-1= 0-28.txt > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_5E8A5AE8-CF8C-41F7-8970-E2218848F574 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yoav,

Thanks for pitching in as chair! 
These are the current drafts we have = been discussing. While the SET Token is further along, both are = expecting some discussion and change.  For example, there was a = recent proposal from Justin to optimize parsing structure.

https://tools.ietf.org/html/draft-hunt-idevent-token-06
https://tools.ietf.org/html/draft-hunt-idevent-distribution-01<= /a>

I also = propose to review these drafts in that meeting and am available to work = offline during the week to those interested. We may even want to book an = informal working room if there is interest.




On Oct 28, 2016, at 12:57 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi, folks

So we have formed a = working group, and we have a tools page ([1]) and a charter ([2]).

This acting chair gig happened rather = suddenly, so I will use the next week to catch up on the mailing list = archives.

In the meantime, the tools page = looks rather empty, and our charter has us adopting an event token draft = and an event delivery draft by February. So if anyone has a private = draft that may be a starting point for either of those, please send me a = note and I=E2=80=99ll make it appear on the tools page. To be clear, = this is not WG adoption, just the =E2=80=9Crelated active drafts=E2=80=9D = section of the page.

Similarly, if someone = has a draft that is related to this group=E2=80=99s work in some other = way, send me a note as well.

In other news, = we have a single 1-hour slot in Seoul. We=E2=80=99ll be meeting on = Wednesday, 16-Nov at 11:10 AM in Studio 3. We still don=E2=80=99t have = an agenda. Anyone who wants a (short!) slot on that agenda, please send = me a note as well. Having a relevant draft as described two paragraphs = ago will help.

So I hope to see you all in = Seoul

Yoav
(as acting = chair)

[1] https://tools.ietf.org/wg/secevent/
[2] https://tools.ietf.org/wg/secevent/charters?item=3Dcharter-sece= vent-2016-10-28.txt
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_5E8A5AE8-CF8C-41F7-8970-E2218848F574-- From nobody Fri Oct 28 13:18:49 2016 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 4C67D129636; Fri, 28 Oct 2016 13:18:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147768592827.24923.3343279288188915195.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 13:18:48 -0700 Archived-At: Subject: [Id-event] The SECEVENT WG has placed draft-hunt-idevent-token in state "Candidate for WG Adoption" X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 20:18:48 -0000 The SECEVENT WG has placed draft-hunt-idevent-token in state Candidate for WG Adoption (entered by Yoav Nir) The document is available at https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ From nobody Fri Oct 28 13:19:41 2016 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 21848129636; Fri, 28 Oct 2016 13:19:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147768598013.24908.5142529726182471343.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 13:19:40 -0700 Archived-At: Subject: [Id-event] The SECEVENT WG has placed draft-hunt-idevent-distribution in state "Candidate for WG Adoption" X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 20:19:40 -0000 The SECEVENT WG has placed draft-hunt-idevent-distribution in state Candidate for WG Adoption (entered by Yoav Nir) The document is available at https://datatracker.ietf.org/doc/draft-hunt-idevent-distribution/ From nobody Fri Oct 28 13:38:52 2016 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 265AD12962F for ; Fri, 28 Oct 2016 13:38:52 -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, FREEMAIL_FROM=0.001, 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=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 OFL2avOQO5vt for ; Fri, 28 Oct 2016 13:38:50 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 2F94312958F for ; Fri, 28 Oct 2016 13:38:50 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id e69so126225669wmg.0 for ; Fri, 28 Oct 2016 13:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gnIjaM/l0AoxMy2O+d1/xODiLVzlv46mw0C7Z93xy/c=; b=wSI5j4ascuNC2TtyUV2RJZR45ZnUl+Qvwrez0pAptmWsNBgLgfCecPLaAUGEt8ChDK Zjf2LiqhjxEqaDBrt4MI1U0MPz2TsWpF2CEJ8S7U9DkD5gVw04b+JJ4fvN7BG3T6gSd9 GhMOvFFd8MeWvXFRUWti/IIkMmOX2eLdAHclz6o2xqcFP+m4bxQW3KlG7ETCS2eTZahL Ggqnr3MA4QS4tgIJ6Kbz8o5rIZwEodyiut6jhrzUA4quWEmCZ3EoJJI1M9ZGcfHKotbg PEO5cts1KCiJhYpveSmEda9jias6IOiPVle44MHp+PZeNPg2eAhJWdO5raSXFr/WmiUm 1vdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gnIjaM/l0AoxMy2O+d1/xODiLVzlv46mw0C7Z93xy/c=; b=J76i+T984b6AF9GIoIYfK7Pb2mZC0q6gn5klNlS0QQBKqRUPsqU5decQEdEEvSyiX8 O9VKsKAPMQADoIjzE+V6b14Niuo/FO4yqhj8CeNTCiNkQPOnzFr5OEqILZr5WE8LOorU 2h3ZPCb37PZ0DP3nWPmTiIlm2MJ+6yGdXenwTXlPlok6wNB8wCvD/NWhDEPziRgSOf8e yIDoVr9IjZtBwy47K0lt07FxyVtZ5CeOd01cmK0dTCgaW2MoiXQhuYIHxK359ctMrsNS ZJQojNHoAzFefZKUmM3S0afuAiNolHEX0C83GIdX7wfDMpL7qg5yVqYH7fU7PTdT/ykI qang== X-Gm-Message-State: ABUngveTvqOn203Fxb8WRtqJI+9Lf7whpXRrfUwC4tgtONmLR2MF1BTUkR5hfKY6WOKpLA== X-Received: by 10.194.86.201 with SMTP id r9mr12859392wjz.5.1477687128719; Fri, 28 Oct 2016 13:38:48 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id q134sm10701782wme.3.2016.10.28.13.38.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 13:38:48 -0700 (PDT) From: Yoav Nir Message-Id: <36177C19-0B9B-4F94-B710-789BD0263923@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_87E29403-787F-4FD5-B53A-EADA680360D5" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Fri, 28 Oct 2016 23:38:46 +0300 In-Reply-To: To: Phil Hunt References: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Meeting in Seoul X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 20:38:52 -0000 --Apple-Mail=_87E29403-787F-4FD5-B53A-EADA680360D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Oct 2016, at 23:15, Phil Hunt wrote: >=20 > Yoav, >=20 > Thanks for pitching in as chair!=20 >=20 > These are the current drafts we have been discussing. While the SET = Token is further along, both are expecting some discussion and change. = For example, there was a recent proposal from Justin to optimize parsing = structure. >=20 > https://tools.ietf.org/html/draft-hunt-idevent-token-06 = > https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 = >=20 > I also propose to review these drafts in that meeting That would be great. This is the first meeting of the WG and there = wasn=E2=80=99t a BoF. We can expect a bunch of tourists, so a good = explanation of what this is about would be great. > and am available to work offline during the week to those interested. = We may even want to book an informal working room if there is interest. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 --Apple-Mail=_87E29403-787F-4FD5-B53A-EADA680360D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 28 Oct 2016, at 23:15, Phil Hunt <phil.hunt@oracle.com> wrote:

Yoav,

Thanks for pitching in = as chair! 

These are the current drafts we have been discussing. While = the SET Token is further along, both are expecting some discussion and = change.  For example, there was a recent proposal from Justin to = optimize parsing structure.

https://tools.ietf.org/html/draft-hunt-idevent-token-06
https://tools.ietf.org/html/draft-hunt-idevent-distribution-01<= /a>

I also = propose to review these drafts in that meeting =

That would be = great. This is the first meeting of the WG and there wasn=E2=80=99t a = BoF. We can expect a bunch of tourists, so a good explanation of what = this is about would be great.

= --Apple-Mail=_87E29403-787F-4FD5-B53A-EADA680360D5-- From nobody Fri Oct 28 14:20:10 2016 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 8E3D61294FB for ; Fri, 28 Oct 2016 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 GgYFE4SxbrAa for ; Fri, 28 Oct 2016 14:20:07 -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 2E5421294D5 for ; Fri, 28 Oct 2016 14:20:07 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9SLK4Wa024482 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Oct 2016 21:20:04 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9SLK4MH003097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Oct 2016 21:20:04 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u9SLK4ZU005971; Fri, 28 Oct 2016 21:20:04 GMT Received: from [100.110.237.250] (/104.132.1.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Oct 2016 14:20:03 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_D09E0894-5E78-421A-BE4F-32DBC0B4B94E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <36177C19-0B9B-4F94-B710-789BD0263923@gmail.com> Date: Fri, 28 Oct 2016 14:20:02 -0700 Message-Id: <424BE424-508E-4DD4-AB29-CB76E02310D9@oracle.com> References: <36177C19-0B9B-4F94-B710-789BD0263923@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Meeting in Seoul X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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, 28 Oct 2016 21:20:08 -0000 --Apple-Mail=_D09E0894-5E78-421A-BE4F-32DBC0B4B94E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Oct 28, 2016, at 1:38 PM, Yoav Nir wrote: >=20 >=20 >> On 28 Oct 2016, at 23:15, Phil Hunt > wrote: >>=20 >> Yoav, >>=20 >> Thanks for pitching in as chair!=20 >>=20 >> These are the current drafts we have been discussing. While the SET = Token is further along, both are expecting some discussion and change. = For example, there was a recent proposal from Justin to optimize parsing = structure. >>=20 >> https://tools.ietf.org/html/draft-hunt-idevent-token-06 = >> https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 = >>=20 >> I also propose to review these drafts in that meeting >=20 > That would be great. This is the first meeting of the WG and there = wasn=E2=80=99t a BoF. We can expect a bunch of tourists, so a good = explanation of what this is about would be great. >=20 >> and am available to work offline during the week to those interested. = We may even want to book an informal working room if there is interest. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_D09E0894-5E78-421A-BE4F-32DBC0B4B94E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed.




On Oct 28, 2016, at 1:38 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:


On 28 Oct 2016, at 23:15, Phil Hunt <phil.hunt@oracle.com> wrote:

Yoav,

Thanks for pitching in = as chair! 

These are the current drafts we have been discussing. While = the SET Token is further along, both are expecting some discussion and = change.  For example, there was a recent proposal from Justin to = optimize parsing structure.

https://tools.ietf.org/html/draft-hunt-idevent-token-06
https://tools.ietf.org/html/draft-hunt-idevent-distribution-01<= /a>

I also = propose to review these drafts in that meeting =

That = would be great. This is the first meeting of the WG and there wasn=E2=80=99= t a BoF. We can expect a bunch of tourists, so a good explanation of = what this is about would be great.

and am available to work offline during the week to those = interested. We may even want to book an informal working room if there = is interest.

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

= --Apple-Mail=_D09E0894-5E78-421A-BE4F-32DBC0B4B94E-- From nobody Sat Oct 29 08:21:01 2016 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 7A360129538 for ; Sat, 29 Oct 2016 08:21:00 -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, FREEMAIL_FROM=0.001, 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=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 q-5JQSR1r60m for ; Sat, 29 Oct 2016 08:20:58 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5DAE41294EA for ; Sat, 29 Oct 2016 08:20:58 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id 140so117523182wmv.0 for ; Sat, 29 Oct 2016 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VSYp85EzLcujH8QH9KaEfIeHai1FOmIPP9y0p5KkLEU=; b=dawDHb6BWRjd+FIWSl7p4xKd/5neMEm6Zn6WqaBcjQW5Wxle1/Yx1JQGA4moStwtL8 Fc9+CLKgrZfF1QWb0zgnDWxFfCFLsHfx8YnHk1zLuUS5sXDxT5ztBJOi1YOz4OCzJNio 8RAlJe/pZ57BU1KO83y4jeBXPZ6YufNblAsdD1orjvkrwwWXn7LMWzUBwfcSlyIiuToE s8uqcmDX5N/Ihl8K4f5HXcOAn1Di8o7LFq6cWbnXeh3CLb1izZq4/Hoek9emkznMFMwy wlr2ZGK7NOy4+gDkZ7F/vZtcbsDo6uOORENNXWIAz5vTESZeHPzBNzu48A57U5fJa+I9 qY9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VSYp85EzLcujH8QH9KaEfIeHai1FOmIPP9y0p5KkLEU=; b=jfQGbS6KMV9jcwqvVi8DqoLUHRSMN4FiCz35EU3S7z/Tu8zozvXNj9Morh7VftcfwC BqOg+6vjOTy4nswzJCQ/RCnTqzxIrPgc44gA3L8n+jm/c/tqNi7vPswvyz6DymFNZ5kA L698ewK3Zv/WyOKFaJWSR/2V8iWlOmZSUcIVHHYuUI6Ac9+rz1dFJTBy9aaOnRsapP4H HJyPhZRyttKd6rHPKKRohy8JxPaQOS5g9W/NojJwrA4Ez7EunuiwSOXHInBowax+1w47 /yPvm7vq7yfWOMXGJT0Ej2lPjVv0LDZ/VNYg521hy9ckT0RDamVD4kCIzxZ+3ZUpKvUs 92PQ== X-Gm-Message-State: ABUngvdDL7VnD1U9225uviMJ/5WsUWdvPB4HCF3oMyMvoJlXsWp+qPGlKSQV6OOZBChzZw== X-Received: by 10.28.131.72 with SMTP id f69mr3270297wmd.33.1477754456946; Sat, 29 Oct 2016 08:20:56 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p9sm19926522wjs.11.2016.10.29.08.20.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 08:20:56 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BBE20C02-6C3B-478C-B4ED-7A4F45B1ACE7" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Sat, 29 Oct 2016 18:20:54 +0300 In-Reply-To: <424BE424-508E-4DD4-AB29-CB76E02310D9@oracle.com> To: Phil Hunt References: <36177C19-0B9B-4F94-B710-789BD0263923@gmail.com> <424BE424-508E-4DD4-AB29-CB76E02310D9@oracle.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Meeting in Seoul X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 29 Oct 2016 15:21:00 -0000 --Apple-Mail=_BBE20C02-6C3B-478C-B4ED-7A4F45B1ACE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good. So how long will you need? > On 29 Oct 2016, at 0:20, Phil Hunt wrote: >=20 > Agreed. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Oct 28, 2016, at 1:38 PM, Yoav Nir > wrote: >>=20 >>=20 >>> On 28 Oct 2016, at 23:15, Phil Hunt > wrote: >>>=20 >>> Yoav, >>>=20 >>> Thanks for pitching in as chair!=20 >>>=20 >>> These are the current drafts we have been discussing. While the SET = Token is further along, both are expecting some discussion and change. = For example, there was a recent proposal from Justin to optimize parsing = structure. >>>=20 >>> https://tools.ietf.org/html/draft-hunt-idevent-token-06 = >>> https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 = >>>=20 >>> I also propose to review these drafts in that meeting >>=20 >> That would be great. This is the first meeting of the WG and there = wasn=E2=80=99t a BoF. We can expect a bunch of tourists, so a good = explanation of what this is about would be great. >>=20 >>> and am available to work offline during the week to those = interested. We may even want to book an informal working room if there = is interest. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 --Apple-Mail=_BBE20C02-6C3B-478C-B4ED-7A4F45B1ACE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good. So how long will you need?

On = 29 Oct 2016, at 0:20, Phil Hunt <phil.hunt@oracle.com> wrote:

Agreed.





On Oct 28, 2016, at 1:38 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:


On 28 Oct 2016, at 23:15, Phil Hunt <phil.hunt@oracle.com> wrote:

Yoav,

Thanks for pitching in = as chair! 

These are the current drafts we have been discussing. While = the SET Token is further along, both are expecting some discussion and = change.  For example, there was a recent proposal from Justin to = optimize parsing structure.

https://tools.ietf.org/html/draft-hunt-idevent-token-06
https://tools.ietf.org/html/draft-hunt-idevent-distribution-01<= /a>

I also = propose to review these drafts in that meeting =

That = would be great. This is the first meeting of the WG and there wasn=E2=80=99= t a BoF. We can expect a bunch of tourists, so a good explanation of = what this is about would be great.

and am available to work offline during the week to those = interested. We may even want to book an informal working room if there = is interest.

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


= --Apple-Mail=_BBE20C02-6C3B-478C-B4ED-7A4F45B1ACE7-- From nobody Sat Oct 29 08:41:43 2016 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 5CB361295C5 for ; Sat, 29 Oct 2016 08:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, 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 wprzl4z-RrPF for ; Sat, 29 Oct 2016 08:41:39 -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 19DB212940B for ; Sat, 29 Oct 2016 08:41:37 -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 u9TFfYQb016701 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 29 Oct 2016 15:41: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 u9TFfYbC019822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 29 Oct 2016 15:41:34 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id u9TFfXoJ017369; Sat, 29 Oct 2016 15:41:33 GMT Received: from [25.90.125.246] (/72.143.224.186) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Oct 2016 08:41:32 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-8E49B0FE-B534-4D62-A0E9-516E918012DF Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Sat, 29 Oct 2016 08:41:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: <78093771-81F1-4937-8686-7585E0E450F4@oracle.com> References: <36177C19-0B9B-4F94-B710-789BD0263923@gmail.com> <424BE424-508E-4DD4-AB29-CB76E02310D9@oracle.com> To: Yoav Nir X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: id-event@ietf.org Subject: Re: [Id-event] Meeting in Seoul X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 29 Oct 2016 15:41:41 -0000 --Apple-Mail-8E49B0FE-B534-4D62-A0E9-516E918012DF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For the informal session? 2-3hours.=20 Phil > On Oct 29, 2016, at 8:20 AM, Yoav Nir wrote: >=20 > Good. So how long will you need? >=20 >> On 29 Oct 2016, at 0:20, Phil Hunt wrote: >>=20 >> Agreed. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >>>> On Oct 28, 2016, at 1:38 PM, Yoav Nir wrote: >>>>=20 >>>>=20 >>>> On 28 Oct 2016, at 23:15, Phil Hunt wrote: >>>>=20 >>>> Yoav, >>>>=20 >>>> Thanks for pitching in as chair!=20 >>>>=20 >>>> These are the current drafts we have been discussing. While the SET Tok= en is further along, both are expecting some discussion and change. For exa= mple, there was a recent proposal from Justin to optimize parsing structure.= >>>>=20 >>>> https://tools.ietf.org/html/draft-hunt-idevent-token-06 >>>> https://tools.ietf.org/html/draft-hunt-idevent-distribution-01 >>>>=20 >>>> I also propose to review these drafts in that meeting >>>=20 >>> That would be great. This is the first meeting of the WG and there wasn=E2= =80=99t a BoF. We can expect a bunch of tourists, so a good explanation of w= hat this is about would be great. >>>=20 >>>> and am available to work offline during the week to those interested. W= e may even want to book an informal working room if there is interest. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >=20 --Apple-Mail-8E49B0FE-B534-4D62-A0E9-516E918012DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For the informal session? 2-3hours.&nb= sp;

Phil

On Oct 29, 2016, at 8:20 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Good. So how long will you need?

On 29 Oct 2016, at 0:20, Phil Hunt <phil.hunt@oracle.com> wrote:

Agreed.

Phil
<= br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com





On Oct 28, 2016, at 1:38 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
<= br class=3D"Apple-interchange-newline">

On 28 Oct 2016, at 23:15, Phil Hunt <phil.hunt@oracle.com> w= rote:

Yoav,

Thanks for pitching in as chair! 

These are the current drafts we have b= een discussing. While the SET Token is further along, both are expecting som= e discussion and change.  For example, there was a recent proposal from= Justin to optimize parsing structure.

<= /div>
https://tools.ietf.org/html/draft-hunt-idevent-token= -06
https://tools.ietf.org/html/draft-hun= t-idevent-distribution-01

I also propose to review these drafts in that meeting

That would be grea= t. This is the first meeting of the WG and there wasn=E2=80=99t a BoF. We ca= n expect a bunch of tourists, so a good explanation of what this is about wo= uld be great.

and am available to work offline during the week t= o those interested. We may even want to book an informal working room if the= re is interest.

Phil
<= br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com

=

_______________________________________________Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mail= man/listinfo/id-event


= --Apple-Mail-8E49B0FE-B534-4D62-A0E9-516E918012DF--