Return-Path: 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 1F1BF1202B8 for ; Mon, 22 Jul 2019 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 XNhRxBDEjzCH for ; Mon, 22 Jul 2019 06:41:46 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 056E5120121 for ; Mon, 22 Jul 2019 06:41:46 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id h19so28819074wme.0 for ; Mon, 22 Jul 2019 06:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=01Uim3GuuaAzBWPDJbRwN6tiCLJOMiQbpiMGiUaEX/A=; b=Z4MdVCV6ei360dF1NsUFuSGo0SHrXZsQyLK+zMa8xWTWoJipwIuIn6gOzdsRjX1r/H iKy9icJdOcNrjYI8ZrPNBRtmlM8h2Vfcds81mQtGfYOXPmTs+OKZKTpAQpFB+IF8SVnU nmHuHGF0n+eoUJHTqARvXiWo5mCwaEX2Pu2XU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=01Uim3GuuaAzBWPDJbRwN6tiCLJOMiQbpiMGiUaEX/A=; b=QShyyjZQ5IOcDnu0IBPhqzHh5BTudKVtDpFAxwFWtMImZXpx4rCH7Q0cDYIJrNp4Bi kdKTpDcNohvbN3OG2JjWfc4ubMvA7MlylUL0Ug3KdiYD4QgDsgLrAU4iJIc4N6vczC9K qXTnHw9IXMry9L1seGvn8LTOkQDolTJjinrjW/YEva6xffiVY+nUJTtPuMu5LAU9YVmm 1dxjVvxC7U4H08/pSTGurmMQuKECyCFnoMBJpsRrCZzLDhbP4lE1qdhYQIojkIrZyXig gN6iTMLIpMSe7XEZWxbWmEjQwooqAWv87q5OuUVmjXgMkrbjFR0oQcePdjUJcZkkdGgN dPhw== X-Gm-Message-State: APjAAAX4svMQIY28V88S4l39QNa3pl/WO78VCiMDL8iWeNIPPC1M4PHD qhytT7ChWT+cR1Slx/T97BncRw== X-Google-Smtp-Source: APXvYqx765GuylfW5HtFICdmLxcqG7K5S1K4LpuNYWh7oNzWJdWqibjqh5vXhPfP8L0hoFTEpjuzcA== X-Received: by 2002:a1c:c545:: with SMTP id v66mr65493712wmf.51.1563802904395; Mon, 22 Jul 2019 06:41:44 -0700 (PDT) Received: from [192.168.1.64] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id f3sm23642206wrt.56.2019.07.22.06.41.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:41:43 -0700 (PDT) From: Neil Madden Message-Id: <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 14:41:41 +0100 In-Reply-To: Cc: Aaron Parecki , oauth To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Transaction Authorization X-BeenThere: oauth@ietf.org 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: Mon, 22 Jul 2019 13:41:52 -0000 --Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jul 2019, at 22:22, Dick Hardt wrote: >=20 > Hi Neil, I agree that an access token that is usable across resources = is problematic. >=20 > How are you thinking multiple access tokens would be returned? Well there are lots of possible ways, e.g.: { "tokens": [ { "resource": "https://res1", "access_token": "..." },=20 { "resource": "res2", ...}, ... ] } I'm not particularly wedded to any format. > Why do you think the request needs to return multiple tokens rather = than making a separate request for each token? That would seem to = simplify the request and response as context would only need to provided = for the one access token. Note that in Aaron's proposal we have a "user" section on (presumably) = every access token response, which indicates a userinfo endpoint that = itself needs an access token. So either the same access token is used to = access that userinfo endpoint (which means that the RS can also access = the userinfo endpoint), or else we already need to return a second = access token in the same request, e.g.: { "access_token": { "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type": "bearer" }, "user": { "id": "5035678642", "userinfo": "https://authorization-server.com/user/5035678642 = ", "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk" } } >=20 >=20 >=20 > On Fri, Jul 19, 2019 at 11:42 PM Neil Madden = > wrote: > If we=E2=80=99re going to redesign OAuth, one improvement would be to = allow a client to request different access tokens for different resource = servers in a single request. That should include issuing a different = access token for the userinfo endpoint vs other RSes.=20 >=20 > One of the weaknesses of combined OAuth + OIDC use now is that if you = request OIDC scopes and scopes for another resource in the same request = then you inadvertently give those other RSes access to the user=E2=80=99s = profile.=20 >=20 > =E2=80=94 Neil >=20 > On 20 Jul 2019, at 01:02, Aaron Parecki > wrote: >=20 >> Hi all, I'm looking forward to the discussion on this on Tuesday! >>=20 >> I wanted to add my thoughts on a potential addition to this draft, = specifically around returning some minimal user information in the = transaction response. >>=20 >> The summary of the suggestion is to return a new "user" key along = with the access token that contains the user ID and userinfo endpoint, = such as: >>=20 >> { >> "access_token": { >> "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type": "bearer" >> }, >> "user": { >> "id": "5035678642", >> "userinfo": "https://authorization-server.com/user/5035678642 = " >> } >> } >>=20 >> A more detailed analysis of the specific proposal and motivation = behind this is available on my blog: >>=20 >> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz = >>=20 >> Thanks! >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >>=20 >>=20 >> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer > wrote: >> I have requested time to present Transactional Authorization (the XYZ = project) at the Montreal meeting in a couple weeks. Ahead of that, = I=E2=80=99ve uploaded a new version of the spec: >>=20 >> https://tools.ietf.org/html/draft-richer-transactional-authz-02 = >>=20 >> Additionally, I=E2=80=99ve updated the writeup and examples on = https://oauth.xyz/ =20 >>=20 >> I plan to be in Montreal for the whole week, and I=E2=80=99ve = requested from the chairs that I present during the Tuesday session due = to limited availability of some key WG members on Friday.=20 >>=20 >> =E2=80=94 Justin >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 21 Jul 2019, at 22:22, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Neil, I agree that an access token that is usable across = resources is problematic.

