Conceptual Scope w.r.t. OpenID Connect/OAuth 2.0

[achimschloss]

First off all thanks for pushing this topic forward, federated id/authorization are a key concepts for RP and user likewise going forward.. Ideating how they could be bundled with higher level capabilities of user-agents could be intriguing.

Having that said I think it would be good to scope the aim of the effort in a bit more depth in terms of how it relates flows / principals of OIDC Connect/OAuth 2.0 because they are the protocols of choice for any mayor IDP and coming from that angle this would allow us to slice and dice this much better. Since users interact via a multitude of devices types that are also not user agent based (native apps, SmartTVs, ....) generic protocols will need to work in conjunction with any new approaches / layers.

The explainer only generally differentiates between SDK and non SDK based approaches.

Confidential / Public Clients:

In terms of security IDPs typically differentiate between Confidential (server side/secure management of client authentication possible) and public clients (native apps, JS/SDK based integrations unable to do so). Based on the classification of the client they will:

• mandate certain Flow (OIDC) / Grant Types (OAuth) to prevent impersonation etc.
• restrict information sharing (claims), for example by only allowing mandatory fields in ID-Tokens etc.

Today one would categorise this sdk/user agent based approaches as public clients in term of holding credentials as well as in terms of API access (userInfo or any other), is the aim here also to establish

• user-agent side means of a confidential client by protecting the Sandboxed IDP (I guess thats tricky)
• or are you assuming the SDK will just wrap a PKCE type flow to allow a native/SPA type flow in a secure way (https://oauth.net/2/pkce/)

Todays SDK based approaches typically would still redirect to RPs server side once an authentication was established to actually use authorised APIs / store information server side. Assuming you'd want to avoid this, any thought on that?

Information Transfer/Access

OIDC/OAuth is mainly designed to:

1. Authenticate users to RPs (leveraging ID-Tokens -> OIDC only)
2. Authorize transfer of user information (OIDC) or more generically allow API access (OAuth) using access/refresh tokens for server side data transfer

Should this new API deal with Authentication and Authorisation (it seems so). What would be the high level flow of information look like, compared to how it's done today? The explainer mainly refers to ID Tokens, any thoughts on access tokens yet?

IDP vs. User-Agent privacy - cf. Friction

The main benefit / aim of IDPs is to decouple

• a users account (authorisation/ID mechanism) from an RP / specific user agent
• managing authorisations for an individual user for a specific RP (APIs, User-Data, Login behavior, ...)

The explainer explicitly aims to not introduce additional friction for a user, conceptually that would entail that the user can also retain choices with this API across user-agents / devices using the IDP. How will this approach allow a user to preserve "settings" with an IDP?