Re: [Id-event] draft-scurtescu-secevent-event-stream-mgmt-api-00

[Phil Hunt <[e-mail]>]

This is to provide feedback on the proposal submitted by Marius [0].

I do not believe the draft [0] is close to ready for adoption. I am concerned that the design unnecessarily complicates and limits implementation for many tenancy and/or enterprise focused cloud vendors, as well as enterprise organizations that need to receive or send SETs. This applies to all of the areas proposed:  RISC, OAuth Revocation, OIDC Backchannel Logout, SCIM, etc.

The following is a list of items that are of concern:

* Metadata is far from complete - this is to be expected. One of the items that needs to be worked out is what does a publisher need to know in order to formulate SETs with the correct signing and encryption. E.g. should a stream configuration have jwksuris for transmitter (presumably for signing) and receiver (for encryption)?  For each item of meta data it has to be made clear what the format of the field is and what the allowances are for defaults, overrides, and updates by parties.

* Extension mechanism - for profiling specifications and extension mechanism is needed to define different forms of stream parameters and the contents of a stream.  For example, the notion of subscription is narrowly defined and does not apply to SCIM except in one of many potential methods of management. It doesn’t necessarily work for Backchannel Logout either.

* RESTfullness and Stream documents - AFAIK a REST API uses HTTP methods to define operations against documents.  In the proposed ID, a stream has no specific resource URI endpoint - it is a shared endpoint where the configuration is implied by reading a credential.  The stateful management of streams to me *screams* for a resource URL for the stream object against which a set of simple HTTP methods define update and query actions.  

* Multiple endpoints - This spec has many different endpoints to express different operations.  This is not only vastly different from typical RESTful patterns it also opens us up to the same security configuraiton problems that OAuth currently has.  IOW how does a receiver know that it has discovered all the correct endpoints?  Are they relative to some root?

* No Update method (only replace) - no ability to easily change specific configuration items like jwks_uris that might change to facilitate key rotation over time.  

* Stream status - there is an ability to discover a stream has failed but no metadata to describe the reason for failure
   Update - Can a receiver pause or enable recovery? For example, if a receiver is getting garbage (e.g. because of bad keys) can the receiver tell the transmitter to stop?

* Stream identifier - There is no individual stream identifier. The spec states…
> An Event Transmitter MAY use the same URLs as endpoints for multiple
>    streams, provided that the Event Transmitter has some mechanism
>    through which they can identify the applicable Event Stream for any
>    given request, e.g. from authentication credentials.  The definition
>    of such mechanisms is outside the scope of this specification.
This turns out to be overly restrictive. This was discussed at length in the development of the delivery API. It simply isn’t workable. It makes it hard to:
Allow DevOps systems to independently check operational status of streams because they must have a copy of the receivers credential
It forces receivers to have multiple credentials if they are receiving multiple streams from a sending organization.  For example an RP may receive events from multiple tenancies
The credentials of provisioning entities and administrators are likely not the same as the receiving entity.
The receiver of a SET of SETs for RISC or OIDC should not be restricted or bound to the Client_ID of the RP.  The RP *must* be able to outsource handling of events to another server entity (with different credential) or to an external third party such as a CASB vendor.
Multiple security entities will need to provision, manage, monitor, and interact with Stream resources

Subject enrolment - The method published really only addressed the RISC use cases. It does not address broader user cases such as membership as defined by a group or profile condition.  Even within RISC there is no agreement yet on how clients and IDPs track subjects (e.g. sub, email, telephone, etc).

These capabilities were addressed in the original distribution draft (section 2 and 4 of the distribution draft [1]) submitted last year to the WG. They were addressed because of the base protocol (RFC7644) supports - see the SCIM Use Case document for more discussion on provisioning protocol capabilities of RFC7644 [2]. It may be worthwhile reproducing those sections as a separate draft with clear examples on how all the use cases items are covered in the specs and are in fact already proven to work well as a provisioning protocol.  I can do that if there is interest. 

[0]  draft-scurtescu-secevent.event-stream-mgmt-ap
[1] https://tools.ietf.org/html/draft-hunt-secevent-distribution-01
[2] https://tools.ietf.org/html/draft-hunt-secevent-usecases-00

Going forward, I am working on a new control plane specification document which I believe covers all of the use cases for RISC, Logout, and SCIM. It can be used in minimalistic fashion (avoiding much of RFC7644/43) in a way that looks similar to Marius and Annabelle’s proposal. I hope to have this done soon and am waiting for a few comments before publishing.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
> On Aug 11, 2017, at 10:43 AM, Marius Scurtescu <[e-mail]> wrote:
> 
> A new version of the management api (aka control plane) draft was published:
> https://datatracker.ietf.org/doc/draft-scurtescu-secevent-event-stream-mgmt-api/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dscurtescu-2Dsecevent-2Devent-2Dstream-2Dmgmt-2Dapi_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=8GQYK59RCc9Z6vAq3NiokxFhK9W8kVnqk4vcMalYBnU&s=v1QewDOZz8s-Ou3qL_OEwysJfux5p5Ror1gtDtCB-oc&e=>
> 
> The document was renamed and it replaces:
> draft-scurtescu-secevent-simple-control-plane
> 
> This new version addresses most of the feedback received at IETF 99 in Prague:
> - stream configuration update operation added
> - stream status operation added
> - verification event defined in this draft
> - 429 HTTP status codes clean up
> - added security considerations section
> - moved endpoint descriptions to Event Stream Management section
> - fixed example URIs and phone numbers
> - typos and text changes
> 
> Please read and provide feedback. We would like to see this draft adopted as a workgroup draft as soon as possible.
> 
> Thanks,
> Marius
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=8GQYK59RCc9Z6vAq3NiokxFhK9W8kVnqk4vcMalYBnU&s=k-N-QlKTDPikiSIcAZfAhA7rrErQ0peqxXzp176jKoI&e=