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

Brian Campbell <bcampbell@pingidentity.com> Wed, 20 January 2016 22:19 UTC

Return-Path: <bcampbell@pingidentity.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 8CC6B1AD371 for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 14:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 DuEEvenT-y41 for <oauth@ietfa.amsl.com>; Wed, 20 Jan 2016 14:18:59 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 B310C1AD36F for <oauth@ietf.org>; Wed, 20 Jan 2016 14:18:59 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id g73so35991533ioe.3 for <oauth@ietf.org>; Wed, 20 Jan 2016 14:18:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W7FxT5RGxHq5GBAZgZ2Ho6oxrmy98cn8JKIFheY6PPY=; b=OeYA0ZyE2jT51rFP6zxtAPtmwnidVHaeuBiMfjVmy63Dj8HdB4acQDkngESphr1sza fQNF2iM15KWJWjBI4D2jOMpfIpoU+jnBbySYrtbpU1HNfR7aSE5FWu1CfuneQmneRPDl /4V2Pa25ywmsJWobqnKVBwWFmVnaYa4XyKNuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W7FxT5RGxHq5GBAZgZ2Ho6oxrmy98cn8JKIFheY6PPY=; b=R37VL7lcKLc+G+JBqV1UYyRQxjCQRYbVYAaz0jKNG+I68m44KOclq/TW90MarCsnKd aEF4GE7f7j4WoCa1T9L8I1T/QscjIaUDaPGqVf/WXldkJCegTJn3jHkPVDSuMADelT3A YfWuTLuHbEJJsLi6aiPS9YSIFREYvgy1kIZ9kXbHFlHq3zvswOA7tisADPyt74Bz7Oeo h+tsUt7SITBEaQuIOWeH8p3vqaoBCHZVlJ/4HnygeNGg56FHSbV2oYoVkdYyuiR3Evbx 1bFaisp7Vow30cY9Vmzs50y8TgGbCPwKGwD2efyfEzQL160VP1HwXtj4A2VX1JBL5wxZ CLzA==
X-Gm-Message-State: ALoCoQk3LJTXqievI92iSq9SO9Oy1PDnr451VcugbJX7/u9LdrCCRmI9oNYE0ZmqLDA8ZHYpPJIPbnkwknuXLmCdzvV1fB8fUhAwPi16zi3bAF1dHTn29Qc=
X-Received: by 10.107.16.226 with SMTP id 95mr39808662ioq.147.1453328339032; Wed, 20 Jan 2016 14:18:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Wed, 20 Jan 2016 14:18:29 -0800 (PST)
In-Reply-To: <569F9955.9030001@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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 20 Jan 2016 15:18:29 -0700
Message-ID: <CA+k3eCTzX+DkuEzb5XdTxtouOgkdMfZxp=Ue4ZvDJLf0wCFdPA@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="001a113ecda063f6bc0529cb5f09"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/wVJnYIlpG2xK8AdO3KD5hZXU0gI>
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: Wed, 20 Jan 2016 22:19:01 -0000

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> 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
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>