From nobody Thu Jul 14 11:37: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 45EFD12D162 for ; Thu, 14 Jul 2016 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=engageidentity-com.20150623.gappssmtp.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 VNq4EXxv5Ybr for ; Thu, 14 Jul 2016 11:37:22 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 A4A5B12D123 for ; Thu, 14 Jul 2016 11:37:21 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id q132so70869658lfe.3 for ; Thu, 14 Jul 2016 11:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rg6oEBRb32R013NwQBM961kJX4L0aGv1RSsZo3ON2kQ=; b=T5cLSDSeBh9DyTgmBnAdnCGbjXaOaIFf9w2792VYtvS5aJG2IlUT7ciy8dTrmuK0zB LCrUpN0e6E6s9CHk3adpMWZAwGoE0FtKF/P6QjGqcp22tvnsvDcg8Sv0qFyod3tQrAmQ dyEFXaxJEObB2Ity/FKHBiah999vivdqZIbupjM4WzG1j/1jAxRGwbn72l/NIgR4l8Z4 hCWrfAkRBaxE8eM2nhNNRBHAgv8QFzRhyUeAbIQB8YzLSKWs8Mx35idCuJlZLo1oot1V GItJl9f3/Vtp084aIbS0fg+bxivmroAQsvwdYyME6mYRRu28pcJdAAHchQVVOspqaIyO gjQA== 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; bh=rg6oEBRb32R013NwQBM961kJX4L0aGv1RSsZo3ON2kQ=; b=dEzCaDGC2ltybGwribSt1eM+MKMut45Vw+O8JqC96Pn4mSvyynswcj0yhuKU2Dwj1P Z1Yjd63HNRd2jSwJCgBOAc49Lo5dq/IaTENIm10qPfgDE5aQfSK7wPj2w+PLFWV12mn7 wmlB6dh/Ds+OyxDBRaQYr3G6LeoEFS8HF/fHN2mb5psxWAI1lNs8FjpAtaEf8o4Rs0B4 znIExti12xA5RkpKqaJFgfr/LeTEC5Nna0uz4eVkZIl51mjOvQuJx3CtCIr4e6X6CKLd xNrngndPUelvA2sidr+n8/pnGCAX7jEAqC2fmuc/8XKFaq07kGzizlfai91DfYrCqOvf p4/w== X-Gm-Message-State: ALyK8tKKeRL/imq98rQm4UhTf+ndklRNnfzuEIxTe7fQYUaqvSHuiX/4GiJ1kFscFVX1P4K9Ae3QS7zzrAcf5gax X-Received: by 10.25.88.20 with SMTP id m20mr8070249lfb.150.1468521439661; Thu, 14 Jul 2016 11:37:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.241 with HTTP; Thu, 14 Jul 2016 11:37:19 -0700 (PDT) From: Sarah Squire Date: Thu, 14 Jul 2016 11:37:19 -0700 Message-ID: To: id-event@ietf.org Content-Type: multipart/alternative; boundary=001a113f2f08c1aa0f05379cca39 Archived-At: Subject: [Id-event] ID Event Discussion at IETF 96 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, 14 Jul 2016 18:37:23 -0000 --001a113f2f08c1aa0f05379cca39 Content-Type: text/plain; charset=UTF-8 Is there an ID Event discussion planned at IETF 96? If so, where? If not, let's put one together! Sarah Sarah Squire Engage Identity http://engageidentity.com --001a113f2f08c1aa0f05379cca39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there an ID Event discussion planned at IETF 96? If so,= where? If not, let's put one together!

Sarah