How are you thinking multiple access tokens would be = returned?

Well there are lots of possible ways, = e.g.:

{
"tokens": = [
    { "resource": "https://res1", "access_token": "..." = }, 
    { "resource": "res2", ...}, = ...
]
}

I'm not = particularly wedded to any format.

Why do you think the request = needs to return multiple tokens rather than making a separate request = for each token? That would seem to simplify the request and response as = context would only need to provided for the one access = token.

Note = that in Aaron's proposal we have a "user" section on (presumably) every = access token response, which indicates a userinfo endpoint that itself = needs an access token. So either the same access token is used to access = that userinfo endpoint (which means that the RS can also access the = userinfo endpoint), or else we already need to return a second access = token in the same request, e.g.:

{
  =     "access_token": {
        "value": = "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =       "type": "bearer"
      },
      "user": {
  =       "id": "5035678642",
  =       "userinfo": "https://authorization-server.com/user/5035678642",
        = "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
      }
    }




On Fri, Jul 19, 2019 at 11:42 PM Neil = Madden <neil.madden@forgerock.com> wrote:
If we=E2=80=99re = going to redesign OAuth, one improvement would be to allow a client to = request different access tokens for different resource servers in a = single request. That should include issuing a different access token for = the userinfo endpoint vs other RSes. 

One of the = weaknesses of combined OAuth + OIDC use now is that if you request OIDC = scopes and scopes for another resource in the same request then you = inadvertently give those other RSes access to the user=E2=80=99s = profile. 

=E2=80=94 Neil
On 20 Jul 2019, at 01:02, Aaron Parecki <aaron@parecki.com> wrote:

Hi all, I'm looking forward to = the discussion on this on Tuesday!

I wanted to add my thoughts on a = potential addition to this draft, specifically around returning some = minimal user information in the transaction response.

The summary of the = suggestion is to return a new "user" key along with the access token = that contains the user ID and userinfo endpoint, such as:

    {
      "access_token": {
        "value": = "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =       "type": "bearer"
  =     },
      "user": = {
        "id": "5035678642",
        "userinfo": "https://authorization-server.com/user/5035678642"
      }
  =   }

A more detailed analysis of the specific proposal and = motivation behind this is available on my blog:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk



On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jricher@mit.edu> wrote:
I have requested time to present Transactional Authorization (the XYZ = project) at the Montreal meeting in a couple weeks. Ahead of that, = I=E2=80=99ve uploaded a new version of the spec:

https://tools.ietf.org/html/draft-richer-transactional-authz-02=

Additionally, I=E2=80=99ve updated the writeup and = examples on https://oauth.xyz/ 

I plan to be in Montreal for the whole week, and I=E2=80=99= ve requested from the chairs that I present during the Tuesday session = due to limited availability of some key WG members on = Friday. 

=E2=80=94 Justin

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_B227755C-60F1-4DCE-8E44-CA8F06D35C5C--