OAUTH WG WG STATUS Oauth Assertion Framework – RFC Editor Queue JWT - RFC Editor JWT Bearer - RFC Editor Proof Key for code exchange – to IESG PoP Architecture – to IESG PoP Semantics for JWT WGLC in Progress Token Introspection – Shepherd write up Token Introspection – Justin Made changes from WGLC most notably some specific requirements for “active” Open Issues: Registries Main issues is trying use the JWT registry with Token Introspection, so there is a (1) proposal to extend the JWT registry or (2) to create a new registry and seed it with the JWT registry, (3) and last proposal is to create a new introspection registry-only Mike – is for option2 to be aligned with how this has been done before Brian – 2 separate registries are needed, so option 2 would work John – Does not want the JWT to be a dumping ground, so separate registries needed Poll – option 1 – 0 votes, option 2 – 12, option 3 -1 POP Semantics – Mike WGLC ends soon, new comments came in so need to talk about these and push a new draft out Brian – Made some editorial comments, concerns over the CNF and the structure. Review document – Justin, Nat John Bradley gave overview of Proof of Possession Proof-of-Possession Blog post from John Bradley see http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html Discussion over how to stay in step with the industry, other ietf work PoP AS to Client Key Distribution - Hannes and John Bradley Open Issues – can asymmetric keys be used with more than one resource server Protect Refresh Token as well as Access token ? TBD, need usecase Need to have more discussions on client held keys and server keys There needs to be a matrix of all the options that may be available (will call out the various redundancies) HTTP Message signing Tie and OAUTH token and signature to a specific HTTP request This is not binding to the TLS session There are other ways to do this, OAUTH 1.0 and AWS OAUTH Token Exchange ActAS, onBehalfOf functionality Stable drafts Need more input and more eyes on this Phil – so folks are not interested in the expensive token chains and validating Brian – none of his feedback has been considered In-official meeting will be scheduled during this week. Open Redirectors Leaks information in the fragment and referrer, this applies to all protocols that use redirects Some of the mitigations Append fragments to all redirects Internal redirect Append content-security-policy Header Include Referrer meta tag So do we do something specific in OAUTH like put this into the security document Suggestion to update the OAuth Thread document to include these types of recommendations. No decision made. Destination Claim – Brian A new claim for specifying the destination of the JWT, not the same as audience (who) but where is the key, A single value destination, may need to make this a multi-value Discussion needed how it is different to the audience claim. End of meeting