Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 10 Jan 2013 21:38:50 +0000

Interesting use case, and not dissimilar to some others I've heard. How would you go about tracking this? Why would the instances need to know about each other?

One possible approach would be to use a common initializing Request Access Token that is used to call client_register on all instances of a given client. They wouldn't know about each other, per se, but the Authorization Server would at least know enough to be able to tie them together.

There's also the OAuth2 Instance Information extension that I had tried to push a few years ago that comes up every now and again, that might be of use here with some modifications:

http://tools.ietf.org/html/draft-richer-oauth-instance-00

I think I'd like to know more about your concerns and the parameters of your use case first.

I am CC'ing the IETF OAuth Working Group email list, where this draft is being discussed and worked on.

 -- Justin

On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" <[email-masked]<mailto:[email-masked]>> wrote:

I would like to be able to use this protocol to dynamically register clients, but am challenged by the fact that there could be multiple instances of a public client, each unaware of what others have done.  The current protocol doesn't seem to address this.

            Keith
_________________________________
Keith W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007
[email-masked]<mailto:[email-masked]>
www.gehealthcare.com<http://www.gehealthcare.com/>

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

---

From: "Boone, Keith W (GE Healthcare)" <[email-masked]>
Date: Thu, 10 Jan 2013 21:54:10 +0000

The challenge is that we project an environment where there could be thousands of applications conforming to a particular API (see http://wiki.siframework.org/ABBI+Pull+Workgroup), with thousands of data holders making data available through those APIs, and several authorizers (in the OAuth 2.0 sense).  For public (locally installed or web-browser based applications), we'd like to avoid what I call the million registration problem<http://motorcycleguy.blogspot.com/2012/10/thousand-of-providers-and-apps-for-abbi.html> (ignore the technical details), which would require thousands of developers to manually register their applications with all of the authorizers.

Because this is healthcare data, it is entirely possible that data holders will INSIST on being authorizers, which makes the problem even more challenging.

The issue that the ABBI Pull workgroup has been asked to address is to ensure that there is some way to manage bad actors in this eco-system, e.g., through a black-list, white-list or other trust-mechanism.  This wouldn't necessarily be required to be used, but would help an authorizer make an application access control decision.

The challenge with a public application using dynamic registration is that

a)     The application cannot keep it's credentials secret, and so must retrieve them in some way securely

b)    If the client_id is not tied back to the application identity, then we have concerns about the trust mechanism being able to protect the environment,

c)     And yet, we also want to protect clients from denial of service attacks where a client could be impersonated (to an authorizer), and obtain a client_id.

Imagine the case where I purchase an application and download it to my iPhone and to my iPad.  Then I connect that application to a data holder/authorizer combination it hasn't seen before.  Through dynamic client registration, I could register that application for my iPhone, but the instance of that same application running on my iPad would know nothing about the first registration.  So it would attempt to do it all over again.  What happens here?

            Keith

M +1 617 640 7007

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Thursday, January 10, 2013 4:39 PM
To: Boone, Keith W (GE Healthcare)
Cc: [email-masked] WG
Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg

 -- Justin

            Keith

M +1 617 640 7007

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 11 Jan 2013 17:10:38 +0000

Thanks for the thorough writeup, this is definitely an interesting use case. There are a few ways that you could go about this, from what I'm seeing, but there are also some things to untangle first. My apologies for the wall of text.

First, public clients can keep secrets, but there's a difference in the kind of secret they can keep. A client_secret in the traditional pre-registered out-of-band OAuth case is what's considered a configuration-time secret. This means that it effectively has to be configured with the software when it's deployed. This includes downloading the app to a smarphone or loading the Javascript app into the browser. The reason they can't keep these kinds of secrets is that all copies of the app would have the same secret and it would potentially be exposed to any end user. This is a bad thing since any end user could now fully impersonate the app with their own code. However, there is another class of secret: runtime. A runtime secret is something that the client gains after it has been configured and deployed, like the OAuth access token or any kind of client information (including an id and secret) gained from dynamic registration. This still doesn't change the fact that dynamic registration still can make sense with public clients (with no secret), but the very nature of the operation does change the nature of the secrets in question.

In your final example, if you're using a per-instance dynamic client registration, why wouldn't you want the iPad and iPhone app to re-register itself? That seems to be the whole point, since they'd necessarily be getting different client secrets. What do you see as the downside to this, especially when it can be automated? There are some approaches that you can take to group together sets of dynamically registered clients, too. More on how this might work in practice, below.