Sara= h Squire
Engage Identity
http://engageidentity.com<= /a>
--001a113f2f08c1aa0f05379cca39-- From nobody Thu Jul 14 22:59: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 B596412D5A2 for ; Thu, 14 Jul 2016 22:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=engageidentity-com.20150623.gappssmtp.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 rGc3f3_SGcLa for ; Thu, 14 Jul 2016 22:59:20 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 AE2C312D8C6 for ; Thu, 14 Jul 2016 22:59:19 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id q132so79450053lfe.3 for ; Thu, 14 Jul 2016 22:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aQv5FH0VJKMWoO5PNf1K/lzgURnxaVhL16dCG5zIH04=; b=ZTHVzvzEaWCArY6fm7+S3sQ5ehEzYtwrqtZ+kXIVBFt2nMcf5iigzCmjWZaEEnquL7 kSJ9pgEft2JGxKDfqDtCXpAmhnPPX+GcTD4AAtKIo/gZfEoXAySt9UGPhJIMRveqcY7M dTZUhFmASRegGHQqGqxAkKDfnMWE+e4EKGGQcHhee1Wwv+ffz3bTorUAIJai0e5y5167 FCSOLfovXOB9GKnt53abd7ttYozXQizUsDq37aAMrSPyXwHZJWvAKFu9sG0oQx7QmbU5 WIMAz+amjh8Nn4SF1tWSHA0O9rK1qAi6jU8X4f0skVCYdLEUV0NfNr2cCwcvfs/xmos5 2plQ== 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=aQv5FH0VJKMWoO5PNf1K/lzgURnxaVhL16dCG5zIH04=; b=Ou48x8h055UHlNZxoRjWd0LBGQCfsuxtt3yRBMPmPwgkZZzoA/43yFQnCC8mLQ/Tll aynkkCrSqgmN+iCwvYR+YC8PrjzCKAFrqAvBsYJiKnb4jvHMDmN+f5XpSTAHQ70v6Tsp qrmNWn/oltnvzD/VbuwguptGcrpYy4p/vRsXLXc869papjLSvco1sGU7buuy2IKlmXSJ DJQN3M1zUo+UuXF5N1D5//RQB7ox7pc6Dt4SuUpRKnzQ+OsBx2gXtC1hCBttXaNrsBjR kvAUkUOCYpi0ACD6xXvgrSegA+zADDnkfBGyaGeZ5w3MUprJ1HvGQ7fWolHqRFkEwC7M /elg== X-Gm-Message-State: ALyK8tJjpeiZDRYldpZv0gRkKa0vxn0SUvNUsFWUOXAwcX9j3JjvHP3gFCnXqTTPtRqh05R98HV/FKlr1qr2U5t0 X-Received: by 10.25.88.20 with SMTP id m20mr9392659lfb.150.1468562357602; Thu, 14 Jul 2016 22:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.241 with HTTP; Thu, 14 Jul 2016 22:59:16 -0700 (PDT) In-Reply-To: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> References: <42194DA6-B018-4879-B472-A180EB131A04@oracle.com> From: Sarah Squire Date: Thu, 14 Jul 2016 22:59:16 -0700 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a113f2f08a7d48d0537a6513f Archived-At: Cc: Alan Karp , Mike Jones , Vivek Biswas , "Morteza Ansari \(moransar\)" , "id-event@ietf.org" Subject: Re: [Id-event] Straw man text for proposed charter 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, 15 Jul 2016 05:59:23 -0000 --001a113f2f08a7d48d0537a6513f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 format, 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 agree 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 securit= y > 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=E2=80=99s why there=E2=80=99s a claims registry =E2=80=93 so= common 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 there i= s > a possibility to define claims which are domain specific. Thereby claims > generated in one application could be understood by another application > 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 an > 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 =E2=80=93 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. M= y > 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 be >> stated as being out of scope in the working group charter. Attempting t= o >> 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=E2=80=99s an application-specif= ic >> decision. >> >> Should events be idempotent? That=E2=80=99s an application-specific dec= ision. >> >> Should events be unicast, multicast, or broadcast? That=E2=80=99s an >> application-specific decision. >> >> Should events have categories with category-specific subscriptions? >> That=E2=80=99s 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=E2= =80=99s an >> application-specific decision. >> >> I could continue with this list, but I think you all get the point=E2=80= =A6 >> >> >> >> If we start debating application-specific event delivery mechanisms, >> we=E2=80=99ll please almost no one, since nearly all applications have d= ifferent >> event delivery requirements. We MUST explicitly rule all delivery >> mechanisms as being out of scope. >> >> >> >> If we define only a data format, we can quickly produce a very useful >> specification. If we don=E2=80=99t, we=E2=80=99ll get bogged down in th= e mud of debating >> which applications we=E2=80=99re catering to and which we aren=E2=80=99t= =E2=80=93 an exercise of >> picking favorites and limiting applicability of the specification. That >> way is a slow, painful descent into standards quicksand =E2=80=93 someth= ing we must >> avoid. Having a standard ID events representation is far too important = to >> tie to a particular limited event delivery mechanism. >> >> >> >> Sincerely, >> >> -- Mike >> >> >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Alan >> Karp >> *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) < >> moransar@cisco.com> wrote: >> >> Hi folks, >> >> >> >> At IIW a few of us (Phil, William, Adam, and I) huddled for a bit and pu= t >> 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 > > --001a113f2f08a7d48d0537a6513f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just submitting my two cents in writing before we hop= efully have a chance to meet about this next week...

