[Openid-specs-risc] subscription/enrolment - why do we need a receiver API for it?

Hardt, Dick 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.

/Dick


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170302/0f4af4e1/attachment.html>


More information about the Openid-specs-risc mailing list