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

[Justin Richer <[e-mail]>]

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:
>
> 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:[e-mail]]
> *Sent:* Sunday, January 13, 2013 12:29 PM
> *To:* Boone, Keith W (GE Healthcare)
> *Cc:* Richer, Justin P.; [e-mail] 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)" 
> <[e-mail] <mailto:[e-mail]>>:
>
>     <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?
>
> 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.
>
>
>
> Keith
>
> *__________________________________
> _**Keith W. Boone*
> Standards Architect
> GE Healthcare
>
> M [phone]
>
> [e-mail] <mailto:[e-mail]>
> www.gehealthcare.com <http://www.gehealthcare.com/>
>
> 116 Huntington Ave
> Boston, MA 02116
> USA
>
> GE imagination at work
>
> *From:*Richer, Justin P. [mailto:[e-mail]]
> *Sent:* Thursday, January 10, 2013 4:39 PM
> *To:* Boone, Keith W (GE Healthcare)
> *Cc:* [e-mail] <mailto:[e-mail]> 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:
>
> 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)" 
> <[e-mail] <mailto:[e-mail]>> 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 [phone]
>
> [e-mail] <mailto:[e-mail]>
> www.gehealthcare.com <http://www.gehealthcare.com/>
>
> 116 Huntington Ave
> Boston, MA 02116
> USA
>
> GE imagination at work
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>