[OAUTH-WG] Dynamic Client Registration

[Hannes Tschofenig <[e-mail]>]

Hi all,

reading througth various dynamic client registration document I get the 
impression that there is one area of potential disconnect, namely in the 
end user / developer experience.

When OpenID started this concept that a random IdP could talk to a 
random RP it seemed like a great idea. There was no need to exchange 
secrets and go through this complicated introduction process between the 
different parties, which sometimes even required business argeements. 
Those processes were known from Kerberos and also from the SAML identity 
federations.

OpenID looked at the entire step from a technical point of view in an 
attempt to exchange the necessary information and then you were done 
with it.

However, there was a bit more to this whole process, namely the entire 
notion of trust. In particular, there was the problem that the IdP would 
hand out information (personal data) to RPs only based on the user's 
consent. Of course, things could go wrong and some RPs misused the data 
given by the RP. The IdP couldn't really do anything about that since it 
knew nothing about the developer at the RP or the RP itself.

So, how does the IdP ensure that it has some way to improve security and 
privacy of their users without handing out just everything. Of course, 
the IdP had it's own interest to know to know data is being passed to.

Jumping to OAuth many deployments required developers to register and 
this registration procedure might require lots of information (such as 
credit card number, phone number, agreeing the terms of service, etc.). 
So, in many cases it wasn't purely about giving the developer a 
client-id and a shared secret for the client application.

Now, here is the challenge: there are obviously different environments 
developers produce software for (such as the Web, the mobile app 
eco-system, and enterprise environments). They might all have different 
processes and expectations about the entire process.

We have pretty much short-cut the entire story to the purely technical 
parts, namely to sending messages around and defining new attributes and 
have done very little in describing the process itself that we assume 
takes place.

I know that you have these processes in your head when you write your 
documents and in discussions I have heard about these processes. 
Unfortunately, they aren't really documented anywhere. I guess it is 
needless to say that the expectations about how enterprises plan to 
deploy software vs. how the same is done for the Web is somewhat different.

So, I believe it is useful to chat about these aspects even though they 
may just lead to a few paragraphs in our documents providing background 
information rather than actual normative specification text.

Ciao
Hannes