Regarding DoS, this is something that the DynReg spec starts to touch on in its security considerations section. You're basically going to want to do some kind of throttling and monitoring on an open endpoint like that, especially if it's internet-facing.

Now, on to what I see as some possible approaches for what you want to do:

1) Use well-known client_ids for public clients.

In this case, you don't use dynamic registration at all and just say that all clients are public clients, and tell every Authorization Server where to get the list of well-known client ids. You would want to take steps to protect the redirect_uri's for each of these client_ids to make them less susceptible to hijacking, since calls to the token endpoint would no longer have a client_secret to protect them.

Side note: On the RHEx project (which you mention in your blog post), it's true that we didn't profile public clients or dynamically registered clients, but the idea here was that if you were going to do that, you would want a different profile that called out the unique security issues that come with these kinds of things.

2) Use a centralized server to register all clients.

Nothing in OAuth says that each server has to have a local copy of the client credentials, especially if you're using a Client Assertion to authenticate to the Token Endpoint. You could pretty easily accomplish this by having a central location (or forest of them) that app developers can sign up at, where they're given a "developer key" to embed into their applications. This doesn't work very well with mobile and in-browser apps, because the developer key can leak, making it ultimately unsuitable for distributed-code clients like that. However, it could work just fine for any clients where the configuration-time secrets can be kept, like web servers.

And even in the distributed apps case, you do still have to have a resource owner click "Approve" for the client to get anywhere. Your Authorization Servers can put in appropriate warning boxes and

3) Preregister each client as a "class", use DynReg to register the "instance" of each class.

This is an interesting hybrid approach that the DynReg spec (and OpenID Connect) are built to handle explicitly. In this, developers get a "developer key" as in (2), but each instance of the application uses that developer key (which is really just an OAuth2 access token) to call the Registration Endpoint. This way, the Authorization Server can effectively group together multiple instances of the same client, logically. It could even decide to do something special and give them related client_ids, in order to help keep the books straight, but each client would be able to get its very own client_secret. The Authorization Server can also impose restrictions on things like allowed scopes and redirect_uris for each class of client, so that you don't have things going completely rogue on you.

With this, you could take an approach like in (2) and use a centralized server (or forest) for minting these developer keys, say as a signed JWT. The developer keys would be distributed with the applications themselves, so some will leak, but that's not so bad. The clients still have to register themselves, so you can't have your iPad impersonating your iPhone, or anybody else's iPad for that matter. They're all ultimately unique and it's easy for the AS to tell them apart (and group them together).

This approach is what I am currently thinking might be the best approach for your use case. Or at the very least, one to strongly consider in your approach.

4) UMA

In an ideal world, I think this would evolve into a User Managed Access, or UMA, type of system. I know there have been a few attempts at building out a healthcare-centric UMA, but nothing at that scale from what I've seen. In UMA (which uses OAuth, DynReg, Token Introspection, OpenID Connect, and other components), the different parties in OAuth are given a means of being introduced to each other with the right humans in the loop at the right time. We built the initial RHEx prototype in such a way that we could incorporate UMA in future work. I even have a really big, scary diagram to that effect someplace, I'll have to see if I can dig it up. While UMA is a bit more complicated of a platform (tons of moving parts), it's also very flexible and very powerful, and I'd encourage you to start looking in that direction, or at least get some discussion going around it.

tl;dr: You've got a few viable choices depending on the kind of ecosystem you want to have, but I'd recommend using a client-class approach or UMA.

Hope this was helpful, and I'd be interested to hear what the rest of the WG might think about this.

 -- Justin

On Jan 10, 2013, at 4:54 PM, "Boone, Keith W (GE Healthcare)" <[email-masked]<mailto:[email-masked]>>
 wrote:

            Keith

M +1 617 640 7007

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

From: Richer, Justin P. [mailto:[email-masked]<http://mitre.org>]
Sent: Thursday, January 10, 2013 4:39 PM
To: Boone, Keith W (GE Healthcare)
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: Mail regarding draft-ietf-oauth-dyn-reg

 -- Justin

            Keith

M +1 617 640 7007

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Jan 2013 18:28:36 +0100

Hi Keith,

comment see below.

Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE Healthcare)" <[email-masked]>:

> <snip>

Is this a problem? The user should be able the data she desires from both app, independent of the client id.

What do your want to achieve? I don't understand why different instances of an app need to be aware of each other. I would assume a user wants to access the same data from all those instances. But this is merely controlled by the user identity with the app.

