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

Adam Dawes adawes at google.com
Wed Mar 1 06:24:52 UTC 2017


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
> <(650)%20214-2410>
>
>
>
>


-- 
Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170228/3ba36836/attachment-0001.html>


More information about the Openid-specs-risc mailing list