Re: [OAUTH-WG] updated Distributed OAuth ID

Torsten Lodderstedt <> Tue, 17 July 2018 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9129E130DCA for <>; Tue, 17 Jul 2018 08:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HL5e9qetenZY for <>; Tue, 17 Jul 2018 08:59:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E19B124BE5 for <>; Tue, 17 Jul 2018 08:59:57 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <>) id 1ffSOI-0005VU-VG; Tue, 17 Jul 2018 17:59:55 +0200
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_BF7BDCF7-4A79-4892-9236-022C07C1AA02"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 17 Jul 2018 17:59:52 +0200
In-Reply-To: <>
To: Dick Hardt <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <>
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jul 2018 16:00:00 -0000

Hi Dick,

I like the draft! It puts together some best practices relevant for dynamic OAuth in a reasonable way.

Some comments: 

Section 2: 
I appreciate the idea to let the resource determine its resource URI (later used as aud of the access token). This will allow the RS to segment and group its resources as needed.

Section 3: 
Don’t you think it could be a useful information to have the resource URI available in the authorization flow?I would assume it could have some additional meaning to the AS and could also be the context of the scope.

Section 4: 
I think the client MUST authenticate using a PoP (asymmetric crypto based) mechanisms due to the attack angle given in 6.3
Did you intentionally restricted the draft to single resources? I would desire support for an integrated UI flow for authorizing access to multiple resources at once. This makes sense in multi-service deployments.

Section 6.1. 
I suggest you also refer to for a comprehensive discussion of this threat.

kind regards,

> Am 12.06.2018 um 21:28 schrieb Dick Hardt <>om>:
> Hey OAuth WG
> I have worked with Nat and Brian to merge our concepts and those are captured in the updated draft.
> We are hopeful the WG will adopt this draft as a WG document.
> Any comments and feedback are welcome!
> /Dick
> _______________________________________________
> OAuth mailing list