Minutes interim-2021-oauth-03: Mon 12:00
minutes-interim-2021-oauth-03-202103291200-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Title Minutes interim-2021-oauth-03: Mon 12:00
State Active
Other versions markdown
Last updated 2021-03-30

Meeting Minutes
minutes-interim-2021-oauth-03-202103291200

OAuth WG Interim Meeting - Client Intermediary Metadata & Multi-Subject JWT

Date

29 March 2021, 12:00pm EDT

Notes

Note taker: Dick Hardt

Client Intermediary Metadata presented by Aaron Parecki

Used in Financial APIs, health care Torsten: application is the client id Aaron: user wants to see the app they are using, and intermediaries are listed in fine print Torsten: this is a legal problem, not a technical problem Aaron: hear from people from FDX Don: (from FDX) need to know the other nodes in the chain of calls - this standardizes what is done as one offs now Anil: (from FDX) the client does not have relationship with data provider, data aggregator has relationship with provider. Provider now has visibility to who all has access to the data Torsten: How does the App get the client ID Anil: the client ID is issued to the aggregator Torsten: Aggregator is the client to the data provider. Aaron: want to show the app the user is seeing to be the app they are using Torsten: every application would set up a relationship with each aggregator Justin: using dynamic registration to register a client is a particular instantiation of the chain. Any considerations given to authenticating the aggregator in the authentication request. Aaron: this draft does not address that issue. The FDX spec addresses these issues. This draft is what was generic. The other aspects are viewed as industry specific. Denis: the term aggregator is missing from spec, and no privacy considerations in spec. To address what the aggregator can see. Aaron: provide transparency to user who is involved in chain. Yes, should add a privacy consideration section. Goal is to allow user to see who is getting access to their data. Justin: what happens when one of the parties lie about what is actually happening. Aaron: like many things in OAuth, these aspects are managed out of band. Torsten: in the end, the data provider relies on the aggregator for the identity of the client. Relying on client registration is a strong assumption. Aaron: would have to look at use cases in how this is done in FDX Torsten: Anil: looking at fine grained consent Dick: plaid gets uses to enter their credentials into the app directly, not use an OAuth flow Aaron: I should have started that we want to stop the current bad behavior Don: FDX is working to make the changes Rifaat: what is status? Aaron: is this something that other people in IETF would be interested in? If it is only FDX / financial oriented? Justin: what if IETF chops this up and makes it something unrecognizable? What would FDX do if that happens? Anil: I'm not familiar with how IETF works. Aaron: if there are breaking changes, will FDX make changes to its specs Don: we will want to reuse what is already there. We Aaron: breaking change is something is different Don: we can back port name changes -- if it is still fit for purpose we will keep uses Justin: something brought in to IETF may change (reference to FAPI) Anil: what I am hearing that we will need to participate Rifaat: are people interested in working on this problem? Indicate in chat. Rifaat: I don't see anyone chiming in. Let's continue discussion on mail list to see if we can get others interested. Justin noted in Chat that he would contribute if it came to IETF.

Multi-Subject JWT - Rifaat

Rifaat: is there interest in this work from the WG? Mike Jones: how are you representing the relationship? Rifaat: using URN with "rel" to show the relationship between primary subject and secondary subject Mike Jones: confused about slide (clarified) Mike: How did STIR solve this? Rifaat: did a one off solution Mike: is there enough in common between the use cases to standardize? Roman: let's go back to list and better describe what is happening to see what next would be.

Rifaat: reminder to add name to list.

Topic - Client Intermediary Metadata

Presenter: Aaron Parecki Draft: https://datatracker.ietf.org/doc/draft-parecki-oauth-client-intermediary-metadata/ Slides: Client Intermediary Metadata

Topic - Multi-Subject JWT

Presenter: Rifaat Shekh-Yusef Draft: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ Slides: Multi-Subject JWT

Attendees

  • Rifaat Shekh-Yusef (chair)
  • Hannes Tschofenig (chair)
  • Aaron Parecki (Presenter)
  • Anthony Nadalin
  • Mike Jones
  • Dick Hardt
  • Anil Mahalaha
  • Jeff Craig
  • Don Cardinal
  • Denis Pinkas
  • Vittorio Bertocci
  • Filip Skokan
  • Torsten Lodderstedt
  • Peter Yee
  • Roman Danyliw
  • Justin Richer

Recording

https://ietf.webex.com/webappng/sites/ietf/recording/4762c7c8318745dd89fe786234dd81a9/playback

Next Interim Meetings

  • April 5 RAR – Torsten https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

  • April 12 Security BCP – Daniel https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

  • April 19 Identity Use Cases in Browser Catalog – Vittorio/George https://datatracker.ietf.org/doc/draft-bertocci-identity-in-browser/

  • April 26 TMI BFF – Vittorio/Brian https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/