Requirements related to OAuth Client Registration

[elf-pavlik]

This issue intends to provide space for focused discussion on various aspects of this specific issue. Few excerpts from discussion in #21

@jricher Instead of dynamic registration as in the current prototype, we should be using static registration or its equivalent to introduce a client to the AS. With the current prototype setup, registration is required to set up a client_id and associate it with the application keys. The downside is that for ephemeral applications, and even native applications that can get deactivated/uninstalled/abandoned, this leaves a lot of dangling registrations at an AS that will never be seen again. The client ID in OAuth2 allows an instance of software to be identified across multiple authorization requests, but it’s rare that a single application instance would ever ask for a second token. I believe that we can use technologies like PKCE and DPoP to fill in the functionality currently provided by DynReg. Coupled with this, we can use a WebID for the client ID, or use it to fetch/validate a client ID, and tie that to a set of display and key information for a client. Client IDs are public information, and any attacker could claim any client ID, but we can use WebID mechanisms to lock down the behavior of a given client ID such that any attacker would need to also have control over the appropriate URLs for an app.

@zenomt regarding Dynamic Registration: today, dynamic registration is used only between a client (such as a single-page browser app (SPA)) and the user's OpenID Provider. since the user is likely to be the same from use-to-use of the same SPA in the same browser on the same device, the SPA can (and many do) remember the client ID & secret (and other aspects of the openid-configuration) from run-to-run in that browser on that device. and as we discussed on the call this morning, my proposal doesn't require a dynamic registration with the Resource Server's Authorization Server either.

@jricher DynReg is needed in WebID-OIDC because the keying material used by the client is associated with the client's registration, and not with the access token itself. This doesn't make sense for ephemeral keys and in-browser clients. This is in fact where DPoP comes into play: the keys used by DPoP do not need to be pre-registered with the client, removing the need to have each instance of the client dynamically register itself with the target AS.

@zenomt i'm not sure what you mean by "target AS". in the current Solid POPToken scheme and in my proposal, dynamic registration is only done between the client app and the user's trusted OpenID Provider.

@dmitrizagidulin Currently, the WebID-OIDC protocol does not use the Dynamic Registration to register a client app's keys.
An ephemeral key pair for the client app is generated for each session, and is sent over to the IdP during the Authorization Request step (and returned in the ID Token). (These are the keys that are used for the PoP token etc).

So, currently, we're only using DynReg for a (throwaway) client_id, that's about it.

Then conversation goes little further but I think that last sentence from @dmitrizagidulin captures the current state of things.

I also see in #6

@jaxoncreed The current OIDC use in Solid required dynamic registration which, for the Solid use case, is an unneeded step. https://oauth.xyz/ might be a better fit

I think it would be useful if that suggestion relates to misunderstanding about registering client keys during Dynamic Registration or OAuth.xyz addresses something related to (currently undefined) requirements for client registration.

Last but not least @zenomt mentioned couple of times Stateless Client Registration. We could also document what role we see it can play.

This issue also seems directly related to authenticating clients #25 and identifiers for clients solid/authorization-panel#30

@dmitrizagidulin An ephemeral key pair for the client app is generated for each session, and is sent over to the IdP during the Authorization Request step (and returned in the ID Token). (These are the keys that are used for the PoP token etc).

In #25 I mention advantage of storing non-extractably CryptoKey compared to storing plain text client_id and secret. I understand that in WebID-OIDC you intended key pair to be generated by client each session. Did you intend client to store client_id and client_secret across those sessions, where it uses different key pairs? If true this aspect seems missing in your summary.

So, currently, we're only using DynReg for a (throwaway) client_id, that's about it.

I recall during one of the calls you mentioned NSS issuing both client_id and client_secret, which then can get used with refresh_token grant. At the same time I notice lack of client_secret in snippet from https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md#11-returns-successful-registration

[acoburn]

The key parts of this issue are addressed with https://solid.github.io/authentication-panel/solid-oidc/#clientids-webid