Re: [OAUTH-WG] Dynamic Client Registration

[Hannes Tschofenig <[e-mail]>]

Hi Phil,

you are right that I should have used different terminology, such as the 
classification that Justin uses in his document (such as 'open 
registration', 'protected registration') since the term 'enterprise' and 
'web' carries a lot of other emotions and baggage that is not relevant 
to this discussion.

What would be good to ensure is that we capture the different classes.
We have at least the following cases:

  * Out-of-band registration of the developer and the client (as we have 
it with many deployments of OAuth 2.0 today).

  * Open Registration (where there is no prior interaction between the 
RP and the IdP).

  * Then, there is a mixed case (where I would include your softare 
statements) where other information is used for authorizing the client 
(or client instance).

[The difficulty I had writing these cases while at the same time looking 
at draft-richer-oauth-dyn-reg-core-00 tells me that the major 
differences between the different cases are not immediately visible from 
Appendix B of draft-richer-oauth-dyn-reg-core-00 even though there is a 
lot of text.]

In some sense you have tried your own version of this classification in 
the software statement document, but as I had noted in my review, I 
believe you are also not quite there yet.

Ciao
Hannes

Am 02.11.13 17:08, schrieb Phil Hunt:
> Hannes,
>
> Some really good, thought provoking comments! I had not really been
> focused as much on financial relationships between SP and client. I
> must confess I considered web clients that set up major relations
> with service providers. In these cases I dismissed them as a use case
> because they would most likely configure manually and actually end up
> in the "static" class of clients. Still, I think we should give this
> some more careful thought.
>
> What were you thinking of as a "enterprise" that differentiates with
> what we are currently talking about? Enterprise these days has so
> much derogatory baggage that it is hard to tell what is being
> referred to.
>
> There is a quality of APIs that 6749 focuses on that registration can
> fix.  6749 works well for "monopoly"/"singleton"  API providers like
> Google, Facebook, etc.  Yet there are lots of "open" APIs established
> through open source projects, open standards (e.g. Connect), and
> commercial cases where customers will deploy their own copies of an
> API.  I'm not sure this really is "enterprise".  Even in the
> commercial cases, these APIs are most often made available as "open"
> for use by third party developers.  For me, this isn't a case of
> extending OAuth to support "enterprise", but rather extending OAuth
> to support "open" or "multiple-deployment" APIs on the web no matter
> where or how they are deployed.
>
> Phil
>
> @independentid www.independentid.com [e-mail]
>
> On 2013-11-02, at 3:21 AM, Hannes Tschofenig
> <[e-mail]> wrote:
>
>> 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 _______________________________________________ OAuth
>> mailing list [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>