[OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 24

Panca Agus Ananda <panca70@outlook.com> Tue, 02 December 2014 20:15 UTC

Return-Path: <panca70@outlook.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4A7951A7014 for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 12:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wDGFvssZya5o for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 12:15:23 -0800 (PST)
Received: from BLU004-OMC4S7.hotmail.com (blu004-omc4s7.hotmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3441A701C for <oauth@ietf.org>; Tue, 2 Dec 2014 12:15:03 -0800 (PST)
Received: from BLU406-EAS110 ([]) by BLU004-OMC4S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Dec 2014 12:15:02 -0800
X-TMN: [hf0zbC64OdCpDlUc5rQJjPQ+P1vXuI/n]
X-Originating-Email: [panca70@outlook.com]
Message-ID: <BLU406-EAS1105CFC26EA544C7D0A9BCCA67A0@phx.gbl>
Content-Type: multipart/alternative; boundary="_b9d4fddd-a6b6-4cbb-a00a-42e6ded2d50c_"
MIME-Version: 1.0
X-Client-ID: 509
X-Mailer: BlackBerry Email (
Date: Wed, 03 Dec 2014 03:14:58 +0700
From: Panca Agus Ananda <panca70@outlook.com>
To: oauth@ietf.org
X-OriginalArrivalTime: 02 Dec 2014 20:15:02.0594 (UTC) FILETIME=[A7AA0A20:01D00E6C]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-StZAeeA-OTShQk_p1uLAJXu_hI
Cc: Outlook Traveller <panca_assaaf@yahoo.com>
Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 74, Issue 24
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: <http://www.ietf.org/mail-archive/web/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: Tue, 02 Dec 2014 20:15:25 -0000


Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Rabu, 3 Desember 2014 03.00
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest, Vol 74, Issue 24

Send OAuth mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."

Today's Topics:

   1. Re: Review of draft-ietf-oauth-introspection-01
      (Richer, Justin P.)


Message: 1
Date: Tue, 2 Dec 2014 19:56:35 +0000
From: "Richer, Justin P." <jricher@mitre.org>
To: Bill Mills <wmills_92105@yahoo.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
Message-ID: <EA29FCAC-B690-40D3-A6EF-345F4483856E@mitre.org>
Content-Type: text/plain; charset="us-ascii"

Agreed, which is why we've got space for the "sub" and "user_id" fields but not anything else about the user, and we've got a privacy considerations section for dealing with that. If you can help make the wording on that section stronger, I'd appreciate it.

 -- Justin

On Dec 2, 2014, at 2:25 PM, Bill Mills <wmills_92105@yahoo.com<mailto:wmills_92105@yahoo.com>> wrote:

If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake.

On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." <jricher@mitre.org<mailto:jricher@mitre.org>> wrote:

That's all fine -- it's all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token.

Can you explain how this is related to "act on behalf of"? I don't see any connection.

 -- Justin

On Dec 2, 2014, at 2:09 PM, Bill Mills <wmills_92105@yahoo.com<mailto:wmills_92105@yahoo.com>> wrote:

Fetching the public key for a token might be fine, but what if the introspection endpoint returns the symmetric key?  Data about the user?  Where does this blur the line between this and "act on behalf of"?

On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." <jricher@mitre.org<mailto:jricher@mitre.org>> wrote:

The call to introspection has a TLS requirement, but the call to the RS wouldn't necessarily have that requirement. The signature and the token identifier are two different things. The identifier doesn't do an attacker any good on its own without the verifiable signature that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.

 -- Justin

On Dec 2, 2014, at 1:40 PM, Bill Mills <wmills_92105@yahoo.com<mailto:wmills_92105@yahoo.com>> wrote:

"However, I think it's very clear how PoP tokens would work. ..."

I don't know if that's true.  POP tokens (as yet to be fully defined) would then also have a TLS or transport security requirement unless there is token introspection client auth in play I think.  Otherwise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/6392a329/attachment.html>


Subject: Digest Footer

OAuth mailing list


End of OAuth Digest, Vol 74, Issue 24