Lo= oking 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 format, this= is less structured than what I was envisioning, but we could easily do a h= ealthcare-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 ar= e 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 the= se are application layer decisions. However, if we're talking about clo= ud provider-to-cloud provider communication, that certainly is facilitated = by a well-defined transport layer. Again, we're willing to profile what= ever the group comes up with for our own ends, but I don't really see t= he benefit of having a loosely defined transport layer - it just seems like= more work for all the implementers to actually agree on endpoints on a cas= e-by-case basis.

Looking forward to discussing fur= ther in Berlin!

Sarah
On Sat, May 7, 2016 at 6:53 PM, Phil Hunt (I= DM) <phil.hunt@oracle.com> wrote:
We also set things up so even a domain sp= ecific event can be extended.=C2=A0

Eg on a passwo= rd reset event, so event publishers may want to add security domain specifi= c attributes. The spec lets them do that while avoiding interop issues.=C2= =A0

I believe in the spec we had the example of an= account reset and the publisher adds reset count as an extension.=C2=A0

Phil

On May 7, 2016, at 13:31, Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com> wrote:

Indeed, that=E2=80=99s why there=E2=80=99s a claims = registry =E2=80=93 so common claims can be defined once and then reused.

=C2=A0

From: Vivek Biswas
Sent: Saturday, May 7, 2016 1:24 PM
To: Mike Jones
Cc: Alan Ka= rp; Morteza Ansari (moransar); id-event@ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

=C2=A0

Yes, I agree that the claims can be application specific, however ther= e is a possibility to define claims which are domain specific. Thereby clai= ms generated in one application could be understood by another =C2=A0applic= ation 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
=C2=A0 Consulting Member, Oracle

Sent from my iPhone

On May 7, 2016, at 1:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

Thanks Alan,

=C2=A0

Interoperability will = be on a per-application basis, just like JWT interoperability.=C2=A0 The cl= aims needed in an identity event are application-specific, just like claims= are for JWTs.=C2=A0 This is the same standards posture and JWTs are a huge success =E2=80=93 including for interoperabili= ty, even if I do say so myself.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Best wishes,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

As one who proposed doing= more, I believe that your position is valid.=C2=A0 My only question is whe= ther or not that will be enough for interoperability.


--------------
Alan Karp

On Thu, May 5, 2016 at 10:00 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Thanks guys, for writing the initial = charter text.=C2=A0 Reading it now, I am extremely worried by the scope cre= ep evident in the proposal.

=C2=A0

I strongly support a working group to= define an ID Events data format.=C2=A0 I just as strongly believe that spe= cific event delivery mechanisms will necessarily be application-specific and therefore MUST be explicitly be stated as bein= g out of scope in the working group charter.=C2=A0 Attempting to specify a = particular event delivery mechanism will take something that could be simpl= e and quick to approve and bog it down in necessarily application-specific debates.

=C2=A0

Should event delivery be reliable?=C2= =A0 That=E2=80=99s an application-specific decision.

Should events be idempotent?=C2=A0 Th= at=E2=80=99s an application-specific decision.

Should events be unicast, multicast, = or broadcast?=C2=A0 That=E2=80=99s an application-specific decision.=

Should events have categories with ca= tegory-specific subscriptions?=C2=A0 That=E2=80=99s an application-specific= decision.

Should only one party at a time be ab= le to register for delivery of events or should multiple parties be able to= request delivery?=C2=A0 That=E2=80=99s an application-specific decision.

I could continue with this list, but = I think you all get the point=E2=80=A6

=C2=A0

If we start debating application-spec= ific event delivery mechanisms, we=E2=80=99ll please almost no one, since n= early all applications have different event delivery requirements.=C2=A0 We MUST explicitly rule all delivery mechanisms as bei= ng out of scope.

=C2=A0

If we define only a data format, we c= an quickly produce a very useful specification.=C2=A0 If we don=E2=80=99t, = we=E2=80=99ll get bogged down in the mud of debating which applications we=E2=80=99re catering to and which we aren=E2=80=99t =E2=80=93 an exercis= e of picking favorites and limiting applicability of the specification.=C2= =A0 That way is a slow, painful descent into standards quicksand =E2=80=93 = something we must avoid.=C2=A0 Having a standard ID events representation i= s far too important to tie to a particular limited event delivery mechanism.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Sincerely,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org= ] On Behalf Of Alan Karp
Sent: Thursday, May 5, 2016 9:43 PM
To: Morteza Ansari (moransar) <moransar@cisco.com>
Cc: id-event@= ietf.org
Subject: Re: [Id-event] Straw man text for proposed charter

=C2=A0

I don't see anything about access control for pu= blishing events and subscribing to them.=C2=A0 I also think the spec should= allow filters on subscriptions.



--------------
Alan Karp

=C2=A0

On Thu, May 5, 2016 at 11:18 AM, Morteza Ansari (mor= ansar) <moransar= @cisco.com> wrote:

Hi folks,

=C2=A0

At IIW a few of us (Phil, William, Adam= , and I) huddled for a bit and put together the attached as a straw man cha= rter proposal to start the discussion. Please send your comments and suggestions for any changes or propose a new one if= you think its necessary.

=C2=A0

=C2=A0

Cheers,

Morteza


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

=C2=A0


_______________________________________________
Id-event mailing list
Id-event@ietf.= org
https://www.ietf.org/mailman/listinfo/id-event
___________________= ____________________________
Id-event mailing listId-event@iet= f.org
https://www.ietf.org/mailman/listinfo/id-event<= /a>

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


