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

["Boone, Keith W (GE Healthcare)" <[e-mail]>]

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