Web Authorization Protocol (OAuth) ================================== Date: WEDNESDAY, July 31, 2013 Time: 0900-1130 CEST Room: Tiergarten 1/2 Chairs: Hannes Tschofenig/Derek Atkins Minute Taker: Leif Johansson * Abbreviations: - Torsten Lodderstedt (TL) - Barry Leiba (BL) - Leif Johansson (LJ) - Tony Nadalin (TN) - Hannes Tschofenig (HT) - Derek Atkins (DA) - Phil Hunt (PH) - Paul Hoffman (PHO) - Mike Jones (MJ) - Lucy Lynch (LL) - Nat Sakimura (NS) - Carsten Bormann (CB) - John Bradley (JB) * Chair Overview (DA & HT) - Milestone review. - BL notes that the old notewell was used - Use case draft needs a new document editor. Several persons volunteered to do a review including TN, Robin Wilton, JB, TL, and Peter Gietz. - Agenda Bashing * Dynamic Client Registration - Working group document (JB) https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ - LJ asked for clarification in sec considerations on none method and signed metadata - TN This document should not be in WGLC right now - too many open issues and alternative proposals - LJ - probably want to say "let's not progress beyond WGLC" - PH echo TN comments. Surprised that this went to WGLC - DA WGLC does not mean "no more changes" - PHO mismatch between what authors believes and what WG believes about the document readyness - HT & PHO discuss what to do about the draft. - PH: not clear what to do about the two competing proposals - PHO: not at all comfortable with multiple solutions. we should not be at WGLC at all. - SCIM-based Proposal (PH) https://datatracker.ietf.org/doc/draft-hunt-oauth-scim-client-reg/ - JB - (about "Basic Flow" diagram) up to E it could be the dynamic reg spec, i.e the top part of the diagram isn't in conflict with the current proposal. There is a second proposal that is quite different and is not compat. with dynreg. - Justin (via jabber): nervous about parsing software version - PH: spec says only do direct compare, so no issue there - Robin Wilton: can the two specs be progress separately? - PH: it makes sense to keep using SCIM for provisioning but understand that OpenIDC folks need something can stand on its own - JB: several ideas need to be compared for doing something about application registration & provisioning. The dynreg spec leaves a hook for this. From OpenIDC pov low priority for taking on a dependency on SCIM. - PH: several of these issues need more discussion. push back on WGLC at this time for dynreg. - Justin (jabber): make sense for this to be separate draft sitting on top of SCIM base spec and dynreg - TN: we use SCIM as an endpoint for this. We believe that the static schema in dynreg is a misstake & big problem - Justin (jabber): Schema is plenty extensible - PH: ignoring unknown schema elements is not extensibility - PHO: resonable amount of disagreement - should we push forward at all? - HT: need to figure out what the other groups want - PHO & others talk about who "owns" Blue Button+ & what to do & what constitutes interop. - PHO & LJ - is there a common direction? - MJ disagree that this was developed for OpenIDC. Question for WG: do we want an interoperable solution for this? - PH: what is the critical point of interop? - MJ: fair enough - PH: primary concern has always been OpenIDC if you look at the mailthread. - MJ & JB: not true - we've (OpenIDC) has accepted breaking changes - TN: why are we really doing this instead of completing other efforts in OAUTH? - HT: the WG has stated that it wants this - Justin (jabber): dynreg isn't just OpenIDC - PH: move on to the second proposal... describes an alternative proposal - Justin (jabber): there isn't always a rel. with the API publisher - Multiple: discussion about the idea - several expressions of cautios interest - JB: unclear how this works for webserver apps - Discussion about scalability and the webapp case - PH: highlighting how OpenIDC is a special case - more discussion - TL: lets modularize - have separate I-D for software statements - PH: dynreg may be fine but maybe not the only solution - PH: need to think about how these specifications relate to each other - Justin (jabber): how does this handle one piece of sw talking to multiple ASes? - PH: need to consider carefully - LL: echo TL & pickup the "profile" meme. Write this up as profiles & architect carefully! - Justin (jabber): applauding! - HT: we will reach out to some of the implements (like Roland Hedberg or the BlueButton guys) - HT: will host design team calls - PH to split off software assertion into separate spec * JWT (MJ) https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ - very few updates - time for WGLC? underlying JOSE specs are stable enough - HT: objections to WGLC? (none voiced) - TL, Karen, PHO, BC volunteered to do WGLC review * Assertions (BC) https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ - WGLC ends by 8/8 - BL on WGLC comments: talked to MJ about how to achieve interop. - BL: describe how you could combine specifications to make at least one interoperable specification - MJ: profiles exists for both SAML and OpenIDC. those are not IETF specifications though - BL: ok to point to external doc from either of the I-Ds in question - MJ: very achievable - BL: all should go to the IESG at the same time to establish context - PHO: is this for the IESG benefit or for future developers - BL: the latter - PHO: talk to Heather Flanagan or the IANA - they have talked about having long-term access to external documents - BL: ok will consider that - or we can copy text into WG wiki - BC: interop does not require external profiles actually - TL: same experience at DT with the JSON-based assertion format - no addl profiles are needed - MJ: a SAML deployment needs agreement on certain SAML-specific conventions - this is what BL is referring to - BC: right - TN: so just refer to the SAML specs - BL: maybe enough - JB and TL volunteered to make a review. * Security (HT) https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/ https://datatracker.ietf.org/doc/draft-tschofenig-oauth-audience/ - HT: overview & intro - calls will continue work - HT: We will schedule conference calls to progress the work. * Rechartering and Future work (all) - HT: what should we be working on next? - MJ: proof-of-possession (aka Holder of Key) - multiple +1 from the room - Justin (jabber): token introspection! - app security - NS - Describe security issue with iOS: multiple apps can register for the same URI scheme - JSON metadata for OAuth Responses 1.0 - NS - TL: how do we handle error codes - should take a new look at that - TL: need a mechanism for discovery of AS capabilities - CoRE authorization (CB) - CoRE introduction - HT & DA: make preso for CoRE wg for next IETF describing how OAuth could work for CoRE. CoRE group will inform OAuth about progress as requirements are more clearly specified. - User Authentication for Clients - PH - PH: multiple blogs about this problem: user auth being used for OAuth instead of OpenID Connect etc - PH: gap for authentication-only case - LJ: simplicity argument never ends - NS: user_info endpoint is optional in OpenIDC - NS: also why use separate claims? by changing the claims you have written a compliant OpenIDC profile. - HT: session ajourned