Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 21 January 2016 10:05 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03B31A21AC for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 02:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
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 8aNoE1JT4vaQ for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 02:05:06 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 E14841A1EFD for <oauth@ietf.org>; Thu, 21 Jan 2016 02:05:05 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id l65so212983832wmf.1 for <oauth@ietf.org>; Thu, 21 Jan 2016 02:05:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=2FSiGM+JXmRa8cmzR7iRRiUrOAkYiYh0WlH+8YVpaHs=; b=yuMJLNTn0QDPU9Q+pXbV/MnYW05arcPmAtISN5jNhfMpeirywf8+R78yl0vGSNhrig X4rl3vu8rzeU2otBYjAQbCBO/3J6bY/nLzAqXj5Gwcs4S6fJiz185dKa3QLzdNk/semT Z3Dex7YNzfV2lkGSyXYUGLG0AXV3OM28rNUnamc06CAnDl5yo5ToSFMWBevJjVG3p7Oy FjPyyRx5WkWtaxuYvq3tKJP+wq90vn1BZvT52wt03br1+Rb7Y7vaTHQeifxq0Yxltxup Xhs4QLui24pJm/doMvXYutqsPpiYkIbKoXqQOHKqRaXgUi+c3kfGQTTB52+PP3iU6JZo k63Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=2FSiGM+JXmRa8cmzR7iRRiUrOAkYiYh0WlH+8YVpaHs=; b=PVHLwbgx/LSczRVK5V/iG/a3ZTzFOdVjKjbARzdG3/foT9AXSKvdDA65ROljPPz94q wrc2G+SfxcCxD7yuEvntKqmE4wologIJgTqjJrU5paIKmhPKV/22U3/3hAWR7F4560wG FVWEUWKq6gcaNzHaFPS/uzc6PiuGw84QE1fIe4+PfuhJxNjrA3B0ldVc4xzZ50E9xcPV UqH2wVZug6uBqTc5JA9oUfAz4yYhJ7ikvZy+zdYJCVdF1yKCp98PBr/xVHUhN/oHc/jA P6a8qyy0tpFXqoeViLEO4FhDNlx8xmdjDMn6Necm8fIbpd40wkGQ+Cx9npCMV9JOcG6A Do+A==
X-Gm-Message-State: AG10YOQWzenrdVV7U8zImgG3Mq4GqzeaxbKRyG+sES+CDom0gl9y3irtm+zcyRF3JyJ6/g==
X-Received: by 10.28.175.147 with SMTP id y141mr8799781wme.64.1453370704449; Thu, 21 Jan 2016 02:05:04 -0800 (PST)
Received: from [192.168.2.7] ([5.179.70.21]) by smtp.googlemail.com with ESMTPSA id g3sm662036wjw.31.2016.01.21.02.05.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 02:05:03 -0800 (PST)
To: Brian Campbell <bcampbell@pingidentity.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <CA+k3eCSpWFwyvk=XHP4b_zxzu-zrMYsS-axF6csO90-ahmkueQ@mail.gmail.com> <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com> <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <ade5692aa1afa2d9d79b8ac7a55bf150@lodderstedt.net> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <A1C1786C-BE13-4D0F-9541-BEAE4DB8F284@mit.edu> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <CA+k3eCTzX+DkuEzb5XdTxtouOgkdMfZxp=Ue4ZvDJLf0wCFdPA@mail.gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <56A0AD4E.9050301@gmail.com>
Date: Thu, 21 Jan 2016 10:05:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCTzX+DkuEzb5XdTxtouOgkdMfZxp=Ue4ZvDJLf0wCFdPA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/yzI0OjIj8Nuer6_x3_2UfMuNdq4>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2016 10:05:07 -0000

Hi Brian

In our own code both authorization code and implicit flow requests can 
accommodate an audience property too.
You are right in the latter case there won't be a separate request to a 
token endpoint hence we are treating what follows after the user has 
authorized the implicit client as if it were a token endpoint request.

Not sure about using the audience property in the code flow but I guess 
it can be useful too - for example, the user may be shown this property, 
and then when the client requests a token and happens to supply an 
audience property alongside the code then this audience will have to 
match the one stored in the code grant data...

Cheers, Sergey

On 20/01/16 22:18, Brian Campbell wrote:
> There does seem to be a need to provide the client a means of telling
> the AS the place(s) and/or entity(s) where it intends to use the token
> it's asking for. And that it's common enough to warrant it's own small
> spec. This has come up several times before and I think has some
> consensus behind doing it. What needs to happen to move forward?
>
> The concept shows up in these three different drafts (that I know of
> anyway):
>
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3
> has an audience parameter
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
> has an aud parameter
> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has
> both an audience and a resource resource
>
> All the above apply only to the token request. However, there are ways
> of requesting/obtaining access tokens that don't involve the token
> endpoint <https://tools.ietf.org/html/rfc6749#section-4.2> so I think it
> follows that  the same facility should be available for the
> authorization request too.
>
>
>
>
> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
>     Hi Sergey,
>
>     that's a good question. After this document was published the
>     functionality had been integrated into the PoP solution document.
>     Recently, I got feedback that the functionality should be more generic
>     and it is independent of the PoP work.
>
>     So, I guess it is a good time to discuss the needed functionality and
>     where it should be included.
>
>     Ciao
>     Hannes
>
>
>     On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
>      > Hi
>      >
>      > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm
>      > wondering if it is still relevant.
>      >
>      > I know the token introspection response can provide the audience
>      > value(s), but the question is really how a client is associated
>     with a a
>      > given audience in the first place. As such [1] may still make
>     sense, for
>      > example, I can think of two options:
>      > 1. the client audiences are set out of band during the client
>      > registration time and all the tokens issued to that client will be
>      > restricted accordingly
>      > 2. the client is requesting a specific audience during the grant to
>      > token exchange as per [1]
>      >
>      > I guess 1. is how it is done in practice or is 2. is also a valid
>     option ?
>      >
>      >
>      > Thanks, Sergey
>      >
>      >
>      > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>      >
>      > _______________________________________________
>      > OAuth mailing list
>      > OAuth@ietf.org <mailto:OAuth@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>