Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

Brian Campbell <bcampbell@pingidentity.com> Fri, 18 March 2016 22:05 UTC

Return-Path: <bcampbell@pingidentity.com>
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 A835712D684 for <oauth@ietfa.amsl.com>; Fri, 18 Mar 2016 15:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 DYto-vkqDmPU for <oauth@ietfa.amsl.com>; Fri, 18 Mar 2016 15:05:06 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 9273F12D5BE for <oauth@ietf.org>; Fri, 18 Mar 2016 15:05:06 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id av4so48649873igc.1 for <oauth@ietf.org>; Fri, 18 Mar 2016 15:05:06 -0700 (PDT)
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; bh=Vge5+OoHz4pZtCJetlqzs4epDVA6tzP5x/krTAbMqE4=; b=AV+AWjAr94/lpunlahKT4tquFCiVtqmF0CraBcHRGnGRkpypBv7zve9c05hKIx94hq u7IrXdOIrfQcFeL7Bcn1EKsnqtIm/i64oLE3vSRdHzBLCVLMx4rbQVDrPeoFwIjwKzbK 8Ei6fm6YiAnMnKEpHluNcLd7hJLz+p6GCBlPs=
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; bh=Vge5+OoHz4pZtCJetlqzs4epDVA6tzP5x/krTAbMqE4=; b=ZraQFSnqb75n1aRqkmmhttJ8IT9IVDBArVBoVN5kzqo8W5dXgSVYZoFlkf6wK0G5ze G8FbrE1ezQBdLhjyt4ctGTiPejE+j9Iq9zyKl4E2qZCbGRLFisTokjCWeLNK5MhvHtB+ 1TntaORwxqQfYLJHFP1tJRXwTbvoKpi7TkrciK+lhe0vx5yjIyPk2YWrg5aRAcfNU3Wx mcjP4qGJwXK0oQqrnKkhdl8iyUyhbC5x7op6xPDV+dUW8X2jcMAf7/qk/RL8y/27F0Vu stCSIsG3M1+641eePeyaVX0l8JHYW7mMMBwmrp3Vv7uUPqK1zCZDNGtJvIeWBmjmZzq+ 7HqA==
X-Gm-Message-State: AD7BkJLnzntJwu6NDQXtL9piK4U95Y7ajOFukXN+//JxEhoUEwMm5b2WmWwn7SEDvJPdEKXegm9FVdmYZlbbBcO3
X-Received: by 10.50.32.70 with SMTP id g6mr1634854igi.57.1458338705725; Fri, 18 Mar 2016 15:05:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 18 Mar 2016 15:04:36 -0700 (PDT)
In-Reply-To: <56EAEB54.8010208@aol.com>
References: <56EAEB54.8010208@aol.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 18 Mar 2016 16:04:36 -0600
Message-ID: <CA+k3eCQ-C+MuAV__JnPMJqeKWMn=Qe2yGB06qzpet=xx1xGZ0g@mail.gmail.com>
To: George Fletcher <gffletch@aol.com>
Content-Type: multipart/alternative; boundary="047d7b10ca55847b45052e59f064"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/f7MD2FBxfQ9ajXsuhQbGvCWECt4>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 18 Mar 2016 22:05:09 -0000

The "a. wrong AS /token endpoint" is the mix-up issue, which can be
mitigated by returning an identifier for the AS in the authorization
response. It is something that needs to be addressed but "discovery" or
metadata aren't needed and audience restricted access tokens tokens don't
help.

Maybe that's obvious but there seems to be a lot of confusion on all this
so I wanted to reiterate it.

On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher <gffletch@aol.com> wrote:

> Goals:
>
> 1. Help the client not send a token to the "wrong" endpoint
>    a. wrong AS /token endpoint
>    b. evil RS endpoint(s)
> 2. Allow good RS to determine if the token being validated was intended
> for that RS
>
> Other high-level goals?
>
> Use cases:
>
> 1. RS that supports multiple AS (we've had this in production since 2011)
> 2. RS rejects token not issued for use at the RS
> 3. Client that dynamically supports new RS (say any client that supports
> the jabber API)
> 4. Client that dynamically supports new AS
>
> Feel free to add to the list :)
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>