Re: [OAUTH-WG] draft-ietf-oauth-rar use of “WWW-Authenticate” Response Header

Brian Campbell <bcampbell@pingidentity.com> Fri, 26 May 2023 18:24 UTC

Return-Path: <bcampbell@pingidentity.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 80991C151B23 for <oauth@ietfa.amsl.com>; Fri, 26 May 2023 11:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=pingidentity.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 iVoF3RjYdhDS for <oauth@ietfa.amsl.com>; Fri, 26 May 2023 11:23:58 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F94FC151B0F for <oauth@ietf.org>; Fri, 26 May 2023 11:23:58 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1b021cddb74so1993515ad.0 for <oauth@ietf.org>; Fri, 26 May 2023 11:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; t=1685125437; x=1687717437; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3smkm1IfeqtrDp8K82RqxX59RhGP4Obp1EZhqRXf0sg=; b=HF4s7EpZcYlJeY2EER+wf9iy/rpycBJ/qEF8eTq3BHQwquA/mxl4hoan8ibcYT/+Mk tVsyG0Uq5QJ8ZSMzN4bKrj8kEXB1cSfrvSOtuhPRnoht3FyQSYBGzzpIoo9LcDN2hWK/ yLIOUmWZlCjrznoFQpMRe9LAqDrtJ+W/TA3TNrAxfY+G6wFCXv5vqpzrAG9xHUtBu+Zi 7pyFImPk5sp+mJsg/iqvoqYQoNzoGxeaMrvDGOrwIw/8hTz6GqsLc3e3q09RmBFLfuN+ yW0j5sZc1jFWR+KT64gcRp9llzloQHApIr8WHvsSpcKP8XQqFNVwBM/BwtkHSiu3dPD+ t6zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685125437; x=1687717437; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3smkm1IfeqtrDp8K82RqxX59RhGP4Obp1EZhqRXf0sg=; b=jTk35uLSHl4jN4oujYbKq/4Fd/6JHWbnoG967t/Ckuoh1OCYKi8FtimTTPEPqNPtQU /c0d3pGrgF4XaTwypDQ93wxIsyvt7bVHVEqaijQZKZZeHnOhNmxdo60fcgfMeR008W2q Ic7Ih/f/X4ssHGA/bA9toodZxO10e3rUV6seD08niXUgJIQUZqKazgaZP98+VgbL8zt5 h1o5E3a693m3hr9mbfqjcbJQoQIxql8vRgHh0u636fBOOKmRiqtQeRaL23R/9nnQBe6X WUd0MeD/lImyEY/Q5FKpbiHeUhgJbVstmlhE/Jd9ECDVkXQlE9PDoQmyVa6j86/bHzTG 6EOw==
X-Gm-Message-State: AC+VfDwsECUmAyXKEVcw5AJHflLQnWMchk1asyPM3JEImTevfX1iVXee WqDmdaESFYb8aTQcHzCAbmqkbcEvlVJJ01GjwTtSLXoT6JHZS6vSak/mPlwAKrPyxO5v6BfnTs5 x6wdiEfy8IfAaLb3ELcD9uOoT2qA=
X-Google-Smtp-Source: ACHHUZ77ki7dZbiefhUGo91Y+TYm1Q8ba0oE08dZABaUkmd0e0kQBDnSEBs1981oHqYADcZd2eGCF/rPypzLtNva6gU=
X-Received: by 2002:a17:903:1cf:b0:1a9:40d5:b0ae with SMTP id e15-20020a17090301cf00b001a940d5b0aemr3277210plh.12.1685125437102; Fri, 26 May 2023 11:23:57 -0700 (PDT)
MIME-Version: 1.0
References: <41869F2A-F0B1-4409-8739-5BB3A820CBF6@santander.co.uk> <CA+k3eCTWLVns4dAL-ant4Qh_Ler_eYFTx9UBUB3Uv5L-+ZRn+g@mail.gmail.com> <0E64099F-0A54-4A56-A022-97A35D30C1D9@santander.co.uk>
In-Reply-To: <0E64099F-0A54-4A56-A022-97A35D30C1D9@santander.co.uk>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 26 May 2023 12:23:26 -0600
Message-ID: <CA+k3eCRciv_4nGyidG+Qn-3HoDAexUrPH2jqOhH9K12NhLsnmw@mail.gmail.com>
To: "Oliva Fernandez, Jorge" <Jorge.OlivaFernandez=40santander.co.uk@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000015164405fc9cd7bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ehBGpQQ_MW1vhJLxxM9onN0fjPE>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-rar use of “WWW-Authenticate” Response Header
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, 26 May 2023 18:24:02 -0000

There are certainly similarities between authorization details and scope.
And yes, both are API-specific to some extent. But scope is generally more
coarse-grained while authorization details can have lots of, well, um, very
specific details relating deep into the API. So much so that expressing
those details at the layer of the “WWW-Authenticate” Response Header didn't
seem needed or necessarily appropriate. I realize that's probably not a
satisfying answer but is my understanding of the consensus behind what
ended up in the document. Also the scope param of the “WWW-Authenticate”
response header apparently isn't used a lot in practice so there wasn't a
lot of interest/focus to continue with the construct. Note also that the
document is in the late late stages of the RFC Editors' queue
https://www.rfc-editor.org/auth48/rfc9396 so well past the point of
accepting significant changes. You could, of course, propose new work to
the WG towards this end, if you feel strongly about it. But the RAR
document is basically frozen now.

