Subject: [OAUTH-WG] Dynamic Client Registration

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 02 Nov 2013 11:21:44 +0100

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

---

From: Phil Hunt <[email-masked]>
Date: Sat, 2 Nov 2013 09:08:37 -0700

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
[email-masked]

On 2013-11-02, at 3:21 AM, Hannes Tschofenig <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Sun, 3 Nov 2013 04:28:36 +0000

Hannes,

There are a number of major use cases and expectations that I've kept in mind throughout the development of this protocol. Some of the fallout of this is captured in appendix B of the current draft, but I'd be happy to write them out here:

First, the use cases of OpenID Connect and UMA are driving factors, which shouldn't be surprising since the draft that we have now came into existence by combining the UMA dynamic registration draft (which started its life over 3 years ago now) and the OpenID Connect dynamic registration draft (which is at least 2 years old). In both of these cases, the trust starts at the end user, who effectively makes the introductions between the different components. For example, in Connect's fully open and distributed mode, the end user types in a web finger address at the RP to point to an IdP that the RP's potentially never heard of. That RP needs to be able to talk to that IdP in real time, while the user is still there. Likewise in UMA, the end user points the client at the API which discovers the AS. Any kind of step that requires a system administrator or developer to be involved is a dead stop for the fully distributed cases of these protocols, since the whole point is to *automate* the process of registration. The case is even more clear with BlueButton+, a healthcare data access protocol, where the end user is the patient. The patient has the right and ability to connect their health care provider's API (protected by the provider's AS) to a client of the patient's choosing, even if the provider or the provider's software vendor has never heard of the client software before. 

That said, there's a "more trusted" middle ground where you get authorized to call the registration endpoint, and you can show that by presenting an initial access token as part of that request. We've taken that mechanism with BlueButton+ and defined our own initial access token as a signed JWT assertion presented as a bearer assertion. (There's also a discovery protocol in BB+ that defines how the AS can validate the assertion.) Large providers, like the Googles and Facebooks of the world, like to have a relationship with the developer ahead of time. The developer is effectively issued an access token to tie their clients back to the developer's account. There can be a problem with this though, and it's important to think of the dynamic registration from two perspectives: 

>From the perspective of the AS, the protocol is all about introducing new clients. In this view, you've got an AS with lots of different client applications trying to talk to it. These might be many copies of the same code base, or many different code bases, but each instance needs to be able to present a client_id and client_secret (or equivalent authentication) that the AS can recognize. In an enterprise, it's common to think from this perspective because it's usually the enterprise that's rolling out the AS and wanting to provide access to a published API to a bunch of clients that may or may not be known ahead of time. 

>From the perspective of the client (which is really to say, an instance of a client), the protocol is all about introducing the client to a bunch of different auth servers. This is usually the case when you've got an "open" API, like OIDC, that may be hosted by any number of unknown parties that need to be discovered at runtime. One client can talk to a number of different instantiations of this same API. This perspective often gets lost when people talk about deploying auth servers (especially the large internet providers) or having some kind of trusted registration, like what Google wants to do with giving developers access tokens. However, I think that this perspective is going to become more important as we have more widespread common APIs and better service discovery systems.  Note that in BB+ we have both open and trusted registrations, with the open registrations MTI.

Extensibility of the base draft is also a very important consideration to me. OAuth works because it's a set of composable blocks that can be brought together to solve a wide variety of problems. As such, it's important that the client's metadata be safely and easily extensible so that specific protocols being protected by OAuth (like Connect or Blue Button) can easily define protocol-specific client aspects. This would also be the logical place to inject Phil's proposed software statement, as an extension to the client's presented metadata and a means for protecting particular fields with a signature. Additionally, since OAuth has many different methods of clients authenticating, the draft defines a registry to allow for specific OAuth-protected protocols and systems to define different auth methods, like Connect's private_key_jwt and client_secret_jwt methods that are more specific to how Connect defines its interactions. I'm sure there will be other methods in the future, too.

Finally, the ability of the client to manage the metadata that's attached to a client_id over time is important in some use cases. Fundamentally, the registration process is the "Create" verb, and the "Read/Update/Delete" verbs are a short step after that to implement. It's become clear to me that if your authorization servers are fully stateless, or if you believe that all of the metadata properties of a given client (or even piece of software with multiple instances), then the management API doesn't make any sense. However, neither of these assumptions are universal, and with the right components, we can have a system that can be composed in different ways to fit all of these use cases.

 -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 03 Nov 2013 10:27:52 +0100

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 [email-masked]
>
>> 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.
>>
>> 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 [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 03 Nov 2013 10:27:58 +0100

Thanks for sharing your perspective, Justin.

This is a good summary of the use cases in the appendix of
draft-richer-oauth-dyn-reg-core-00 and draft-ietf-oauth-dyn-reg-14. The 
text in the appendix is more focuses on the technical aspects but I 
believe the main difference really is in the user/developer experience 
in those use cases, which you have summarized in this mail. I
wonder whether it would make sense to include this brief summary of the
use cases in the introduction section of the document (and point to the
more detailed writeup in the appendix).

Read through the document I have been to find out what the disconnect in
the group has been and my only idea was that it might have something to
do with the focus on different scenarios. If that's not the case then I
really don't know.

Since I am interested to make some progress on this area I am curious
about what could be done.

Here is what I believe I see:

* We have the core specification (with is with
draft-richer-oauth-dyn-reg-core-00 quite stripped down to focus on the
interaction with the registration endpoint)

* We have the software statements document
<draft-hunt-oauth-software-statement-00>, which are a step that happens
before the registration interaction kicks in. I see this as an
independent specification that can easily be run before the steps
outlined in
draft-richer-oauth-dyn-reg-core-00

* We have two approaches for managing registration information, namely
draft-richer-oauth-dyn-reg-management and
draft-hunt-oauth-scim-client-reg-00 (whereby the latter uses SCIM as a
baseline and the former doesn't). I understand the argument that someone
who already implements SCIM might as well want to re-use it. Of course,
if you don't use SCIM then that argument does not get you too far. In
that sense, I could imagine both being valid approach (with suitability
for different environments). What I would like to see is how different
they are with their on-the-wire behavior since both are supposed to be
RESTful APIs

* Finally, there was this worry about the stateless nature of the AS
(with respect to the clients and their client ids). John had produced an
interesting writeup to illustrate that you can accomplish the goal with
the current OAuth 2.0 spec when you construct the client-id in a special
way.

A path forward could be to

  * go ahead with draft-richer-oauth-dyn-reg-core-00 (with minor updates
to create the link to the other documents, such as the software statement).

  * publish the software statement document

  * for the approach of managing registration requires a bit of analysis
to see whether the two approaches are indeed that different. If they are
indeed very different then it might make sense to publish both. However,
if they are not that different then we need to make a decision what we
want to go further with. We don't need two specifications that are
almost identical

  * I also think we should publish
draft-bradley-stateless-oauth-client-00 as an informational document
since it seems to be something that people worry about and the document
illustrates how to accomplish the desired functionality without
normative changes to the OAuth 2.0 protocol.

Ciao
Hannes

Am 03.11.13 05:28, schrieb Richer, Justin P.:
> Hannes,
>
> There are a number of major use cases and expectations that I've kept
> in mind throughout the development of this protocol. Some of the
> fallout of this is captured in appendix B of the current draft, but
> I'd be happy to write them out here:
>
>
> First, the use cases of OpenID Connect and UMA are driving factors,
> which shouldn't be surprising since the draft that we have now came
> into existence by combining the UMA dynamic registration draft (which
> started its life over 3 years ago now) and the OpenID Connect dynamic
> registration draft (which is at least 2 years old). In both of these
> cases, the trust starts at the end user, who effectively makes the
> introductions between the different components. For example, in
> Connect's fully open and distributed mode, the end user types in a
> web finger address at the RP to point to an IdP that the RP's
> potentially never heard of. That RP needs to be able to talk to that
> IdP in real time, while the user is still there. Likewise in UMA, the
> end user points the client at the API which discovers the AS. Any
> kind of step that requires a system administrator or developer to be
> involved is a dead stop for the fully distributed cases of these
> protocols, since the whole point is to *automate* the process of
> registration. The case is even more clear with BlueButton+, a
> healthcare data access protocol, where the end user is the patient.
> The patient has the right and ability to connect their health care
> provider's API (protected by the provider's AS) to a client of the
> patient's choosing, even if the provider or the provider's software
> vendor has never heard of the client software before.
>
> That said, there's a "more trusted" middle ground where you get
> authorized to call the registration endpoint, and you can show that
> by presenting an initial access token as part of that request. We've
> taken that mechanism with BlueButton+ and defined our own initial
> access token as a signed JWT assertion presented as a bearer
> assertion. (There's also a discovery protocol in BB+ that defines how
> the AS can validate the assertion.) Large providers, like the Googles
> and Facebooks of the world, like to have a relationship with the
> developer ahead of time. The developer is effectively issued an
> access token to tie their clients back to the developer's account.
> There can be a problem with this though, and it's important to think
> of the dynamic registration from two perspectives:
>
> From the perspective of the AS, the protocol is all about introducing
> new clients. In this view, you've got an AS with lots of different
> client applications trying to talk to it. These might be many copies
> of the same code base, or many different code bases, but each
> instance needs to be able to present a client_id and client_secret
> (or equivalent authentication) that the AS can recognize. In an
> enterprise, it's common to think from this perspective because it's
> usually the enterprise that's rolling out the AS and wanting to
> provide access to a published API to a bunch of clients that may or
> may not be known ahead of time.
>
> From the perspective of the client (which is really to say, an
> instance of a client), the protocol is all about introducing the
> client to a bunch of different auth servers. This is usually the case
> when you've got an "open" API, like OIDC, that may be hosted by any
> number of unknown parties that need to be discovered at runtime. One
> client can talk to a number of different instantiations of this same
> API. This perspective often gets lost when people talk about
> deploying auth servers (especially the large internet providers) or
> having some kind of trusted registration, like what Google wants to
> do with giving developers access tokens. However, I think that this
> perspective is going to become more important as we have more
> widespread common APIs and better service discovery systems.  Note
> that in BB+ we have both open and trusted registrations, with the
> open registrations MTI.
>
>
> Extensibility of the base draft is also a very important
> consideration to me. OAuth works because it's a set of composable
> blocks that can be brought together to solve a wide variety of
> problems. As such, it's important that the client's metadata be
> safely and easily extensible so that specific protocols being
> protected by OAuth (like Connect or Blue Button) can easily define
> protocol-specific client aspects. This would also be the logical
> place to inject Phil's proposed software statement, as an extension
> to the client's presented metadata and a means for protecting
> particular fields with a signature. Additionally, since OAuth has
> many different methods of clients authenticating, the draft defines a
> registry to allow for specific OAuth-protected protocols and systems
> to define different auth methods, like Connect's private_key_jwt and
> client_secret_jwt methods that are more specific to how Connect
> defines its interactions. I'm sure there will be other methods in the
> future, too.
>
>
> Finally, the ability of the client to manage the metadata that's
> attached to a client_id over time is important in some use cases.
> Fundamentally, the registration process is the "Create" verb, and the
> "Read/Update/Delete" verbs are a short step after that to implement.
> It's become clear to me that if your authorization servers are fully
> stateless, or if you believe that all of the metadata properties of a
> given client (or even piece of software with multiple instances),
> then the management API doesn't make any sense. However, neither of
> these assumptions are universal, and with the right components, we
> can have a system that can be composed in different ways to fit all
> of these use cases.
>
> -- Justin
>
> On Nov 2, 2013, at 6:21 AM, Hannes Tschofenig
> <[email-masked]> wrote:
>
>> Hi all,
>>

---

From: Phil Hunt <[email-masked]>
Date: Sun, 3 Nov 2013 10:40:50 -0800

One other major different is that one starts with token issuance and option rest for updates if needed. (Dyn assoc). 

The other is rest centric with token issuance added on as a new mechanism (dyn reg)

Phil

> On Nov 3, 2013, at 1:27, Hannes Tschofenig <[email-masked]> wrote:
> 
> draft-richer-oauth-dyn-reg-core-00 and draft-ietf-oauth-dyn-reg-14. The text in the appendix is more focuses on the technical aspects but I believe the main difference really is in the user/developer experience in those use cases, which you have summarized in this mail. I

---

From: Phil Hunt <[email-masked]>
Date: Sun, 3 Nov 2013 10:43:01 -0800

+1 agreed. There is lots to negotiate still. 

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.
> 
> * 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
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Sun, 3 Nov 2013 21:42:20 +0000

Hannes,

I think that your proposed path forward is reasonable, and it fits with the mentality I've always held that we can build this with reusable blocks to fit many different use cases. 

For what it's worth, I think that if people want a SCIM-based management profile then it should be published and handled in the SCIM working group so that it can track with the SCIM spec (which is still changing). In my opinion, there is plenty of value of having a non-SCIM RESTful API for everyone who wants to manage the objects but not implement all of SCIM. We can define that API here.

 -- Justin