Re: [OAUTH-WG] Dynamic Client Registration

[Phil Hunt <[e-mail]>]

+1 agreed. There is lots to negotiate still. 

Phil

> On Nov 3, 2013, at 1:27, Hannes Tschofenig <[e-mail]> wrote:
> 
> 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
>