Re: [OAUTH-WG] AS Discovery in Distributed Draft

David Waite <david@alkaline-solutions.com> Tue, 06 November 2018 05:35 UTC

Return-Path: <david@alkaline-solutions.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31E12D4F2 for <oauth@ietfa.amsl.com>; Mon, 5 Nov 2018 21:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH9NKPhZ_REz for <oauth@ietfa.amsl.com>; Mon, 5 Nov 2018 21:35:40 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E0129619 for <oauth@ietf.org>; Mon, 5 Nov 2018 21:35:40 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:24d2:4c99:bef7:cb04] (unknown [IPv6:2601:282:202:b210:24d2:4c99:bef7:cb04]) by alkaline-solutions.com (Postfix) with ESMTPSA id E09BC31682; Tue, 6 Nov 2018 05:35:39 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <FA19C20D-59B9-47F1-B874-C15204CD87BD@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_19CD317F-5A61-456C-911A-7C70A8B650FE"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 05 Nov 2018 22:35:39 -0700
In-Reply-To: <CFFB07DA-F980-4B47-95D9-051BF660D736@mit.edu>
Cc: "oauth@ietf.org" <oauth@ietf.org>
To: Justin P Richer <jricher@mit.edu>
References: <CFFB07DA-F980-4B47-95D9-051BF660D736@mit.edu>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/tnt9g3eJMEsy5Xvga38oX9ZCzb0>
Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 05:35:42 -0000

Is there a need for a client to understand the identity of an authorization server?

This would seem to mean that the token or authorization endpoint would need to be that identity, rather than the issuer (since now the metadata might not be from an authoritative location)

-DW

> On Nov 5, 2018, at 10:19 PM, Justin P Richer <jricher@mit.edu> wrote:
> 
> In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response’s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn’t, we tried the issuer; if neither was set we didn’t do any discovery.
> 
> I’m sensitive to Torsten’s concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.
> 
> — Justin
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth