[Openid-specs-risc] subscription/enrolment - why do we need a receiver API for it?
Michael.Jones at microsoft.com
Thu Mar 2 05:12:16 UTC 2017
I concur that at the RISC F2F there was agreement that the data plane and the control plane would be separate interfaces. There was also agreement that connections were uni-directional and that if the two parties wanted bi-directional data exchange, they would establish two distinct uni-directional connections in opposite directions.
From: Openid-specs-risc [mailto:openid-specs-risc-bounces at lists.openid.net] On Behalf Of Hardt, Dick
Sent: Wednesday, March 1, 2017 8:58 PM
To: Marius Scurtescu <mscurtescu at google.com>
Cc: openid-specs-risc at lists.openid.net
Subject: Re: [Openid-specs-risc] subscription/enrolment - why do we need a receiver API for it?
On 3/1/17, 7:48 PM, someone claiming to be "Marius Scurtescu" <mscurtescu at google.com<mailto:mscurtescu at google.com>> wrote:
On Wed, Mar 1, 2017 at 7:31 PM, Hardt, Dick <dick at amazon.com<mailto:dick at amazon.com>> wrote:
If it is a control plane mechanism that is changing state, then it is a command, and may have an error. Sure, we can ignore any error, but that is a subobtimal control plane mechanism.
Why all the pushback on a separate control plane Phil? Is it because you don’t want to write the spec?
I started this whole discussion after catching up with emails after a long while. Not sure there was any pushback, but sending user enrollment requests as regular SETs came up, I think Adam mentioned that, and I assumed there was some talk about merging the two channels and requiring full duplex.
At the RISC F2F we were talking about a separate control plane API and a data plane event stream. There was no discussion of mixing the two.
At the F2F Phil expressed concern over having to write a spec for a new REST API. I’m probing to see if that is what the issue is.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-risc