OAuth WG Meeting Agenda ----------------------- Note taker: Amanda Anganes, Jean Mahoney Note well, blue sheets, agenda bashing, etc 1. Status Update, Agenda Bashing (Chairs) Status update: published 3 docs as RFCs since last IETF meeting Several docs in WG queue, Threat Model in RFC editor queue 2. Token Revocation (Torsten Lodderstedt) Torsten Lodderstedt presented update Status: working on new -02 rev, should be published sometime this week or next Amanda Anganes, Justin Richer, Tony Nadalin will review once -02 is released; provide feedback whether it is ready for WGLC 3. Assertions (Mike Jones) http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ Mike Jones presented update in WGLC (assertions, jwt-bearer profile, saml profile) Hannes - I need to create the shepherd statement for it. I received feedback on 2 implementations - JSON and SAML. Hannes - we have these 3 documents. Who has read the assertions doc? (around 12 people raised hands). Who is working on a SAML implementation? (4 people) JSON implementation? (2 people) Mike - there are a dozen JSON implementations. John Bradley - one JSON implementation is the test harness at the OSIS interop site. AI: Hannes needs to put together Shepherd writeup; needs feedback on drafts and implementation status Nat Sakumura, Torsten will review, other reviews would be appreciated 4. OAuth Use Cases (Zachary Zeltsan) http://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases/ Zachary Zeltsan presented update Hannes - Who has read this? (3 people, 2 of them authors) Can someone help with the doc? Several use cases refer to functionality that has not been standardized yet Tony will work with Zachary to improve the doc 5. JWT (Mike Jones) http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ Mike Jones presented update Hannes - Who has read this doc? It's important. (10 people) We will start WGLC when JOSE does WGLC. ACTION: Jeff Hodges, Klaas, and Leif to review the draft. 6. Security (Phil Hunt and Hannes Tschofenig) http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ Phil Hunt and Hannes presented update WG has a Security item, draft-tschofenig-oauth-security-00 draft is a response Slide: Suggested Design Approach. Phil - if we build a jot based solution, can reuse. Avoid options as much as possible. Hannes - the mandatory state attribute tightens up options in the base spec. Justin - aren't those issues orthogonal? How are they related? Hannes - it's not just a token format, it's more than that. Justin - Is this a high-security profile? Hannes - this provides better security. Torsten - I'm struggling with the state attribute being mandatory. Through the threat analysis, the [??] is a MUST. If it uses state attribute or another. Hannes - any type of cross side scripting would be problematic. There's no increase in security between MAC token and bearer token. People get this wrong in deployment. Torsten - our core spec has a security section. Most implementers don't read the threat model, but that's ok. It's an IETF doc that was input to our other docs. What's the purpose of this activity? Phil - if I'm an application and pass a token to the trading application, it can use the token. I as an app didn't mean for that. The resource site doesn't know. There's no binding back to the client. Torsten - this slide is talking about more than that. Hannes - to rephrase - is there a way to write this down, so that it doesn't work if you do it incorrectly? In the [??] specification - if you omit certain fields, it just doesn't work. Tony - Open ID has taken one approach to harden. They have a use case driving it. I don't see a use case here. I'd like to see it. For the suggested design approach. I don't know what you are trying to solve. Phil - We need to know the list of issues. Need to find key use case that OAuth hasn't solved. ACTION: Provide use cases. Leif - scalability use case - trust lists full of keys. Why do I have to provision 9 secrets? They have asymmetric keys already. Phil - there's a difference between public and private clients. There are symmetric and asymmetric cases. Leif - asymmetric. I would like a mechanism that would allow me to use existing keys. used between auth and resource server. Phil - you can have a key bound to the ?? and bound to the session. One is permanent. [??] Hannes - Leif, send your use case to the list. ACTION: Leif to send the scalability use case to the list. Igor - nobody was interested in use cases for the last presentation. Hannes - the docs have different audiences. Mike - We can tighten up our use of OAuth to mitigate threats. I agree with Tony and Igor. There's in interest in holder of key [??]. They exist in SAML. But not JSON REST world. We could get traction there. Hannes - we gave the holder of key presentation previously. It led to the publication of the doc Phil was talking about. Mike - the connect spec is good in this regard. I don't know if connect is a superset of requirements. How do we get a handle on the problem? The list of threats and requirements is long. We could strike off lots of requirements. It could reinforce - and it's the spec for OAuth. Or it may need to be supplemented. Justin Richer - We as a wg need to approach with the realization that we won't find a single solution to fit everything. Be careful of the one solution that kinda does everything. Taking jot and mac as starting points - they are different approaches. Make them as strong and useful as we can. Don't throw out everything for the ultimate super token. Hannes - How to proceed on the topic? Could organize design calls to accelerate the work. Put together a design team. When do we want to make a decision - February? Barry - make it clear that you are appointing a design team as input to wg. Or wg calls where everyone is welcome. Hannes - I like open mtgs. I noticed that the process doesn't support the former. Barry - you need at least 2 weeks notice for calls. Stephen - you can schedule starting now. Do some doodle polls. A deadline will help here. What do want done by February? Hannes - straw man proposals for docs - solution docs to present to wg. Justin - wg would decide which straw man doc would fulfill charter items? Hannes - yes Stephen - Danger of beauty contest and/or pissing competition. Phil - read the doc and add a paragraph or two for your use case. Then review the use case. Stephen - it's easy to contribute use cases when someone else does the work. Phil - I don't mind doing the work if someone provides a paragraph. Stephen - good if the folks at the mic have agreement. Hannes - interested in weekly calls and additional deadline - End of year, agree on requirements use cases. Feb - something to present to wg. Justin - lower frequently - biweekly. Yes Torsten - I can review. My not have time to part on calls. Mike - What's the intended outcome again? Hannes - input - the current doc. beef up use cases and requirements. When we agree, we will ask the wg to consider it. Mike - is this pursuing holder of key? Hannes - yes. Justin - my understanding - where holder of key fits, where mac fits, where magic token fits. I encourage use of list for collecting use cases. Stephen - [??] Hannes - if different ideas come up, the group needs to decides which ones. The solution space is large. I don't have impression that it would be easy to agree. I worry that we have 10 docs. Then blow up charter. Phil - I'm concerned about creating 10-20 specs that we go forward with. stephen - virtual interim meetings with minutes? Hannes - yes stephen - if you treat the feb output as design team output, the wg could toss it out. Leif - There's a requirement gathering phase - make that inclusive. Make the design phase a more focused effort that comes up with a proposal for the wg. Hannes - sounds good. Summarize: Virtual interim meetings for requirements and use cases. Finish by end of the year - 2-3 calls. Afterward, form a design team to produce 1 or more solution docs for Feb. Group to be approved by wg. Hum if you think that's a good idea: hums Hum if you object: No objections. ACTION: Hold virtual interim meetings for requirement and use case gathering. Work to be finished by the end of the year. ACTION: Form a design team, a group to be approved by the working group, to produce one or more solution documents for February. 7. Dynamic Client Registration (Justin Richer) http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ Would like community to look at it - what belongs and what doesn't in this draft. Higher level [??] can use and extend this. ACTION: wg to review what does and doesn't belong in this draft. How would a client do this registration? Client shows up at client registration endpoint - this is a new endpoint - not reusing anything - It pushes form parameters that describes the client. Gets back a JSON doc with client id and possibly client secret and a registration access token (oath bearer token). This first step may be protected by bearer token itself. Developer key can get client id instead of baking the client id into the client itself. Would like to have open registration to allow for wider interoperability. Would like to standardize on gating mechanism. Leif - Entirely open and slightly open and then no dynamic registration. There are many large scale deployments that want to do dynamic registration. Strange that we are mandating bearer tokens and asymmetric keys which would allow [??]. You don't want to do this with refresh tokens. If you do trust management with MAC. Justin - You can do trust management with bearer token, but not direct interop. This is an optional mechanism. John Bradley - the oconnect reg draft says it's an OAuth protected endpoint. The only reasonable is bearer token. We're the only people using the assertion draft in the wild. Having other auth mechanisms is not a problem. It's a common pattern. Justin - we decided to call it a bearer token. Would like to relax the restriction on that. Would like feedback from the wg. Next step - client wants to update metadata (not security related). Do we have an endpoint with multiple operations, or make it more RESTish? There's an operation parameter with client update. Send registration access token with that request. The public client can have protect access to update metadata. We are issuing tokens from 3 end points. That feels funny to me. We could issue a code from the reg endpoint with bells and whistles of a token. A lot of things we could do. We don't want token to live forever. Want to be able to refresh token. Open issues - no unregister step - What happens with registration access token expires? - How do we describe such that Openconnect and UMA can extend it? Section 3 - client metadata - profiles and extensions would do work here. Leif - form handling - I argue for JSON again. It's a well-defined form for meta data. We have deployment experience here. Justin - agree with sentiment, and it would be more REST like. client gen up a JSON object. However - it's an odd token endpoint, since the other endpoints take forms. Consistency isn't losing much. metadata does fine with a flat input. Mat - consistency is important. JWS will be useful. Justin - profiling any endpoint. Leif - how to do JWS mechanism in the best way? It would be good to have a JSON [??] Here's the abstract thing to end point. Not too late. Justin - what gets spit out to the end points? [??] Reluctant to do JSON only. Hannes - anyone read the doc submitted 2 days ago? (1 person) I would like reviewers. I'll ask the UMA guys. Reviewers: Nat John Torsten ACTION: Hannes to ask UMA folks to review the doc. ACTION: Nat, John, Torsten to review the doc. Justin - the doc has 8 authors on it. I've talked with almost everyone. They are willing to act as coauthors/reviewers. Hannes - you can't have 8 authors. Justin - it will stay under the 5 author limit. Stephen - Add folks that drop off the author list in the contributor section. Acknowledgement section is for reviewers. 8. Roadmap (Chairs) Several people presenting Abandoned drafts are listed on slide deck Slide: UX Presenter: Nat Justin - Expired ages ago but has been incorporated into the OpenID Connect (OIDC) spec. It may be useful to pull out and make generic. Stephen (as individual) - why do it in OAuth? This is very generic. Justin - the client may want to say about the user experience. Server can ignore. John - all of these are used by google and Facebook OAuth endpoint independent of OIDC. There are regulations on redirecting people in their language. Justin - a bunch of people are inventing the same thing. Torsten - it make sense to make it generic. Stephen - It has more to do with redirection Justin - but this is redirection for auth. John - language preference in the browser is ignored and useless. Justin - helps the end user make an informed decision. Hannes - who has implemented or interested? Mike - I have an implementation, but I'm not interested in standardizing here. There's already a de facto standard. Hannes - who is interested in standardizing? (4 people?) Scott - I'm concerned that it would screw up OIDC, which is widely deployed. We need to be sensitive to de facto standards. Slide: JSON Based Request Object Presenter: Nat Nat - Propose to take this a wg item. Justin - could address endpoint consistency issue, as a blanket solution. Slide: Hyperlinked OAuth Presenter: Nat Nat - we need out-of-channel metadata. This can be mitigated with insertion of JSON structure. Shouldn't break current implementation. It would be useful addition. Torsten - this info makes the audience restriction transparent to client. The client knows the urls he can send the access token. John - I agree with Torsten that this mitigates the confused client attack. Doesn't break existing clients. Justin - This is compatible with any kind of token. John - and multiple tokens. Justin - Extends metadata structure. Could use with holder of key token as well Tony - token exist today that does this. John - the client doesn't know it. Tony - this breaks this transparency. Justin - reinforces the opacity the token. Tony - you don't needs this structure for this work. Justin - the same argument was made for the expires and token fields. A major design goal - tokens opaque to the client. Any metadata has to live outside the token. What bits really matter? Type and expiration and that's it. Nat's proposal gives us more metainfo that is RESTful. Smart client would parse the metainfo and be opaque to contents of token itself. John - we've been working on token expansion in OIDC. This is a straw man proposal. Is this optional or mandatory - need to decide. Nat - this is optional. Phil - is this a OAuth wg item or oIDC? Scott - we're doing something similar in OIDC. We prefer it to be an OAuth specification if it's going to be done. Hannes - Nat - submit a draft to the wg list. ACTION: Nat to submit a draft to the working group. Slide: Chained Tokens Presenter: Justin Justin - I found Phil's draft after I wrote mine and they are nearly identical. Basic idea - client gets original oauth token, gives it to resource server. Works with bearer tokens. Don't know about others. Sends to auth server to get sister token with a lower scope to present to a 2nd protected resource. Turtles all the way down. New grant point [??] takes in client credentials, down scope and side scope and side chain. Phil - I did get comments on my draft - there's a strong desire to reduce steps. You may make many calls to the resource server. The further away from the resource server, the cost goes up. Good but only when crossing security domain. Servers might have a mac token that would carry payload of the bearer token could do it in a single step. Justin - we have use case where we have tightly coupled things bound by licenses. Cutting down steps is worth it. In my draft - it would be reasonable to cache the 2nd access token. You have a close enough relationship with the resource server. If any of the links break, it degrades nicely. Hannes - the token chaining is brought up often. Slide: Alternate Serialization Presenter Justin Justin - this is simple Leif - if you are in the app space, parsing xml or JSON is free anyway. You want to define a schema. Justin - I don't want to write a schema. If someone wants to write it, I'll attach as an appendix. Slide: Client Instance Presenter: Justin Justin - can see what instance is doing something without changing client id. Slide: Device FLow Justin - Had carved out of OAuth 2 core because there's not enough implementation experience. It's academic, but folks think it's useful. Mike - It's used in cameras. Not academic, but not common. Torsten - the flow reintroduces [??] We do this with TV boxes. Justin - It's for clients with limited display and input abilities. How to close off the negotiation? I haven't heard anyone in community say that it needs to be done. Hannes - need to reach to the community - internet of things. Justin - feels like a hole that we should solve. ACTION: Reach out to the Internet-of-Things community to see if there is interest in this topic. Slide: Multiple Tokens Presenter: Torsten Torsten - auth server has resource servers in different security domains. I"m working on a draft. Justin - folks have asked the list for this. Tony - The was brought up a long time ago. We went through this. There's lots of issues - look at the list. I don't want to rehash for months. Torsten - I already went through the list. Slide: Token Introspection Justin - client gets a token, have another endpoint define were it sends it and gets metadata back. You can do cool stuff with distributed systems. Slide: RS-->AS connection skipped. Slide: UMA skipped. Slide: Implementations Hannes - Is there a value to link to open source implementations on the wg page? Justin - the site is still there, the guy is going to publish an OAuth book. It's not Chris or Aaron hammer. Aaron Perecki. How much does the wg want to own the brand? Hannes - you can't own the brand. Folks felt it was useful to list. Who would help with creating list? (No hands raised) Lucy - I'd be willing to coordinating pointers sent to the list. But evaluating whether they are compliant implementations is a can of worms. Hannes - I don't want to evaluate. I need to formulate what I really want to see and will post to the list. ACTION: Hannes to clarify what he wants to see and post it to the list. Slides: Interoperability testing events Justin - RFC ??? states that OAuth is not interoperable Leif - the OIDC test site, you can turn off OIDC and it becomes OAuth endpoints. Hannes - is there value in coordinating an interop event? Or test online? Mike - I've helped organize interop tests before. You need a sponsor with money to produce test cases and put them online. Is someone willing to sponsor this work? Otherwise it's doomed. Hannes - is there interest? Leif - the OIDC test tools, [??] could turn off OIDC and help with that. OIDC is a tight-knit group and deploys rapidly. For reusing the test tool, I can facilitate. Slide: Best Current Practices Hannes - would it make sense to capture practices on a wiki page with reviews. Any interested on working on this? Mike - we have the threat model which docs best practices. Hannes - I'm not sure it's correct. Anything else needed? No one jumping up. SLide: Education and Information Sharing Hannes - Would it make sense to link presentations on our pages. Or if you write articles for journals so you don't have to redo writing it again. If you want to share, I'll create a wiki page. Hannes - I'll talk to lief about the interop test. Justin - there's a standing problem - googling OAuth doesn't come up in the top results. Putting stuff on wiki won't show up. Mike - where are we on our expert for IANA registry. Derek - the AD has to do that.