OAUTH WG - IETF 88 PARTICIPANTS ------------ * Anthony Nadlin (AN) * Brian Campbell (BN) * Derek Atkins (DA) * John Bradley (JB) * Justin Richer (JR) * Mike Jones (MJ) * Nat Sakamura (NS) * Phil Hunt (PH) * Prateek Mishra (PM) * Stephen Farrell (SF) * Tim Bray (TB) * Torsten Lodderstedt (TL) * Matt Miller (MM) Draft Statuses -------------- * draft-ietf-oauth-jwt-bearer :: Mike Jones is working to update from feedback * PH : At the end of Berlin, presented auth draft. Some changes to align with OpenID, but waiting on recharter discussion. Would like feedback. * NS : What is a good time to talk about recharter? * DA : Looks to AD -- let's finish some of the work we've got, then we can talk about adding more work. * SF : I don't think I saw discussion about recharter, and we have a number of knotty problems that need to be resolved first. * PM : I am confused about where we are with the SAML and assertions dtrafts? * DA : Waiting on Barry and Hannes to finish reviews -- can't do anything until they're done. * PM : Are there any substantive problems? * DA : None that I'm aware of * SF : Sometimes there's too much process in the IESG, so we're kind of waiting on the WG to finish. * NS : On recharter, should we postpone all the discussion on new documents until we get these other things done? I am puzzled by all the -00's while there's WG items to finish. * DA : These new drafts are toward the current charter items. * BN : My understanding -- came back from IESG after 86, and made significant changes. Now waiting on Hannes and other feedback. * DA : Hannes has been very busy with other activities, and can't get to these right now. We are waiting on Hannes right now. * JR : I suggest we fold stateless-client into dynamic registration. Proof of Possession (Anthony Nadlin) ------------------------------------ * PH : IIRC the MAC spec was folding in HotK, and we thought symmetric was sufficient. * JR : To follow up, we had decided that we wanted to do MAC (symmetric), but if we could do asymmetric as easily then we would. * JB : There was a feeling at the time that asymmetric with channel binding was too complicated, so we started off with the simplest (symmetric). I just sent a message to the list about why symmetric keys are bad. One advantage of asymmetric keys is that people do the right thing more often. * PM : Are you referencing a draft? * AN : Yes, there's a HotK draft (expired), that we think should be updated to talk about asymmetric keys. * PM : ANd you're proposing a new approach? * AN : No, I'm proposing we move it into the WG draft. * PH : On TLS channel binding, that was something exploring a new draft. It was interesting, but introduced a bunch of new questions. * AN : Channel binding was one approach, but there are others. I am proposing we update the HotK draft to talk about a couple of other ways. * JR : One feature from OAuth1 and other drafts, is to optionally sign parts of the HTTP message in addition to just the token. * AN : It gets into some issues, but if you have a specific use-case then we should talk about it. * JR : I brought them up on the list and in the call, but I can reiterate them again. And I think we can layer them into the JWT approach. * AN : But it's a different signature * JR : It's actually not -- it's just JWS. * MJ : I lost track -- does this require rechartering, and is recharting in flight? * DA : I don't think this draft requires rechartering, and we do not have a recharting in flight * TL : Did you want to remove symmetric? * NA : No, we just wanted to update the asymmetric part. ActAs/OnBefalfOf (Mike Jones) ----------------------------- * TL : Clarifying question: is the security token an assertion? * MJ : Yes, it's functionally equivalent. * TL : I suggest you use assertion. Also, is this meant to be a token, or an assertion? * MJ : It's an assertion. It might be used as an access token, but that is outside the scope of this. * TL : I suggest this go to another endpoint because it's not compliant to the current semantics * JR : I would like to see an alignment or clear delineation between this approach and where tokens have been used to get other tokens. I'm not going so far as to requiring a different endpoint, but I would like an alignment or delineation. * DA : What's the difference between of an assertion and a token? * JR : A token is completely opague to the client. * MJ : I take your point on comparing this to token-in/token-out approaches * PM : Is this a profile of the assertion draft? * MJ : No * PM : And this is not a profile is because this is returning an assertion? * MJ : There are several reasons -- you can use an assertion to get access tokens or authorization codes. We didn't want to jam a third thing into the assertions draft. * PM : I would like to see some standardization in this space * JB : I agree that I think this is a good pattern. I would have said that these tokens are encrypted for the intended audience, but are most likely opaque to the client. The intent is not to send structured tokens to the client, but to send structured tokens to the recipients through the client. It might be similar enough to overload, but we need to think carefully about it. * NS I think this support is for a very important use-cases. What's the relationship between OBO and OpenID-Connect ? * MJ : One is used as a client id for openid-connect, and one might be a security token for some other party. * NS : Where would this fall within our current charter? * DA : I don't think this falls within the current charter. * AN : I would also want to look at it as pure token exchanges. The current specs are rather ambiguous about what exactly is returned. I'm not opposed with the endpoint sending back specific token types. Also, this pattern matches what a lot of enterprises do today, so I think we need to extend this into OAuth. * TL : Why does this need to return structured tokens? I think the structured tokens limits us too much. * MJ : That might be, but the structure allows us to verify the identity. * JB : Note that an opaque token could be a reference, or it could be a structured token. * MJ : To be clear, I didn't talk about token references at all. * JB : Token references is also a legitimate design pattern. I have customers that can't use structured tokens. * MJ : OAuth already has artifacts -- authorization codes and access tokens * TL : WHo is the recipient? * MJ : THat is out of scope * TL : I suggest comparing this to the token exchange approach. I think this is very similar to the other approach. * MJ : I wrote this to get the discussion going, which it seems to do. But I want to know what the group wants to do next. * DA : I think we should take this to the list, and see if the WG wants to recharter to take on this work. * PH : I would like to see a fresh perspective on the use-case, since REST is point-to-point and more immediately needed, while WS-Trust is more end-to-end and not really needed. DynReg ------ * MJ : Some times you don't want to register at all. Purpose of registration is to get a client id. You could define ways to generate client ids without registering. Is that what you were getting at. * JR: The answer is yes. * JR : How I get the client id is independent. As a consequence we have two RFCs for that. We can get tokens in a number of different ways. * AN : Client doesn't know how to encode things. * JR : Assertions don't give you a client id. * PH : Are we addressing all the use cases? Transient use case; software statement which can be given out-of-band. Put in an identifier and that would be known to the end-point. Software state is a known profile. * JR : Client id is public information, bad idea for authentication purposes. Use only as a point of reference. Still useful for authorization server w/o having to reregister all the time. * MM : I'm going to needs this. We want to handle stateless client really well. Boot strap to oauth. If we can keep common ground that would be benefical for 3rd party clients. Need a standardized way of getting them. Not concerned of what's in them. * JR : Original use case for the client. Server wants to know what's in them. * MM : Important for clients on how to get them. * JR : Gives you reusable components. * JB : Can escalate privileges. We have a number of ways for doing client credentials. We identify through some credential or redirect. We can't blow a hole in our security model. We have a client with an opaque token for reference or assertion. What are we attempting to gaurantee registration identification. This is core to our security model. Have to allow for self assertion. * JR : I can make a client id, the server has to be very careful. The purpose of registration; there are two aspects; 1. the authz server needs an identifier 2. a client talks to multiple authz servers in different security domain. Dyn reg needs to solve both problems. * MJ : Tony said: We don't want to jam structed identifiers in the enterprise. Authz server chooses to issue structured identifier or authz server could advertize client identification structures. These are two separate choices for authz servers. We can define a simple registration structure and a separate structure for the non-registration case. * PH : Three registration modes; wanted to flesh out the various client types. * MM : The assertion that non-http client don't use URIs is false. Whatever structure we use, the bare minimums needs to be defined. * PH : For the client perspective, it needs to be consistent. * MM : We need to be consistent for the protocol used. * JR : Everything is optional -- hand waving. Send these fields ever time using this protocol. Connect does this already. * JB : Most protocols use URIs. Leave other options of identifying the client. * MM : There is an HTTP response with a location, it uses a URI. URI location doesn't have to be HTTP or HTTPs. * TB : Lots of use cases that should be considered, but are not being considered. * JR : Cred uid moved to optional. * MM : Dyn 14 works for me right now, could have clarifications on client implementations, etc. * TB : There are lots of use cases for which dynreg-14 works pretty well, and I’m a little sorry to see those being pushed on the shelf while the WG addresses more. * MJ : Support separation out core registration from the ability to update state. * AN : We've come up alternatives that solves are use cases. There are scalability issues with dyn 14. * PH : What are the use cases for a management API? It is not clear. Registration (Phil Hunt) ------------ * JR : I think a large part of the mismatch in the usefulness of a management API. If the client software is very fixed, then you don't need a management API. If it's more ephemeral, then management makes sense. * PH : Is it something really worth having a protocl for? * JR : If you have a manual admin process, then you don't need an API. But if you don't have an administrative step, then that's where it makes sense. * PH : If you allow your clients to be anything they want at any time, why would you let clients do this over protocol? * JR: You are conflating many different ascpects. Hackers aren't just going to do whatever they want, because presumably we have endpoints that require authentication/authorization. * JR : In the association draft, the token-in is the software statement, correct? * PH : Correct * JR : So changing the token-out is changing the software statement then? * PH : No, you can ask for the token type separate. * JR : So if your model calls for PKI, or etc, then you could do that without changing anything...? * JR : I see associations and dynreg as the same thing. What gets passed in is slightly different, but what gets passed out is what the client needs to know. With that, you could very easily send out a client_secret, or an assertion, or a certain token, without changing the registration at all. * PH : We did this move the ball forward thing. What we have today is a password that has to be stored. * JR : Passwords don't have to be stateful * PH : Why do you need it then? * JR : Because that's how OAuth works today * PH : It's not. Don't we want to move the ball forward? * JR : What you have could spit out a client secret or an assertion. Clients today assume HTTP with headers. * JR : One more point about client associations can't be reasonably implemented today, because the token endpoint takes in a set of form parameters (one of them being grant_type). Client association uses the same field name expressed in a JSON object, and that's fine because it's in the context of the JSON object. We used to have form parameter for dynreg, and decided to move to JSON. * JR : In order for my existing endpoints to implement this, I would need to examine the grant_type to determine if I am parsing form params or JSON. * BN (via JR) : He believed that JSON in was a confused portion of the client association. * JR : As an implementer, I know that I cannot do client associations * PH : Whether we have consensus or not, we could merge the specs. * JR : From my perspective, I don't think we can do client associations via the token endpoint; it would need to be a new endpoint. * PH : You said that a software statement is not possible. * JR : I have been supportive of software statement from the start. * PH : I don't see a point in closed loophole, except for Torsten's point about a token endpoint being just a token endpoint. We are defining a new profile, not a new endpoint. * JR : And my point, I don't think this is implementable as it is currently written. That said, parts about validating the registration should be merged in. * PH : Your point is well made. * JR : The Connect API says that the token endpoint could be the same as your registration endpoint, if you can handle it. What I want is the abiity to separate the functionality based on the endpoint. If you want to co-host it, then go ahead. but I think it's important not to require it. * PM : One point - just because draft allows for a client secret part of the spec, and human beings need passwords, but we need to be careful for using these for other functions because of the Lowest Common Denominator factor. * PM : Second point - what kind of token endpoint is appropriate, and that seems like a solvable issue. * PH : I say it doesn't matter, but there is merit to re-using the token endpoint. We do it all over the place. * PM : OK, if the current RFC doesn't accommodate that, then we need to address that. * PH : Everything is basically doing something-in to something-out. * JB : I think your presentation was lacking what you were proposing to merge, and some of us are confused. * PH : I was working with an open format discussion, and that was not clear from the slides. * JB : One thing that is similar is the software statement and my draft about a structured client_id. It was not specific to dynreg-14, it could be used with client assocications. You just need to get this to the authorization server, either with storing state or through the client id. Possibly how you create the JSON object and possibly sign it could be agreed on. * PH : One of the things I'm trying to get to is consistent use of the software statement. * JB : Having a client authenticate itself with an assertion is not really different from authenticating with a password. * PH : There is a differece. Dynamic registration its a registration step not an authentication step. You could try to track that the client returned again, and is that a worthwhile thing, I'm not sure. * JB : And it depends on what your notion of a transient client is. Just because it's Javascript running in a browser might not mean there isn't a central authority. * JB : Can we reach consensus on the following?: * JB : Perhaps we have some convergence on the stateless client parameters and software statements. Exactly what the parameters and the software statement there is some possible agreement. Exactly what endpoint is doing it might require extra shoehorning. The token endpoint isn't the one actually protected by OAuth. * PH : Does registration itself need to be protected. Which gets back to if we need a registration token. * PH : One of the reasons that I put software statement as a separate parameter is to try to not conflate all of this together. * JB : I think there are a couple of issues to sort out, and the sooner it happens the better. * AN : There is a lot of abuse about the endpoints today. The spec doesn't clear state that the endpoint only return one thing, and some things have implemented them together because they don't want them separate * TL : As an outside observer, I find this discussion very useful. I propose we really nail down the pros/cons about the approaches in order to move forward. * PH : It sounds like you say it's a more core issue. * DA : I encourage people continue to discuss this to keep making progress, but we haven't yet come to a conclusion. * Lucy Lynch : I just want to +1 all of this. We originally separated because we couldn't agree on it. I agree this is a realy important dialog, and I'm not sure anyone really understands what it means.