Re: [scim] [EXTERNAL] Re: New Version Notification for draft-hunt-scim-events-00.txt

[Phillip Hunt <[e-mail]>]

Danny,

Thanks for your support. 

With regards to breaking out async events, I would take a look at the SET Http Polling spec to fully understand the concerns. 

Also we should consider how many senders and receivers their are in async cases. Eg. Is it more important that single “receiver” route completion notices originated at many possible scim replicas, or is this a per client notice scenario? eg to facilitate browser UI workflow. 

Phil

> On May 4, 2022, at 7:44 PM, Danny Zollner <[e-mail]> wrote:
> 
> 
> Hi Phil,
>  
> I sat down and gave this a thorough read tonight – overall I really like the draft and would support it being adopted. I’m a bit weak on the SET/Shared Signals side of things and limped along a bit, but I think everything made sense and I can see value in what it offers. Similar to Matt, I’ll reach out to you on the side with a few typos/nitpicks I came across.
>  
> The only specific change I’d like to suggest/request would be around async request handling. Janelle and I have been discussing this recently and we’d like to see async request handling become a part of SCIM. We’d like to draft something around async request handling without SET – likely including a body in the 202 response with some form of transaction ID, and defining a new SCIM endpoint (and accompanying ServiceProviderConfig, etc..) that a client could reach back out to at a later time (optionally suggested either in the response body) with the transaction ID to check on the status. Given what we’d like to accomplish, I’d be interested in finding a way to spin off a separate draft focused on async request processing and incorporate both the SCIM-only and SCIM + SET options. To avoid any redundancy or conflicts, some portion of what you’ve detailed in this draft might be better off moving over to the other draft.
>  
> -Danny
>  
> From: scim <[e-mail]> On Behalf Of Phillip Hunt
> Sent: Tuesday, March 1, 2022 6:49 PM
> To: Matt Peterson (mpeterso) <[e-mail]>
> Cc: SCIM WG <[e-mail]>
> Subject: [EXTERNAL] Re: [scim] New Version Notification for draft-hunt-scim-events-00.txt
>  
> Matt
>  
> Thanks for your feedback.  Regarding your feedback I would refer you to the SSEF framework that Nancy mentioned. 
>  
> https://sharedsignals.guide/
>  
> The OpenId SSEF community is dealing with feed management.  
> 
> Phil
> 
> 
> On Mar 1, 2022, at 3:20 PM, Matt Peterson (mpeterso) <[e-mail]> wrote:
> 
> 
> Hi Phil,
>  
> I finally found time today to review draft-hunt-scim-events-00. 
>  
> I am happy that this draft addresses two very common use cases that the draft labels: “coordinated provisioning” and “domain-based replication”.  I have been strong proponent of these use cases in meetings and on this list, so I wanted to emphasize for others.  If you are interested in keeping your SCIM Client up to date with changes happening on the SCIM Service Provider, YOU SHOULD READ THIS DRAFT. 😊
>  
> I have created a short list of nit-picks (typos, rewords, etc) that I will send to you privately.   In addition, I have a few initial comments for the list since there may be others that have similar thoughts when they read the draft: 
>  
> For point-to-point delivery over HTTP Push-based SET (RFC 8935), the draft does not describe the SCIM mechanism by which the Event Provider (SCIM Service Provider) determines the HTTP endpoint to use when transmitting to the Event Receiver.   
> For point-to-point delivery over HTTP Poll-based SET (RFC8936), the draft does not describe the SCIM mechanism for “pre-arranging polling endpoint to check for SETs that are available.
> The draft does not describe ServiceProviderConfig schema that would allow a SCIM Service Provider’s support for SCIM Events to be discovered
>  
> Thoughts?
>  
> --
> Matt Peterson
>  
> From: scim <[e-mail]> On Behalf Of Phillip Hunt
> Sent: Sunday, February 13, 2022 2:49 PM
> To: SCIM WG <[e-mail]>
> Subject: Re: [scim] New Version Notification for draft-hunt-scim-events-00.txt
>  
> CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
>  
> Hi SCIMers!
>  
> As promised, I have submitted the draft proposal for Co-ordinated Events between SCIM Providers (called SCIM Profile for Security Event Tokens).
>  
> The draft is a bit long, but that is primarily because I have included a number of diagrams and examples as well as use case (delivery mode) discussion. The actual implementation specification is relatively short.
>  
> The draft leverages the Securtiy Event Token spec set and defines events for SCIM that can be used for:
> * Feed control (what resources are part of an event feed)
> * HTTP Async Request completion messages
> * Security signals
> * Co-ordinated cross-domain provisioning and domain based replication.
>  
> Apologies, the draft has a few “TODOs". Though I have included several privacy and security considerations in the content, I still need to complete the separate sections. As an editor introducing a brand new specification, I prefer to do write these sections when there is a rudimentary consensus and the basic approach has crystalized. I plan to complete this before adoption as a possible working group draft.
>  
> There is also a section on event processing logic.I feel this too needs some prior requirements discussion as we may need to refine scenarios. It could also be argued that processing logic is up to the implementer and not necessary for inter-op. 
>  
> One item that is out of scope for this draft is “bootstrap” and “recovery” for SCIM Service Providers. I’m not sure this content belongs in this draft. Obviously if one is setting up a new replica node, you have to have a method for initial transfer. I would be happy to contribute to, or help write such a draft. It might not need to be normative but more of a best practice draft.
>  
> Finally, it is my hope that this draft eliminates much (or all) of the stated requests I have heard for cursor-based paging.  The idea of event processing is to prevent the repeated need for full system transfers (via paged gets) by dealing with events as they occur once two or more systems are running based on a bulk load.  The approach of using “call-backs” also helps to enforce data access and disclosure restrictions that might not otherwise be possible in cursor-based approaches.
>  
> Chairs…obviously I would like to discuss this at the next IETF meeting in March.
>  
> Phillip Hunt
> @independentid
> [e-mail]
>  
>  
> 
> 
> 
> 
> Begin forwarded message:
>  
> From: [e-mail]
> Subject: New Version Notification for draft-hunt-scim-events-00.txt
> Date: February 13, 2022 at 1:29:45 PM PST
> To: "Phil Hunt" <[e-mail]>, "Phillip Hunt" <[e-mail]>
>  
> 
> A new version of I-D, draft-hunt-scim-events-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Name: draft-hunt-scim-events
> Revision: 00
> Title: SCIM Profile for Security Event Tokens
> Document date: 2022-02-13
> Group: Individual Submission
> Pages: 27
> URL:            https://www.ietf.org/archive/id/draft-hunt-scim-events-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-scim-events/
> Html:           https://www.ietf.org/archive/id/draft-hunt-scim-events-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hunt-scim-events
> 
> 
> Abstract:
>   This specification profiles the Security Event Token specification,
>   to define a set of events for SCIM Protocol servers that can be used
>   for asynchronous transaction confirmations, replication, cross-domain
>   provisioning co-ordination, and security signals.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
>