Subject: [Id-event] Summary of initial discussion and what do we want to achieve

From: Phil Hunt <[email-masked]>
Date: Wed, 4 Nov 2015 17:41:21 +0900

Sorry I did not get this out earlier. Good to see everyone on the list already!

To get the discussion going, here are some notes from the informal meeting that spawned this group.  I’ve combined a bunch of comments from our offline thread. Apologies if I have missed anything.

Before we go much further, I want to remind folks that this is not yet a work group. Part of what we want to discuss is:
* What drafts (if any) should be written
* Where do we want to do the work (it does not necessarily fit with OAuth or SCIM)
  e.g. This could end-up in a WG where we do the foundational pieces and then each interested group then profiles for their area.
* What is the problem and what are the common themes that unite the common effort?

As usual all of this stuff falls under the IETF Notewell rules.

Summary:  there are a number of different initiatives that are all starting to generate events around identity. We got together to talk about whether we should be aligning our efforts. The areas that may be interested are:

OIDC - Session Logout / Revocation
OAuth - Token Revocation
RISC - Account events (take over, account reset, etc)
SCIM - Provisioning events (has overlap with RISC)
Consent - Tracking and delivery of consent events (e.g. in a distributed healthcare system).

The group had agreement that there should be a core “event” JWT specification developed at the IETF. This becomes the basic information packet that can be delivered via HTTP and other protocols.  Once the Event JWT is defined, each group can create profiles appropriate to their constituency. 

The general feeling was that all cases need a publish and subscribe model, but that different areas might have widely varying types of subscriptions.  E.g.
*  1:1 - a web app getting notifications about changes to a user’s profile or a de-provisioning notification
*  1:secured set of RPs - e.g. notifying RPs about session or token revocations
*  1:domain - inter-domain state change notifications
-  broadcast - e.g. sending out a RISC event to interested subscriber domains.

While I suggested the Pub/Sub/Hub model that initial proposal "SCIM Notify" has (see https://tools.ietf.org/html/draft-hunt-scim-notify-00), there was no immediate consensus that this was the right approach. We since discussed that we don’t necessarily need to include the publisher to hub portion. The main part of the hub functionality that describes how feeds and subscriptions work are the more important parts - whether a hub is implemented is really something up to the implementer and isn’t really an important inter-op point.

We talked about some of the issues with using JWT tokens. More specifically around type indicators. Since that discussion is already started I won’t re-hash it here.

We also talked that the message system should be self-healing. There might need to be a way for a subscriber to detect or confirm if it has missed any messages. E.g. clients could check message-id numbers etc. We would also like to ensure, for scalability and security reasons, that messages are not kept for long periods of time.

Other comments were made in direct emails between the attendees. I see some of those comments have already started happening.

Thanks everyone!

Phil

@independentid
www.independentid.com
[email-masked]