Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

"Manger, James" <James.H.Manger@team.telstra.com> Fri, 05 June 2020 02:23 UTC

Return-Path: <James.H.Manger@team.telstra.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 832013A1144 for <oauth@ietfa.amsl.com>; Thu, 4 Jun 2020 19:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com
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 N0y2AnzYYDwX for <oauth@ietfa.amsl.com>; Thu, 4 Jun 2020 19:23:24 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC133A1146 for <oauth@ietf.org>; Thu, 4 Jun 2020 19:23:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.73,474,1583154000"; d="scan'208,217";a="377009174"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 05 Jun 2020 12:23:19 +1000
Received: from wsapp6785.srv.dir.telstra.com ([10.75.3.134]) by ipcavi.tcif.telstra.com.au with ESMTP; 05 Jun 2020 12:23:18 +1000
Received: from wsapp5872.srv.dir.telstra.com (10.75.11.108) by wsapp6785.srv.dir.telstra.com (10.75.3.134) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 12:23:17 +1000
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5872.srv.dir.telstra.com (10.75.11.108) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 12:23:17 +1000
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 5 Jun 2020 12:23:17 +1000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OUjZFFg1e8T7/tvGLYaLDQQ47laNrd8YTLE06WZqF5Az5GwVAFPv+1OffcRsSxJDWbD+Oz8AWoosaCXyI7HCiEjY87ysWs13fnmUJ3wpa4jpQWbf6mfileEfmb/hh6o00JEq9zbBuwp3u/YuxhtcqJOs/DAptWBHgMrfUaQcfyJ0tHV2Yp5kz/4yAnjM/aNrgqAyCTtNwnbnY36BC/ymlSmfJrrU58HRVv4UQuQT4ve1kq93UQOeFHQOQjTDH3ireAzBsbHA/XCvmKyZWHELx2FN0ucKLJeLXZ6+X/fiRZ2SCOyZaI6IKxxBVroKhElqA1E8RytGtq6ubcfppAgZgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0lM8mXlHkppZ4QJQpwfpsr8IJgS17gtNMui94LbBTc=; b=SvcwFufgfWavLHoTrlaGFGZUUVAvZIer4HzNLzxqadeiXyTmHf38NN5WjhhNodh5O7aDpYjlT2E6jsFg/8md3hjDcyf9Oi4O+mmcwGiMVD2W4DrT7nwlHPlK4/rrn2u+gjembkNeMkd0pLRk9Sdrl15O8cPFe8jx77FoYSdHXa5MtanVSqqCz/hCR3N1VcJQnSXWbKI4frV6nQ7L0m3G+v1OFBeDHP2zLT84zl7cK6kBxwKAarCNVPR3jupFkceCFRVdq1i7E8Es7BPOGqP2ERCTITZv3pMwpUr1V3jC7bBLASLU+gJGoNDQfAtwijs61sxoXOoEu9S6wxgujPcqvA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0lM8mXlHkppZ4QJQpwfpsr8IJgS17gtNMui94LbBTc=; b=UitxfbXnLHqoFXP2wTkPKcYwbpsg+n0EgrrItj7dNFin9qRmH+t+5CcUrQSHJTcUsXP/3s1u6jztRDvRgy0JGW7wTJd0si4yTBFMUZs3IGV3LWKEkdEsxX9ObbdbOHzIxKa4aK+ZvZNfaPsFEPbMJDbleOM0qSvV4X2euRpzbpo=
Received: from ME2PR01MB3011.ausprd01.prod.outlook.com (2603:10c6:201:19::12) by ME2PR01MB2610.ausprd01.prod.outlook.com (2603:10c6:201:16::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Fri, 5 Jun 2020 02:23:15 +0000
Received: from ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::7959:e5a7:16dc:e620]) by ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::7959:e5a7:16dc:e620%7]) with mapi id 15.20.3066.018; Fri, 5 Jun 2020 02:23:15 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Joseph Heenan <joseph@authlete.com>, Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
CC: Openid-specs-fapi <openid-specs-fapi@lists.openid.net>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Issuers, Discovery Docs & Brands
Thread-Index: AQHWNDCDDhHpSvSeYEGNG+LAGM0HA6jG7muAgAA8JACAAVvEAIAAr/0Q
Date: Fri, 05 Jun 2020 02:23:15 +0000
Message-ID: <ME2PR01MB3011FF24E2C95FF0BDB0287CE5860@ME2PR01MB3011.ausprd01.prod.outlook.com>
References: <mailman.1608.1590473008.8861.oauth@ietf.org> <CAOW4vyONovS7SLPnTpoGVoi5T92M7tMDbQ4N4o3hGodQRssqSQ@mail.gmail.com> <CAP-T6TT3yo8NhLOGhk3XmPDJJaR6nccjigGSM=VuauysekhV2g@mail.gmail.com> <CAOW4vyNfwRLuNDXg2fVDPVRov_REKYR+KirgDPUq-AdwW4s+mw@mail.gmail.com> <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com>
In-Reply-To: <0CD7A267-59D0-4815-BC24-3A0C80321542@authlete.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
authentication-results: authlete.com; dkim=none (message not signed) header.d=none;authlete.com; dmarc=none action=none header.from=team.telstra.com;
x-originating-ip: [144.132.40.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 95625b6d-8025-4fa6-5de3-08d808f76770
x-ms-traffictypediagnostic: ME2PR01MB2610:
x-microsoft-antispam-prvs: <ME2PR01MB261036154BF3C960FE237795E5860@ME2PR01MB2610.ausprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0425A67DEF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gCUSj/mev8nuFevdjzD+uYTyM+Zi5GuxBqEPGEPNXZo3r9GoCn/+CidCU9M12kgZBrTzBj9jK+OB6XNqICx+0PpDgupfX0OogtKZm+mPA8SRZTueT43DZ8RRcub0OUH4DSnngqUJeF2bNtZ2+i149sFZfdqWin0sRmWZu8paIH7a+oxlcKVfVlovuLu2q5yq5bHfin//SC/uDrUwZqgL9xDubhamYFPyx3OiB5tJjUFoc2de1TEKo7gkuoI8wAdC56n0Y1y9NmtwpGmhDPx6Dgi2vpzZHOAbaEiWa1fw1nzrQZNpj0gyhqzwbVXZiR3Un5wx7GnwUA7BHmUQ1+DZntUfn5JLrLKbfJTdIIu9fhiGNnlo6yyBvWpCzXUaqPdL1y6au89BEboQjcc7ml8ULQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3011.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(366004)(346002)(396003)(136003)(52536014)(76116006)(66556008)(71200400001)(66476007)(64756008)(66446008)(66946007)(478600001)(8936002)(4326008)(8676002)(33656002)(9686003)(186003)(55016002)(2906002)(26005)(6506007)(5660300002)(110136005)(316002)(166002)(54906003)(83380400001)(7696005)(86362001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: eqcqINJxiNQumXZbJteG1ctdogl2ROfM3t762+5yfwO+RAMhkL1l5E7TAaSyr007TzcvKY9pU1rzgtQaYGVLgPgc26BGAHbGjJcvdpAhdOCHuH7Jw/nSgRwpG+0g/ywzhZ9mdXSm4PeINsuvIQFM1v7lI/WB8HiW6rCJMzJPioKWyNa0Q1bn35pj0akCLTg3UmhAkqgpCNneltxCTG8WrmR7Uuj0Xmj4V1tg/3pBBNlmvMtLJ6l7MsbBUfSGcRwhyXpMVO9TEYJ7bLHOIQYCT3cb69v/9dBD3+X6htLQqGea4onhaGHFX3wlha+kKVdFpl+I3Y0DyMs2Z+2TUbb2/fRbhxHcH/TDINqGiXspocVahFfxAGXHL5o+E5aHVWUGQxCQGwMCOkHyKNxOYtg9rlat1W6KebIlCoBCYHEYqKj8ZdLOpNBQldOKr+OD6rNLfSIOD3ttUXFN1VXnFv7oiGNdxsYoU8nFf0pvKHFTHp0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_ME2PR01MB3011FF24E2C95FF0BDB0287CE5860ME2PR01MB3011ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 95625b6d-8025-4fa6-5de3-08d808f76770
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 02:23:15.6857 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: I8AU0JuZhdlGkDaUZNPBcLfHCTbYOVBfFgmS42Q2VoLqVbJDCRazPsGX/Z7s7aV41QS9v622jw3fRzpFnGtonofJLLNNcmcSOoqZQLWKy/A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB2610
X-OriginatorOrg: team.telstra.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/M9NQElNUQxBFi3V1gj6AXL8GwBg>
Subject: Re: [OAUTH-WG] Issuers, Discovery Docs & Brands
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: Fri, 05 Jun 2020 02:23:27 -0000

Wedging support for multiple Authorization Server brands via this "alternative_authorization_endpoints" metadata field is a very kludgy hack.

> "alternative_authorization_endpoints": {
>    "banking": {
>      "authorization_endpoint": "https://loadsamoney/business/auth",
>      "description": "loadsmoney business banking customers",
>      "logo_url": "https://loadsamoney/business/logo.png"
>    },
>    "personal": {
>      "authorization_endpoint": "https://loadsamoney/consumer/auth",
>      "description": "loadsmoney personal customers",
>      "logo_url": "https://loadsamoney/consumer/logo.png"
>    }
>  }

It assumes only 1 piece of metadata (authorization_endpoint) is brand-specific, but none of the other 50 (eg ui_locales_supported, op_tos_uri, scopes_supported, …) from 4 different specs currently listed in the metadata registry<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata> (not to mention the ones in draft specs not registered yet).
It offers 1 logo (in one size/resolution/format/colour-palette/…) and 1 description (in one language), which is likely to be totally inadequate so the suggestion is probably only a fraction of the actual complexity required.


If you want to build a “chooser” user-interface allowing a user to, say, pick between multiple banks & brands then that needs a solution quite distinct from AS metadata.

If you want to allow a client to reuse 1 dynamic registration across multiple brands, could you compare the “registration_endpoint” in each brand’s own AS metadata (being careful a malicious AS cannot trick the client into sharing the client’s creds from a victim AS). Or how about an “associated_issuer” member holding an array of issuer identifiers. If issA & issB each list each other in their “associated_issuer” metadata, then a client registration at either can be used at the other.

If you merely want to trigger a different look-n-feel, define a “brand” parameter to add the to the authorization request.

--
James Manger