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 ====== NOTES ====== Agenda Setting ============ No changes to agenda Security Event Token (SET) ====================== Phil Hunt reviewed slides https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-events/ 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 https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-delivery/ 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 https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-management-rest/ 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 https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-management-rest-eg/ 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 https://datatracker.ietf.org/meeting/100/materials/slides-100-secevent-set-management-scim/ 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 undeployable. AOB === No time for other business Meeting adjourns