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

"Richer, Justin P." <> Thu, 10 January 2013 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D68521F88E8 for <>; Thu, 10 Jan 2013 13:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.087, 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 oVVSne4Hj8WN for <>; Thu, 10 Jan 2013 13:38:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 123F421F8765 for <>; Thu, 10 Jan 2013 13:38:53 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 732771F34BA; Thu, 10 Jan 2013 16:38:52 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG ( []) by (Postfix) with ESMTP id 5A1231F34BB; Thu, 10 Jan 2013 16:38:52 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS04.MITRE.ORG ([]) with mapi id 14.02.0318.004; Thu, 10 Jan 2013 16:38:52 -0500
From: "Richer, Justin P." <>
To: "Boone, Keith W (GE Healthcare)" <>
Thread-Topic: Mail regarding draft-ietf-oauth-dyn-reg
Thread-Index: Ac3utCNS17plP6SWSbiehcbL+FvGpwA8KZMA
Date: Thu, 10 Jan 2013 21:38:50 +0000
Message-ID: <B33BFB58CCC8BE4998958016839DE27E0687614D@IMCMBX01.MITRE.ORG>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E0687614DIMCMBX01MITREOR_"
MIME-Version: 1.0
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 21:38:54 -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:

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