[scim] Plan for distribution draft for IETF99 Prague

Phil Hunt <phil.hunt@oracle.com> Sun, 07 May 2017 21:49 UTC

From: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_76C4B00E-8E65-49CE-B103-85C8304D3B12"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <AFEAF7F3-A140-4293-934B-9172F4A00BEA@oracle.com>
Date: Sun, 07 May 2017 14:49:44 -0700
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "scim@ietf.org WG" <scim@ietf.org>
To: ID Events Mailing List <id-event@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/95YpuF97m1_zWq9krh1K3Efd0j0>
Subject: [scim] Plan for distribution draft for IETF99 Prague
Precedence: list

Hi all,

Marius and I have been doing a lot of discussion since the last IETF meeting and with various folks.

Going forwards, Marius and I plan to do the following:

1. Data Plane - The distribution draft will be cut down to cover the data plane - delivery of events (ietf-hunt-secevents-delivery). It will be expanded to include polling of one or more events via HTTP GET to address firewall use cases.

Marius and I believe there is reasonably consensus on this (though some are confused). The distribution draft will cover all cases from SCIM, RISC, and Backchannel Logout.

The Data plane will define and describe the Verification event, how it is used and validated for both push and poll. The spec will not cover how or when a transmitter decides to initiate verification as this is assumed to be part of the control plane.

Important: The data plane is not and will not be based on SCIM.

The objective of this draft is to allow near term implementation and piloting to move forward.

Monitoring and automated provisioning will be part of a new draft….

2. Control Plane - new alternate proposal
Marius has offered to produce a new draft (e.g. ietf-scurtescu-secevent-stream-mgmt) as a brand new Control Plane proposal.

Since part of the problem with the original proposal was a lack of consensus on the requirements for the control plane, I would encourage discussion on the features of the control plane now.

For example:
* How a stream is registered/defined (CREATE)
* How a stream is validated (verification)
* How a stream is monitored including indication of transmission problems (READ)
* How a stream configuration can be updated (e.g. credential rotation or endpoint change) (UPDATE)
* How a stream can be paused or stopped (UPDATE)
* How to delete a stream- (DELETE)
* Meta data including issuer and receiver public key sets (e.g. jwks_Uri)
* Some generic discussion of credentials for HTTP authentication
* From a data perspective:
- what event types are in a stream?
- what subjects are part of a stream and how are they managed (see use cases)
- how is this modelled and managed?
- can a receiver inquire if a subject is enrolled?
- what are the different identifiers that can be used: subject, email, telephone, etc?
* How is the control api extensible to support the various profiling specs that will use the SEC EVENTS control plane draft?

ps. I am stepping down from participating as an author or editor in the control plane draft going forwards.

Regards,

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>

[scim] Plan for distribution draft for IETF99 Pra… Phil Hunt