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