revisiting building IAE on top of first party apps draft

[jogu]

Two things have changed since we last discussed this:

1. first party apps is moving to WGLC
2. https://www.ietf.org/archive/id/draft-ietf-oauth-first-party-apps-03.html#section-1.1 specifically acknowledges that it may be extended for non-first-party use cases ("Profiles of this specification that extend the usage to non-first-party use cases MUST describe how their application of this specification avoids the risks associated with third-party apps directly interacting with the user.")

[dpostnikov]

Discussed on APAC call today. @paulbastian @charsleysa are supportive.

@jogu mentioned that the spec name might be an issue.

@mickrau raised an issue of a potential delay of 1.1 if we pivot now. @jogu mentioned that it depends on how IETF WGs progress.

@fkj: The security model is quite different from their assumptions, so I think the first step is figuring out whether our model works with their assumptions.

[jogu]

Discussed on today's WG call:

Concern if this would affect timescales.

Need to consider if any of the non-normative guidance in first party apps makes our use case misleading.

They might be willing to rename the spec if everyone can agree on a better name (Aaron floated the idea of 'Direct Interaction API', do people like that?

Joseph raised some issues in their GitHub for some things that might affect our usage: https://github.com/oauth-wg/oauth-first-party-apps/issues

[mickrau]

Here is a comparison table (draft). Feel free to edit or comment.

From my side there is nothing fundamentally objectionable about using the first‑api‑app.
A large part of the current IAE definition (interactive_type: urn:openid:dcp:iae:openid4vp_presentation) would end up in a profile definition.

Advantages:

• Reuse of the core mechanics and security mechanisms (DPOP‑bound auth_session), PKCE, redirect_to_web flow (although this seems somewhat more limited to me)

Disadvantages:

• potential time delay
• misleading name (i would like "Direct Interaction API")
• no negotiation mechanism in spec (could be added to profile)

[fkj]

@mickrau Thanks a lot! We should try to figure out the open questions you've noted in the table with the participation of the first-party-apps draft authors. A lot of them will probably also be issues for other users of the draft.

[dpostnikov]

@fkj potential topic for IIW?

Who is going to be there?

[fkj]

I will be there. I assume at least some of the first-party-app draft authors will also be there.

[mickrau]

@fkj I won't be attending IIW, but I would really like to see some progress made on this issue. Has anyone already contacted the authors?

[fkj]

@mickrau Not that I know of. Maybe you could post an email to them and CC the DCP list?

[Sakurann]

DCP WG discussion:

• Current hypothesis is that IAE spec text can be rewritten as a profile of first party app without any technical breaking changes to the current IAE mechanism itself. if this is the case, we might be able to switch without much effort. Will be harder if there are any technical breaking changes to current IAE. @mickrau can you a pass at it? @fkj and @GarethCOliver can support.
  • based on the comparison here https://github.com/openid/OpenID4VCI/blob/719-revisiting-building-iae-on-top-of-first-party-apps-draft/1.1/discussion/comparison_iae_1stpartyapp.md
  • will have to add security considerations for "Profiles of this specification that extend the usage to non-first-party use cases MUST describe how their application of this specification avoids the risks associated with third-party apps directly interacting with the user."

[fkj]

Discussed with the first-party apps authors (and others) at IIW.
Conclusions:

• We should define our own redirect_to_web because theirs is JUST for going to an OAuth server
  • In PAR case, it means continue (i.e. you are done)
  • In non-PAR it means start over
  • Ours means something like “continue on web” or “do a step on the web”
• Should we add our own interaction_types parameter?
  • From a FPA perspective, it is intentionally not defined because they assume first-party so no negotiation is needed
  • So yes.
• Should we even do this rebuilding?
  • Is it worth taking on a dependency?
  • Helps only having to do security analysis once, e.g. for the AS mixup attack
  • If you are not an AS that also implements FPA, you probably don’t care. But if you are one, it makes a plugin type architecture possible
  • We could do a smaller profile that just does negotiation if other people also want it, then base on that instead
• AS mixup attack in AS Mix-Up Attack on IAE #595
  • Will attempt fix in FPA
  • @jogu will open an issue in the FPA repository