I see two possible scenarios:

a) the app does not have an user management but relies on the user to setup the connection to a particular resource server. The user would do this on every device, i.e. every app instance would carry out the OAuth dance with the particular authorizer.

b) the app has their own user management. So the user would 1) register for an account and 2) connect this account to the resources managed by the authorizer. Assumption: the app has an backend and stores user data there. On the second device, the user has only to login using her app account and is done.

Regards,
Torsten.

> [email-masked]
> www.gehealthcare.com
> On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" <[email-masked]> wrote:
> 
> 
> [email-masked]
> www.gehealthcare.com
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Boone, Keith W (GE Healthcare)" <[email-masked]>
Date: Mon, 14 Jan 2013 02:44:14 +0000

More walls of text as my understanding grows:

I've revised my understanding a bit since my first posting.  Let me see if I can explain a little more clearly:

1.     We'd like to have some way for authorization endpoints to make an authorization decision based on policies about an application.
This is something that is deemed essential for these applications since they will be accessing protected health information from entities covered under or associated with entities covered under HIPAA.
In my initial thinking, the client credentials would identify the application so that policy checking would be enabled by the data holder.  But the client_name and/or client_url could also be used by the authorizer.
Policies might say something like: Application XYZ has been certified by organization ABC to be compliant with policy 123, and should be granted access.  Or, Application XYZ is known to be a Trojan and should not be granted access.  Or Application XYZ is known to be susceptible to virus QRS and should no longer be granted access. How these policies are distributed to authorizers isn't part of this discussion.  Access tokens issued by authorizers could be sufficiently short-lived that routine refreshes would be necessary, allowing policy checks to be performed as frequently as necessary.

2.     We'd like to facilitate an automated process whereby application can be dynamically registered without requiring a lot of infrastructure.

I think there are three actors in the registration process.  I'll call them the registrar, the application instance, and the authorization endpoint.  The registrar is a confidential client.  It serves three functions:

1.     It "registers" application instances (others have referred to this as the application) with itself, and configures those application instances so that they can communicate with it securely in the future.

2.     It registers an application (others have called this an application class) with an authorizer.

3.     It facilitates communication between an application instance and the authorizer by obtaining authorization tokens which are then communicated to the application instance to register itself with the authorizer.

The registrar "registers" the application (class) during the first registration (thus, not needing an access_token), and since it is a confidential client, can secure its client_id and client_secret.  This registration is scoped to only support facilitating the initial authorization of an application instance (using the scope parameter).

An application instance must configure itself (post deployment) by communicating with the registrar.  This will allow the application instance and the registrar to secure their communications in future conversations.  How they do that is out of scope.  An application will be configured (pre-deployment) to communicate with a specific registrar.

When an application instance wishes to be registered with an authorizer that it hasn't seen before it performs the following steps:

1.     It requests an access token from the registrar for the authorizer.  The registrar will, if it hasn't already, register the application with the authorizer.  It will then use its client_id and client_secret with the authorizer to obtain an access token for the instance needing registration.  These will be returned to the application instance.

2.     It uses that access token with the authorizer to register itself.

What I've done here is essential split the client into two components:  A confidential registrar component, and a (possibly public) application instance component.  The registrar only communicates with authorizers and application instances.  It never actually does any work with data holders.

This seems like it would work for my use case, but still feels overly cumbersome. In order to access data, an application instance:

1.     Has to be pre-configured with a registrar.

2.     Has to be post-configured by that registrar.

3.     The registrar has to register the application with an authorization endpoint.

4.     The registrar has to obtain an access token from an authorization endpoint on behalf of an application instance

5.     The registrar has to communicate that access token to the application instance.

6.     The application instance has to register itself with the authorization endpoint.

7.     The data holder has to authorize the end user and the application instance to access the data.

To make myself feel better, I looked at each of these steps:

1.     This pre-configuration is not hard.

2.     Registering an installed application with the developer of that application is a pretty common feature (in the PC world, not as much in the mobile app world).  That can be combined with the post-configuration step that enables secure communication with the registrar.  This could even be similar to the dynamic registration workflow, save that the application instance is dynamically registering itself with the registrar.

3.     This is very similar to step 6, and might often be coded by the same developers, or use the same libraries.

4.     This is standard OAuth stuff.

5.     This could be done using standard OAuth stuff.  In fact, step 2 could in fact be an OAuth workflow, where an application instance requests an access token from the registrar, which then reroutes that request to the authorization endpoint, using its own credentials.

