Re: [OAUTH-WG] draft-hardt-oauth-mutual-01
Dick Hardt <dick.hardt@gmail.com> Tue, 16 January 2018 21:25 UTC
Return-Path: <dick.hardt@gmail.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 54CE112EB24 for <oauth@ietfa.amsl.com>; Tue, 16 Jan 2018 13:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FJaqSzU4hwv0 for <oauth@ietfa.amsl.com>; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61CC12E3AE for <oauth@ietf.org>; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id t5so4242551pfi.0 for <oauth@ietf.org>; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1RCQI9wn7yB5d0e+SJCqTS5JsfLgwKIkA0z9qvmKpL4=; b=WwUBhTvgpe3K4Yv7jv+28geDlzvqhS8hpgnLnDSx4rlKZr59mCyfQX6u7YBJXAVZ7n dDVM52APbXsObztNLFiG3r1lrblEcBkTn6HStHwN+SWnhEF9WSQDHEGjVeI5PB2L026M ZRxk6Seu+BlHgamlFEarwqy8l8+HD53scoNpYAt8J3Yx74AmFVuqlx2P+C1QIThLORKn vBKoPGbRJeQPpvaVQjt6OSFen7QtQz7Has0wKl9by4YCrWgb4LEHNbWgHEY/aw1FAJeM Gy8Wf/WzWK82yxaCm2pAhlLLpyYf8o3ltoi2rWnWI7j0PulA05bG5DmZpjdoRRFa6CHf hO2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1RCQI9wn7yB5d0e+SJCqTS5JsfLgwKIkA0z9qvmKpL4=; b=cDSv0yVV+dh5hl6cY5jhrlon7K9raxbp05mQJIdETWzNr5Icx9wHm+rs76/DDfBRtJ wxifOF36ANtbRqb7QJdmZLoaimq8rGgYCIbvWTEEJVOpIBfy3PA7R1UTzuMk1huI1Ww0 HcYpiM3CRjnu8L/p37g1ETBZNUFkO293BIYaMFJRJA7u+XN6eDcmctaQaQnVOP/nO+Ls 0RSYN/Y5rc2iN+3mtYau5y6rzZJe6DfrVxtZ4MRgym+0R2bsFsWlJHGhukcUBWciv0V0 0zdlS/zim3cUCuzKmlMC+7+mWFljV6b9ODchaaIvTyp5n86qSHqzfhTnofhI8uqIaA7z LChQ==
X-Gm-Message-State: AKwxytc5jP8OrBnPpr1b4yvg4659LuX0qbjlIefSiP/2mKyc8tiUHuFG Pb96COz3N3HHOmphIHubFpspT4KfA4O0vTWLelo=
X-Google-Smtp-Source: ACJfBoswzP+GxE559bNGRV2rwihujXsf765CjDKHhA8ROAGcsR/dL8DMy30SPgPgLpTksyrlLLr7Hbn4d56CD0hEciI=
X-Received: by 10.98.162.10 with SMTP id m10mr10385705pff.168.1516137934274; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.143.133 with HTTP; Tue, 16 Jan 2018 13:25:13 -0800 (PST)
In-Reply-To: <CA+k3eCQQe-cpywqkfoO6=dhr6vLxmu6Z=pJfGWcy7eOPVCy42g@mail.gmail.com>
References: <CAD9ie-t3RduyvdB7_YMa8f-t9EWvKw8fHNdQfvhYbCpttiHjCg@mail.gmail.com> <fa362c26-8b1a-6f21-d4fa-8bd8fa9fba76@gmx.net> <CA+k3eCQsn=0M8pCv+6MhKQ0d8jgFpOXgLG+8DAscd9PE4XRmPw@mail.gmail.com> <CAD9ie-s-K-BmH3NkZOj0kJ9E4kktoDZXwwhjmVApWobf9+3D+w@mail.gmail.com> <CA+k3eCQQe-cpywqkfoO6=dhr6vLxmu6Z=pJfGWcy7eOPVCy42g@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 16 Jan 2018 13:25:13 -0800
Message-ID: <CAD9ie-uLHn_O-_cZEhJ56CsBOe8aW==ty8pq2ZgfOF2Pa1joFQ@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="f4030437dbcc00c7a30562eb5f1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gT5QnlLGlIxd1Tewwni3QuJZJ9k>
Subject: Re: [OAUTH-WG] draft-hardt-oauth-mutual-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Jan 2018 21:25:36 -0000
Comments inline ... On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote: > > *On client_id:* > With the authorization_code code grant (sec https://tools.ietf.org/html/rf > c6749#section-4.1.3), the client_id is "REQUIRED, if the client is not > authenticating with the authorization server as described in Section > 3.2.1." And Section 3.2.1 (see https://tools.ietf.org/html/rf > c6749#section-3.2.1) kinda describes why it is required for > unauthenticated clients: > > "A client MAY use the "client_id" request parameter to identify itself > when sending requests to the token endpoint. In the > "authorization_code" "grant_type" request to the token endpoint, an > unauthenticated client MUST send its "client_id" to prevent itself > from inadvertently accepting a code intended for a client with a > different "client_id". This protects the client from substitution of > the authentication code. (It provides no additional security for the > protected resource.)" > > So it's there to let the AS detect code substitution and protect public > clients from it. I don't think that the same situation applies to the code > that's created and pushed with this reciprocal flow. > The client_id is linked to the access token for reciprocal, and to the client secret. The client_id let's the AS know which secret it should be comparing, and to verify the access token really does belong to the client_id. Is there a reason you would NOT want to pass the client_id? > > > > *On the response:* > The extension grants section (see https://tools.ietf.org/html/rf > c6749#section-4.5) of OAuth says, > > "If the access token request is valid and authorized, the > authorization server issues an access token and optional refresh > token as described in Section 5.1 <https://tools.ietf.org/html/rfc6749#section-5.1>. If the request failed client > authentication or is invalid, the authorization server returns an > error response as described in Section 5.2 <https://tools.ietf.org/html/rfc6749#section-5.2>." > > So I'd sorta expect the reciprocal code grant to try and comply with those > responses. Mostly for consistency and, while it doesn't exactly fit, for > what is already there like error codes. Or give more detail about why it's > doing something different and how different looks (like the response body). > But maybe that's overly pedantic and just 200/400 are enough. I dunno. > But it is not an access token request, and I think having it look like an access token request will be confusing to developers. It is the opposite of an access token request. This really is a back channel version of the Authorization Response https://tools.ietf.org/html/rfc6749#section-4.1.2, which of course has no response codes. /Dick
- [OAUTH-WG] draft-hardt-oauth-mutual-01 Dick Hardt
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Hannes Tschofenig
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Brian Campbell
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Dick Hardt
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Dick Hardt
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Brian Campbell
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Dick Hardt
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Brian Campbell
- Re: [OAUTH-WG] draft-hardt-oauth-mutual-01 Dick Hardt