Chairs: Dick Hardt, Yaron Sheffer Room: Zurich C, Wednesday, 9:00-11:30
Yoav Nir taking notes; Rich Salz monitoring Jabber
~50 people in the room.
Meeting began at 9:02.
Note Well was presented.
Agenda bashing - no bashes.
Blue sheets passed around.
Some discusson on the appropriate terminology, which will be handled later.
The previous clarification about SETs not being commands (but rather claims) will have to be clarified further. We can't enforce that the content is not a command. Justin said that the recipient might interpret it as a command, but this protocol does not treat it as a command. It's just a format.
Yaron: there is a difference between infrastructure that handles commands and infrastructure that handles claims. For example the need to respond to a command. Justin: Yes, you can use SET to build a command infrastructure, but we're not helping with that.
Yaron: we'll have a consensus call.
"Claims" vs "facts": does it matter? "claim" is the more common terminology. Justin prefers "signal". Phil prefers "assertions" because they're not always user claims. Mike says that claims are tied to subjects, and not all subjects are users. Jim Fenton says that "claim" is overloaded, "signals" or "statements" are better. Yaron: let's take it to the list.
Confusion of SETs with ID tokens: Justin: we don't mention "nonce" anymore. Yaron: saying the issuer is never malicious should not be part of the model. I am worried about complex issuers, with some part of the issuer being malicious. Justin: whoever has the private key can make statements. Marius: we make the assumption that we have perfect implementation. We need a reasonable way to differentiate. I don't think we solved the problem. Mike: a RP must validate the nonce or you're toast. Dick: +1 for Marius. Phil: JWT has no typing. You're free to ignore what you don't understand. Existing ID token systems will ignore our fields. We need a mechanism that does not conform with current use. Ben Kaduk: if you want to go outside current JWT, just use something that doesn't conform to JWT.
Can SETs be confused with access tokens? Mike suggests using a different "aud" (audience) value. Or use the presence of "events" claim (but that is not useful for old code that will ignore them). Or distinguish by the lack of access token claims.
Justin: if you are willing to accept JWT from the network you need to be careful about what you are accepting. You need to be able to tell them apart. You can't be accepting random ID tokens. SETs don't cause that. Should discuss this in the draft: make sure what you're taking in is the right thing.
Thorsten: There needs to be a concept of how to do this. Happens elsewhere. By the type field? When the same issuer issues both SETs and Access Tokens, then you have to solve the problem. Mike: in some of our systems we already have this problem. Mike: there is a type field, but its use is not mandatory. Phil: I like using a different issuer. It's stronger than audience. A lot of code ignores audience and nonce. Marius: Can't use a different issuer. Audience is the best short-term solution. Long-term not for this group. Dick: need to make sure any SET is going to break existing deployments and what they accept. Need a BCP for JWT going forward. Justin: if that is a requirement then we can't use JWT. Mike: should poll big vendors. Yaron: should work for smaller libraries as well. Brian Campbell: we're a medium vendor. Can embed something in the JOSE header, maybe use the crit claim. Yaron: do we know if critical claims are supported? Brian: No.
Use of the aud claim. Brian: we can allow applications to use some component of the audience in a way they need. Justin: what is the application here? Any top-level claim should be defined by SET. The top level "issuer" should be the issuer of the SET. We can define a syntax and it won't hurt downstream application, but I don't see the utility.
(Skipped a couple of slides) Use of the iss (issuer) claim. Can it be omitted. Phil: some SETs need it, so let's require it everywhere. Justin: thinking in terms of code paths. Information redundancy is not a big deal and we don't want different libraries looking at different layers to find the data. Mike: depends on use-case. Phil: that's a minority of use cases. If set issuer and token issuer have different things, just wanted to point that out.
Mike: is going to WGLC in June realistic? Can't know yet. Dick: lots of opinions on what to do with the security concerns. Has to be addressed before WGLC. Jin Fenton: several large structural things need to be fixed first. The document needs a real Security Considerations section. Privacy Considerations has to be split (audit doesn't belong).
Yaron: we might end up with a separate privacy considerations document.
Phil: Yeah, these sections are not fleshed out yet.
Leif: security is usually not part of a simplification
Brian Campbell: algorithm agility is needed, but we made it easier for some of these attacks. It doesn't have to be through a value in the message.
Kathleen: JOSE and JWT are used a lot. Need to be proactive on this. Might need a statement on this. Proposes to use oauth.net.
Yaron: asumption about channel reliability for provisioning events?
Phil: assured delivery.
Justin: HEART - health relationship Trust.
Phil: RISC and SCIM talk about same events. Distribution draft has to handle.
Yaron: worried about this becoming a general-purpose synchronization protocol.
Dick: worried it becomes too broad and general-purpose. Need a balance between what's in scope and what isn't.
Yaron: more opinions about synchronization vs. events?
Phil (with SCIM participant hat on) SET itself would not define the replication but could be the trigger.
Tony: Don't do that now, but we might look into changing.
Leif: There is missing language about what is a subject. The IDP itself? Have use cases that cover them.
Morteza (via Jabber): +1 for Tony and Phil.
Joe S: There will be some different requirements if this is a synchronization protocol.
Dick: Do we need a reliable transport or not?
Phil; It's a bit orthogonal. Individual receivers might have different requirements. Google is fine with missing events, Oracle is not.
Marius: another distinction between sync and SETs is the amount of data.
Tony: we wound up polling. We're not looking for detailed events. We're looking for the trigger, for the diffrences.
Justin: Agree with Tony. Treat these things (and call them out) as event signals, things that happened rather than "here's all the information about everything that's happened".
Yaron: can't do transactional updates without.
Justin: No. "This is a thing that changed." you can build a protocol that uses this as a component to get all the data.
Tony: yeah, we have this in SCIM
Yaron: polling is not an event. It's a command. [Edit: Tony and others explained that the protocol will send the signal, later polling is out of scope.]
Phil: Tony, Morteza and I will resolve this. Probably without exapnding the charter. Looking for signals and get the rest from SCIM. Passing a command saves a step but it's the signal we're looking for.
Leif: not a command. Use the signal as you see fit. Don't have to act on it.
Dick: Chairs are confused. Anybody want command-like?
(crickets)
Yaron: sounds like consensus [i.e. protocol will transmit events, not commands].
Justin: "receiver" and "transmitter" make sense here because this draft is about transmitting and receiving.
Leif: Trying to keep two systems more or less in sync and raise a flag when either of them goes away. Like BGP. Keep things related to state away from transport.
Justin: do we want to have a single security mechanism that is tied in or make it loose like in HTTP.
Yaron: you need something for interop.
Leif: don't mix semantics from data plane into control plane. We struggled with this in SCIM.
Leif: There are so many ways to deploy security.
Phil: if we narrow the scope and (for example) pick OAuth and profile it that way, we went through this cycle with SCIM. It's tricky but it gets things done.
Dick: so "out of scope"?
Phil: No opinion. I can put it in?
Dick: any one thinks it should be in scope?
Yaron (from room mic to signify individual-ness): if we keep authentication out we can't test interop for SET. We should have something.
Marius: We can mandate that profiles mandate.
Joe S: Agree with Yaron. Ideally you'll have a library that support this transport. Without mechanisms it's all left to the profiles. Why not have a common infrastructure for that that is useful?
Tony: Don't see why that would be in the base. Too many ways to do this. It would screw everything up.
Leif: In practice you'll have a SET library that relies on an HTTP stack. And it will have everything that an HTTP library has available. That is why we layer on top of HTTP. Specifying OAuth takes that away.
Kathleen: mandatory to use?
Leif: Is there a mandatory to use for HTTP?
Kathleen: OAuth bearer tokens have three.
Leif: as long as you support something that HTTP supports. I want whatever is the mandatory security mechanism for HTTP as a mandatory to implement.
Ben K: why is Yaron worried about interop? There needs to be integration between the HTTP and the control plane.
Yaron: takes back previous statement. No need to have an MTI security mechanism for interop.
Phil: There are two layers: HTTP is just another HTTP service, should work like any other HTTP. At the message layer there are the mssages, the JWTs themselves.
Phil: In the last re-working of the draft, the GET command looks like a SCIM thing. If you only implement the MTI (GET) you don't need a full SCIM library. If you want more management stuff, SCIM has lots of ways to help.
Dick (from the floor): not clear how you would use SCIM to manage streams.
Phil: Create, modify, patch.
The meeting ended 11:33.