Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
Justin Richer <jricher@mit.edu> Tue, 25 October 2022 01:03 UTC
Return-Path: <jricher@mit.edu>
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 A5CAAC1522CF for <oauth@ietfa.amsl.com>; Mon, 24 Oct 2022 18:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
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 fLMYHpmVYvHl for <oauth@ietfa.amsl.com>; Mon, 24 Oct 2022 18:03:34 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 4EFF4C1522B0 for <oauth@ietf.org>; Mon, 24 Oct 2022 18:03:34 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 29P13RFK009772; Mon, 24 Oct 2022 21:03:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1666659810; bh=1rYpIem6vYxxBp1hz9EwX3NeBmJjkkKm7zSD9baLGMk=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=f2Ysb5LTTbxxTo/QkkxT07YgFUDu4XLFl0Gi+KnJo5rFwXZklMT/ieRIcZGFPFlfE 0TK33BXwaQ3VG7LIqic1wGcJIN+gTaKbE7r+Jdy/O8THko/CTcnEddgUcuF7YSsOX5 EQN9bwiZj7ZbupxHszCqIlr7iqO94/3JZuO+I+AQNnFM3Js5fo+dIgrQ7QRRMxr7bx +8w+ZhgvS4MNHqfZualTZybd/FMAq+bWIfsyrhsmmW2TQRCiLFROQUtJlstsMHNNiw Ardvg80bOvD9PnlhC2Bid9RtjFsSeo/W+mJNBLhxOd82fBlVn7jq3zyNAvRiWkTU/n h7vDuJVqMte7Q==
Received: from oc11expo16.exchange.mit.edu (18.9.4.47) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Mon, 24 Oct 2022 21:03:16 -0400
Received: from oc11exhyb5.exchange.mit.edu (18.9.1.110) by oc11expo16.exchange.mit.edu (18.9.4.47) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 24 Oct 2022 21:03:26 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.108) by oc11exhyb5.exchange.mit.edu (18.9.1.110) with Microsoft SMTP Server (TLS) id 15.0.1497.42 via Frontend Transport; Mon, 24 Oct 2022 21:03:26 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CC6JhiVSxiw8RDw82Aflerm/voz8R84eHHnH9pxMBqxXLDZoAPbHG+defWIAAELo4LnbP7Jx1qzvRM2Auyo9DO9chioKkgQu1ffg2QGqf/MNkadr/+0prF/khzYkNp+mMAMzUcCsd7P1Dsxl65+0k3xJhpEKXbbBYzHXczbsb7qubdQwEcvOdJ4nNiz8EixorGdeKI8hEVQdcKUHYYxBmaUaHnS/leBWxk3RbrT4dHO4F8TKT9NOBiSLuz+3Tqq5yNarsG1Y71QbsrBGamYB065qMw5d1AWL6cvZKmLnwtnyUmPmQF4hNSEUvQxB/vGSBouttx2Sqjw0oOqoaHhgCA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1rYpIem6vYxxBp1hz9EwX3NeBmJjkkKm7zSD9baLGMk=; b=bQQPsFvzVWb7/d9MLaq2kAZ5s3/bkOrsvq4v/AFxvEdPWCxn+R+9f9of+ZBJwPOOzi/1pLJP04dTh7kwgfAfNTCyxh2kSGg+1X9AH3tkfYpAtjJ9dDSKx02WeNP6TT6IX46wlgk8eGMgJS1x4jA+oBiItr6UAS6ZKtPKl9G0ZDEbS5S6ee252QLzv3hOtvPP7o2SKqUh6bPoODqmXirY+j9+/6fqvckGYTe/JJkOvyAs9gCsYj63Iuo1rNWEPYytxld9GVZ/OWrLYWSHFlllWsyEvdL6PqBTwjzfrovChQTwcFzDh2f9j5cYr2Y6JJcsabyBoutTtoK3GwrKYhyfaw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none
Received: from DM6PR01MB4444.prod.exchangelabs.com (2603:10b6:5:78::15) by BL0PR01MB4737.prod.exchangelabs.com (2603:10b6:208:30::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.21; Tue, 25 Oct 2022 01:03:22 +0000
Received: from DM6PR01MB4444.prod.exchangelabs.com ([fe80::9d85:53b9:9d56:e615]) by DM6PR01MB4444.prod.exchangelabs.com ([fe80::9d85:53b9:9d56:e615%7]) with mapi id 15.20.5723.032; Tue, 25 Oct 2022 01:03:22 +0000
From: Justin Richer <jricher@mit.edu>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
CC: "rdd@cert.org" <rdd@cert.org>, "oauth@ietf.org" <oauth@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
Thread-Index: AdjIiWV70TiGp2n1QyK+vwbKisrOXgaaBi8AASnDYJAACuzpgAASVPiA
Date: Tue, 25 Oct 2022 01:03:22 +0000
Message-ID: <B3CB2D48-3F6F-4566-96E0-3396C1913EDE@mit.edu>
References: <BN2P110MB110748BA202E467849E8A973DC469@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <EC76A798-8FA9-44D8-A508-952269CFB290@lodderstedt.net> <BN2P110MB1107CE072D8C7CB807D2D23FDC2E9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <8A472C89-AE85-4623-8656-B280F3DF197C@lodderstedt.net>
In-Reply-To: <8A472C89-AE85-4623-8656-B280F3DF197C@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mit.edu;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR01MB4444:EE_|BL0PR01MB4737:EE_
x-ms-office365-filtering-correlation-id: 1a5cdb8f-0f1a-4793-131a-08dab624b6b9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BVvqBWkt7W2yfBqiwofb4B7VWeORVQDcGKWBnzq+o8bA2m0Avuo8WG5gHIpA2D1cCQXCd0w/VkG/wyiCb9xoldZOTMOCgeFyv9WA0CZyHLfSk7cmITBu1BWJiYqZBVtcEz89I7nypPLl/I70AYlEtX0xFGUohwx0g3n207AlUetq73t9q89+d+QXqSnvMSsH7Pazor0rZWYM45RTHHsI68tdPV3CuSCFECtAmRGiJtcMgZtu9dsT9cD0YMoAOJmEbb6SlChPI25J7j01kwxIC9xtl1cJXkE8LTZR8AguNkH3JTIEcSZ8eQRDdu0zse/19GKEVgEquJ6b6u1/7ipRFY9H1jWxMDGgxyBTAH5R+t/TIO2BpsK1UNk/oQDDQbjbdFWNBNWNsE945vR353rCy2SPj8ho/YcqBZPRadoIATO6ged656TTavZuuTWmW7LCDL7+4xN7gNxZLCkuCXpmkdQznGyTUD2HGjUgW08VAUQ5X6mjzLkOD6IjhVhnvbhvk2HQ5ZF5T1jzom+vJ51KsQdp4Jza5xLbK+P4M/q/VdOW02+GePQC6WnKP9sNwiSXXGXFnVcgWi+3q+1I77WUCJzntRVguKrqVTKBCa20VlPB9FlAPfiGb+FRsnRdOQ1BCJmsUATnQrr/Ta1yJWylXghsg5YxnqLslcmxyHjIU9nxgU9p/RnE1Rm+4nUijW64O1ttTDvIofKKSqqLGhF075gITF1Rqwbi+gdM5A3AQGQ4AzAJq7sanNOgv6lLCGUSxUcTuvaP6dM7bI2wt5nYOk6nMibjoe28oGrcj9ymgCbzHVogWGwKn7Z5GQ9oyfXUy9FVi0W9K2nzMBY6cEuTAg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR01MB4444.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(451199015)(26005)(6512007)(122000001)(36756003)(478600001)(2906002)(71200400001)(966005)(6486002)(2616005)(38100700002)(166002)(86362001)(75432002)(53546011)(38070700005)(6506007)(83380400001)(33656002)(186003)(64756008)(66446008)(66476007)(66556008)(4326008)(66899015)(316002)(41300700001)(54906003)(786003)(6916009)(8676002)(8936002)(21615005)(5660300002)(91956017)(76116006)(66946007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: UW1wGG96HEBkDicvr79aK19rPNEQydHmxyUILQL0HDYTVMRLnWGoHpqAKQ6LIIJhvZsnHjzGA6ccCeRXAT54/8axzk5ND7enD6MTTY3FN3o1DELZMTWrqABAeH3GdU0Ebc2wdoI8IzBNXMykJaHSNg3rydb5551ACn3efoQtjr5K2ezdvpTwPzG8giqlvhqFlVGj9yNw+bGMBBJlmdelj2TWEWduj14pDr15WWpSp+rC1DLhbpnkk9/1OZeMIbGnKacrzF1U7TPgrn9jeJxu+mZfZNx64JD9IY0YqRsZApPbCjJ9S4++U4qynKjKlVGz086K+oq75tlrBXjeXjeBP98Xv718lzIdit1ODtnnQY5Lefzsr3iHZiHy3yWUF4jFr5EH49fKCkb62yPLDT+WhZoW6/lf9jKmIw1Pjs7sV7pkYEe6UdH6SamkTxzjRUbGFIPHNaw3PykJOXiMx0fDW4k4rIWDpgdC0OTeTtf3ZHe1uEwgAPyqfrcQBxdA4cdWYuoJEhUkh8PLEV4dQduugzc62yTGwEdF6QsCuno85qsyExraBBgZ9tHZJKI4SXfrtKbRDIW7d8y0FdBN2L0Q0lCb7uCVAZ+3gk15YSnpyLeT/dxDWX65GlmqpDtklnna86B8sjhmInE+An5hy6AmTquML6REquknVnLWvpebh57jm9kU4I2Fuxen1Hs2J5gbyFthuIYd7U76v9LdSMOinm2ZgRoETMuI7ocydz5TceIbWeDaz/gK3wjS/iFoOXXP5mzUpUhby3xEE3aL1rkWVs9hJ4ik7icWEG/IHYISNibAAr+XAl03ez7vI8GG3gCTp1zxobDThz/jYurSq0NQzl6G7FiVYnlHMrxHfTodllvCm2g2ktUluPz/ktpgaRLM/vGIcHu+HEGvWQHBoddo6SY5YElcw1mW1P0f++YMuhKUL8xstSLfh+tbmHpx2xeYOiABePZjPyfQ3RhKh8U8RRizXyHdoaUCBb6CyPCmkBMy8ospzSn4RIpfNa/mZTxWdm4S2d7Z8aeI2wWsbutfBYWXRSllV72nMinuzK1vqH1vjnsdUUS5WObINGJj6magzlJF6D9RGYdYAWk0Iyq5dd9qPruaGs0YBeeMjARrTKrQY6scm2UJ5WhITb4xInWtM/h7ncMOsxFXOsZO6Re57hBSvo4TG0CWM5ORP/YqIYmoKaIB7EImSJJtsOBCwnqu2Jy3IabQpcl2K6tP2Z16C83VzUy0BScTtOFWQSpjHyHC4MMan+uBIlIG/Y2rjyelfebnu9fWfkyDaykYFmFw+qG5zd5q351wt4s9QbfqR8Dp08A39ik3tlvt8lhfYUDkyIw5lMAQLAxS49NE9yHVF2SLPNXIwI1op8z8od/mfbbwWT0jAzW9AeWugW+0WZbZiLhEtu/3/X0avLvrOtp5FFNx6iMvsmph6CWT5gJ9HV+rPAdfHheVYP5EuiWgYn5vsdqVTP0ySz4vJf4qMJJjY2pyxRAs1KDjoZi1Fpfd+WN5zYCYrOT/zm3e5EhVQ86oGApv5MAdRexhgtG+bBLPbEgHBiGi7ddOu3j5x8sMYGgCP2qx6TVyv9OjyoNMPSkL
Content-Type: multipart/alternative; boundary="_000_B3CB2D483F6F456696E03396C1913EDEmitedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4444.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a5cdb8f-0f1a-4793-131a-08dab624b6b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2022 01:03:22.6537 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8V4aRIdnRumPT9QacesHysTXbP00oY6gWevAVLW2dGo0+E392B1ANUp4lIAXP6Ej
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4737
X-OriginatorOrg: mit.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2zu6rbpsskrXEV01eV-PFLDsR34>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
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: Tue, 25 Oct 2022 01:03:36 -0000
Thank you, Torsten! — Justin On Oct 24, 2022, at 12:18 PM, Torsten Lodderstedt <torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>> wrote: Hi Roman, I just published revision -14 with the all the agreed changes. https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html best regards, Torsten. Am 24.10.2022 um 13:07 schrieb Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>>: Hi Torsten! Thanks for the response. More inline ... -----Original Message----- From: Torsten Lodderstedt <torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>> Sent: Tuesday, October 18, 2022 9:00 AM To: Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org>; Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>>; jricher@mit.edu<mailto:jricher@mit.edu> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12 Hi Roman, thanks for you review. I’m trying to do the next round for the outstanding issues you raised. Am 15.09.2022 um 00:30 schrieb Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>>: Hi! I performed an AD review of draft-ietf-oauth-rar-12. Thanks for this document. My feedback is as follows: ** Section 2. Editorial This field MUST be compared using an exact byte match of the string value against known types by the AS. Consider if you want to introduce how the lack of match will be handled here - it is covered later. I’m not sure how to handle this as there is no direct consequence (in the sense of error condition) other then that different byte arrays constitute different types. We could state something like this: "String values with different byte representations constitute different types.“ ? Works for me. ** Section 2.2. All data fields are OPTIONAL for use by a given API definition. I don't follow how this is true in the general case. I was under the impression that this section defined what is expected to be common fields. Couldn't some AS with a particular type require their presence? ** Section 3. Editorial OLD In case of authorization requests as defined in [RFC6749], implementors MAY consider to use NEW In case of authorization requests as defined in [RFC6749], implementors MAY consider using ... ** Section 3. Typo. s/intiate/initiate/ ** Section 5. Typo. OLD authorization details type or authorization details NEW authorization_details type or authorization_details The spec uses authorization details types to refer to the general concept and authorization_details to refer to the parameter. I think the former is appropriate at this place. Understood. ** Section 6.1 However, when comparing a new request to an existing request, authorization servers can use the same processing techniques as used in granting the request in the first place to determine if a resource owner needs to authorize the request. Why is it possible to assess two arbitrary requests in this case to determine "if a resource owner needs to authorize the request", but the prior paragraph explicitly calls out that comparing two arbitrary requests is not feasible? To me is seems like comparing two requests to understand if more or less permissions are being requested is equivalent to determining if a new request exceed the current request to determine if going back to the resource owner is needed. ** Section 6.1. Typo. s/isaunce/issuance/ ** Section 7. If the client does not specify the authorization_details token request parameters, the AS determines the resulting authorization details at its discretion. The authorization server MAY consider the values of other parameters such as resource and scope if they are present during this processing, and the details of such considerations are outside the scope of this specification. This guidance seems to indicate the use of the scope parameter is optional in determining the authorization details. Section 3.1 says "The AS MUST consider both sets of requirements in combination with each other for the given authorization request." My read is that this is conflicting guidance and Section 3.1 is correct. Justin: „You aren’t required to use “scope” in order to use “authorization_details”, but we do want to say that the AS is allowed to (or even is supposed to) consider both “scope” and “authorization_details” when determining the resulting access for any given request that might have both. The guidance in 3.1 should probably say “the AS MUST consider all requirements present on a request” or something like that?“ Section 3 already states that the AS must consider scope and resource in addition to authorisation details. I suggest to drop that sentence entirely. Works for me. ** Figure 15. The text prior to this figure says that for "For our running example, this would look like this" indicating that this figure is similar to previous examples. There is one key different - this is the first use of a "payment_initiator" type with the API URL prepended. ** Section 7.1. Typo. s/sub set/subset/ ** Section 8. What is the difference between this section and Section 5 beyond this text explicitly stating the name of the error value (invalid_authorization_details). I'd recommend stating the normative behavior twice; that is, why are both sections needed? 5 and 8 define the error behaviour of different endpoint. But you are right, the text is the same (with 5 being even more detailed). Suggest to remove the text in 8 with a reference to 5. Works for me. Thanks, Roman best regards, Torsten. ** Section 9.2. Editorial. There is some kind of rendering issues in the RFC7622 reference. It reads "[!@RFC7662]". ** Section 11.2. Products supporting this specification should provide the following basic functions: Should this section be more tightly scoped to AS behavior instead of a "products"? ** Section 11.2. Accept authorization_details parameter in authorization requests including basic syntax check for compliance with this specification Why only "basic syntax checking"? Perhaps "syntax checking"? ** Section 11.2 One option would be to have a mechanism allowing the registration of extension modules, each of them responsible for rendering the respective user consent and any transformation needed to provide the data needed to the resource server by way of structured access tokens or token introspection responses. I don't follow the flexibility being described here. "One option ..." with respect to what? ** Section 11.3. Could this section provide an example of what it would mean to use JSON schema ids in the type value. ** Section 12. Please note that the Security Considerations of RFC6749, RFC7662, and RFC8414 apply. ** Section 13. Implementers MUST design and use authorization details in a privacy- preserving manner. I completely agree with the principle, but this design guidance cannot be enforced without specifics. I recommend s/MUST/must/. The more specific text in this section can use the normative MUST statements. ** Section 13. Any sensitive personal data included in authorization details MUST be prevented from leaking, e.g., through referrer headers. Is "leaking" the same as being sent unencrypted? Recommend being clear. ** Section 13. The AS SHOULD share this data with those parties on a "need to know" basis. Completely agree. Consider ending this sentence with "... as determined by local policy", or the equivalent to make it clear that it will not be document in this specification. Thanks, Roman _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] AD review of draft-ietf-oauth-rar-12 Roman Danyliw
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Justin Richer
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Brian Campbell
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Roman Danyliw
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Roman Danyliw
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Justin Richer
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Roman Danyliw
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Torsten Lodderstedt
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Brian Campbell
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Roman Danyliw
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Torsten Lodderstedt
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Justin Richer
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Roman Danyliw
- Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-… Justin Richer