6.     This is the basic dynamic registration.

The registrar seems to be a simple enough web service that wouldn't take a lot of infrastructure to develop or maintain.  At a bare minimum, it needs to store its client credentials for registrations with different authorizers, and execute two different OAuth workflows:  Registering an application (class) with an authorizer, and obtaining an authorization token from an authorization and communicating that token to an application instance.  A single registrar service could be provided that supports multiple applications, perhaps combining with other services (such as an app store).  If using other OAuth workflows.

I thought about having the registrar do a couple of other things to simplify, but they just didn't seem to work:

1.     It could just configure the application with the client_id and client_secret that were issued during the "first" registration.  Even though these could be secured during that post-installation registration step, having each client instance share an id and secret didn't feel secure.  Someone will mess it up and that id and secret could then be used as an attack vector.

2.     The registrar could perform the registration for the client, and return the client_id and secret it obtained on behalf of the client, but the registrar and the application need not be created by the same organizations, and the registrar would then have access to an id and secret that it didn't need to have access to.

Am I overthinking this, or is this right?

            Keith

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Sunday, January 13, 2013 12:29 PM
To: Boone, Keith W (GE Healthcare)
Cc: Richer, Justin P.; [email-masked] WG
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg

Hi Keith,

comment see below.

Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE Healthcare)" <[email-masked]<mailto:[email-masked]>>:
<snip>

Regards,
Torsten.

            Keith

M +1 617 640 7007

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

 -- Justin

            Keith

M +1 617 640 7007

116 Huntington Ave
Boston, MA 02116
USA
GE imagination at work

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Jan 2013 12:37:06 -0500

Keith,

I think that splitting the application like this is definitely 
complicating things, and it fails to address one key problem: how do the 
"instances" authenticate with the "registrar" portion? You mention it 
could be an OAuth2 flow, but which one? Do these potentially public 
instances need to ask the user? How can you tell a good one from a bad 
one? With this in mind, it seems to me that you haven't actually solved 
the problem, just moved it one step down the line while introducing 
another place for sensitive materials like access tokens to leak from. 
In other words, what do you buy by having the registrar request tokens 
on behalf of someone else instead of them just getting their own tokens? 
Basing things on client_name or client_url are not going to work, since 
those fields are self-asserted. What's to stop me from registering a 
client with the same display name as "Good Client" that actually goes 
and does bad things?

After reading through your writeup below, I still suggest (as per my 
previous email [1]) that you make use of a "client class" type approach 
with a centralized place to register the client classes. It would have 
many of the hallmarks that you're after and fits completely in the 
existing infrastructure. Faced with this use case, this is how I would 
personally go about building it:

1) Create a centralized "application registration" database for the 
network.
2) People go here to register their application once and get a 
deployment key, which is a signed JWT OAuth2 access token.
3) All downstream authorization servers know how to validate these 
deployment keys by checking the signature of the tokens or (better) 
doing an introspection call back to the centralized server.
4) Instances of an application get copies of the deployment key baked in 
and protected at runtime. This part could potentially leak out, so it 
shouldn't be trusted without verification and user involvement.
5) An instance does Dynamic Registration on the downstream AS, using the 
deployment key as authentication.
6) The downstream AS verifies this deployment key as in (3)
7) The downstream AS generates a new client_id and client_secret for the 
instance, tying it to the deployment key presented in (5)
6) Normal OAuth happens here, with the option to warn the user that the 
client was dynamically registered and/or is public -- this is best 
practice, not baked into the protocol itself.

Now let's say that something goes wrong with the deployment key and it 
needs to be revoked so a new one can be issued. You either push the news 
out to the downstream AS through some kind of configuration management 
or you wait for it to call the token introspection again and see that 
something's up. Now the AS can decide if it wants to nuke all existing 
instances associated with that deployment key, including their secrets 
and their tokens.

It's arguable that this doesn't buy you all that much over just baking a 
client_id into all of your instances and doing public clients, and that 
may be right. However, at least the token endpoint calls within a 
particular instance can't be coopted and traded by another instance of 
the same client, since their id and secret will be different. Is that 
worth the extra overhead? I'm not sure, but maybe so.

  -- Justin

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg10510.html

