Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

Brian Campbell <bcampbell@pingidentity.com> Wed, 25 November 2015 15:30 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 2A5641B2E24 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 07:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Level:
X-Spam-Status: No, score=-1.368 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, T_REMOTE_IMAGE=0.01] 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 uXkcdnLufBQY for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 07:30:36 -0800 (PST)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 EB7A81B2E20 for <oauth@ietf.org>; Wed, 25 Nov 2015 07:30:35 -0800 (PST)
Received: by igcph11 with SMTP id ph11so95785360igc.1 for <oauth@ietf.org>; Wed, 25 Nov 2015 07:30:35 -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=nQgMMwZ9cwM3O9DJPeBTeDbX+vpvFJh8n2JfUMjwoPo=; b=Xy4VzriTeFdz/HTP7HusBhwUP4uoL2OjgSb56pE4rACw8G497ud4Q501Ij+lanfWss Yw4xs2fEQGxe6lcCpNX6eRIK9+dPlOj73TWJ1tDV3/11hxtQSEO7A+7w7/u15VJ9bVU9 EuG49tdXlJ7Fs56uy98fqJeZoYok4aKjmsVIg=
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=nQgMMwZ9cwM3O9DJPeBTeDbX+vpvFJh8n2JfUMjwoPo=; b=F4s52hzNBG5Bp+1uHIULqoi72cnXKqC69N/XRRP96x/uIFJUNggOVsPjWzcm9DYgI+ BlP1pJh9SM5+OubmE+bRzY8HyTox8Lfh6p4um87I9ejpfTdyrztfbCmQWpWfZrr1wmtl 1dA8Beci5jNVPfPOVaWK0O8ncVu9AJGju9T5Gd0KZEZr+gfxoB7CsG6BDYkVVVZ6Sj5P J+bLjPWR3EO4hleVo7SKQf+k6HZmcDQEZ0HDSfjMWhj1boFjAiYCsp/v+Rh41EKlTTp5 lk3JptcQ0qaXK/N13l9OWaNIRAU5FXJ7rSUXB+vjZAd/0gnKY/PDt6DS2zgCXFpZgRt3 MOFw==
X-Gm-Message-State: ALoCoQl4YHkQNgQ5DZNr0i8vdmRjXVBGvTktHMxPrBosIX5hFN2cHYGoZ8MUz8iFGnDurIpfK8F+
X-Received: by 10.50.143.10 with SMTP id sa10mr4804859igb.77.1448465435328; Wed, 25 Nov 2015 07:30:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.23.133 with HTTP; Wed, 25 Nov 2015 07:30:05 -0800 (PST)
In-Reply-To: <F787FB76-5C8D-45F5-8A81-E430E75A0455@oracle.com>
References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <F787FB76-5C8D-45F5-8A81-E430E75A0455@oracle.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 25 Nov 2015 08:30:05 -0700
Message-ID: <CA+k3eCSeOyc2HMY+sK9rSjxkSAvNPWqwKyJNjDZAaCu2Stqk=w@mail.gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary=001a1135fe9abe432705255f2363
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/SU0Bd2e-QkSje4Vto0swzroDfTc>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt
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, 25 Nov 2015 15:30:38 -0000

Looking at the diff I noticed the following new text, which seems to
conflate bearer/PoP and opaqueness to the client. A client demonstrating
proof-of-possession of some key is orthogonal to the client being able to
parse and understand the access token itself.

"In contrast to bearer tokens [RFC6750] which call for tokens that are
opaque to OAuth 2.0 clients, this specification defines the requirements
for proof-of-possession ("PoP") tokens that may be parsed and verified by
OAuth 2.0 clients and relying parties."

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

> This draft addresses review comments from Kathleen and Erik raised since
> the last draft.
>
> It may not include some of the discussion from yesterday/today.  I will
> add that as the group decides.
>
> Cheers,
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol Working
> Group of the IETF.
> >
> >        Title           : OAuth 2.0 Proof-of-Possession (PoP) Security
> Architecture
> >        Authors         : Phil Hunt
> >                          Justin Richer
> >                          William Mills
> >                          Prateek Mishra
> >                          Hannes Tschofenig
> >       Filename        : draft-ietf-oauth-pop-architecture-06.txt
> >       Pages           : 23
> >       Date            : 2015-11-24
> >
> > Abstract:
> >   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
> >   allows any party in possession of a bearer token (a "bearer") to get
> >   access to the associated resources (without demonstrating possession
> >   of a cryptographic key).  To prevent misuse, bearer tokens must be
> >   protected from disclosure in transit and at rest.
> >
> >   Some scenarios demand additional security protection whereby a client
> >   needs to demonstrate possession of cryptographic keying material when
> >   accessing a protected resource.  This document motivates the
> >   development of the OAuth 2.0 proof-of-possession security mechanism.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > 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
>



-- 
[image: Ping Identity logo] <https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: twitter]
@pingidentity Connect with us!
<https://www.pingidentity.com/>[image: pingidentity.com]
<https://www.pingidentity.com/>
<https://ping.force.com/Support/PingIdentityCommunityHome>[image:
pingidentity.com] <https://ping.force.com/Support/PingIdentityCommunityHome>
[image: twitter logo]
<http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
<https://www.linkedin.com/company/21870> [image: Facebook logo]
<https://www.facebook.com/pingidentitypage> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: slideshare logo]
<http://www.slideshare.net/PingIdentity> [image: flipboard logo]
<http://flip.it/vjBF7> [image: rss feed icon]
<https://www.pingidentity.com/blogs/>