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


29 March 2021, 12:00pm EDT


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




Next Interim Meetings