Subject: [Id-event] Fwd: New Version Notification for draft-hunt-secevent-sstp-00.txt

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Mar 2018 20:59:07 +0000

Given the discussion around having a single MTI method for SET Delivery, and consensus issue emerging on choosing PUSH or PULL for MTI, this draft is submitted as a *compromise* which merges both methods into a single “symmetric” approach capable of addressing both communities concerns and all use cases. The draft has 3 examples which show how PULL-only, PUSH-only, and how PUSH-PULL may be accomplished using the unified approach.

Whether “pushing” (e.g. from an issuer to a receiver HTTP endpoint) or “pulling” (by a receiver from an issuer HTTP endpoint), the same transfer and response methods and formats are always used.  Because delivery can be either direction or both directions, the sender and receiver are free to choose role as HTTP Client or Server based on the environmental and network restrictions they face.

Where possible, we have kept the protocol signalling and responses the same or simpler. Three changes in particular: 
* Transmitter/receiver terminology is dropped (due to bi-directionality) and replaced with HTTP Client vs. HTTP/SSTP Server. (non-normative)
* Both pushers and pullers use the same multi-SET format.  (normative change for PUSH)
* The flag maxEvents=N is now replaced with a simple boolean returnEvents and now also allows the HTTP client to indicate it does not want to pull events 

Previous features and capability(such as multi-threading) characteristics have been preserved. For example, error signalling was the same for both methods and remains the same.

Tony and I recognize that as separate methods, there could be more optimization. For example, in PUSH mode, receivers now have to process a JSON structure that contains multiple SETs vs. just parsing one set. We considered preserving single-event (application/jwt) format, and could still do so. However, having multiple content-types seems to add unnecessary complexity and more implementer coding.

Best Regards,

Phil

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

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hunt-secevent-sstp-00.txt
> Date: March 22, 2018 at 11:00:01 AM GMT
> To: "Phil Hunt" <[email-masked]>, "Anthony Nadalin" <[email-masked]>
> 
> 
> A new version of I-D, draft-hunt-secevent-sstp-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Name:		draft-hunt-secevent-sstp
> Revision:	00
> Title:		Symmetric SET Transfer Protocol
> Document date:	2018-03-22
> Group:		Individual Submission
> Pages:		23
> URL:            https://www.ietf.org/internet-drafts/draft-hunt-secevent-sstp-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-secevent-sstp/
> Htmlized:       https://tools.ietf.org/html/draft-hunt-secevent-sstp-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hunt-secevent-sstp
> 
> 
> Abstract:
>   This specification defines how security event tokens (SETs) may be
>   exchanged between a client and service provider using HTTP POST over
>   TLS using a symmetric format.  The specification supports three modes
>   of operation: "push", "pull", and "push-pull" bi-directional SET
>   exchange.  The specification also defines a simple acknowledge
>   mechanism allowing parties to confirm delivery.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 26 Mar 2018 19:04:26 +0000

While there is a certain simplicity in having a single protocol where all requests and responses look the same, this simplicity is superficial; this protocol has all the same complexities and interop challenges as the two protocol approach, albeit in different forms. As with Push/Poll, SSTP allows an event transmitter to transmit requests by acting as an HTTP client (i.e. “push”) or as an HTTP server (i.e. “pull”). However, neither mode is MTI for SSTP so saying simply that “I support SSTP” is insufficient to inform others how to integrate with you. The question changes from “which protocol did you implement?” to “which features of the protocol did you implement?” but the question still has to be answered.

Similarly I think bi-directionality is far less useful in practice than it might seem. For the use cases that we’ve been discussing SET reception is likely to be centralized, either as a single endpoint that receives SETs or as a single system that polls for SETs, but SET generation is likely to be distributed, as different events occur in different places within the client’s architecture. A client would have to reconcile this conflict in order for them to make use of SSTP’s bi-directionality, and that adds significant complexity. For the server, it’s not quite so bad. Supporting bi-directional SSTP isn’t much more complex than supporting HTTP Poll. However, it does tightly couple the server’s SET transmission and SET reception systems together, which introduces unnecessary operational risk for both systems. From a functional standpoint, there is no reason these two systems need to depend on one another.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Thursday, March 22, 2018 at 2:00 PM
To: ID Events Mailing List <[email-masked]>
Subject: [Id-event] Fwd: New Version Notification for draft-hunt-secevent-sstp-00.txt

Best Regards,

Phil

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

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hunt-secevent-sstp-00.txt
Date: March 22, 2018 at 11:00:01 AM GMT
To: "Phil Hunt" <[email-masked]<mailto:[email-masked]>>, "Anthony Nadalin" <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat