Minutes IETF100: secevent

Meeting Minutes Security Events (secevent) WG
Title Minutes IETF100: secevent
State Active
Other versions plain text
Last updated 2017-11-18

Meeting 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

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 RFCs?
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 consensus. 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

No time for other business

Meeting adjourns