--001a113f2f08a7d48d0537a6513f-- From nobody Sun Jul 17 08:57: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 68EE71288B8 for ; Sun, 17 Jul 2016 08:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=engageidentity-com.20150623.gappssmtp.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 wggzb55h-bCu for ; Sun, 17 Jul 2016 08:57:18 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 CAD7212D0AC for ; Sun, 17 Jul 2016 08:57:17 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id f93so116944667lfi.2 for ; Sun, 17 Jul 2016 08:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engageidentity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=J30zRR8khueh6cbuxl8CYyD5lCCPn5cu5oV4fYmnIss=; b=BCCdva1zXxRV7y8S2P8uJAUSJepc5QUmqmlVMFwMLav4FE3W3rEqs04dd3TpIdufJE hVZj18Evj794WXncYo67YtrvvDgk4zWGmLe7E325htDhQrGg6ZD+whO1Tcb0A5Hl0o3H h23mW7y+SEFXiJcrSmZhlOw/AVTaLggJ36cUMgE+XRS32+celtFZqIFnUe+FrK+l5JMn Ix3yydvBu8+rJBdFwqxKp5noexmU2fzkeMTbhHUJK3kaAziTPfH9xlOVE9NPe+0E0I+W +f2Hht7bDdtztgmb46l5++ZAeiQlHxXM4HTcSCXqAha52SzFMzdp2pO0sbG369b0YBbf Ayag== 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:date :message-id:subject:from:to; bh=J30zRR8khueh6cbuxl8CYyD5lCCPn5cu5oV4fYmnIss=; b=Nlag4nSpcK01JXt68P6QYk8RJV2nTuWrrf5zwCuOf8s3g8Hp3n/vxTvGOA2xXqXz/X +3JkxhLwsafVwE/4c9FODwXreouwJ6E16N6hyELZuWmsYp/k9x4UsYuwO92L1YofdIbX pHjovn08MPWJHU4PJEedKgUD1lMKgrCgG8lrb6+MGUUiHmq51Ptxq+P0OOB2RrLHLcnU Gla07JgIIRF2VZg9Jkac8VlSsnyn8QOnZRnFpxJCfyuJuC8NSSvTVoCFGcAkzAGkq1al gfdCzcXS/yIFpCJI6tV6vGXw16cvD9PAq/PsoXZg1PPIdq/UHClVx8DB9z65Dt6GBGL7 8Zyg== X-Gm-Message-State: ALyK8tJFX0bqrx4RR9v5tYwMTRTB6J4zPT0ixyGS4rcWgjfhlYMfMS2fVcZBqSdfKg4Z0spNkpPDEyWprRfXf1UE MIME-Version: 1.0 X-Received: by 10.25.39.85 with SMTP id n82mr14203007lfn.29.1468771035447; Sun, 17 Jul 2016 08:57:15 -0700 (PDT) Received: by 10.114.3.241 with HTTP; Sun, 17 Jul 2016 08:57:15 -0700 (PDT) Received: by 10.114.3.241 with HTTP; Sun, 17 Jul 2016 08:57:15 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Jul 2016 08:57:15 -0700 Message-ID: From: Sarah Squire To: id-event@ietf.org Content-Type: multipart/alternative; boundary=001a11410fecd31c620537d6e701 Archived-At: Subject: Re: [Id-event] ID Event Discussion at IETF 96 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: Sun, 17 Jul 2016 15:57:21 -0000 --001a11410fecd31c620537d6e701 Content-Type: text/plain; charset=UTF-8 We've decided to have an unsanctioned breakfast BoF on Thursday morning. We're meeting at 9am at the LA Cafe in the Intercontinental. Please join us! On Jul 14, 2016 20:37, "Sarah Squire" wrote: > Is there an ID Event discussion planned at IETF 96? If so, where? If not, > let's put one together! > > Sarah > > Sarah Squire > Engage Identity > http://engageidentity.com > --001a11410fecd31c620537d6e701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We've decided to have an unsanctioned=C2=A0=C2=A0 breakf= ast BoF on Thursday morning. We're meeting at 9am at the LA Cafe in the= Intercontinental. Please join us!


On Jul 14, 2016 2= 0:37, "Sarah Squire" <sarah@engageidentity.com> wrote:
Is there an ID Event discussion pl= anned at IETF 96? If so, where? If not, let's put one together!
Sarah

