> On Nov 7, 2018, at 9:08 AM, Simon Moffatt <simon.moff...@forgerock.com> wrote:
>
> It's an interesting topic. I think there is a definitely a set of options
> and considerations for this. Namely operational. For example, hugely
> popular mobile apps (multi-million downloads across different OS's) using
> dynamic reg with per-instance private creds requires the AS to be able to
> store and index those client profiles easily. Smaller scale custom built
> authorization servers are not necessarily going to be able to handle that -
> hence the popularity of assuming everything is generic and public coupled
> with PKCE.
>
Having unique client identifiers does provide some niceties. As examples: it
gives a user a chance to administer/revoke those clients, and it gives the AS
an opportunity to do behavioral analysis with a per-client rather than per-user
granularity.
It also allows you to track user-granted consent per client. There are very
limited options (really, just id_token_hint from OIDC) to indicate when hitting
the authorization endpoint that you have prior consent.
In any case, the ability to work with public clients or the need to do dynamic
client registration is AS policy, not something clients typically have the
power to decide.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
