[OAUTH-WG] Feed back on draft-sh-rats-oidc at-00
George Fletcher <george.fletcher@capitalone.com> Fri, 28 July 2023 17:47 UTC
Return-Path: <george.fletcher@capitalone.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 13CBFC14CEFA for <oauth@ietfa.amsl.com>; Fri, 28 Jul 2023 10:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.604
X-Spam-Level:
X-Spam-Status: No, score=-14.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=capitalone.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1OV7xg88z98 for <oauth@ietfa.amsl.com>; Fri, 28 Jul 2023 10:47:31 -0700 (PDT)
Received: from mx0a-001b4101.pphosted.com (mx0a-001b4101.pphosted.com [148.163.151.254]) (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 66489C14CE2E for <oauth@ietf.org>; Fri, 28 Jul 2023 10:47:31 -0700 (PDT)
Received: from pps.filterd (m0264423.ppops.net [127.0.0.1]) by mx0a-001b4101.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 36SHUcYH004147 for <oauth@ietf.org>; Fri, 28 Jul 2023 13:47:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capitalone.com; h=mime-version : from : date : message-id : subject : to : content-type; s=SM2048Mar2022; bh=G+uy4/rLoLJxTwX1qewSXEudTSn+0cJhdvFjCaQNUXA=; b=iVHiWP3SjTbfqS6XEuAA5itH5nWiTsn0miVTEnzxO/Ai/GCv7HoiQkPfdUEHGdvhcfH7 EMQ9yYmwQ2hY5WnGeDZJa8Qa5nzys/TVLG2BvauT1oxHOIgJxtSpCeWl1QVRzg+5WCOQ OwEOskmbDyCt6RhifoWgOlMRXcLxEuq/grkBFXPvUhfYRfDOqWsGfKovx0fcY5HI4BdR XASCERvlR3WPu3ZUjNSnXs+AxJgE4yC9RgszPH2Qk3lz7MZi8sSysIR0p6fh5Ywv9CI4 nXBk+n4bOdOrex/liojWk8PXuEOk9sQJWA6jYdvPQEWRkDxxN0aJ9GxkOrKR62NwUsY0 ZQ==
Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by mx0a-001b4101.pphosted.com (PPS) with ESMTPS id 3s2r5p1c40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for <oauth@ietf.org>; Fri, 28 Jul 2023 13:47:29 -0400
Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-99bcf6ae8e1so129929166b.0 for <oauth@ietf.org>; Fri, 28 Jul 2023 10:47:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690566410; x=1691171210; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lTCBDWZ9ajvRM/UOCrUKFkO9yLhLjthbmGAnuP+sljM=; b=L4hWg0XblYAXPOJ6pCKcZCoCnftw+WpmcnJ9yWcmiHXHE4IgbivZfQTO/5Ndo9rKK6 51h8wc+NiATdX1/JzWeD1yKVTquOh+CgqjBCuw7Z5D2oQxhQF3aAOlG20wlrDGfNNUO4 siXaJ7le/GnuR49dWG9WGf9FUJsgcQ/qMCtzn4TwB7kzI07OPTsr8F4sVNXMfc9LNnxt /22MhAOEWmOwXx5S3UNs+14m3+8ymHIyLIOwzp80LzkUSYlh82C62txZbXCDiKTbRiiG bQmfvZ1HS/dZL/C8EEXeeiYkpp64nUid7Zjw+mbMPLEPcnkv2XRPw7LCyGdleDvK8eRg E/GA==
X-Gm-Message-State: ABy/qLYyPVEIjvwZNFT+fcuAWmkCq8xg5zMFBUHv6IUeug75EB4H2iWd 9Kzbh85pxSF/OKT8rE1LTSXN1g1eWz8O5RVl/Mm+uFgeCqdferFy5Fdn4uPrzvlp8vfTIfWgNj2 HSLOjIC8CNXyUDRbHzjADB2UWfGFLjQ==
X-Received: by 2002:a17:907:2c59:b0:99b:ef56:93c with SMTP id hf25-20020a1709072c5900b0099bef56093cmr60348ejc.39.1690566410378; Fri, 28 Jul 2023 10:46:50 -0700 (PDT)
X-Google-Smtp-Source: APBJJlGPFRRTfCJis1QgNDq+1VT4ydnPOeYIZV2Y4cmbwl/5L6QgSdsaByXT3yx3p0fNeX/FZJItX6t0+VjuZ6Fo5aA=
X-Received: by 2002:a17:907:2c59:b0:99b:ef56:93c with SMTP id hf25-20020a1709072c5900b0099bef56093cmr60337ejc.39.1690566410009; Fri, 28 Jul 2023 10:46:50 -0700 (PDT)
MIME-Version: 1.0
From: George Fletcher <george.fletcher@capitalone.com>
Date: Fri, 28 Jul 2023 08:16:30 -0700
Message-ID: <CAJnLd9+FRG7DfLK4xrFfVqKwrL0Bf5Y=2Rs4NsX_zmNt9qkhDQ@mail.gmail.com>
To: "Smith, Ned" <ned.smith@intel.com>, "hardjono@mit.edu" <hardjono@mit.edu>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000569e1b06018faae3"
X-Proofpoint-GUID: Cye0DxyAb8pQw-icWO1-5ic7j1EnIojh
X-Proofpoint-ORIG-GUID: Cye0DxyAb8pQw-icWO1-5ic7j1EnIojh
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-27_10,2023-07-26_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=1 malwarescore=0 mlxlogscore=999 adultscore=0 spamscore=0 phishscore=1 suspectscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=forced scancount=1 engine=8.12.0-2306200000 definitions=main-2307280162
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/WfqtwrTv7pfWnyxoQak1qsJ0w1g>
Subject: [OAUTH-WG] Feed back on draft-sh-rats-oidc at-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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, 28 Jul 2023 17:47:35 -0000
Hi Ned/Thomas, Thanks so much for the conversation at IETF on the potential value of combining the attestation work with OpenID Connect and OAuth. Given the spec references a lot of OpenID Connect artifacts, I’ve used OpenID Connect points in this response. However, from an IETF perspective, this would be connected to OAuth and the Authorization Server. It might be useful to map the work to OAuth directly and then let OpenID Connect (which is built on top of OAuth) to “inherit” the capability. As promised, here is some feedback on the presented draft… Section 2.1 * The userinfo endpoint is an API specified by the OpenID Connect protocol. It’s usually part of the OpenID Provider. Regardless it’s not a useragent/browser. Section 3.1 * userinfo (see previous comment) * End user (EU/Alice) is not an application. In OAuth the end user is called the Resource Owner. The application is called the ‘client’. So the Resource Owner uses the client to access the RO’s resources. * Relying Party - generally in OAuth/OpenID Connect the relying party is not looking for attestations. It’s looking for an authorization token to be presented by a client. In the case of attestations… it would be the OpenID Provider that would be interested in the attestations (in this context it may be possible to consider the OpenID Provider playing the role of a RRP). Section 3.2.1 * this isn’t really how the OpenID connect protocol works. In a general mobile app flow, the mobile app (aka the client) will open a browser to the OpenID Provider’s /authorization endpoint which starts the authentication/consent/authorization flow. Once the user has authenticated, the OpenID Provider provides a ‘code’ back to the native application which then exchanges that ‘code’ for the ‘id-token and access-token’ at the /token endpoint of the OpenID Provider Beyond this part of the spec I got confused on how the protocol is supposed to work and who the core agents are in the flow. A diagram would be really helpful showing the core steps. In my view, it’s more likely that the OpenID Provider will be the entity desiring an attestation about the client making the request. This could be just an attestation about the client software, or could also include an attestation about general characteristics of the device (e.g. is it jail broken or not). There are two main use cases… 1. The client is a mobile app in which case it may be able to obtain an attestation before starting the authorization flow 2. The client is a web service (or relying party) and the OpenID Provider wants some attestation about the software and environment in which that client is running. I suspect we can address both cases with the same flow. We might need an initial step for the client to obtain a nonce from the OpenID Provider before presenting the attestation so that the attestation can contain the nonce allowing the OpenID provider to know this is a fresh attestation and bound into the authorization process requested by the client. Thanks, George -- [image: Capital One] George Fletcher (he/him) Executive Distinguished Engineer • Identity Architect [image: address]8020 Towers Crescent Drive, Vienna, VA 22128 [image: mobile]616-498-8240 assistant: [image: email] genevieve.morgan@capitalone.com ______________________________________________________________________ The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
- [OAUTH-WG] Feed back on draft-sh-rats-oidc at-00 George Fletcher
- Re: [OAUTH-WG] Feed back on draft-sh-rats-oidc at… Smith, Ned
- Re: [OAUTH-WG] [External Sender] Re: Feed back on… George Fletcher