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 0C08B1200B8 for ; Mon, 22 Jul 2019 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 uX8_1VTQDfCg for ; Mon, 22 Jul 2019 14:46:32 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 223841200B6 for ; Mon, 22 Jul 2019 14:46:32 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id b29so20531073lfq.1 for ; Mon, 22 Jul 2019 14:46: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=ho2Fnu9EaXFdQ94b8Hn+NLR1dQ6LIb6YPviowWxH0G4=; b=cjNQQez8JB6m6ls80nh8vNDfh69qU4FycJnBcgk/0flgqb5nVnuumP9kv8uLpKS2o0 iy3QPdwNYVQnIH6X/R/lDERB6/eePAB1owfcXCknEv2ovl/AtDi2uzB5CcYArxICGYkz kjtxIAKY07jZV+duMM0Qu4abzwJF4ejYv+4qKBUigh7rhw+Zwnu+TaEF/C4GubAlHY0+ IlLejJRmFcSgnlhNkKauOdUNe3OXtQe0DDL7GcqgwZrLUfzxm9M91aTRFnHSGaLas4mm OXZ8QWhN3Cd+1x70on4ZSmce1iUGWGUftsCCjXUkUicBXBTOuHz9Vq1lkfMoJ8MyIReg k+YA== 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=ho2Fnu9EaXFdQ94b8Hn+NLR1dQ6LIb6YPviowWxH0G4=; b=AUkE9zvc4KlVds41fAXXpcsqZ7mib8sse+wh9hBOwgogmDhtMgS4ZIXxcpvb7UnKEe hwSe7xMRzb0xm+QAVvPBP4uJW6rYbLj+thG6wBXrlo4R/jga9LAgg/8yfYOsMkJFXyXH ijGpZIXhwLjQAMyeg+T02r7BKJ3wnCVRj87NpBL41BgyNn5zkB3XfRODKqkqmBji1di/ eQ2CBN7uUpNNBm4a7tiR9eJIsgxxSOp10OuJPsc7zCRVxx5oCGthXHFOmmwKR1kRITFt c9kN/EqGPwGz2RPIM1WNno0BQHvU+V8r1NycU58foSnrG/fQ1ybIiwGcaZYk1VuYtM+F fckg== X-Gm-Message-State: APjAAAUjrSTdVKq77cjhAl/q4aygBz3IvQApJWnZfyMZGyOV/t1072aG K3w3owGt4yQjoe1fcWuety65aWNC8ptiMyTMoG4= X-Google-Smtp-Source: APXvYqzaqugvwY8LLQFmf7qULIZXzJMxwU2mOWAebj2vocHd/zxPYZBFHnvee2lAWRm8wo4vdLjrFM+1lsO/ERn2WpA= X-Received: by 2002:ac2:546a:: with SMTP id e10mr33651854lfn.75.1563831990256; Mon, 22 Jul 2019 14:46:30 -0700 (PDT) MIME-Version: 1.0 References: <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> In-Reply-To: <06AF6986-B2D2-4B00-B8DA-0DB2F7C1FA8F@forgerock.com> From: Dick Hardt Date: Mon, 22 Jul 2019 17:46:19 -0400 Message-ID: To: Neil Madden Cc: Aaron Parecki , oauth Content-Type: multipart/alternative; boundary="000000000000448906058e4c02e5" 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 21:46:35 -0000 --000000000000448906058e4c02e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil I see that you are looking at how to modify Justin's proposal, and I'm looking at what are the requirements. Ignoring the specifics, is there a reason why multiple tokens need to be returned in the same request? On Mon, Jul 22, 2019 at 9:41 AM Neil Madden wrote: > > On 21 Jul 2019, at 22:22, Dick Hardt 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 th= e > userinfo endpoint), or else we already need to return a second access tok= en > 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 > wrote: > >> If we=E2=80=99re going to redesign OAuth, one improvement would be to al= low a >> client to request different access tokens for different resource servers= in >> a single request. That should include issuing a different access token f= or >> 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=99= s 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 >> the access token that contains the user ID and userinfo endpoint, such a= s: >> >> { >> "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://oauth.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 >> > > --000000000000448906058e4c02e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil

I see that you are looking at h= ow to modify Justin's proposal, and I'm looking at what are the req= uirements.

Ignoring the specifics, is there a reas= on why multiple tokens need to be returned in the same request?
<= br>

On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <neil.madden@forgerock.com> wrote:

On 21 Jul 2019, = at 22:22, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Neil, I a= gree that an access token that is usable across resources is problematic.
How are you thinking multiple access tokens would be retu= rned?

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

{
"tokens&= quot;: [
=C2=A0 =C2=A0 { "resource": "https://res1", "access_token&q= uot;: "..." },=C2=A0
=C2=A0 =C2=A0 { "resource&quo= t;: "res2", ...}, ...
]
}

I'm not particularly wedded to any format.

Why do you think the req= uest needs to return multiple tokens rather than making a separate request = for each token? That would seem to simplify the request and response as con= text 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, wh= ich indicates a userinfo endpoint that itself needs an access token. So eit= her the same access token is used to access that userinfo endpoint (which m= eans 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.:
=
{
= =C2=A0 =C2=A0=C2=A0=C2=A0 "access_token": {
=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0 "value": "UM1P9PMHKUR64TB8N6BW7OZB= 8CDFONP219RP1LT0",
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "= ;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.co= m/user/5035678642",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo_at": "b0D= l3KsXXOGc7tWfFLZYv7G5bXk"
=C2=A0 =C2=A0=C2=A0=C2=A0 }
=C2=A0 =C2=A0=C2=A0}




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 woul= d be to allow a client to request different access tokens for different res= ource servers in a single request. That should include issuing a different = access token for the userinfo endpoint vs other RSes.=C2=A0

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

<= div dir=3D"ltr">=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 thoug= hts on a potential addition to this draft, specifically around returning so= me minimal user information in the transaction response.

The summary of the suggestion is to return a new "user" ke= y along with the access token that contains the user ID and userinfo endpoi= nt, 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 &= quot;value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "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&quo= t;,
=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 "userinfo": "htt= ps://authorization-server.com/user/5035678642"
=C2=A0 =C2=A0=C2= =A0=C2=A0 }
=C2=A0 =C2=A0=C2=A0}

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


Th= anks!

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

--000000000000448906058e4c02e5--