Subject: Re: [Id-event] Straw man text for proposed charter

From: Sarah Squire <[email-masked]>
Date: Thu, 14 Jul 2016 22:59:16 -0700

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) <[email-masked]>
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 <[email-masked]> wrote:
>
> Indeed, that’s why there’s a claims registry – so common claims can be
> defined once and then reused.
>
>
>
> *From: *Vivek Biswas <[email-masked]>
> *Sent: *Saturday, May 7, 2016 1:24 PM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Alan Karp <[email-masked]>; Morteza Ansari (moransar)
> <[email-masked]>; [email-masked]
> *Subject: *Re: [Id-event] Straw man text for proposed charter
>
>
> Yes, I agree that the claims can be application specific, however there is
> 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 <[email-masked]>
> 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 – including for
> interoperability, even if I do say so myself.
>
>
>
>                                                           Best wishes,
>
>                                                           -- Mike
>
>
>
>
>
>
>
>
>
> *From: *Alan Karp <[email-masked]>
> *Sent: *Saturday, May 7, 2016 10:23 AM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Morteza Ansari (moransar) <[email-masked]>; [email-masked]
> *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 <[email-masked]>
> 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 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’s an application-specific
>> decision.
>>
>> Should events be idempotent?  That’s an application-specific decision.
>>
>> Should events be unicast, multicast, or broadcast?  That’s an
>> application-specific decision.
>>
>> Should events have categories with category-specific subscriptions?
>> That’s 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’s an
>> application-specific decision.
>>
>> I could continue with this list, but I think you all get the point…
>>
>>
>>
>> If we start debating application-specific event delivery mechanisms,
>> we’ll please almost no one, since nearly all applications have different
>> 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’t, we’ll get bogged down in the mud of debating
>> which applications we’re catering to and which we aren’t – an exercise of
>> picking favorites and limiting applicability of the specification.  That
>> way is a slow, painful descent into standards quicksand – something 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:[email-masked]] *On Behalf Of *Alan
>> Karp
>> *Sent:* Thursday, May 5, 2016 9:43 PM
>> *To:* Morteza Ansari (moransar) <[email-masked]>
>> *Cc:* [email-masked]
>> *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) <
>> [email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/id-event
>>
>>
>>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>