On 01/13/2013 09:44 PM, Boone, Keith W (GE Healthcare) wrote:
> I've revised my understanding a bit since my first posting.  Let me 
> see if I can explain a little more clearly:
>
> 1.We'd like to have some way for authorization endpoints to make an 
> authorization decision based on policies about an application.
> This is something that is deemed essential for these applications 
> since they will be accessing protected health information from 
> entities covered under or associated with entities covered under HIPAA.
> In my initial thinking, the client credentials would identify the 
> application so that policy checking would be enabled by the data 
> holder.  But the client_name and/or client_url could also be used by 
> the authorizer.
> Policies might say something like: Application XYZ has been certified 
> by organization ABC to be compliant with policy 123, and should be 
> granted access.  Or, Application XYZ is known to be a Trojan and 
> should not be granted access.  Or Application XYZ is known to be 
> susceptible to virus QRS and should no longer be granted access. How 
> these policies are distributed to authorizers isn't part of this 
> discussion. Access tokens issued by authorizers could be sufficiently 
> short-lived that routine refreshes would be necessary, allowing policy 
> checks to be performed as frequently as necessary.
>
> 2.We'd like to facilitate an automated process whereby application can 
> be dynamically registered without requiring a lot of infrastructure.
>
> I think there are three actors in the registration process. I'll call 
> them the registrar, the application instance, and the authorization 
> endpoint.  The registrar is a confidential client.  It serves three 
> functions:
>
> 1.It "registers" application instances (others have referred to this 
> as the application) with itself, and configures those application 
> instances so that they can communicate with it securely in the future.
>
> 2.It registers an application (others have called this an application 
> class) with an authorizer.
>
> 3.It facilitates communication between an application instance and the 
> authorizer by obtaining authorization tokens which are then 
> communicated to the application instance to register itself with the 
> authorizer.
>
> The registrar "registers" the application (class) during the first 
> registration (thus, not needing an access_token), and since it is a 
> confidential client, can secure its client_id and client_secret.  This 
> registration is scoped to only support facilitating the initial 
> authorization of an application instance (using the scope parameter).
>
> An application instance must configure itself (post deployment) by 
> communicating with the registrar.  This will allow the application 
> instance and the registrar to secure their communications in future 
> conversations.  How they do that is out of scope.  An application will 
> be configured (pre-deployment) to communicate with a specific registrar.
>
> When an application instance wishes to be registered with an 
> authorizer that it hasn't seen before it performs the following steps:
>
> 1.It requests an access token from the registrar for the authorizer.  
> The registrar will, if it hasn't already, register the application 
> with the authorizer.  It will then use its client_id and client_secret 
> with the authorizer to obtain an access token for the instance needing 
> registration.  These will be returned to the application instance.
>
> 2.It uses that access token with the authorizer to register itself.
>
> What I've done here is essential split the client into two 
> components:  A confidential registrar component, and a (possibly 
> public) application instance component.  The registrar only 
> communicates with authorizers and application instances.  It never 
> actually does any work with data holders.
>
> This seems like it would work for my use case, but still feels overly 
> cumbersome. In order to access data, an application instance:
>
> 1.Has to be pre-configured with a registrar.
>
> 2.Has to be post-configured by that registrar.
>
> 3.The registrar has to register the application with an authorization 
> endpoint.
>
> 4.The registrar has to obtain an access token from an authorization 
> endpoint on behalf of an application instance
>
> 5.The registrar has to communicate that access token to the 
> application instance.
>
> 6.The application instance has to register itself with the 
> authorization endpoint.
>
> 7.The data holder has to authorize the end user and the application 
> instance to access the data.
>
> 1.This pre-configuration is not hard.
>
> 2.Registering an installed application with the developer of that 
> application is a pretty common feature (in the PC world, not as much 
> in the mobile app world).  That can be combined with the 
> post-configuration step that enables secure communication with the 
> registrar.  This could even be similar to the dynamic registration 
> workflow, save that the application instance is dynamically 
> registering itself with the registrar.
>
> 3.This is very similar to step 6, and might often be coded by the same 
> developers, or use the same libraries.
>
> 4.This is standard OAuth stuff.
>
> 5.This could be done using standard OAuth stuff.  In fact, step 2 
> could in fact be an OAuth workflow, where an application instance 
> requests an access token from the registrar, which then reroutes that 
> request to the authorization endpoint, using its own credentials.
>
> 6.This is the basic dynamic registration.
>
> The registrar seems to be a simple enough web service that wouldn't 
> take a lot of infrastructure to develop or maintain.  At a bare 
> minimum, it needs to store its client credentials for registrations 
> with different authorizers, and execute two different OAuth 
> workflows:  Registering an application (class) with an authorizer, and 
> obtaining an authorization token from an authorization and 
> communicating that token to an application instance.  A single 
> registrar service could be provided that supports multiple 
> applications, perhaps combining with other services (such as an app 
> store).  If using other OAuth workflows.
>
> I thought about having the registrar do a couple of other things to 
> simplify, but they just didn't seem to work:
>
> 1.It could just configure the application with the client_id and 
> client_secret that were issued during the "first" registration.  Even 
> though these could be secured during that post-installation 
> registration step, having each client instance share an id and secret 
> didn't feel secure.  Someone will mess it up and that id and secret 
> could then be used as an attack vector.
>
> 2.The registrar could perform the registration for the client, and 
> return the client_id and secret it obtained on behalf of the client, 
> but the registrar and the application need not be created by the same 
> organizations, and the registrar would then have access to an id and 
> secret that it didn't need to have access to.
>
> *From:*Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Sunday, January 13, 2013 12:29 PM
> *To:* Boone, Keith W (GE Healthcare)
> *Cc:* Richer, Justin P.; [email-masked] WG
> *Subject:* Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg
>
> Hi Keith,
>
> comment see below.
>
> Am 10.01.2013 um 22:54 schrieb "Boone, Keith W (GE Healthcare)" 
> <[email-masked] <mailto:[email-masked]>>:
>
>     <snip>
>
>     Imagine the case where I purchase an application and download it
>     to my iPhone and to my iPad.  Then I connect that application to a
>     data holder/authorizer combination it hasn't seen before.  Through
>     dynamic client registration, I could register that application for
>     my iPhone, but the instance of that same application running on my
>     iPad would know nothing about the first registration.  So it would
>     attempt to do it all over again.  What happens here?
>
> What do your want to achieve? I don't understand why different 
> instances of an app need to be aware of each other. I would assume a 
> user wants to access the same data from all those instances. But this 
> is merely controlled by the user identity with the app.
>
> a) the app does not have an user management but relies on the user to 
> setup the connection to a particular resource server. The user would 
> do this on every device, i.e. every app instance would carry out the 
> OAuth dance with the particular authorizer.
>
> b) the app has their own user management. So the user would 1) 
> register for an account and 2) connect this account to the resources 
> managed by the authorizer. Assumption: the app has an backend and 
> stores user data there. On the second device, the user has only to 
> login using her app account and is done.
>
> Regards,
>
> Torsten.
>
>
>
> Keith
>
> *__________________________________
> _**Keith W. Boone*
> Standards Architect
> GE Healthcare
>
> M +1 617 640 7007
>
> [email-masked] <mailto:[email-masked]>
> www.gehealthcare.com <http://www.gehealthcare.com/>
>
> 116 Huntington Ave
> Boston, MA 02116
> USA
>
> GE imagination at work
>
> *From:*Richer, Justin P. [mailto:[email-masked]]
> *Sent:* Thursday, January 10, 2013 4:39 PM
> *To:* Boone, Keith W (GE Healthcare)
> *Cc:* [email-masked] <mailto:[email-masked]> WG
> *Subject:* Re: Mail regarding draft-ietf-oauth-dyn-reg
>
> Interesting use case, and not dissimilar to some others I've heard. 
> How would you go about tracking this? Why would the instances need to 
> know about each other?
>
> One possible approach would be to use a common initializing Request 
> Access Token that is used to call client_register on all instances of 
> a given client. They wouldn't know about each other, per se, but the 
> Authorization Server would at least know enough to be able to tie them 
> together.
>
> There's also the OAuth2 Instance Information extension that I had 
> tried to push a few years ago that comes up every now and again, that 
> might be of use here with some modifications:
>
> On Jan 10, 2013, at 4:24 PM, "Boone, Keith W (GE Healthcare)" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>
> I would like to be able to use this protocol to dynamically register 
> clients, but am challenged by the fact that there could be multiple 
> instances of a public client, each unaware of what others have done.  
> The current protocol doesn't seem to address this.
>
>
>             Keith
>
> *__________________________________
> _**Keith W. Boone*
> Standards Architect
> GE Healthcare
>
> M +1 617 640 7007
>
> [email-masked] <mailto:[email-masked]>
> www.gehealthcare.com <http://www.gehealthcare.com/>
>
> 116 Huntington Ave
> Boston, MA 02116
> USA
>
> GE imagination at work
>
>     [email-masked] <mailto:[email-masked]>