[Txauth] Questions on the TxAuth charter
Kim <kim@identityblog.com> Tue, 28 January 2020 00:57 UTC
Return-Path: <kim@identityblog.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD523A0784 for <txauth@ietfa.amsl.com>; Mon, 27 Jan 2020 16:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=humanpresent.onmicrosoft.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 vfCYYYnw3mAR for <txauth@ietfa.amsl.com>; Mon, 27 Jan 2020 16:57:39 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2097.outbound.protection.outlook.com [40.107.236.97]) (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 124153A0777 for <txauth@ietf.org>; Mon, 27 Jan 2020 16:57:38 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ir5eC+c5YGn4iUzI/xDEeIHNhmuvUfm5RPNVkT7ulbfzahaj5YYIYIu13J7A5Y9Oz8LoaIGaTRWa/taINrBgLOoTrlJ+1bYnDMs85Z6tR+za+DuRrQpXMeukTalwlCd99uxRMu7rSscOui8keH9QWrFztWSKMkaMcDudXspq72/90afZhmkSmy8+B17+W66srVJ0RNjIQ+grFjkMEqWDILbay/VAqfPPQ9jEIFh6G+JRvOFebBNMnBuxB0NTyI8mtUQQ2fclMK9VGXs31XMa3OF95pS96SFMmiux/BxmM4nqH8s0oZjcv3f0b/xxbS7MxB+GsmPTnm1MJpz4CU9upQ==
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=1yY+KMZjiJpv/0VRk8iQEhwTH7OTTNRpFRclNbeoEME=; b=iAerjCUPzmJbUVzwUQKM9rrjYMGXSpVwob+yaivLsUnfWpjg6Dn4FbI7en2ZX2RQp7I7O1HPj914NRwAPxVfJZktmF+0JkTBcStUA2WgafKrlvOgEzUE/U2ZKvkM+SVVDJWkFLl1p2JW/Dyw07AmnYJXR2eoxEqIiLQNM6h2JEqU/a+bcL19pVJ+7J6bkwRpHdK/xZtsaN3KKBaN2hyamtvIj8VeYlUb2rTZRD7BaMlF93wUBPPKn6DzRuCJB5N31bhVWvjqQqGQko/4dsaxoCheNf74jmeyiv0gfkgECTWUcbzlUvX2PIZ5DkXSPxCZGvKZZToSwy690oVNegUabA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=identityblog.com; dmarc=pass action=none header.from=identityblog.com; dkim=pass header.d=identityblog.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=humanpresent.onmicrosoft.com; s=selector2-humanpresent-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1yY+KMZjiJpv/0VRk8iQEhwTH7OTTNRpFRclNbeoEME=; b=jA7Vg7IZdLIw4MbL+g9/GRQl+PFzDQHWHejXef57rz/hR260+D/dlCg1NuZwB8RYDfYKvZ0R2LHDVGesaEWW2yZf0GT0XaeZO47KN/TAohVSTuTPKNGQ2smwxLyMjeqhClvAHEOdeE2QPBa5YtLLXxVm/q2ezBknvWVrF6OYL7g=
Received: from MWHPR1601MB1280.namprd16.prod.outlook.com (10.172.98.11) by MWHPR1601MB1182.namprd16.prod.outlook.com (10.172.102.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Tue, 28 Jan 2020 00:57:36 +0000
Received: from MWHPR1601MB1280.namprd16.prod.outlook.com ([fe80::3452:f8ca:1662:552e]) by MWHPR1601MB1280.namprd16.prod.outlook.com ([fe80::3452:f8ca:1662:552e%11]) with mapi id 15.20.2665.026; Tue, 28 Jan 2020 00:57:35 +0000
From: Kim <kim@identityblog.com>
To: "txauth@ietf.org" <txauth@ietf.org>
Thread-Topic: Questions on the TxAuth charter
Thread-Index: AdXVdev1XhtwHfEhQu6tUSp4GGwQ5g==
Date: Tue, 28 Jan 2020 00:57:35 +0000
Message-ID: <MWHPR1601MB1280C9D00C71F4335FC172EECA0A0@MWHPR1601MB1280.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kim@identityblog.com;
x-originating-ip: [172.58.139.60]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b91f2466-1376-41f1-67f4-08d7a38d1092
x-ms-traffictypediagnostic: MWHPR1601MB1182:
x-microsoft-antispam-prvs: <MWHPR1601MB118279D103ECB337E500D4CECA0A0@MWHPR1601MB1182.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029651C7A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(39830400003)(136003)(346002)(396003)(376002)(366004)(189003)(199004)(2906002)(6916009)(508600001)(55016002)(7696005)(6506007)(186003)(33656002)(26005)(9686003)(316002)(8676002)(81156014)(52536014)(81166006)(5660300002)(66556008)(64756008)(66946007)(66446008)(66476007)(86362001)(71200400001)(76116006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1601MB1182; H:MWHPR1601MB1280.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: identityblog.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AhVhCXpLW0nVtNIS8vI9ERe3u7msRwoWjnKh7XKl9uLQqGBOBrhKT+f6lW9ss36Mph+sSiq2nZCSDzBOm/uUGSZEr1al/vRvnHOb3nIkrzUOm04a0wmXoznT8LhfFu9cnB9BTnIWaBgJ+W92ZYsMXs6xh5gf5ple9VQCouZL4mznhshIHx+dCzhSVHYm/Gex5SbecbkUDx0Z/M2VoHydu6ouyom47I2/aULFRgQmnrczruA+7OjyHs8k8hAtdE8/Y+6qyMbIg5o5qec6pavsvkoa3S4EI8fSOwHVUNFjeM7z2eFdhhFrhKhn1T6MMLvqi2TSZuwaqhxoIPdoHeUy8PDeJVk5fRCnGJ9B0a9sDnu/FjnVW1lJbutMG2nNxcLIIp1qs+PI20VHvWqO3HYoWfGiHTs+4t1wgMe/6aqwqrJwbfjOoyPLM6pzABk/C5G9
x-ms-exchange-antispam-messagedata: 8Wq2XDwML+8+2HCvg2nUPfUTJij0a+oYIZqcb9GgxCzJ5lSdxuxgzOlZWxn9jsx+n4VMNLxOJs8P7JxHMqmsUR3tMqn17glZh2chvuKteWnuSiaf1WXeR4Txo5LPTOGTYEIQw1WYm36uDR8KUH/DOg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR1601MB1280C9D00C71F4335FC172EECA0A0MWHPR1601MB1280_"
MIME-Version: 1.0
X-OriginatorOrg: identityblog.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b91f2466-1376-41f1-67f4-08d7a38d1092
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 00:57:35.8841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c3439b4d-884a-42b8-8e49-94af41f1b711
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: T2uFbjDNY2Q75OimRE4DCWFtHtI0+DCCyCs7GioB6qR01RpQe7rG9f8gxg6B8Ec06HLiyfnAK0l1TP0EqmkxNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1601MB1182
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE>
Subject: [Txauth] Questions on the TxAuth charter
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2020 00:57:41 -0000
Dear Justin, The current wording of the draft charter raised questions for me that others might share. Clarifying these would help those of us not familiar with the work to date. > This group is chartered to develop a delegation protocol for authorization, identity, and API access. Can you please expand on what you mean by delegation of identity and whether that leverages claims and tokens as defined in OpenID Connect? > The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0. I understand and support the motivations to rework the authorization flows. However, the identity representations in OpenID Connect have already shown themselves to work well in conveying the identity of the end user. It seems prudent to avoid the confusion and complexity that would result from introducing new mechanisms to do the same thing. Will the enhancements to the authorization leverage what already works and has become a unifying technology? > This protocol will allow an authorizing party to delegate access to client software through an authorization server... > The client and AS will involve the authorizing party as necessary through interaction mechanisms indicated by the protocol. What is the authorizing party? Is that one of the roles in the protocol? Is it the end user? > Approval of AS attestation to identity claims Does this mean that the AS is approving of the claims and conveying that approval to another party (and what party would that be)? By identity claims are you leveraging claims as defined in OpenID Connect? Are the identity claims about the end user - or other subjects as well? > Mechanisms for providing user, software, organization, and other pieces of information used in authorization decisions - Could you elaborate on what information about users would be supplemental to those expressed as claims? Also, would information about software and organization be expressed as claims? > Optimization of information and API access beyond identity through the delegation process Could you please explain what is meant by this goal and how it relates to identity? Thanks! Kim Cameron