Subject: Re: [Id-event] [Openid-specs-risc] Breaking out the distribution draft

From: Craig McMurtry <[email-masked]>
Date: Wed, 1 Mar 2017 00:28:34 +0000

After some discussion with the RISC WG folks and Adam Dawes, I would like to propose that I break out a SET Transmission draft that includes the following:

1.  Basic HTTPS POST profile to a specified endpoint.  It is up to the receiver to provide fault tolerance and high-availability that meets its own delivery assurance requirements.
2.  A set of metadata that describes the endpoints, the encryption methods (eg. keys for signing and encrypting JWTs) etc.
3.  A simple control plane API that allows a subscriber (receiver) to perform an HTTPS GET to obtain the current configuration and subscription (stream) status.  While compatible with SCIM, it will NOT require SCIM to be implemented.
4.  Configuration of subscriptions (streams) is done through out-of-scope administrative processes offered by event publishers.
5.  In the initial profile, subscribers will not be able to “pause” streams automatically unless offered through the administrative interface of the publisher.

  *   In breaking it out, I’d be delighted to see a shift away from Security Event Tokens, to a specification for publishing a catalog of event tokens and subscribing to them.  I imagine that all of the participants on this thread, at least, have a variety of entities about which they may which to publish notifications.  If there already was a specification for publishing a catalog and subscribing to a feed, then the Security Event Token and Transmission specifications should simply cite that specification and say little else; it is precisely because there isn’t, that those basic operations are being incorporated into a specification for security events.

The single thing I wish had been done differently with SCIM was that the very nice mechanism it provides for an extensible schema was not broken out into a specification that was silent with respect to its semantic domain.  As it is, I believe the landscape actually has OData and SCIM providing alternative ways of standardizing a variety of REST endpoints, and while it’s heretical for someone at Microsoft to express a preference for the latter, I might be inclined to do so.

  *   At least one version of the Security Event Token specifications I read accommodated both subscriptions for receiving a push of notifications as well as subscriptions for pulling notifications, depending on what the feed in question supported.  A prominent opinion among my colleagues, which I share, is that security-related events cannot be missed.  The simplest solution to that problem, at least at the protocol layer, is to at least have the option of having the events pulled.  Implementers can then proceed to specify, out of band, how they throttle subscribers.

  *   The most basic definition of the event token should not prescribe the format of the JSON within the JWT, but merely suggest one.  The current specification would exclude that JSON being OData, I believe, which is an impediment to adoption.  Besides OData, presumably other would-be implementers already have structures that would be perfectly suitable.

  *   Adoption of SCIM is picking up fast.  I deal with at least one new implementer every week.  Nevertheless, I don’t see much of a prospect for the SCIM event specification.  Provided one can put ANY JSON anywhere in the event, I could and would simply put in SCIM objects as defined by the existing 2.0 specification, rather than ones further refined by a new specification.

In summary …

  1.  No restriction to security.
  2.  Push and Pull
  3.  No prescribed data format below JWT.

Craig McMurtry
Developer, Identity Management

Microsoft Corporation
Building 27, Office 3474
1 Microsoft Way, Redmond, WA 98052

Office: +1.425.707.9810|Mobile: +1.425.503.2854|Fax: +1.425.936.7329

Re: [Id-event] [Openid-specs-risc] Breaking out the distribution draft

"Hardt, Dick" <[email-masked]> Tue, 28 February 2017 19:42 UTCShow header<https://mailarchive.ietf.org/arch/search/?email_list=id-event>

From: "Hardt, Dick" <[email-masked]>
To: "Phil Hunt (IDM)" <[email-masked]>

On 2/28/17, 9:12 AM, someone claiming to be "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>> wrote:

RISC use case is typically bi-directional so events can be used. It also works better because usually a receiver may add only or drop only depending on implicit or explicit federation.

This sentence does not make sense to me.

Adam argued for all other update items to be done OOB.

Adam: would you elaborate? As I understand it, you are saying you don’t want to standardize how Amazon and Google / Microsoft will coordinate, and this also leaves out how PayPal and Identity Analytics would signal. We should standardize how we subscribe to subjects.

That just left error signalling for the receiver to find out why events were not coming.

The ping?

We left it that scim can be quickly added for those that want full automated CRUD (oracle does). Buy it would not be required in core.

“SCIM quickly added” sounds like an oxymoron. ☺

Phil

On Feb 28, 2017, at 8:32 AM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps I am missing it, but I don’t see a mechanism for the receiver to add / delete which subjects the receiver is interested in. Is this not included, or am I misunderstanding what is below?

Or is that out of scope? If so, that seems odd as there is a control plane API in (3)

/Dick

On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

I think this is great Phil. Thanks again for the detailed conversation where we were able to arrive at this.

On Mon, Feb 27, 2017 at 1:35 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Please confirm if you agree with the following:

I had previously promised to break up the distribution draft into components. I ran into some difficulty as to how subscribers (receivers) of events find out if the publisher is having problems delivering events.

After some discussion with the RISC WG folks and Adam Dawes, I would like to propose that I break out a SET Transmission draft that includes the following:

1.  Basic HTTPS POST profile to a specified endpoint.  It is up to the receiver to provide fault tolerance and high-availability that meets its own delivery assurance requirements.
2.  A set of metadata that describes the endpoints, the encryption methods (eg. keys for signing and encrypting JWTs) etc.
3.  A simple control plane API that allows a subscriber (receiver) to perform an HTTPS GET to obtain the current configuration and subscription (stream) status.  While compatible with SCIM, it will NOT require SCIM to be implemented.
4.  Configuration of subscriptions (streams) is done through out-of-scope administrative processes offered by event publishers.
5.  In the initial profile, subscribers will not be able to “pause” streams automatically unless offered through the administrative interface of the publisher.

If people have a need for automated management, the basic idea is that you implement the POST and PATCH methods of SCIM and you are good to go. We don’t need to spend a lot of time on it as there is nothing special to do once the metadata for streams is defined.

Does this work for everyone?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410