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

Wed Mar 1 17:08:59 UTC 2017

I think it is fine. 

The catch is that for this to work there has to be bi-directional data streams which in the case of RISC seems true. 

I don't see this as impacting the SEC EVENTs work other than as a use case. 

Phil

> On Feb 28, 2017, at 10:24 PM, Adam Dawes <adawes at google.com> wrote:
> 
> Thanks for bringing this up Dick. I think you're worried about, when alice at gmail.com signs up for an account at Amazon, how would Amazon register to get events from Google. I think we can deal with this if Amazon sends a SET token to google with an "account created" event which would then create a registration at google for Amazon to receive events about alice at .
> 
> I think it is totally reasonable to think of account creation as a notifiable event. And in typical RISC fashion, it is up to the recipient to do what it will with the events. From Google's perspective, we would white list a set of partners where we have contracts to enable implicit registration. I think we should work out some response codes to make it clear to the sender whether the registration succeeded.
> 
> We didn't talk a lot about this in the F2F but is an idea that I had in my deck and I think it came up in Phil and my conversation last week. Phil, does the above give you any concerns? 
> 
>> On Tue, Feb 28, 2017 at 9:12 AM, Phil Hunt (IDM) <phil.hunt at oracle.com> 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. 
>> 
>> Adam argued for all other update items to be done OOB.  
>> 
>> That just left error signalling for the receiver to find out why events were not coming. 
>> 
>> 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. 
>> 
>> Phil
>> 
>>> On Feb 28, 2017, at 8:32 AM, Hardt, Dick <dick at amazon.com> 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" <openid-specs-risc-bounces at lists.openid.net on behalf of adawes at google.com> 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 <phil.hunt at oracle.com> 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
>>> 
>>> phil.hunt at oracle.com
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> _______________________________________________
>>> Id-event mailing list
>>> Id-event at ietf.org
>>> https://www.ietf.org/mailman/listinfo/id-event
>>> 
>>> 
>>> 
>>> 
>>>  
>>> 
>>> --
>>> 
>>> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
>>> 
>>>  
>>> 
> 
> 
> 
> -- 
> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
> 
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170301/32e04e01/attachment.html>