Web Authorization Protocol WG ============================= THURSDAY, March 29, 2012 1300-1500 Afternoon Session I Room: 252A Chairs: Hannes Tschofenig & Derek Atkins 1. Agenda Bashing, WG Status Welcome Derek. Thanks to Barry & Blaine. 2. OAuth Threats Document (Torsten) https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ Draft completed WG Last Call Applied changed from LC and published new revision Next step: Barry wants to continue as document shepherd and he has to do a review before moving the document to the IESG. Will take Mike Thomas' issue. Find text to make everyone happy. Barry will do this work the week following the IETF meeting. 3. OAuth Assertions (Mike) https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/ Mike gives a short update. Take to WG Last Call? Yes Mike briefly mentions the non-WG documents JSON Web Token (JWT) and JWT Bearer Token. Derek will be the shedherd for draft-ietf-oauth-urn-sub-ns and Hannes for the other two documents. WGLC will be issued during the week following the IETF meeting. 4. MAC Token (Chairs) https://datatracker.ietf.org/doc/draft-ietf-OAuth-v2-http-mac/ Hannes chatted with Eran. He wants to remain the editor of the document Who is also able to work on it? Eran believes it is ready. BL: Find a shepherd from the WG Bill Mills: raised hand as reviewer Only two people willing to move forward with the document. Bill: solves a problem that others do not. We don't have other token formats that are signed. Barry: I think it is important to have but if only two people involved we don't have consensus. Does the document have to happen, Stephen? Stephen: I would like to see it happen. MAC is stronger (and better) than bearer. BL: Beat up people who are not raising their hands. Beat on Eran to wake it up (document expired). Mike Jones: If you need the functionality then use OAuth 1.0. The functionality is in 1.0. Bill: 2.0 takes implementation considerations into account and improves interoperability. Igor: A couple of people are interested? Or as independent or AD sponsored? HT: So far we have focused on getting the main documents out of the door. Now, we need to work on the rest of the chartered items, which includes MAC. For some reason the interest seems to have went somewhere else. We need at least some reviews. Eran changed the draft over the lifteime quite a bit. Torsten: OAuth2 does not need such a mechanism -- tightly bound to a specific deployment. Only one threat cannot be handled, which is a resource server that uses a token. HT: Maybe it's premature? Blaine: to Torsten -- initially we used MAC for performace reasons. But that changed. People implement SSL incorrectly. MAC guarantees you get it right. But I'm not implementing it. Talk to startups using OAuth 1.0a, talk to them and find out if they care. Not going to hear until you ask people. : Do people want MAC? Wants this to happen. Travis Spencer: Customers looking to adopt OAuth, waiting for MAC. (or at least stronger than bearer tokens.) John Bradley: MAC tokens don't sufficiently raise the bar. More concerned about MITM attack. Structured tokens (maybe JWT) with holder-of-key mechanism. To replace SAML or WS*. Paul Hoffman: threat models ready to go, not an operational model. Sounds like it is an operational doc. If there are threats that people feel are legitimate for MACs, put it in the threat model docs for including the mac. Either way you have to be explicit. Not hard to put it into this docs. But not for what this covers. HT: Threats assume an architecture. You document what you know. Torsten: good point. Intro of threat model document: OAuth as used today in static deployment. Beyond that, will face threats that we can mitigate using MAC or something else. Barry: Paul, can you help Torsten? Can also rev the threats doc over time with bis versions. Hannes & Derek will reach out to the mailing list and the broader community to figure out whether there is interest in the work and what the requirements actually are. 5. Re-charter finalization (all) Hannes goes through the charter text, and the milestones. JWT Tokens could be applicable outside OAuth Blaine: I implemented OAuth for some UK government. It was a nightmare. Token issuance and negotiation and AuthZ as one bundle of code. Inseparable. Result of people reading this spec, thinking it's one thing. As OAuth2 made clear. As Conceptual standpoint: seen together. Need different people together. Re: SAML, the format isn't the problem. JB: OpenID Connect is major consumer of JWT spec. Normative dependency. Have miltiple interop impls. Would be happy to engage here. But it has to be done. Used by OpenID and Mozilla. Please don't send us somewhere else. MJ: Other docs is Simple Web Discovery? (in place of Dynamic CL Reg) BL: It is something that somebody has to do. OAuth does live in both. There is no area conflict doing it here. Happy to see this WG do it. Stephen: JWT is clearly about AuthZ. That's okay. But Web Discovery? BL: Need to do outreach and bring the right people into the group. John: Only have 1 impl of discovery. Need discovery to find registration endpoints changes for protecting user's privacy. Blaine: Discovery should be limited to OAuth Torsten: Agree with Blaine Two things -- Discovery and Registration Get on telechat agenda for 4/26, approval on 5/10 Humm to go forward with proposed agenda with 6th document (SWD) and adjusted dates. Hannes & Derek will forward the charter to the IESG with updated milestones. Final comments? Mills: Don't drop MAC John: MAC didn't solve a client's site-to-site needs