Minutes from OAuth at IETF 84 ============================= THURSDAY, August 2, 2012 Scribe: Melinda Shore Agenda-bashing & Status ----------------------- OAuth documents approved (applause). There's another issue - appendix b in core spec tells how to do internationalization, references HTML 4, but W3C in HTML 5 are doing the same thing, need to check that. Stephen asked the RFC editor to hold in AUTH48. Hopefully can add a reference to HTML 5. More of a liaison sort of thing. Thomas Roessler said "When you profile our stuff, ask us." Threat model is complete as far as editors know. There was one open issue regarding mailing list discussion on authentication. Base spec was updated, was something added to threat model? Not sure. JSON web token -------------- Spec is stable, signature functionality unchanged in 1.5 years. Over a dozen implementations. Encryption details being tweaked by jose working group. jose wants to take specs to wglc soon. No open issues. jwt bearer token profiles: fully parallel to saml profile (by design). only difference due to token formats. will be ready to go to wglc once jwt is (dependency). Hannes: still take awhile to get jose spec finished (end of the year), so this document will not progress substantially before then. Still, could use review to make sure it's inline with json signing and encryption. John Bradley and Brian Campbell volunteered. Discussion of use cases for jwt bearer tokens/interoperability with saml. Required claims? No, the only required header is the algorithms. SAML may have issuer as a required element. The jwt profile for oauth has required fields (issuer, audience, others). Does jwt token require either signature or encryption? yes. Now would be a good time to start prototyping jwt bearer tokens for your applications/profiles. OAuth & Assertions ------------------ both saml and jwt derived from abstract assertion profile. these are not token profiles for access tokens, but for doing client authentication and deriving access tokens. open issues - most are editorial and explanatory. request for clarity on the orthogonality of client assertion authentication and assertion grants. Should be no normative changes to the rewrite of draft-ietf-oauth-assertions. Should SHOULD be used less often? Hannes suggested adding explanatory text/guidance. Hannes asked if we really need two different encodings for client authentication as well as for the assertion grant types. Mike Jones asked if he's trying to get specific changes to the documents - he knows of usage cases for both types of grants and both types of encodings. Hannes is asking for additional text in the documents to describe these use cases. Use cases --------- Latest version is not much changed from previous. There are some use cases that are not directly supported by current oauth specs. questions are is this complete, are there new use cases. Time frame for completion - how can you tell when you're done (there's very little structure)? The goal was to cover all features of the protocol. Does not expect many additions to the cases. igor faynberg: when the document stabilizes/fewer comments. How many people have read the document? 5 or 6 people. expect to get a new version in a couple of months. Who's willing to review doc? Tony Nadalin & Robin Wilton. Lucy Lynch: might be useful to flag what's been implemented and what has not. HoK --- An ad hoc discussion Tuesday evening took place to capture the recent mailing list discussion. Eight attendees participated in that discussion. worry is that the client that has bearer token might not be entitled to hold it. desire is to have a "proof" token which validates client use, beyond simple possession. worried about token misappropriation. cloning of device, bad proxy, restored from backup. pkix not always preventing mitm through misconfiguration. services don't need tls but credential still needs to be secured. tls does not always terminate at resource. group felt replay attacks were lower priority. Is an additional mechanism for a client to authenticate a server really necessary? In the MAC token document there's an assumption that you have per-token secrets. Maybe binding tokens to an instance of a client could reduce channel binding churn. Three cases, but actually more like two: 1) tls as proof of key; 2) separate tls/key proof; 3) non-secure resource (there is no channel security). Case three is probably an instance of case two. the mac token document triggered the discussion, so there's already something related. there was a sense in Paris that the mac token document is not what people want. Poll to see how many people understand what's under discussion. Roughly 10. Nat Sakimura asked if there's interest in proofing user presence. Prateep: important question, but a different one. John Bradley said SAML proof-of-possession is used to prove ownership of authz token. Mechanism replays itself in a bunch of places. Does this supersede the mac token document? document hasn't expired yet but it's not clear that there's an author. can this be reused for HoK document? Does there need to be a charter change? Stephen Farrell: need to get the working group to a point where they've figured out what they want, and then see if a charter change is needed. Brian Campbell asked for clear definition of problem space and requirements, which was missing from mac token discussions. Paul Hoffman counterproposal: "what they are," not "what it is." There are multiple use cases - work those out and start over again. Hannes indicated that the progress will be * develop a description about the security threats, * get agreement from the group that these problems are worth solving, * develop solution(s) to address these problems. Where to put the solution text and who the authors of the specifications will be determined at a later point in time. Finished early - other items?