Thanks to Tony Nadalin for the minutes.
          
          
          Monday
          ======
          
          * Chairs Update – Hannes & Rifaat (10 min)
          Overview of agenda and current drafts that are in play. Dick Hardt
          switched jobs and need to find out what is going on with the Distributed
          Oauth. Device flow has had an update but William is not here, there
          was discussions at the Oauth Security Workshop that will make it
          into a new draft. JWT BCP is with AD and all area feedback has been
          incorporated. Brian needs to update Token-Exchange
          Reminder that there are conference calls every 2 week, please join if
          you want to discuss anything.
          
          
          * Security Topics & JWT Introspection - Torsten (45 min)
          
                  https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
          
          
          Its an update to the Threat Model and Security Considerations documents
          and also the Oauth 2.0 Security Considerations documents.
          What has happened since last meeting, 4 revisions?
                  Limit usage of implicit grant.
                  More text of refresh tokens, refined the attack model
                  Not done yet.
                          Grant type PSWD to be deprecated – call in room showed
                          in favor 10 none against
                                  Need to provide alternatives to lots of folks
                                  using this grant
                          Move to public key crypto for authentication - call in
                          room showed in favor8 none against
                          PKCE is now mandatory and also frees up STATE back to
                          application. call in room showed in favor 8 none against
          Recommend PKCE more S256 over NONE - call in room showed in favor 10
          none against
                  There is another SPA specification but not yet completed.
                  Discussion over the if there was a consensus call to deprecating
                  the implicit flow, Mike says there was not a call, others say
                  there was, so Chairs to take this to the list. There was a
                  request for a die-die specification
          
          
                  https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
          
          
          Improves RFC 7662 , used for high assurance use cases such as payments and
          electric signing, 7662 does not take into account signing the responses
          Not many changes since Bangkok, small stable draft
          Request to change this into a more generic specification to the list,
          so 1 response to keep it limited one response to open this up. So tin
          room hum showed hum in favor of keeping existing scope.
          
          
          * UMA drafts - Eve? (45 min)
                  https://datatracker.ietf.org/doc/draft-maler-oauth-umagrant/
          
          UMA enables cross party sharing, concept of a resource owner and resource
          party and these can talk to the same authorization server
          
          UMA Grant Overview
                  Party to party, synchronous
          UMA Federated Authorization
                  1 to n Multiple RS in different domains can use an AS in another
                  domain
          Different tokens
                  Request Party token (RPT), Protection API Access token (PAT)
                  and Persisted Claims Token (PCT)
          
          
                  https://datatracker.ietf.org/doc/draft-maler-oauth-umafedauthz/
          
          
          
          * JWT Usage in OAuth2 Access Tokens - Vittorio (20 min)
             https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/
          
          
          interoperable profile for access tokens.  So defining JWT profile for
          an access token would
                  improve crso vendor interop
                  Proposed JWT Access Token Layout
                  Not to be used as ID token
                  Validating JWT Access tokens process
          
          
          
          
          Thursday
          ========
          
          * OAuth Workshop Update - Hannes (10 min)
          Link to Workshop Agenda - https://sec.uni-stuttgart.de/events/osw2019
          Record attendance, invited guest speaker, hands on workshop, full agenda
          here https://sec.uni-stuttgart.de/events/osw2019/agenda
          
          
          * Browser-based App - Aaron (30 min)
             https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
          
          Written in JavaScript, no backend, require auth code flow with PKCE,
          no implicit flow. Browser based should not get refresh tokens
          Questions on the exact constraints on the proposal, should this be
          only browsers based? What about backend ? What is the scope of the
          specification? Torsten suggests that all the oauth processing can be
          pushed to backend, so one proposal is to make this all about Oauth in
          browser no about backend.
          So this scope would deal with receiving oauth requests, no matter if the
          processing takes place in the browser or in backend, cover both cases
          Must do exact matching on URLs
          Use PKCE instead of CSRF State, need to analyze current state of deployed
          apps, its not a simple change that can just be made. So there may need
          to be some words put in the BCP about state,
          Is S256 adequate for PKCE? Seems ok
          Should password grant be discouraged in BCP, its not been determined if
          this would be a MUST or a SHOULD. This document would prohibit use of
          password grant type
          
          
          * PoP Key Distribution - Hannes (30)
             https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
          
          
          new version published, seems that ACE and Oauth WG Pop tokens doscs can
          share same CWT usage.
          There is a equivalent draft in ACE to the Oauth resource parameters
          specification
          Ready for WGLC?  So there may need some additional work about proving
          a public key without a proof. This specification seems to only be half
          the solution. So must prove control of the public key, how that proof
          is provided seems to be the question, how it crosses boundaries. There
          seems to be some scenarios where I may get a key on behalf of another,
          but you don’t have the requestors private key. Are we enabling a MIM
          here? This may be an ACE issue only?
          
          
          * MTLS Update - Torsten (10 min)
             https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
          
          Client to AS , alternative to Token Binding
          Changes, new abstract protocol diagrams, added new metadata for use of
          a SAN. Added metadata for alternative AS endpoint
          Need more info on how refresh tokens are used for confidential clients
          There sees to be some issues with the metadata changes, as they may
          conflict with the AS Metadata specification, so some research needs to
          be done.  Mike says this needs to be clarified in the spec and if this
          is done then no issue.
          
          
          * Nested JWT - Rifaat (10 min)
             https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
          
          JWT within JWT, current restriction is that the outer JWT not contain
          claims, so this is a spec to remove that limitation.
          What is the motivating use case ?
          
          
          * DPoP Demonstrating Proof-of-Possession
             https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/
          
          New draft, Oauth lacks a mechanism for SPA,
          Prevent replay, we have mTLS and Token Binding, but support is lacking
          in browsers for TB
          Which mechanisms is this applicable to, SPA? Browser based?