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 36C33120147 for ; Sun, 21 Jul 2019 14:22:35 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 mQK0A0TrRCPd for ; Sun, 21 Jul 2019 14:22:32 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 75A20120098 for ; Sun, 21 Jul 2019 14:22:32 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id p197so25112762lfa.2 for ; Sun, 21 Jul 2019 14:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GtVzogqn8sc1eEqARXBQLIDQL0iVNrHpxNv/0qvWCuM=; b=se8ppmB2kkYkzz9BxDeIk9B+yPvUOmqrIp7wUAY3yM5XIkKVQCx6Jh/cz5Mm+J0RBq xutx6A+1F21pclmei/mS73pq3+n9aQWpef7Pe+oYSmzBI22Hr+mcq5vi4R73jDfbl8W1 nSYH/I0lWc2FP4iCB2ilz/0OcSUZoN41hCQtItZzs3dNI+7ExnXyaWvlpC5Hs0qLunKJ PHFVpWi3w6SOLYhGXxUnfSCSGMKhWOJQn5qe79/lpC53oiEn6TshMFsk4p+eCwjgok0U Aqosa6Si8rABDdjTlmNVnALE3jx0aolcfVMvJppqHFpCtlmcRR1LesFT6/AZpHRpHKfN QeBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GtVzogqn8sc1eEqARXBQLIDQL0iVNrHpxNv/0qvWCuM=; b=izO9pr7zQuwjruJ/2ioORZ06W32/a9iLAutuD5/MG/mNbfbBOMnn38mq5o6p5Bl6I3 kiFEPH5rC890R9sN6/gbe/JIDXQegV6LkHcjsf2MeTW4ExzbWqK/H/cvvX+2T4EzEeg7 a3OR5+50Wm7QJoFxl0BeGu3KgkIDU0btQHqF7myLv1F0DN0/axOVoKSlGzleuovILIGT /k+lU6KphdcvA8u0Bxk/rif1Y2tQOV0n8B2Rv38JBfV4lXVhVRq9ZlpGuqPWG6OiD9wc ngWyc8onNc1LPB4ROVgAzMlK1K30X8A1yFQ2zRIuRxqcQBWOA1HmaXpX4il1968urEOU WDNw== X-Gm-Message-State: APjAAAVme6TDv8lMIqQ0gwDO8Gt7sKgVtMnVswoSTjd4UR3uf12qGGI3 g8cyWwHfRiWPCQLi0RwAY5jaI6gjrdHdmucBpD7y+HfE X-Google-Smtp-Source: APXvYqw4if3s8pA9NNUh995Uv3Mk0Cke/VttiCc1LHqSnDivCfAXH5rtFvJMg3bM4jTYu4PV1T/l+q135/pdnopNQNY= X-Received: by 2002:ac2:546a:: with SMTP id e10mr30604368lfn.75.1563744150500; Sun, 21 Jul 2019 14:22:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 21 Jul 2019 14:22:19 -0700 Message-ID: To: Neil Madden Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="0000000000009c39e8058e378e44" 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: Sun, 21 Jul 2019 21:22:35 -0000 --0000000000009c39e8058e378e44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? 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. 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 all= ow a > client to request different access tokens for different resource servers = in > a single request. That should include issuing a different access token fo= r > 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 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 th= e > 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 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://o= auth.xyz/ >> >> >> 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. >> >> =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 > --0000000000009c39e8058e378e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil, I agree that an access token that is usable acros= s resources is problematic.

How are you thinking multipl= e access tokens would be returned?

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



On Fri, Jul 19, 2019 at 11:42 PM Neil Madden = <neil.madden@forgerock.com<= /a>> wrote:
<= div dir=3D"auto">
If we=E2=80=99re g= oing to redesign OAuth, one improvement would be to allow a client to reque= st different access tokens for different resource servers in a single reque= st. That should include issuing a different access token for the userinfo e= ndpoint vs other RSes.=C2=A0

One of the weaknesses of combined OAuth + OIDC use now is that if you re= quest 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 profil= e.=C2=A0

=E2=80=94 Neil
Hi all, I'm looking forward to the discussion on this on Tuesday!
I wanted to add my thoughts on a potential addition to th= is draft, specifically around returning some minimal user information in th= e transaction response.

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

=
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0=C2=A0=C2=A0 "access_token":= {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "value": "UM1P9PMHKUR= 64TB8N6BW7OZB8CDFONP219RP1LT0",
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 &q= uot;type": "bearer"
=C2=A0 =C2=A0=C2=A0=C2=A0 },
=C2= =A0 =C2=A0=C2=A0=C2=A0 "user": {
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0 "id": "5035678642",
=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0 "userinfo": "https://authorization-server.com/use= r/5035678642"
=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0 =C2=A0=C2= =A0}

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

=

Thanks!

----
Aaron Parecki



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 proje= ct) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99ve = uploaded a new version of the spec:


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

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

=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
--0000000000009c39e8058e378e44--