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 1676E1204AB for ; Fri, 19 Jul 2019 23:41:52 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 pvLe3GEUVfMC for ; Fri, 19 Jul 2019 23:41:49 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 34CA8120043 for ; Fri, 19 Jul 2019 23:41:49 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id x4so34172243wrt.6 for ; Fri, 19 Jul 2019 23:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oChL7lCjw31cGLyyUuU8o9HriH/oipkyEUx42wLxTR8=; b=SVxhG39GwuHnYaqkwAASTRz1iAn8ijaA/d6qUydr8aVJ5aoyuyvx696sjAljYg1ISL IFwUg9yKaTmdDrPj3p+WTLb/CCnAnXiUOQOuNzQggNyAuRarNwg5Aznpm6hroAITStZ7 3Rf534xXQCezjsAUMmwhDoutE5jTIaFvdyePw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oChL7lCjw31cGLyyUuU8o9HriH/oipkyEUx42wLxTR8=; b=RsWf5hoQouSmTauwRYmb+e+kVdapFKVwPDp+hpYjQcOYgem5ivENwj8YkNQ9BPUHAi a0iT9VW1Gi17mnDhrEHaSAPVtXArmHqghb4NEw2Zkyc2dfRJbWQegKAeqH3iujz5u5X2 zvkEMjGZVunNqqh5qHO9CCHnm2IOqwj2d3REkFLnop59nPnZkwpLR6SMrHovkm21evJG 6lrCGubijgpnwgrDNm4C7JqimiKMY+DZzzZ10DCU8vR0T3dv0dTOuMG9snOHnccaq7AB YJBiMSoVPN/pc0JCe9LvYMz5pjBFX3RggvTGeO+uU6bPanwLHIRbVOx80DcQHpepQBzF cM8w== X-Gm-Message-State: APjAAAXPpMmsriww1gacORkRPSyitIbClcZrsaLHSrxIP4vVa32IfyPU 8Ne1JMOZ9V/9h7gx3YbcvKxWRw== X-Google-Smtp-Source: APXvYqxmSSnq5CQORXXSzEA9ooZgGLjnvmXQ/3qpnCLegYrggiAXe7DQQ8Y50vpbeVSY6kXnp8VeNg== X-Received: by 2002:adf:f246:: with SMTP id b6mr32807356wrp.92.1563604907622; Fri, 19 Jul 2019 23:41:47 -0700 (PDT) Received: from [192.168.1.65] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id v65sm34031691wme.31.2019.07.19.23.41.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 23:41:46 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Sat, 20 Jul 2019 07:41:46 +0100 Cc: Justin Richer , oauth Content-Transfer-Encoding: 7bit Message-Id: References: To: Aaron Parecki 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: Sat, 20 Jul 2019 06:41:52 -0000 --Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 t= he userinfo endpoint vs other RSes.=20 One of the weaknesses of combined OAuth + OIDC use now is that if you reques= t OIDC scopes and scopes for another resource in the same request then you i= nadvertently give those other RSes access to the user=E2=80=99s profile.=20 =E2=80=94 Neil > 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, specifi= cally around returning some minimal user information in the transaction resp= onse. >=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 th= is 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 pro= ject) 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://oa= uth.xyz/=20 >>=20 >> I plan to be in Montreal for the whole week, and I=E2=80=99ve requested f= rom the chairs that I present during the Tuesday session due to limited avai= lability 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 --Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If w= e=E2=80=99re going to redesign OAuth, one improvement would be to allow a cl= ient to request different access tokens for different resource servers in a s= ingle request. That should include issuing a different access token for the u= serinfo 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 p= rofile. 

=E2=80=94 Nei= l

On 20 Jul 2019, at 01:02, Aaron Parecki <aaron@parecki.com> wrote:

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

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

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

    {
   &= nbsp;  "access_token": {
        "value": "= UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
      &nbs= p; "type": "bearer"
      },
    &n= bsp; "user": {
        "id": "5035678642",
&n= bsp;       "userinfo": "https://authorization-server.com/user/503567864= 2"
      }
    }

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


Thanks!

----
Aaron Pareck= i



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


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 av= ailability 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.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-0B17E3CF-F0BB-4B9D-BCFF-D35A05AE4C54--