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

"Boone, Keith W (GE Healthcare)" <> Thu, 10 January 2013 21:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2314121F88B1 for <>; Thu, 10 Jan 2013 13:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R26ievRn-1or for <>; Thu, 10 Jan 2013 13:54:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EA5C621F8834 for <>; Thu, 10 Jan 2013 13:54:16 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 10 Jan 2013 13:54:17 PST
Received: from unknown (HELO ([]) by with ESMTP; 10 Jan 2013 16:54:15 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 16:54:14 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 16:54:12 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 16:54:11 -0500
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 16:54:11 -0500
From: "Boone, Keith W (GE Healthcare)" <>
To: "Richer, Justin P." <>
Thread-Topic: Mail regarding draft-ietf-oauth-dyn-reg
Thread-Index: Ac3utCNS17plP6SWSbiehcbL+FvGpwA8KZMAAApcswA=
Date: Thu, 10 Jan 2013 21:54:10 +0000
Message-ID: <>
References: <> <B33BFB58CCC8BE4998958016839DE27E0687614D@IMCMBX01.MITRE.ORG>
In-Reply-To: <B33BFB58CCC8BE4998958016839DE27E0687614D@IMCMBX01.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C41EE4B7616F774CBF466291DC59746F0BCD33CINURCNA03e2kadge_"
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Jan 2013 21:54:12.0695 (UTC) FILETIME=[06C22670:01CDEF7D]
X-Mailman-Approved-At: Fri, 11 Jan 2013 00:43:40 -0800
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-dyn-reg
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Jan 2013 22:00:24 -0000

The challenge is that we project an environment where there could be thousands of applications conforming to a particular API (see, 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<> (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 W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007<><>

116 Huntington Ave
Boston, MA 02116
GE imagination at work

From: Richer, Justin P. []
Sent: Thursday, January 10, 2013 4:39 PM
To: Boone, Keith W (GE Healthcare)
Cc: 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:

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)" <<>> 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 W. Boone
Standards Architect
GE Healthcare

M +1 617 640 7007<><>

116 Huntington Ave
Boston, MA 02116
GE imagination at work