Client authentication and consent creation

[yaron-zehavi]

These are 2 related issues.

Client authentication:

• assertion_endpoint includes a client_id but offers no means of client authentication
• IDPs implementing security profiles such as FAPI 2.0 (https://openid.net/specs/fapi-2_0-security-profile.html) require client authentication by means of mTLS or private_key_jwt (client_assertion)
• Proposal:
  • Add to FedCM request optional client authentication mechanisms such as client_assertion
  • Send client_assertion to (at least) login_url and assertion_endpoint. Perhaps to accounts and disconnect as well

Consent Creation

• FedCM relies on pre-existing consents (user of IDP I permits access to ACCOUNT A to RP R), returned in accounts[i].approved_clients, but doesn't offer a way to create new consents
• Some IDPs' regulatory frameworks (e.g: PSD2) mandates:
  • Short idle session timeouts (e.g: 5 minutes)
  • Performing strong customer authentication on every login
  • Consent establishment per data sharing request
  • Maintaining adequate audit trails of all the above -
• This means these IDPs will return HTTP 401 on accounts endpoint and require fresh logins
• Proposal:
  • FedCM could support such requirements by providing login_url client_id & nonce or client_assertion (which is a signed JWT containing among other things client_id & nonce)
  • This shall enable IDPs to:
    • Assert client identity (when client_assertion is used)
    • Present request to user and obtain consent

[bc-pi]

Add to FedCM request optional client authentication mechanisms such as client_assertion

These requests originate from the browser so client (in the OAuth/OIDC sense) authentication isn't really appropriate.

[cbiesinger]

It would probably be better to split the two concerns into separate issues

Anyway, for now you can only use origin+client_id for client authentication, as you observed. With w3c-fedid/custom-requests#2 you can send more data to the ID assertion endpoint. Regarding login_url, we intentionally do not allow sending identifiable data to that URL currently, for privacy reasons.

With regards to consent creation:

• We currently create such a consent when the user logs in successfully and assume that the serverside is also updated in such a way
• For the various additional authentication requirements, you can perhaps use the proposal in Allow IdPs to continue and finish the request in a popup window custom-requests#1

[yaron-zehavi]

Add to FedCM request optional client authentication mechanisms such as client_assertion

These requests originate from the browser so client (in the OAuth/OIDC sense) authentication isn't really appropriate.

I'm thinking about a confidential OAuth client. Requests technically originate from the browser but could employ a secure backend for request preparation.

[yaron-zehavi]

It would probably be better to split the two concerns into separate issues

Anyway, for now you can only use origin+client_id for client authentication, as you observed. With w3c-fedid/custom-requests#2 you can send more data to the ID assertion endpoint. Regarding login_url, we intentionally do not allow sending identifiable data to that URL currently, for privacy reasons.

What privacy considerations? Keeping in mind that login url is called after user clicks to proceed with chosen IDP

With regards to consent creation:

• We currently create such a consent when the user logs in successfully and assume that the serverside is also updated in such a way

• IDP cannot create the consent for RP at login time when RP's identity is not shared with IDP on login endpoint.
• That means IDPs are required to respond to accounts endpoint prior to consent creation, delegating consent dialog to assertion endpoint with popup window using continue_on parameter.
• This conflicts with EU banking regulations, as banks cannot provide accounts response with PII without a fresh SCA login
• So to implement your proposal and comply with banking requirements, 2 user interactions will be required:
  • First to login (which causes accounts to provide all accounts data, without user choice and consent (problematic)
  • Then on assertion endpoint popup the specific consent can be created

Seems unnecessarily cumbersome user experience (2 interactions instead of 1), and not best privacy since IDP has to share all accounts data and cannot filter based on consent.
Login endpoint could have sorted it all out in one interaction causing accounts endpoint to provide only what was consented

• For the various additional authentication requirements, you can perhaps use the proposal in Allow IdPs to continue and finish the request in a popup window #555

[bc-pi]

Add to FedCM request optional client authentication mechanisms such as client_assertion

These requests originate from the browser so client (in the OAuth/OIDC sense) authentication isn't really appropriate.

I'm thinking about a confidential OAuth client. Requests technically originate from the browser but could employ a secure backend for request preparation.

Technically that would not be a confidential OAuth client.

[yaron-zehavi]

Add to FedCM request optional client authentication mechanisms such as client_assertion

These requests originate from the browser so client (in the OAuth/OIDC sense) authentication isn't really appropriate.

I'm thinking about a confidential OAuth client. Requests technically originate from the browser but could employ a secure backend for request preparation.

Technically that would not be a confidential OAuth client.

Are you saying a web client cannot be confidential? Or did I not explain the architecture accurately?
I was referring to a web application with a BFF capable of securely generating signed JWTs

[aaronpk]

You can add client authentication to this flow if you do the slight variation of the flow that I did for IndieAuth. Basically you don't expect the ID token back from the assertion endpoint, you expect an authorization code which is exchanged for an ID token.

This lets you start the flow from the backend, where you can do whatever client authentication you want, or any OAuth extensions like PAR/RAR/JAR/whatever. The authorization code is sent back from the assertion endpoint to the browser, the browser then sends the authorization code back to the server, where the server makes the request for the tokens and can use its client credentials again.

This is basically analogous to treating the FedCM assertion endpoint as an OIDC authorization endpoint and using response_type=code&prompt=none in the OIDC authorization request.

[yaron-zehavi]

You can add client authentication to this flow if you do the slight variation of the flow that I did for IndieAuth. Basically you don't expect the ID token back from the assertion endpoint, you expect an authorization code which is exchanged for an ID token.

This lets you start the flow from the backend, where you can do whatever client authentication you want, or any OAuth extensions like PAR/RAR/JAR/whatever. The authorization code is sent back from the assertion endpoint to the browser, the browser then sends the authorization code back to the server, where the server makes the request for the tokens and can use its client credentials again.

This is basically analogous to treating the FedCM assertion endpoint as an OIDC authorization endpoint and using response_type=code&prompt=none in the OIDC authorization request.

I like it
Where I still see a challenge is the IDP having to provide all accounts without identifying the RP.
And if IDP requests a fresh login prior to providing accounts that's a separate user interaction

[cbiesinger]

It would probably be better to split the two concerns into separate issues
Anyway, for now you can only use origin+client_id for client authentication, as you observed. With w3c-fedid/custom-requests#2 you can send more data to the ID assertion endpoint. Regarding login_url, we intentionally do not allow sending identifiable data to that URL currently, for privacy reasons.

What privacy considerations? Keeping in mind that login url is called after user clicks to proceed with chosen IDP

No, it is also called directly in case of the button mode used with an IDP that's logged out.

[cbiesinger]

Seems unnecessarily cumbersome user experience (2 interactions instead of 1), and not best privacy since IDP has to share all accounts data and cannot filter based on consent. Login endpoint could have sorted it all out in one interaction causing accounts endpoint to provide only what was consented

If you expect that the user logs in ~every time anyway, I am not sure that FedCM offers much value? Partitioned cookies should work just fine.

[aaronpk]

I just wrote up some notes on how you could add client authentication when using OAuth. Notes are still rough, but you can read them here: https://github.com/aaronpk/oauth-fedcm-profile

[bc-pi]

Add to FedCM request optional client authentication mechanisms such as client_assertion

These requests originate from the browser so client (in the OAuth/OIDC sense) authentication isn't really appropriate.

I'm thinking about a confidential OAuth client. Requests technically originate from the browser but could employ a secure backend for request preparation.

Technically that would not be a confidential OAuth client.

Are you saying a web client cannot be confidential? Or did I not explain the architecture accurately? I was referring to a web application with a BFF capable of securely generating signed JWTs

What I was trying to say is that architectural approach is not actually inline with the spirit or letter of being a confidential OAuth client. And almost certainly isn't giving you the security properties thereby bestowed. And very certainly shouldn't be something that's propagated into new contexts like FedCM's identity assertion endpoint.