[OAUTH-WG] Re: RAR's equivalent of insufficient_scope

Dmitry Telegin <dmitryt@backbase.com> Fri, 17 January 2025 13:45 UTC

Return-Path: <dmitryt@backbase.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 1E195C1DC801 for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2025 05:45:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=backbase.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 ky_OEBq9y_9U for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2025 05:45:21 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7AFC1E68DC for <oauth@ietf.org>; Fri, 17 Jan 2025 05:45:21 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-436281c8a38so14250185e9.3 for <oauth@ietf.org>; Fri, 17 Jan 2025 05:45:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; t=1737121519; x=1737726319; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=La2im0d3BFVQj5rdasTbLa9ksgL6ty/Flzf81p1wpzA=; b=Meoulkk3IiB9coIfAkomCVjm8JzBnQN1kgUq4KhFiCct+sGS7uKpyJql4Y9+Jpylf/ v3XXoaCHeBHdRFecL+CBA1TTHCw97qlMt5/1CeGTI5kJct27uvDVdBwC/GcXHnohmjnM C7xuYo81i9/xxiv9w7yoVAcXzfV8lfUJnOvqPnCDIACxIM6neSkwdVEP7LMcpAggC24I +4cpgp1P/kN+06D2P0O9hg5OWiFRyuFmTFt0xq1o+4tlILR2UyuqyY7vHPJwED10HKO9 wfy03SdM7FqQrzM6VF9FHj8oyl+P6FMDTF336wytpkl2DavpIyDXZVYBxZCGgd+eY5Z4 fF/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737121519; x=1737726319; 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=La2im0d3BFVQj5rdasTbLa9ksgL6ty/Flzf81p1wpzA=; b=qqIp6klJ3J7S18Xuq1jzpfiwmKBgFAz12mcPBNbOnI4lbE9sS3DsSEOk22ypAeAXcc t2RHzIjtuWncIFtWsskIjyM/sx9ZG16rdy72dqo7ZGgz5SCH0rqpaKeZHd/muUEWfkSp /FWBuArT/QvmoLnquGOcRBwG2C45R+WD+4E/SRUtREpaR6mUaZqrwBu8gMefHHyVShfZ SV5rEX9gYCYdY5x1rhMVj4jpUEE7pX8ZH946TYmkaR/C24deO+Si9bnrVL/IEPOsehZv 4K1AeAI98L8wEKqhPdmfdVNzTgcG1nfKYWFisYtIMnaw816W2k94yzYHVPXPl3vtKn/g iTxA==
X-Gm-Message-State: AOJu0YysGAW9nF8S84TkxBN62FzjbLmWizMCzJGRWp8tr7En+ns0VbFT cS7zp4vJkNGMl85itv5llmjxSrFmff0B0yw8Bfx/DXyE63/NKpE2IBDBV9HgR5WCWlTh0pRloMU MimA54LCzArXY8/O22r78DKkEU69mdI00oEQpeZEIdv0SgSA1OQ==
X-Gm-Gg: ASbGncsveMW1dWmPg/wZsbcGFS27KhURw3LUWpE/IXH3aayFoRl/wIFmquyvkT2oIbE w02hs/ylQtm8hC0RjhKcx48TwQI1wr8Cdgo8FAQ==
X-Google-Smtp-Source: AGHT+IG/fDyUSPf+b/iHY+3Z/MZcn1tKMGduSbpRA4g5JTLWaiEGgMCLldJPsihSBX9h+oazRcHYM/A/WsB25QA6vAc=
X-Received: by 2002:a05:600c:5112:b0:434:a5bc:70fc with SMTP id 5b1f17b1804b1-438913cfa0emr28527525e9.8.1737121519417; Fri, 17 Jan 2025 05:45:19 -0800 (PST)
MIME-Version: 1.0
References: <CAOtx8DmtKmk1kuvFMDTDfif_qKWu+buC1-ZtmH-dHjhPuHwkmQ@mail.gmail.com> <e18b71ac-cf3f-4735-babb-c9351f03b84b@connect2id.com>
In-Reply-To: <e18b71ac-cf3f-4735-babb-c9351f03b84b@connect2id.com>
From: Dmitry Telegin <dmitryt@backbase.com>
Date: Fri, 17 Jan 2025 13:45:08 +0000
X-Gm-Features: AbW1kvZQ7yiJl_j1c12aECXGA8MxMBUMTpQcFj6wqhJ68j-1IP0os_Xq2PSdQdY
Message-ID: <CAOtx8DmMaRo3neJHWk2ahf7WVvXif4GSAaD1PEhouYdde5eKLg@mail.gmail.com>
To: Vladimir Dzhuvinov / Connect2id <vladimir@connect2id.com>
Content-Type: multipart/alternative; boundary="00000000000018d731062be71f30"
Message-ID-Hash: 77FX3AUX7Q4Y3H7VKC4M2JGVODBDLL6J
X-Message-ID-Hash: 77FX3AUX7Q4Y3H7VKC4M2JGVODBDLL6J
X-MailFrom: dmitryt@backbase.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: RAR's equivalent of insufficient_scope
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5WN_6POIPX1XNNk-2Cv64z6G6Ac>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hello Vladimir,

The problem with "insufficient_scope" is that it refers not to the abstract
scope, but to the concrete "scope" token claim. The "scope" claim might be
fine, but the token might lack the necessary RAR authorization_details. And
yes, there is currently no way for the RS to communicate the requirements
on authorization_details. What I'm thinking of is the following:

     HTTP/1.1 403 Forbidden
     WWW-Authenticate: Bearer realm="example",
                       error="insufficient_authorization",
                       error_description="The access token is lacking
permissions",
                       authorization_details="..."

Dmitry


On Fri, Jan 17, 2025 at 7:32 AM Vladimir Dzhuvinov / Connect2id <
vladimir@connect2id.com> wrote:

>    insufficient_scope
>          The request requires higher privileges than provided by the
>          access token.  The resource server SHOULD respond with the HTTP
>          403 (Forbidden) status code and MAY include the "scope"
>          attribute with the scope necessary to access the protected
>          resource.
>
> "insufficient_scope" should be perfectly fine for "RAR-red" tokens.
>
> The error description is the token not having enough privileges, in the
> general sense.
>
> Do you need to communicate additional error info back from the resource?
>
> Vladimir Dzhuvinov
>
> On 17/01/2025 07:21, Dmitry Telegin wrote:
>
> RAR does not define it's equivalent of RFC 6750's "insufficient_scope"
> error response (could be "insufficient_authorization", for example). Is
> this intentional? If not, would it make sense to define it in a separate
> document?
>
> Dmitry
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>