[Openid-specs-risc] subscription/enrolment - why do we need a receiver API for it?
dick at amazon.com
Thu Mar 2 04:57:46 UTC 2017
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