Sarah = Squire
Engage Identity
http://engageidentity.com
--001a11410fecd31c620537d6e701-- From nobody Thu Jul 21 00:14:40 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 A2D9112DA71 for ; Thu, 21 Jul 2016 00:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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, RP_MATCHES_RCVD=-1.287, 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 DUXyiRSQ5zHE for ; Thu, 21 Jul 2016 00:14:37 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 BBC5012DA5A for ; Thu, 21 Jul 2016 00:14:37 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id z8so44948341ywa.1 for ; Thu, 21 Jul 2016 00:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ekOi8wKs6x0b2VcEizFvCsWGSDZkNVGiBA1ikbKWvjs=; b=gmioxhnK/eW7d26rj5SwFNaA9sSxl0XsvMOBel8Qk/rDkYlDNHB33cRivBIemXofTZ wmEZp2wa3CHt52W29mCFStSg5KTHbrz5Mfb+FRU2/E4KmolUP0l6Mha8OgJ0OOSu4n+1 U2uasQokxrZfkV/CTg60itaQcDMW97if2vkElc4+aE3IPC8JXY+NwZZy1eSnDpV6no7I tvQ6FLEIBSGqK1HCv3H04FfYmEVnBTHxR2WlHm+IQN11zJWXE0U22MLq+C0He8VQ4JO9 2/0TwrmLkNSRBtqQ35ySLP3zTOUx83cgXVNuisKX38d4BV8ZsvbsBq6LIqKkUvCDaN3k yELA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ekOi8wKs6x0b2VcEizFvCsWGSDZkNVGiBA1ikbKWvjs=; b=b1hjrBWLcfusRgFfS+C+zDEz2uT9zIeB2SFjLW6quXMyq1RKaMH+3w/n9boG0HpXGE JYaNan3vDjVLiPJBvgJvR+jcgmL3CpOiIleo4DGSuP+CEtoOCNp72DODowX8KLR+g0Cw 6AQUHrJPA8WqepU2/kcETULvmF+maCUwcXXqZD/nQ5Aj9Jz8WZnQrFiwt6mqYkWq8odx iSBXe8anwNI6K/PJ6wC1vchmo3/YekZZp/YT5L9bpgIAtsd0aqqBPl8hda8RDTeNJsu+ F7WG3NHaKxpgGoVHNmgvyaEGxPzQSFdOszXVgmrV2CxyILb/UCEA9cYXFoZJIH/RYwh+ dx3Q== X-Gm-Message-State: ALyK8tJSMK9YdQgP9M0OoITWI2Vrdmlpp8FbC6s2OWUDKDBwOqkNxtpSTsNnQH+b8/qju+usq10pI6UVkCy6rUiE X-Received: by 10.129.4.78 with SMTP id 75mr32480904ywe.66.1469085276816; Thu, 21 Jul 2016 00:14:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Thu, 21 Jul 2016 07:14:26 +0000 Message-ID: To: Sarah Squire , id-event@ietf.org Content-Type: multipart/alternative; boundary=001a113f1dac122e0005382012ae Archived-At: Subject: Re: [Id-event] ID Event Discussion at IETF 96 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, 21 Jul 2016 07:14:39 -0000 --001a113f1dac122e0005382012ae Content-Type: text/plain; charset=UTF-8 We have a table by the big glass windows in the side area. On Sun, Jul 17, 2016 at 5:57 PM Sarah Squire wrote: > We've decided to have an unsanctioned breakfast BoF on Thursday morning. > We're meeting at 9am at the LA Cafe in the Intercontinental. Please join us! > > On Jul 14, 2016 20:37, "Sarah Squire" wrote: > >> Is there an ID Event discussion planned at IETF 96? If so, where? If not, >> let's put one together! >> >> Sarah >> >> Sarah Squire >> Engage Identity >> http://engageidentity.com >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --001a113f1dac122e0005382012ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have a table by the big glass windows in the side area.

We&= #39;ve decided to have an unsanctioned=C2=A0=C2=A0 breakfast BoF on Thursda= y morning. We're meeting at 9am at the LA Cafe in the Intercontinental.= Please join us!


On Jul 14, 2016 2= 0:37, "Sarah Squire" <sarah@engageidentity.com> wrote:
Is there an ID E= vent discussion planned at IETF 96? If so, where? If not, let's put one= together!

Sarah

Sarah Squire
Engage = Identity
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--001a113f1dac122e0005382012ae--