Minutes IETF101: oauth
minutes-101-oauth-03

Web Authorization Protocol (OAuth)
==================================

Monday’s Agenda
---------------

** Chairs Update – 10 min
https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-chairs-slides-01

Rifaat presented a quick update on the status
A number of issues opened which were closed.
Eric will close them off if there are no outstanding comments

Hannes: There was an OAuth Workshop.
see slides for information on links etc.
Topics: formal analysis, regulation, deployment experience,
new ideas, restructuring difficult issues crypto presentations.


** Mutual TLS Profile for OAuth 2.0 – (15 min, Brian Campbell)

Note: MTLS Sender Constrained Tokens - This is binding the access token to a
client certificate. This is different from token binding concepts so the name is
different.

Discussion:
Recommendation to move to WGLC?  Concerns?
Justin does not object. Has implemented both methods and seder constrained
tokens. Justin has a non-normative clarification he will follow up on later.
Torsten reports implementation and believes it is ready to use. Some open
banking initiatives are now directly referencing this specification.
Mike Jones indicated that he will review the draft.

Hannes indicated that WGLC will begin this week (today?)


** OAuth 2.0 Token Binding – (15 min, Brian Campbell)

Eric - IETF LC has completed and still awaiting Eric’s writeup.

Discussion:
Brian: Implementation should be easy once the hard parts are done — which
depends on support for APIs to expose layers of the TLS needed. Specifically
access to exported keying material is needed.
There was a discussion that because of the cross-over nature of these specs,
there is a lot of difficulty getting other parts done without RFC status
creating a chicken and egg problem.
Mike: Microsoft has an implementation and it is working in production.
Eric reports he is doing his shepherd thing right now.


** OAuth 2.0 Security Best Current Practice - (10 min, Torsten Lodderstedt)

Goal is to turn into an OAuth security best practice (a BCP).
From his perspective the document is ready for WGLC.
Hannes asked for volunteers for reviewers. Brian, Phil, Travis, and William
volunteered to review.


** OAuth 2.0 Device Flow for Browserless and Input Constrained Devices - (10 min, William Denniss)

Eric - is concerned about whether there is an attack pattern (raised by John) -
a confused deputy attack.
John explained.  The device is an oauth client, and the if the oauth server is
compromised.
Fake example:  roku device binds media subscription to it. If netflix were
compromised, that oauth server could receive a request and then fake netflix
goes to amazon, and gets a token and plays it back to the device. If the user
wasn’t paying attention, they might unwitting give bad netflix access to the
users amazon prime account.
Mike indicated there is some new text he and John worked on that they just submitted.
Mike indicated that William had text in the security considerations recommending
explanations be given to the user which explain what they are authorizing so
the user knows what *should* be happening.
Running code at Yahoo Japan, and AirStick 4K, as well as Google.
Hannes indicates he will update the shepherd write-up.


** OAuth 2.0 Incremental Authorization - (15 min, William Denniss)

Allows a client to make multiple authorization requests in an incremental way
allowing for an access/refresh token that cumulatively add new scopes. There is
a way for confidential clients to do this, but the incremental value is for
public clients.

Rifaat: has anyone reviewed this?  Justin, Brian, and one other
Justin Richer - generally makes sense but things some clarifications are needed.
Feels it is an important concept and encourages developers not to ask for uber
tokens.
John Bradley - a good document that we should move forward on it with some
additional security considerations. Incremental OAuth with public clients
has caused unexpected side-effects in the wild and needs to be fixed.
William indicates this is why people should not do this.
Rifaat: Is there anyone who thinks this is a bad idea?  No responses.

Hum for adoption:  A positive hum for adoption was received (no hums against).


** OAuth 2.0 Device Posture Signals - (15 min, William Denniss)

discussion:
Who has read the document: John Bradley
Hannes:  Any implementations?
William:  we have implemented something like this, but not this spec yet.
John:  We may need to pair this with a BCP that digs into operating system
specific issues like how to get windows vs. linux attestations. This shouldn’t
stop us from initially adopting the spec.
Tony volunteered to look at the spec along with a couple others.
John:  this (attestation) also begins to address the question of how do I know
I am talking to the real app.


** HTTP Signing - (10 min, Justin Richer)

Discussion:
Hannes: we went through this a while ago, are we still trying to accomplish the
same things (e.g. we used asym and sym keys, did signing but not encryption).
Eric: there is already a draft for encryption using a pre-shared encryption key.
The yasskin draft does cover body by referencing another draft for the body.
Hannes: How can we tie this back into the POP work for OAuth?.
Eric commented that he doubted this will get picked up due to a number of other
issues
Hannes:  lets keep talking about this during dinner conversation this week.




Wednesday’s Agenda
------------------

** OAuth 2.0 Authorization Server Metadata - (15 min, Mike Jones)

3 IESG updates,, ready to go to IESG editor,
Change to .wellknown, so this is a breaking normative change, this is different
than openid connect metadata, so this could mean 2 different locations
Might make sense as the namespace has changed from OpenID and Oauth so you have
to look in both locations anyway


** JSON Web Token Best Current Practices - (15 min, Mike Jones)
No activity since July 2017
Is there interest to continue ? if so we need more reviews ad eyes on this document
Hannes, says that there is interest and start WG last call, William Dennis will
review along with Tony and Nat


** Client assertion flow - (15 min, Omer Levi Hevroni)
Login screen is need for authentication, apps don’t always want login screen,
login app effects look and feel, need to authenticate to a device
John B: JWT Assertion flow exists already, not sure OTP is the way around this
Justin: There is the client credential flow also
Justin: Not sure what this solves that existing specs already don’t solve,
Omer: Detect comprises of private key is the main goal of this specification
William Dennis: Please upload the draft


** JWT Response for OAuth Token Introspection - (10 min, Torsten Lodderstedt)
Additional JWT based response type for Token Introspection
Allows to encrypt/sign results, so givesS a cryptographic proof , encryption
may allow intermediates  to access token w/o accessing the token
Use case of Qualified Electronic Signature – So this is a eIDAS usecase, may
also solve the identity proofing and authentication)
Why not use structured tokens and have to design a new token
What about the latency issue using token JWT introspection
Usecase: Phantom Token Pattern
Justin: Need to decide if signing the response or sign HTTP signing ?
Torsten wants this on the application level. The current introspection spec
does not currently return a token.
John B: Might want to look at Token Exchange


** Assisted Token - (10 min, Travis Spencer)
When user authenticate, a hidden iFrame is opened and posts a message (new format)
Simplifies developer libraries, such as single page applications
John B: there are iFrames issues, and other security issues


** Resource Indicators for OAuth 2.0 - (10 min, Brian Campbell)
New resource parameter, URI where client intends to use access token
SO where are we today, there is the distributed oauth draft, there are some
similarities but the distributed oauth has more requirements
Hannes: So look at the ACE work on proof of possession tokens


** OAuth Response Metadata - (10 min, Nat Sakimura)
This is similar to the distributed Oauth draft, and is s superset, the way the
metadata is returned is different, and allows it to be used in other cases
Linkage to resource-indicators, can we merge them all 3 ?
How broad do we make this effort ?
William D: likes idea and would like to see the merge, Annabelle thinks this is
in line with distributed-oauth draft