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 phil.h...@oracle.com
On 2013-11-02, at 3:21 AM, Hannes Tschofenig
<hannes.tschofe...@gmx.net> 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 OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