Regards,
Brian





On Fri, May 26, 2023 at 2:14 AM Oliva Fernandez, Jorge
<Jorge.OlivaFernandez=40santander.co.uk@dmarc.ietf.org> wrote:

> Thanks for the answer, Bryan!
>
>
>
> I’m not sure if I understand correctly, the authorization details are
> API-specific the same as the “scope” right? Let me know if I’m
> misinterpreting something but for me RAR is an evolution of the scope,
> because the scope parameter is not useful for complex authorization
> decision we introduce a new field, with a rich syntax to describe the
> operation that is going to be authorized, right? So, if OAuth define that
> the protected resource is able to indicate problems with the authorization
> bearer using the WWW-Authenticate Response Header Field, is not exactly the
> same case when a protected resource needs the rich authorization?
>
>
>
> Best regards.
>
>
>
> *From: *OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell
> <bcampbell=40pingidentity.com@dmarc.ietf.org>
> *Date: *Thursday, 25 May 2023 at 21:30
> *To: *"Oliva Fernandez, Jorge" <Jorge.OlivaFernandez=
> 40santander.co.uk@dmarc.ietf.org>
> *Cc: *"oauth@ietf.org" <oauth@ietf.org>
> *Subject: *[EXT]Re: [OAUTH-WG] draft-ietf-oauth-rar use of
> “WWW-Authenticate” Response Header
>
>
>
> *CAUTION:* This message is from an EXTERNAL sender – be vigilant,
> particularly with links and attachments. If you suspect it, report it
> immediately using the phishing button.
>
> The thinking was generally that params of WWW-Authenticate Response Header
> Field weren't a great fit for rich JSON authorization data (both in syntax
> and semantics).  The authorization detail types are really API-specific
> things, and as a result, it's expected that the methods by which clients
> obtain or generate the authorization details are also API-specific. Not
> sure that exactly answers the question but hopefully helps.
>
>
>
>
>
>
>
> On Thu, May 25, 2023 at 5:16 AM Oliva Fernandez, Jorge
> <Jorge.OlivaFernandez=40santander.co.uk@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> I have been reviewing the last RAR draft (
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-23) and I was
> expecting to find some references about how to use the “WWW-Authenticate”
> Response Header Field defined in RFC6750 (
> https://datatracker.ietf.org/doc/html/rfc6750#section-3) in this document.
>
>
>
> I think that RAR is a great idea for complex authorization where a “scope”
> is not enough to describe what you want to authorize, in OAuth 2.0 there
> exist a way for a protected resource to indicate what “scopes” are need it
> to consider the request “authorized”, should not be an standard way to do
> the same for rich authorization request?
>
>
>
> Best regards.
>
> Emails aren't always secure, and they may be intercepted or changed after
> they've been sent. Santander doesn't accept liability if this happens. If
> you think someone may have interfered with this email, please get in touch
> with the sender another way. This message doesn't create or change any
> contract. Santander doesn't accept responsibility for damage caused by any
> viruses contained in this email or its attachments. Emails may be
> monitored. If you've received this email by mistake, please let the sender
> know at once that it's gone to the wrong person and then destroy it without
> copying, using, or telling anyone about its contents.
>
> Santander UK plc. Registered Office: 2 Triton Square, Regent's Place,
> London, NW1 3AN, United Kingdom. Registered Number 2294747. Registered in
> England and Wales. https://www.santander.co.uk. Telephone 0800 389 7000.
> Calls may be recorded or monitored. Authorised by the Prudential Regulation
> Authority and regulated by the Financial Conduct Authority and the
> Prudential Regulation Authority. Our Financial Services Register number is
> 106054. You can check this on the Financial Services Register by visiting
> the FCA’s website https://www.fca.org.uk/register.  Santander and the
> flame logo are registered trademarks.
>
> Ref:[PDB#1-4B]
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
> Emails aren't always secure, and they may be intercepted or changed after
> they've been sent. Santander doesn't accept liability if this happens. If
> you think someone may have interfered with this email, please get in touch
> with the sender another way. This message doesn't create or change any
> contract. Santander doesn't accept responsibility for damage caused by any
> viruses contained in this email or its attachments. Emails may be
> monitored. If you've received this email by mistake, please let the sender
> know at once that it's gone to the wrong person and then destroy it without
> copying, using, or telling anyone about its contents.
> Santander UK plc. Registered Office: 2 Triton Square, Regent's Place,
> London, NW1 3AN, United Kingdom. Registered Number 2294747. Registered in
> England and Wales. https://www.santander.co.uk. Telephone 0800 389 7000.
> Calls may be recorded or monitored. Authorised by the Prudential Regulation
> Authority and regulated by the Financial Conduct Authority and the
> Prudential Regulation Authority. Our Financial Services Register number is
> 106054. You can check this on the Financial Services Register by visiting
> the FCA’s website https://www.fca.org.uk/register.  Santander and the
> flame logo are registered trademarks.
>
> Ref:[PDB#1-4B]
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._