Subject: [Id-event] Follow-up discussion on stream management API draft

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 18 Jul 2017 15:02:54 +0000

Hi all,

We have reserved a room Wednesday morning to continue discussing the Event Stream Management API draft, please join us!

When: Wednesday, 10:00 AM to 12:00 PM
Where: IETF, Istanbul room
Who: Marius, myself, and hopefully a few more of you :)

For those of you who haven’t seen it yet: https://datatracker.ietf.org/doc/draft-scurtescu-secevent-simple-control-plane/

The general consensus in this morning’s meeting was that people believed this work belonged in the secevents WG, but that the current draft is not ready for adoption. However, there was not a lot of direct feedback on what was missing from or needed improvement in the draft. If you have comments or questions that weren’t covered in today’s discussion (minutes are here<https://datatracker.ietf.org/doc/minutes-99-secevent/>), please join us tomorrow morning or raise them on the list – or just stop me in the hallway. I’ll be working in the Hilton atrium most of Wednesday afternoon, feel free to interrupt me. :)

--
Annabelle Richard Backman

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 18 Jul 2017 08:39:56 -0700

Sorry I can't make it. 

The biggest difference between profiles that I observe is:
* how receiver/transmitter credentials and authorization relationships are set up. 
* how each defines the subjects that are part of feed. Scim uses multiple approaches(groups, roles, filters), risc uses subject enrollment and logout bases it on the idp to rp relationship. 

The risc case is interesting. In addition to composite subjects (sub and iss) there are other forms. Eg email and telephone. Thus suggests enrollment has to express a subject type so the reader can know if it is a saml, connect, email or telephone number. I believe this can be modeled a number of ways. 

I remain concerned that any new stream provisioning/control protocol will be largely duplicative to the scim community. Yet I do understand that some feel that implementing scim is too much. I think you have to look at the enrollment and subject features risc needs to make that call. 

Phil

> On Jul 18, 2017, at 8:02 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Hi all,
>  
> The general consensus in this morning’s meeting was that people believed this work belonged in the secevents WG, but that the current draft is not ready for adoption. However, there was not a lot of direct feedback on what was missing from or needed improvement in the draft. If you have comments or questions that weren’t covered in today’s discussion (minutes are here), please join us tomorrow morning or raise them on the list – or just stop me in the hallway. I’ll be working in the Hilton atrium most of Wednesday afternoon, feel free to interrupt me. :)
>  
> --
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I3pSqZ6QF-0Yovvitc4QgWcAAVa9Sxr0SndEaTeL4XU&s=Hn_cYFVJS3q74dRVS9OPSBfRoR8XXXlZ2wHGTYyo2mg&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 20 Jul 2017 09:09:15 +0200

We are meeting again today, Thursday, from 2 to 4 pm in the same room.

Marius

On Tue, Jul 18, 2017 at 5:39 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> * how each defines the subjects that are part of feed. Scim uses multiple
> approaches(groups, roles, filters), risc uses subject enrollment and logout
> bases it on the idp to rp relationship.
>
> The risc case is interesting. In addition to composite subjects (sub and
> iss) there are other forms. Eg email and telephone. Thus suggests
> enrollment has to express a subject type so the reader can know if it is a
> saml, connect, email or telephone number. I believe this can be modeled a
> number of ways.
>
> I remain concerned that any new stream provisioning/control protocol will
> be largely duplicative to the scim community. Yet I do understand that some
> feel that implementing scim is too much. I think you have to look at the
> enrollment and subject features risc needs to make that call.
>
> Phil
>
> We have reserved a room Wednesday morning to continue discussing the Event
> Stream Management API draft, please join us!
>
>
>
> For those of you who haven’t seen it yet: https://datatracker.ietf.org/
> doc/draft-scurtescu-secevent-simple-control-plane/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dscurtescu-2Dsecevent-2Dsimple-2Dcontrol-2Dplane_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I3pSqZ6QF-0Yovvitc4QgWcAAVa9Sxr0SndEaTeL4XU&s=OOzfODIa5TYws2jcw_TtswoK8hNGFCead9-K6TxrUfs&e=>
>
>
>
> The general consensus in this morning’s meeting was that people believed
> this work belonged in the secevents WG, but that the current draft is not
> ready for adoption. However, there was not a lot of direct feedback on what
> was missing from or needed improvement in the draft. If you have comments
> or questions that weren’t covered in today’s discussion (minutes are here
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D99-2Dsecevent_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I3pSqZ6QF-0Yovvitc4QgWcAAVa9Sxr0SndEaTeL4XU&s=klhYkKmRra4WIo1Ch0LFguIhn86JQ3sJ7Q4zUN5Fz5o&e=>),
> please join us tomorrow morning or raise them on the list – or just stop me
> in the hallway. I’ll be working in the Hilton atrium most of Wednesday
> afternoon, feel free to interrupt me. :)
>
>
>
> --
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I3pSqZ6QF-
> 0Yovvitc4QgWcAAVa9Sxr0SndEaTeL4XU&s=Hn_cYFVJS3q74dRVS9OPSBfRoR8XXXlZ2
> wHGTYyo2mg&e=
>
>
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 20 Jul 2017 09:17:47 +0000

Below are the meeting notes from Tuesday’s discussion.

=====

Attendees:
Annabelle Backman
Marius Scurtescu
Tony Nadalin
Yaron Sheffer

General Comments:
- Tony: Primary concern is that SCIM will still work
- Yaron: Event Stream should be defined in delivery
  - Annabelle: Agreed that it shouldn't be in Management API. Current delivery spec is specific to HTTP, and Event Stream needs to be general. May need a base delivery methods spec.
- Yaron: Move endpoints out of definitions, not needed there.
- Yaron: Replace RISC event types in examples with fake example event types.

Stream Registration:
- Debate over whether a registration API is needed, and if it should be included in this spec
  - Marius: Registration needs to be included, needed for "-as-a-Service" use cases.
  - Annabelle: Shouldn't be MTI, lots of use cases don't need a registration API
  - Marius: This is true for Add Subject/Remove Subject as well
  - Yaron: APIs can be MTI, but implementers can disable/always return error code (e.g. 401 or 403)
- Yaron: Either add the registration POST API or remove the Event Stream Management Endpoint GET API until registration is added.
- Yaron: Replace event types with profile IDs
  - Marius: Neede event types to know which event types are mutually supported by receiver and transmitter
- Annabelle: Need to define a stream status attribute
  - Marius, Yaron: Agreed, 3 values: Active, Paused, Disabled
  - Yaron: Status is useful without other configuration data; add a separate status endpoint.
- Yaron: Need text in Security Considerations about risk of attacker tricking receiver into making Add/Remove Subject requests.
- Annabelle: Draft is inconsistent about notifying receiver that a subject may not be added.
  - Yaron: Remove "MUST NOT notify" language, add recommendations to Security Considerations.

Stream Verification:
- Consensus that verification should not be split across delivery and management specs. Should move verification event definition to management API.
- Yaron: Need maximum frequency for verification requests
  - Annabelle: status endpoint could return a max verification request frequency; the right value may vary for different use cases, profiles
- Marius: does verification event need both nonce and state?
  - Consensus that just state is required
- Marius: transmitter may send verification events without receiver requesting it
- Yaron: use an IETF params URN for verification event type

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tuesday, July 18, 2017 at 5:01 PM
To: SecEvent <[email-masked]>
Subject: Follow-up discussion on stream management API draft

Hi all,