Minutes IETF104: oauth
minutes-104-oauth-00

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?