Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

Vittorio Bertocci <> Wed, 15 April 2020 08:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61B453A0598 for <>; Wed, 15 Apr 2020 01:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cvOlC70wc7Rd for <>; Wed, 15 Apr 2020 01:39:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C4143A0597 for <>; Wed, 15 Apr 2020 01:39:08 -0700 (PDT)
Received: by with SMTP id z9so6391749pjd.2 for <>; Wed, 15 Apr 2020 01:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=jSZMNTEUFd8xkqv35Ah/sCB79Zhpkm/tv+NIRgmwX+8=; b=dBGonPUGn7YuMLSwR7+urKwTHhNH6m7Ym2UjsVXLgzibuKYxIE6uwHaZgoTY/LMB3I R6ZrvDqTmi8f5TJGEGesSmkasJ0EH6vLDtenceBX4VOYr5IERD+2v3YMXCtPCYSfDzJJ R0Y6QyESvZJth1b4tLTrCwk+09I3U/7wzKyUux6bphPYTZ0081OUPxolD5c+DDYzV6Kj n8RAyVWh6AbKsUvqbmBfjU53ccKdLhwy2aHlYmv/uVkPLIeQ0v9IPRmjN8nLOKA691Z+ 0XFLBp7MrlVhk035W67sEJprHJbrDbUQAHA6+deFl2pQz+l/bt6Qht1L302z/oSVDz2Q cBLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=jSZMNTEUFd8xkqv35Ah/sCB79Zhpkm/tv+NIRgmwX+8=; b=AxOR4OxJIvGTAU5HpO1LM6KyBrnPKWXzLVAxgYSiNt+7TDjP0n8/MHleYCJy6y60+q CTmh0BaDJh0mKKcKwR0MwxWmTOrqxPiWE3ptUOzeOvBmnWQsVEKkE7MLhdt+vCZ0yaHI xwxqkot2OAUxwhhKzncMB40X+p9N0IIlCSfK/jlUg1bInBzgaGqTOxYXeESV2dxgbbGe DHiy9C9ktAny1dKg70flGSMziJUWoBoZUM/CLroJuPkGgK1nle0Jv/Jnsy4fn4L10Ip7 fwuBMg7hUqn6NpGscneXW73tfyu4nuvY8i6lnB8OLURQapYC2OvV0tF0oMK6w/nQOp4t AklQ==
X-Gm-Message-State: AGi0Pub/oTRKGSVA5icZQxPvCvJ2wzXsvYxur5wKypT+5SavaPq2vibj B2GujQcPcnz1v5p7l4G05KOcxA==
X-Google-Smtp-Source: APiQypIXVAAs2cdhSu6EexiaW+oyWuOd9u1oxoUxbNEUekv2u+2UZQwwvMQum0VlWftMKPf/dGXolw==
X-Received: by 2002:a17:902:bc8c:: with SMTP id bb12mr3707065plb.13.1586939948190; Wed, 15 Apr 2020 01:39:08 -0700 (PDT)
Received: from ([2603:1036:120:1d::5]) by with ESMTPSA id w12sm6078865pfq.133.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 01:39:07 -0700 (PDT)
From: Vittorio Bertocci <>
To: "Manger, James" <>, George Fletcher <>, Denis <>, "" <>
Thread-Topic: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
Thread-Index: AWM0MTdh96WvNEQ1hTaMCLRLrdsz1zAwQ0Ux5DwM14CAABFGyw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 15 Apr 2020 08:39:07 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB1501454E0BBCD5523A9BBBFDAEDB0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Apr 2020 08:39:13 -0000

Thanks James!
If those scenarios would be an explicit target, then omitting the sub would indeed eliminate any chance of misinterpreting. However those remain fairly theoretical, and would already be pretty problematic in themselves given the need to get a new token per call in order to prevent jti based correlation- I don’t think it’s worth introducing in the spec the possibility to omit the sub, and risk not having it when it’s useful if it’s omitted by mistake in a mainstream scenario, to prevent a possible misinterpretation in a less common scenario.
If you feel very strongly about this, we can complement the warning in the privacy considerations in draft-06 to highlight this scenario- but honestly that seems overkill to me :)

From: "Manger, James" <>
Date: Wednesday, April 15, 2020 at 00:37
To: Vittorio Bertocci <>om>, George Fletcher <>om>, Denis <>fr>, "" <>
Subject: RE: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

> the AS could issue the 'sub' value as "urn:anonymous:<large random number>" and create a new value with every token that is issued

But it those cases it would be better to omit “sub”, instead of sending a per-token value (we have “jti” as a per-token id). That at least avoids other parties misinterpreting these unusual “sub”s as long-term ids (and, for example, creating persistent user entries for each one).

James Manger