* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Secevent Status Pages

Security Events (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2016-Oct-28 —  

IETF-100 secevent minutes

Session 2017-11-13 1330-1530: Bras Basah - Audio stream - secevent chatroom


minutes-100-secevent-00 minutes

          IETF 100 Singapore
          Bras Basah Monday Nov 13, 2017, 13:30 - 15:30
          Agenda Setting                          Dick Hardt (chair)        13:30
          - 13:40
          Security Event Token (SET)              Phil Hunt                 13:40
          - 14:00
          SET Delivery using HTTP                 Marius Scurtescu          14:00
          - 14:20
          Management API for SET Event Streams    Marius Scurtescu          14:20
          - 14:30
          Management API example                  Annabelle Backman         14:30
          - 14:40
          SET Stream Managment and Provisioning   Phil Hunt                 14:40
          - 15:00
          Management API Discussion               Dick Hardt (chair)        15:00
          - 15:20
          AOB                                     Dick Hardt (chair)        15:20
          - 15:30
          Agenda Setting
          No changes to agenda
          Security Event Token (SET)
          Phil Hunt reviewed slides
          Question whether summary of HEART involvement in slides is
          accurate. Justin Richer says "more or less".
          Hunt talks about SCIM and RISC doing similar and related work.
          Hardt asks if SCIM is active working group.
          Hunt: no, not active but this was unresolved from SCIM charter. It was
          input into SecEvents so work is happening here.
          Justin Richer: Original author of syntax. He actually prefers Backman's
          proposal because original intent was to make things simpler for Receiver
          and Backman proposal is simpler. The current proposal went off the rails
          with extensions and now thinks is misguided.
          Tony Nadalin: Think these need to be together. Have cases where both
          SCIM and RISC events need to be in the same payload. Makes it easier
          for engine to determine what is going on as a whole.
          Hardt: Should we force these to be put together?
          Nadalin: Don't know if we should force.
          Hardt: That means that Receivers have to understand when they come
          together and understand them coming separately.
          Nadalin: Yes, not ideal but think it is important to support bundled.
          Richer: If people are giving semantic weight to compound payloads,
          that is problematic. That was never the intended interpretation. Never
          anticipated this and that seems like a bad idea. There is some overhead
          in JOSE signatures.
          Leif: Is a way to do both. Event type could be defined that is a grouping
          of events. Make the grouping semantically explicit.
          SET Delivery using HTTP
          Marius Scurtescu reviewed slides
          Nadalin: What does making polling optional mean?
          Scurtescu: Do I have to do both
          Hunt: Optionality is wrong way to think about this. In firewall scenario,
          polling is only way. Better question is either mandatory to implement
          Annabelle Backman: What does it mean to do SET over HTTP. If both are
          optional, what is way to interop between sender and receiver. Having
          variability weakens spec.
          Hunt: Receiver doesn't have a choice.
          Hardt: This a framework, does SecEvents have to define? Can't that be
          the profile?
          Hunt: Don't think this is profile, this depends on the particularities
          of the Receiver.
          Backman: Having both optional creates basic ambiguity. This creates
          confusion about how to do interop.
          Nadalin: Is authorization header only valid in Push?
          Scurtescu: Proposal is only required for push.
          Hardt: Do we need both to be in spec or in profiles?
          Richer: If everything is going in profiles, what are we doing in
          SecEvents? When we first came together in this, it was pretty simple. Put
          stuff in an envelope and a bunch of other stuff. We've gone a long way
          from there. This leaves precious little for SET to define, just leaving
          us with JWT. Why do we need a spec to agree to use JWT?
          Management API for SET Event Streams
          Marius Scurtescu reviewed slides
          Hardt: Do you need a mechanism for HEART to say you need information
          for a subject?
          Richer: No, don't think so. There are discrete events they are trying
          to communicate and subject is implicit in some other flow.
          Hunt: For SCIM it might be possible to use in consumer environment.
          Backman: On OIDC scenarios, if IDP connection is broken, RP may want to
          unenroll on events for subject.
          Management API example
          Annabelle Backman reviewed slides
          Kathleen Moriarity: Are you thinking about privacy concerns and related
          Backman: WG has thought a lot about this. Haven't looked at RFC but
          happy to talk about it.
          Hardt: clarifies that this is from RISC, which is non IETF spec.
          Moriarity: Use of identifiers is tough, can be harmful.
          Backman: How do we strike right balance of being useful but not harmful.
          Moriarity: Look at drafts for protecting human rights. Identifiers
          relating to people is important at IESG last calls.
          Backman: Looking at hashed identifiers to protect identity
          Hunt: Usually sharing based on the fact that it was previously shared. Not
          exposing new information.
          Richer: Syntactic question: why mucking in root of JWT instead of being
          in event body? The sub in the root is from the issuer of the event.
          Backman: In RISC, need common understanding of the subject so it would
          be fine to have it in the envelope. There's nothing in SET spec to say
          that you can't add to envelope. That should be clarified if we want to
          push to payload object.
          Discussion about multiple event payloads and privacy implications of
          correlating events.
          SET Stream Managment and Provisioning
          Phil Hunt reviewed slides
          Discussion about the fact that profiles would need to determine how to
          do subject management with SCIM. Hardt wondering why SET prescribes SCIM
          profiling to profiling specs. Hunt: just saying work is done and get it
          for free.
          Backman: How much is MTI? We saw capabilities of SCIM, which do you have
          to do?
          Hunt: Object creation, put and get, not patch. SCIM endpoints for resource
          types and schemas have to be implemented. It's how discovery is done.
          Ali Karimi: Is your distribution different than blockchain? It seems
          like it should be problem of people that haven't read SCIM to read it
          because it solves problem. Not to try to do something else.
          Hunt: Not sure. It's news to him. Maybe a happy coincidence. This would
          have pre-dated blockchain.
          Backman: It's a problem of those that want to adopt. For folks we want
          to adopt, it needs to be easy for long tail to adopt.
          Hunt: It's hard to say what is easy.
          Management API Discussion
          Dick Hardt asks are we trying to do too many things. Reviewed slides
          Moriarity: part of ACE working group, lots of different requirements
          and use cases and working through prioritization. They are doing it in
          the wiki. What about running through priorities.
          Hunt: It's not a question of overlap. The square peg/round hole is more
          about enterprise/consumer than the different profiling specs.
          Hardt: Yes, agree that is probably true. We don't have strong consensus
          in SecEvents and that may reflect lack of consensus in RISC.
          Richer: Encourage working group to focus on commalities on different
          profiles rather than focusing on special attributes of a given
          profile. Thinks there are a lot of commanalities, like time of
          event. That's where we'll get multiple groups and profiles to
          use. Discussion has been about not specifying things not finding
          Backman: Description of not specifying is disagreement about what is
          round peg. If we can't even do that, then we can't even see round pegs.
          Nadalin: Because we can't tell, we just use a hammer.
          Moriarity: How can you frame a narrow discussion to get to agreement on
          round pegs? How about starting there?
          Hardt: Lots of contention on each parts of the spec. Are we trying to
          do too much?
          Moriarity: How can we have a guided focused discussion to see if we can
          find consensus.
          Hardt: we had ad hoc meeting to try to do that but feeling like it seemed
          like we are farther. Action to try to have a meeting to see what we find
          agreement on.
          Moriarity: Have to see outcome of that to see what is appropriate to do
          next. Happy to work to support figuring that out.
          Backman: Most contention is less on technical incompatibilities, it
          is more fundamental disagreement on requirements with one side . If we
          can't agree on a common token format, then we are pretty hopeless.
          Hunt: Issue is 03 draft is that it can be used in many ways and others
          want to restrict to a single event. But for those that want to support
          multiple events, it means a huge amount of complexity or just walk
          away. It only looks complex when you have to support multple events and
          for those that don't care, they don't have to use it.
          Hardt: But it may not be working for other profiles. As they've explored
          that, they've come up with issues and there isn't as much commonality
          between RISC and SCIM.
          Hunt: RISC hasn't come to consensus on this so don't mischaracterize.
          Nadalin: This work started in SCIM WG. Had lots of ideas. Other ideas
          have now come in. What MSFT has been doing works for enterprise and
          consumer. Shouldn't limit design to just what has been happening in RISC.
          Scurtescu: Proposals to simplify the SET is coming from people that are
          working on implementers of the spec, so information is p
          John Bradley: When there was a SCIM WG there was a conversation with OIDC
          WG around back channel logout. OIDC had conversation with Leif, shouldn't
          do something separate, explore using SCIM. But after further analysis,
          it was viewed as too complicated. We have attempted to work together,
          management API has become so complicated it is verging on undeployable.
          No time for other business
          Meeting adjourns

Generated from PyHt script /wg/secevent/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -