From hannes.tschofenig@gmx.net Sun Sep 1 00:57:59 2013 Return-Path: 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 AB71011E81D7 for ; Sun, 1 Sep 2013 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-BSYoL-tvVN for ; Sun, 1 Sep 2013 00:57:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF08511E8126 for ; Sun, 1 Sep 2013 00:57:54 -0700 (PDT) Received: from [10.222.29.2] ([212.213.198.101]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Mb7lL-1VZV6Y0Bo3-00KcoV for ; Sun, 01 Sep 2013 09:57:53 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Sep 2013 10:57:23 +0300 Message-Id: To: oauth mailing list Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:VpMEFxMBV/UkMd7yLeoAxb92jZJJPV8pWclrIZ1otrr/9H888CQ Hxd1VPpMhSamFTVvkkjTK9Nv9BKuwHvIs2asnCPBaJ8n7lx8EQlamR3sqrbS1Ey6B0zTnrJ hkgSIJxJ1lhHp+3i9klhyK91pLc3v5gtzsTv8xasFf0xLvRtqFWxih4lskvwP1CriME8Rz7 4nuT4cu21lSKwVXe7/6sQ== Subject: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (28. Aug) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 07:57:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Here are my notes.=20 - - ---- Meeting Minutes ---- * Participants - - - Justin Richer - - - Hannes Tschofenig=20 - - - John Bradley - - - Tony Nadalin - - - Derek Atkins - - - Mike Jones - - - Phil Hunt (joined later) * Minutes Justin explained the document split with a "core" and a "management" = document:=20 http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00 http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 The core document defines the client registration endpoint with a = minimal set of parameters. The management spec defines extended meta = data useful for human-facing authorization. There is also the client = configuration endpoint defined.=20 It is a document re-structuring exercise. Justin explained what he considers the minimum set of parameters. The = claims that the minimum set of parameters have to be considered in = context of what flow you are using. He provides those details in Section = 2 of the core document.=20 The group started a discussion about assertion usage and Tony agreed to = produce a writeup to explain to others what it means.=20 Justin pointed to a mail by George on the list that Tony and the group = should have a look at. Here is the link: = http://www.ietf.org/mail-archive/web/oauth/current/msg12099.html Justin noted that the stateless registration use case is currently = described in the latest draft (in the core document, Appendix B.2). That = use case writeup was provided by John.=20 John said that we could add some more detailed examples of how it would = be implemented but it is a rather implementation specific detail, i.e., = authorization server internal aspects. =20 Justin stated that what we don't have yet is a complete e2e = interoperable description of stateless registration.=20 John responded that we could add that description to the use cases. The = problem is that some people take the examples as the only way to do it. = He said that we could compare it with the OAuth core, which does not = define what the access token is. That does not prevent us from defining = extensions using JSON and other formats. There are good use cases for = the different token formats.=20 John added that there is likely a need for a profile for how to do = dynamic client registration endpoints in a federation concept. That's = another step beyond the basic dynamic client registration.=20 John switched topic and raised a question saying that we have a lot of = disagreements about the software assertions. Some of us think that this = is isomorphic to the initial access token. Would moving that initial = token into a claim into the JSON object rather than content in the HTTP = header help to deal with some of the disagreements?=20 No response.=20 John asked Tony directly whether he is suggesting to re-use the token = endpoint?=20 Tony: Yes. That's what it is anyway.=20 Justin&John: But it is not OAuth protected in the same way since it = requires other credentials.=20 John: I don't see too much difference between the current approach of = the initial access token, which is an OAuth bearer token, and Phil's = proposal other than the type of encoding.=20 John: The client would only present the software assertion and no data = by itself?=20 Tony: Yes.=20 John: Would the assertion be signed by a third party or self-signed?=20 Tony: Could be both.=20 Phil: Some JWT that contains a number of claims would work. If someone = wanted to use existing set of claims then we have those in OpenID = Connect and they would be signed.=20 John: In the current spec the structure of the token is undefined and = left to the AS to decide. To have what Tony wants you would need to = define the structure of the token in case it is self-signed by the = client.=20 Justin: We defined this is in the BlueButton project. We defined various = claims and a discovery component (to avoid sending all the claims with = every request).=20 We are essentially using software assertions.=20 Justin and John talk about the structure of that token. Tony says that he and Phil is trying to write a document in 4 weeks time = that tries to be compatible but some other parts will not be compatible = because it replaces existing functionality (e.g., management).=20 Justin: Initially we didn't have the management functionality in there = but then added it after some discussion on the OAuth mailing list.=20 The discussion started about the stateless use case.=20 John: There are two aspects:=20 a) do you provide third party attested config info about a client? The = info that may be the same for each instance.=20 b) the information you get back could be stateful or stateless in the = second step.=20 Phil: I want fewer options. We have to lock it down somewhat.=20 Justin: I am confused about the optionaliality=20 Phil: At the moment there is little there. There is an OAuth token as a = bearer token.=20 John: The objection is more related to the options of OAuth.=20 Phil: The different types of apps need different features. For example, = mobile apps and Web apps are very different in the flows they need. My = use cases as a software api publisher are not solved.=20 John brings up the discussion about the software assertion as a question = to Phil in an attempt to define the details.=20 Hannes: We are running out of time; what are the next steps? Justin: we need to describe the use cases and have them written down.=20 Phil: We need two aspects:=20 - - way to express that an authorization server accepts requests from X = clients.=20 - - express that a client is a client from X Hannes: Let's not get into the details. We need to find out what the = next steps are.=20 Phil: What do you want? slide set, mail to the list, or a draft.=20 Justin: Ideally drafts.=20 Hannes: How much time do you need?=20 Phil+Tony: for a draft a month. Hannes: Will talk to Derek to see how to proceed; in the meanwhile = please work on the documents and try to get them finalized as soon as = possible. Will also think about future conference calls.=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJSIvNjAAoJEGhJURNOOiAtv4cH+wZeSPGH+Iiuetu6v+HY5YZ9 c0OOFT+U9birXEhXxo0T7mnTziUlqGUKOZ7b0cVRH4pCwcJ7Hqvt70NUs7bwMk/Z SAUNj4WnPCI3WKS8IjS9xV7PPD6bRwnWNoJdGHP3p0wZEvD7KWUbdrnhqC9RzVOc 1AvG1SeiM8GIeRzJI1erhVP01so1S1D65z7hBxi2QtsFgjRv+jWSMFjBx1QXH51k RKUvUJG+mqc88JXXl00EvthRD34Goe63GyyhghU9Uwf+KB1aPorI06wfQpyijGhF pK3VVncg5ZmlyKySpB0W9rDbI/Jz9KDrd6+LzCtD4zT71WaMN9h8sCRXCSEiDb0=3D =3Di/7t -----END PGP SIGNATURE----- From prateek.mishra@oracle.com Mon Sep 2 14:14:37 2013 Return-Path: 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 5E66C21F9EEC for ; Mon, 2 Sep 2013 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id telMah5W0N-v for ; Mon, 2 Sep 2013 14:14:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 645F221F9CBD for ; Mon, 2 Sep 2013 14:14:32 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r82LETHS016868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Sep 2013 21:14:30 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82LETrk010352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Sep 2013 21:14:29 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82LEShY000372; Mon, 2 Sep 2013 21:14:28 GMT Received: from [192.168.2.5] (/24.91.51.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Sep 2013 14:14:28 -0700 Message-ID: <5224FFBB.9050400@oracle.com> Date: Mon, 02 Sep 2013 17:14:35 -0400 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nat Sakimura References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010107080005010406050604" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 21:14:37 -0000 This is a multi-part message in MIME format. --------------010107080005010406050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nat - is there cryptanalysis of the proposed model available anyplace? Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of /RFC/ 6749 is that it avoids stuff like that. What do you mean when you say - [quote] The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it. [\quote] Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs? If not, how should the server embed tcsh in "code" and what constructions are recommended? - prateek > As some of you know, passing the authorization code securely to a > native app on iOS platform is next to impossible. Malicious > application may register the same custom scheme as the victim > application and hope to obtain the code, whose success rate is rather > high. > > We have discussed about it during the OpenID Conenct Meeting at IETF > 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work > group list. I have captured the discussion in the form of I-D. It is > pretty short and hopefully easy to read. > > IMHO, although it came up as an issue in OpenID Connect, this is a > quite useful extension to OAuth 2.0 in general. > > Best, > > Nat Sakimura > > ---------- Forwarded message ---------- > From: > > Date: 2013/7/30 > Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt > To: Nat Sakimura >, > John Bradley >, Naveen Agarwal > > > > > A new version of I-D, draft-sakimura-oauth-tcse-00.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 00 > Title: OAuth Transient Client Secret Extension for Public > Clients > Creation date: 2013-07-29 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 > > > Abstract: > The OAuth 2.0 public client utilizing code flow is susceptible to the > code interception attack. This specification describe a mechanism > that acts as a control against this threat. > > > > > > 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 > . > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010107080005010406050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. 

We have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. 

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general. 

Best, 

Nat Sakimura

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        00
Title:           OAuth Transient Client Secret Extension for Public Clients
Creation date:   2013-07-29
Group:           Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00


Abstract:
   The OAuth 2.0 public client utilizing code flow is susceptible to the
   code interception attack.  This specification describe a mechanism
   that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------010107080005010406050604-- From ve7jtb@ve7jtb.com Mon Sep 2 15:45:32 2013 Return-Path: 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 4CE7F21F99A4 for ; Mon, 2 Sep 2013 15:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnJZ7ylQf41E for ; Mon, 2 Sep 2013 15:45:28 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id C783821F99A2 for ; Mon, 2 Sep 2013 15:45:27 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so5197772pbc.37 for ; Mon, 02 Sep 2013 15:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=PA/xuSNKsE9dHahhC9YLUrypXK0duhDLwdYwcvi0pyA=; b=Y2+8MVKkTMyOmO3Q6gNGVk8ze6g3xRlRVZyRd64C6OyJSTaxxr2tmwzHkIPJxdme2E 741hTF5PEuv4UDCWfeDRhMLwRclzh4os53s7CPITthr1Fata6egZ30jTKj6vb1uAadf4 FfQlW2Rk/NMR5qLrAJBjaqu2faVIickbs1UyOaoSXTytxk2QVSDznSZD92KGy/ybuzTc QJObW+ZjJ6vJPAGXHxlEFGZk5hL56evgcl5hc/VhAty8XVkx8wTgWK+ccuGGzDE+RGqg 9HLsVCA6mx/OaW3Vk1oRcaVdmo9mtHxNnETDjnZw+E838OtK6K83HL9h6itl30maZfbt mu5w== X-Gm-Message-State: ALoCoQmXFxI2WmYAu1k/orAZ3Etbbwtm9clO1U6ocKaJFIDglU0amEdEJjH9tl/6JSCPzF1mcUBb X-Received: by 10.68.76.101 with SMTP id j5mr27955799pbw.67.1378161927244; Mon, 02 Sep 2013 15:45:27 -0700 (PDT) Received: from [192.168.100.93] (S0106602ad09850b5.va.shawcable.net. [70.78.20.194]) by mx.google.com with ESMTPSA id lm2sm19596022pab.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 15:45:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_31BF7765-8A8C-4796-B576-5676E530AE35"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: John Bradley In-Reply-To: <5224FFBB.9050400@oracle.com> Date: Mon, 2 Sep 2013 15:44:57 -0700 Message-Id: <84562CC3-8456-4FF4-8EEB-53DEE0246CCD@ve7jtb.com> References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> To: Prateek Mishra X-Mailer: Apple Mail (2.1508) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 22:45:32 -0000 --Apple-Mail=_31BF7765-8A8C-4796-B576-5676E530AE35 Content-Type: multipart/alternative; boundary="Apple-Mail=_C33389CA-057D-4C11-8EBA-9AE66FA9A925" --Apple-Mail=_C33389CA-057D-4C11-8EBA-9AE66FA9A925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 AS that don't maintain state would need to encode everything into code. = I have seen a couple of implementations do that. The encoding tends = to be custom for size reasons. Many AS maintain server state for code as it also has grants, = redirect_uri, client_id, subject etc that need to be tracked. The point being that the value of "tcsh" not be made available to = someone who intercepts code on the return. This method is being used without hashing, and just sending "tcs" = however that clearly has no resistance if the authorization request can = somehow be intercepted by an attacker as well. In order to stick to well understood crypto I argued that "tcsh" be a = hmac of the client_id using tcs as the key. I also think calling it a = client secret is misleading as it is a proof for the code requester not = the client. This is intended as a early draft to document the security problem on = iOS and one possible mitigation that people are using. While interoperable OAuth clients like Connect may be a edge case to = some, it is desirable to have a solution to this that can work with = multiple AS rather than the client requiring custom code to talk to = every AS. John B. On 2013-09-02, at 2:14 PM, Prateek Mishra = wrote: > Nat - is there cryptanalysis of the proposed model available anyplace? >=20 > Extending protocols by throwing in a smidgen of hashing and a = tablespoon of encryption is often a bad idea. One of the strengths of = RFC 6749 is that it avoids stuff like that. >=20 > What do you mean when you say -=20 >=20 > [quote] > The server MUST NOT include the "tcsh" value in the form that any = entity but itself can extract it. > [\quote] >=20 > Is this even theoretically achievable without a stateful server that = maintains a table of [code x tcsh] pairs?=20 >=20 > If not, how should the server embed tcsh in "code" and what = constructions are recommended? >=20 > - prateek >=20 >> As some of you know, passing the authorization code securely to a = native app on iOS platform is next to impossible. Malicious application = may register the same custom scheme as the victim application and hope = to obtain the code, whose success rate is rather high.=20 >>=20 >> We have discussed about it during the OpenID Conenct Meeting at IETF = 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work = group list. I have captured the discussion in the form of I-D. It is = pretty short and hopefully easy to read.=20 >>=20 >> IMHO, although it came up as an issue in OpenID Connect, this is a = quite useful extension to OAuth 2.0 in general.=20 >>=20 >> Best,=20 >>=20 >> Nat Sakimura >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: 2013/7/30 >> Subject: New Version Notification for = draft-sakimura-oauth-tcse-00.txt >> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>=20 >>=20 >>=20 >> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >> has been successfully submitted by Nat Sakimura and posted to the >> IETF repository. >>=20 >> Filename: draft-sakimura-oauth-tcse >> Revision: 00 >> Title: OAuth Transient Client Secret Extension for Public = Clients >> Creation date: 2013-07-29 >> Group: Individual Submission >> Number of pages: 7 >> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 >>=20 >>=20 >> Abstract: >> The OAuth 2.0 public client utilizing code flow is susceptible to = the >> code interception attack. This specification describe a mechanism >> that acts as a control against this threat. >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C33389CA-057D-4C11-8EBA-9AE66FA9A925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 AS = that don't maintain state would need to encode everything into code. =   I have seen a couple of implementations  do that.  The = encoding tends to be custom for size reasons.
Many AS maintain = server state for code as it also has grants, redirect_uri, client_id, = subject etc that need to be tracked.

The point = being that the value of "tcsh" not be made available to someone who = intercepts code on the return.

This method is = being used without hashing, and just sending "tcs" however that clearly = has no resistance if the authorization request can somehow be = intercepted by an attacker as well.

In order to = stick to well understood crypto I argued that "tcsh" be a hmac of the = client_id using tcs as the key.    I also think calling it a = client secret is misleading as it is a proof for the code requester not = the client.

This is intended as a early draft = to document the security problem on iOS and one possible mitigation that = people are using.

While interoperable OAuth = clients like Connect may be a edge case to some, it is desirable to have = a solution to this that can work with multiple AS rather than the client = requiring custom code to talk to every AS.

John = B.


On 2013-09-02, at 2:14 PM, = Prateek Mishra <prateek.mishra@oracle.com>= ; wrote:

=20 =20
Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. 

We = have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. 

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general. 

Best, 

Nat Sakimura

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        00
Title:           OAuth Transient = Client Secret Extension for Public Clients
Creation date:   2013-07-29
Group:           Individual = Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00<= /a>


Abstract:
   The OAuth 2.0 public client utilizing code flow = is susceptible to the
   code interception attack.  This = specification describe a mechanism
   that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
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

= --Apple-Mail=_C33389CA-057D-4C11-8EBA-9AE66FA9A925-- --Apple-Mail=_31BF7765-8A8C-4796-B576-5676E530AE35 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTAyMjI0NDU4WjAjBgkqhkiG9w0BCQQxFgQUD/phPpKd zR9RIFrivAYyCLarjUUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAIr7JKe2TAlGY755WzCFphROM4jOkJ52bp8hZ+siJ k2N+KMI1+H/zhj3icnsbjPEftrDMifGF7rCylTtAgrPB2qcUgkgRy/wKS05hektFg9OOgPSUwjyE /ef/tBIC5KF0+ND/1FATH3oF1GTf2D1glgGADZtUgJrmuJULVmvEdYkQBAwlbe4emvxKaVnB4eUT rL0GJDUiBp6VhvMVuN19ST1nMN1j2Q6PwR+o/dwcvZqiygqlgEeIg/QuH4KcqIx0zK75rZsyuL2t 4EhiwjbgizwjwTttFkOoo8AmA6keJyhwKspZUZCKtN64wT/ilJmqilTSC6jKsyfqpOcoA83I6gAA AAAAAA== --Apple-Mail=_31BF7765-8A8C-4796-B576-5676E530AE35-- From phil.hunt@oracle.com Mon Sep 2 16:35:14 2013 Return-Path: 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 7927721F9D68 for ; Mon, 2 Sep 2013 16:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYUN7j2pVinb for ; Mon, 2 Sep 2013 16:35:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C99821F9C69 for ; Mon, 2 Sep 2013 16:35:04 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r82NZ3Dw031707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Sep 2013 23:35:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82NZ2XJ007029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Sep 2013 23:35:02 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r82NZ17a007352; Mon, 2 Sep 2013 23:35:01 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Sep 2013 16:34:57 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_B527D013-F2BB-4F33-A92D-DC37AC8E5FB1" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Phil Hunt In-Reply-To: <84562CC3-8456-4FF4-8EEB-53DEE0246CCD@ve7jtb.com> Date: Mon, 2 Sep 2013 16:34:25 -0700 Message-Id: References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> <84562CC3-8456-4FF4-8EEB-53DEE0246CCD@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 23:35:14 -0000 --Apple-Mail=_B527D013-F2BB-4F33-A92D-DC37AC8E5FB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FWIW, this was raised before in 2011. http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-09-02, at 3:44 PM, John Bradley wrote: > AS that don't maintain state would need to encode everything into = code. I have seen a couple of implementations do that. The encoding = tends to be custom for size reasons. > Many AS maintain server state for code as it also has grants, = redirect_uri, client_id, subject etc that need to be tracked. >=20 > The point being that the value of "tcsh" not be made available to = someone who intercepts code on the return. >=20 > This method is being used without hashing, and just sending "tcs" = however that clearly has no resistance if the authorization request can = somehow be intercepted by an attacker as well. >=20 > In order to stick to well understood crypto I argued that "tcsh" be a = hmac of the client_id using tcs as the key. I also think calling it a = client secret is misleading as it is a proof for the code requester not = the client. >=20 > This is intended as a early draft to document the security problem on = iOS and one possible mitigation that people are using. >=20 > While interoperable OAuth clients like Connect may be a edge case to = some, it is desirable to have a solution to this that can work with = multiple AS rather than the client requiring custom code to talk to = every AS. >=20 > John B. >=20 >=20 > On 2013-09-02, at 2:14 PM, Prateek Mishra = wrote: >=20 >> Nat - is there cryptanalysis of the proposed model available = anyplace? >>=20 >> Extending protocols by throwing in a smidgen of hashing and a = tablespoon of encryption is often a bad idea. One of the strengths of = RFC 6749 is that it avoids stuff like that. >>=20 >> What do you mean when you say -=20 >>=20 >> [quote] >> The server MUST NOT include the "tcsh" value in the form that any = entity but itself can extract it. >> [\quote] >>=20 >> Is this even theoretically achievable without a stateful server that = maintains a table of [code x tcsh] pairs?=20 >>=20 >> If not, how should the server embed tcsh in "code" and what = constructions are recommended? >>=20 >> - prateek >>=20 >>> As some of you know, passing the authorization code securely to a = native app on iOS platform is next to impossible. Malicious application = may register the same custom scheme as the victim application and hope = to obtain the code, whose success rate is rather high.=20 >>>=20 >>> We have discussed about it during the OpenID Conenct Meeting at IETF = 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work = group list. I have captured the discussion in the form of I-D. It is = pretty short and hopefully easy to read.=20 >>>=20 >>> IMHO, although it came up as an issue in OpenID Connect, this is a = quite useful extension to OAuth 2.0 in general.=20 >>>=20 >>> Best,=20 >>>=20 >>> Nat Sakimura >>>=20 >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2013/7/30 >>> Subject: New Version Notification for = draft-sakimura-oauth-tcse-00.txt >>> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 00 >>> Title: OAuth Transient Client Secret Extension for Public = Clients >>> Creation date: 2013-07-29 >>> Group: Individual Submission >>> Number of pages: 7 >>> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 >>>=20 >>>=20 >>> Abstract: >>> The OAuth 2.0 public client utilizing code flow is susceptible to = the >>> code interception attack. This specification describe a = mechanism >>> that acts as a control against this threat. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B527D013-F2BB-4F33-A92D-DC37AC8E5FB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 FWIW, = this was raised before in 2011.

= =


On 2013-09-02, at 3:44 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

AS = that don't maintain state would need to encode everything into code. =   I have seen a couple of implementations  do that.  The = encoding tends to be custom for size reasons.
Many AS maintain = server state for code as it also has grants, redirect_uri, client_id, = subject etc that need to be tracked.

The point = being that the value of "tcsh" not be made available to someone who = intercepts code on the return.

This method is = being used without hashing, and just sending "tcs" however that clearly = has no resistance if the authorization request can somehow be = intercepted by an attacker as well.

In order to = stick to well understood crypto I argued that "tcsh" be a hmac of the = client_id using tcs as the key.    I also think calling it a = client secret is misleading as it is a proof for the code requester not = the client.

This is intended as a early draft = to document the security problem on iOS and one possible mitigation that = people are using.

While interoperable OAuth = clients like Connect may be a edge case to some, it is desirable to have = a solution to this that can work with multiple AS rather than the client = requiring custom code to talk to every AS.

John = B.


On 2013-09-02, at 2:14 PM, = Prateek Mishra <prateek.mishra@oracle.com>= ; wrote:

=20 =20
Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. 

We = have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. 

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general. 

Best, 

Nat Sakimura

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        00
Title:           OAuth Transient = Client Secret Extension for Public Clients
Creation date:   2013-07-29
Group:           Individual = Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00<= /a>


Abstract:
   The OAuth 2.0 public client utilizing code flow = is susceptible to the
   code interception attack.  This = specification describe a mechanism
   that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
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

___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_B527D013-F2BB-4F33-A92D-DC37AC8E5FB1-- From ve7jtb@ve7jtb.com Mon Sep 2 18:04:20 2013 Return-Path: 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 437E221F9DAA for ; Mon, 2 Sep 2013 18:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQQ++Z4f5CPN for ; Mon, 2 Sep 2013 18:04:15 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3D77B21F9D99 for ; Mon, 2 Sep 2013 18:04:13 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so5308784pbc.15 for ; Mon, 02 Sep 2013 18:04:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SJYtyK4sCiuKYcfIOWLNRSLWsZbISLM0j1W/8Fqf0/Q=; b=YL//wZWL411lbGS4F8Y8WV2QgoETbJ2k1pBoQ7hQF8Z+v5uH+GTuFxOrxtBqnX65xN zcupcd+mEVKT82NHvJ9Up8PQSmqyLFGLK9ZyCISBUt/RRNlOTXHPIzJsz4/Mg3VKeU+h PfLb+oMh1/2k3yqkdT7mxZFFmtquU4XJ8dHKXMzVQPhTQjPyKz3hFSjN27epbxPQ2p7L W56cEYqr/Lh8bsoYaS14pcYV9RkJU0iCnzIPu77iewnKis0paZH+XnR5R4jzyvc51ifz jsuNPM4LKbeQb4FMTH2DHivkpineyKQ1aVnhnQzXGaRHwQeU/t0pCERkJ0J4PDSUkQvt ClFg== X-Gm-Message-State: ALoCoQkEhqu0iDngl9nbbwocsryiEzdp5naopxIe68z17G8WnH8nlm9+lFHWceO6uODYV5S4hm5Z X-Received: by 10.66.218.226 with SMTP id pj2mr28956576pac.62.1378170252642; Mon, 02 Sep 2013 18:04:12 -0700 (PDT) Received: from [192.168.100.93] (S0106602ad09850b5.va.shawcable.net. [70.78.20.194]) by mx.google.com with ESMTPSA id xn12sm20094830pac.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 18:04:11 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D5AEEF1F-1641-4AD1-964E-66D6071D0229"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: John Bradley In-Reply-To: Date: Mon, 2 Sep 2013 18:04:05 -0700 Message-Id: References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> <84562CC3-8456-4FF4-8EEB-53DEE0246CCD@ve7jtb.com> To: Phil Hunt X-Mailer: Apple Mail (2.1508) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 01:04:20 -0000 --Apple-Mail=_D5AEEF1F-1641-4AD1-964E-66D6071D0229 Content-Type: multipart/alternative; boundary="Apple-Mail=_4F0116F6-B839-49EB-B3D0-49F3C7095C2D" --Apple-Mail=_4F0116F6-B839-49EB-B3D0-49F3C7095C2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes Phil it is the same sort of idea that you proposed in 2011. In this proposal it is limited to preventing an attacker who intercepts = code from being able to use it even if it knows the client_id and secret = of the requester as is likely in a native app without dynamic = registration case. I think of this as a symmetric proof of possession for code rather than = a authentication mechanism for the client. Looking at the old thread I = don't think that was clear to people. I also don't think the problem with native apps custom redirect schemes = being hijacked was apparent to people. =20 Sending the password itself in the authorization request works assuming = the attacker can't see the request as is the case in native environments = currently. We changed it to sending a hash of the secret in the request as sending = passwords in the clear just seems like it will eventually bite us in the = ass. I personally think making it a hmac is something people are more likely = to have the correct code for than a truncated hash, but this is a first = draft. John B. On 2013-09-02, at 4:34 PM, Phil Hunt wrote: > FWIW, this was raised before in 2011. >=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html > http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 2013-09-02, at 3:44 PM, John Bradley wrote: >=20 >> AS that don't maintain state would need to encode everything into = code. I have seen a couple of implementations do that. The encoding = tends to be custom for size reasons. >> Many AS maintain server state for code as it also has grants, = redirect_uri, client_id, subject etc that need to be tracked. >>=20 >> The point being that the value of "tcsh" not be made available to = someone who intercepts code on the return. >>=20 >> This method is being used without hashing, and just sending "tcs" = however that clearly has no resistance if the authorization request can = somehow be intercepted by an attacker as well. >>=20 >> In order to stick to well understood crypto I argued that "tcsh" be a = hmac of the client_id using tcs as the key. I also think calling it a = client secret is misleading as it is a proof for the code requester not = the client. >>=20 >> This is intended as a early draft to document the security problem on = iOS and one possible mitigation that people are using. >>=20 >> While interoperable OAuth clients like Connect may be a edge case to = some, it is desirable to have a solution to this that can work with = multiple AS rather than the client requiring custom code to talk to = every AS. >>=20 >> John B. >>=20 >>=20 >> On 2013-09-02, at 2:14 PM, Prateek Mishra = wrote: >>=20 >>> Nat - is there cryptanalysis of the proposed model available = anyplace? >>>=20 >>> Extending protocols by throwing in a smidgen of hashing and a = tablespoon of encryption is often a bad idea. One of the strengths of = RFC 6749 is that it avoids stuff like that. >>>=20 >>> What do you mean when you say -=20 >>>=20 >>> [quote] >>> The server MUST NOT include the "tcsh" value in the form that any = entity but itself can extract it. >>> [\quote] >>>=20 >>> Is this even theoretically achievable without a stateful server that = maintains a table of [code x tcsh] pairs?=20 >>>=20 >>> If not, how should the server embed tcsh in "code" and what = constructions are recommended? >>>=20 >>> - prateek >>>=20 >>>> As some of you know, passing the authorization code securely to a = native app on iOS platform is next to impossible. Malicious application = may register the same custom scheme as the victim application and hope = to obtain the code, whose success rate is rather high.=20 >>>>=20 >>>> We have discussed about it during the OpenID Conenct Meeting at = IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect = work group list. I have captured the discussion in the form of I-D. It = is pretty short and hopefully easy to read.=20 >>>>=20 >>>> IMHO, although it came up as an issue in OpenID Connect, this is a = quite useful extension to OAuth 2.0 in general.=20 >>>>=20 >>>> Best,=20 >>>>=20 >>>> Nat Sakimura >>>>=20 >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: 2013/7/30 >>>> Subject: New Version Notification for = draft-sakimura-oauth-tcse-00.txt >>>> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>>>=20 >>>>=20 >>>>=20 >>>> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >>>> has been successfully submitted by Nat Sakimura and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-sakimura-oauth-tcse >>>> Revision: 00 >>>> Title: OAuth Transient Client Secret Extension for Public = Clients >>>> Creation date: 2013-07-29 >>>> Group: Individual Submission >>>> Number of pages: 7 >>>> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>>> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> The OAuth 2.0 public client utilizing code flow is susceptible = to the >>>> code interception attack. This specification describe a = mechanism >>>> that acts as a control against this threat. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_4F0116F6-B839-49EB-B3D0-49F3C7095C2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Yes = Phil it is the same sort of idea that you proposed in = 2011.

In this proposal it is limited to preventing an = attacker who intercepts code from being able to use it even if it knows = the client_id and secret of the requester as is likely in a native app = without dynamic registration case.

I think of = this as a symmetric proof of possession for code rather than a = authentication mechanism for the client.  Looking at the old thread = I don't think that was clear to people.

I also = don't think the problem with native apps custom redirect schemes being = hijacked was apparent to people.  

Sending = the password itself in the authorization request works assuming the = attacker can't see the request as is the case in native environments = currently.
We changed it to sending a hash of the secret in = the request as sending passwords in the clear just seems like it will = eventually bite us in the ass.

I personally = think making it a hmac is something people are more likely to have the = correct code for than a truncated hash, but this is a first = draft.

John = B.


On 2013-09-02, at = 4:34 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

FWIW, = this was raised before in 2011.

= =

www.independentid.com
phil.hunt@oracle.com







On 2013-09-02, at 3:44 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

AS = that don't maintain state would need to encode everything into code. =   I have seen a couple of implementations  do that.  The = encoding tends to be custom for size reasons.
Many AS maintain = server state for code as it also has grants, redirect_uri, client_id, = subject etc that need to be tracked.

The point = being that the value of "tcsh" not be made available to someone who = intercepts code on the return.

This method is = being used without hashing, and just sending "tcs" however that clearly = has no resistance if the authorization request can somehow be = intercepted by an attacker as well.

In order to = stick to well understood crypto I argued that "tcsh" be a hmac of the = client_id using tcs as the key.    I also think calling it a = client secret is misleading as it is a proof for the code requester not = the client.

This is intended as a early draft = to document the security problem on iOS and one possible mitigation that = people are using.

While interoperable OAuth = clients like Connect may be a edge case to some, it is desirable to have = a solution to this that can work with multiple AS rather than the client = requiring custom code to talk to every AS.

John = B.


On 2013-09-02, at 2:14 PM, = Prateek Mishra <prateek.mishra@oracle.com>= ; wrote:

=20 =20
Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. 

We = have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. 

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general. 

Best, 

Nat Sakimura

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org><= /span>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>= ;, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        00
Title:           OAuth Transient = Client Secret Extension for Public Clients
Creation date:   2013-07-29
Group:           Individual = Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00<= /a>


Abstract:
   The OAuth 2.0 public client utilizing code flow = is susceptible to the
   code interception attack.  This = specification describe a mechanism
   that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
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

___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail=_4F0116F6-B839-49EB-B3D0-49F3C7095C2D-- --Apple-Mail=_D5AEEF1F-1641-4AD1-964E-66D6071D0229 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTAzMDEwNDA1WjAjBgkqhkiG9w0BCQQxFgQUZY62nSSO lPg/JD687LewAUSdCocwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEATWREvrJmmHaxzUKVq299eRk/7GLQ7uX6vAS5ZfjZ r/y0Dw5ZsQ2kZvtWdkKKxh7VPSwdjy9hLTsm9t0ESIFL250PkWl5dssn1EWs2PdtqY4YAwFCu6uI ACuChyK2cKTnqQHXCSmFwh/qoNIUYxpYgsRfHitujlFobEI1Ei9roQfCnfuhJpVd193FC3/ULQ6j t4PTQhEe63snUOD/0biJ8Xj2c9eFtMGi/42gKghaZVdXk97A+5n34p6qkl5hhSlrt1Mz2zGFCc7q UJGieM/haEmD8khO7vh54rsOTJJFgy/Y5jpN+uWtMRfgCBvq0e5mDz5vhjLHjmdqWWrQLPF5tgAA AAAAAA== --Apple-Mail=_D5AEEF1F-1641-4AD1-964E-66D6071D0229-- From sakimura@gmail.com Tue Sep 3 23:04:19 2013 Return-Path: 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 5D74521E808D for ; Tue, 3 Sep 2013 23:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrDi6K82mcGQ for ; Tue, 3 Sep 2013 23:04:17 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 147B921E8056 for ; Tue, 3 Sep 2013 23:04:16 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id es20so5479897lab.37 for ; Tue, 03 Sep 2013 23:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fxpQJwwA9c5v6SM0lNAXgbojrKPaJHdgesxRyQsqK3E=; b=Ncfzi7Z0rzznXplCrq66RYjrMvZ9JM7p8R3SFPFepaXGoSvKrK5so4rPoyiHENBv0d ijD7Hgwd2t4w/JU2GeMAQnVvTPkUx7o7kyzXTrfbCMozD0ZxrN9Nu2e6l65dOWieoSKt vunt8alCE3+JMQ2k7Oe9nefqlETqBV9tOyQTNIxkPx1QVGMJpg/+HSu6elGV1787W/XS 4LfgGsiHREO3jYC2DyukCrf6CjsP6dDYJWVIpkRiZbvLiLBhu8WjpyLgeERYQvrY7dd4 /hpKnIZRzA4pYq3qfEtgZjuoNRNviPxRRzu767NVf8UzFs24y91WZ40SgxGztFdpmr89 we8A== MIME-Version: 1.0 X-Received: by 10.112.167.230 with SMTP id zr6mr381920lbb.35.1378274655937; Tue, 03 Sep 2013 23:04:15 -0700 (PDT) Received: by 10.112.11.37 with HTTP; Tue, 3 Sep 2013 23:04:15 -0700 (PDT) In-Reply-To: References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> <84562CC3-8456-4FF4-8EEB-53DEE0246CCD@ve7jtb.com> Date: Wed, 4 Sep 2013 15:04:15 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=001a11c342ec452ab504e5889368 Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 06:04:19 -0000 --001a11c342ec452ab504e5889368 Content-Type: text/plain; charset=ISO-8859-1 >From the security PoV, I prefer HMAC as well. If implementers supports the idea, I would change it to HMAC in the next rev. I am also open to changing the param names. As I was writing them, I was reading JWx specs and got influenced by their short names apparently. I have no strong preference. I agree with John that we may want to avoid the name that is a variation on client secret as it would confuse people. 2013/9/3 John Bradley > Yes Phil it is the same sort of idea that you proposed in 2011. > > In this proposal it is limited to preventing an attacker who intercepts > code from being able to use it even if it knows the client_id and secret of > the requester as is likely in a native app without dynamic registration > case. > > I think of this as a symmetric proof of possession for code rather than a > authentication mechanism for the client. Looking at the old thread I don't > think that was clear to people. > > I also don't think the problem with native apps custom redirect schemes > being hijacked was apparent to people. > > Sending the password itself in the authorization request works assuming > the attacker can't see the request as is the case in native environments > currently. > We changed it to sending a hash of the secret in the request as sending > passwords in the clear just seems like it will eventually bite us in the > ass. > > I personally think making it a hmac is something people are more likely to > have the correct code for than a truncated hash, but this is a first draft. > > John B. > > > On 2013-09-02, at 4:34 PM, Phil Hunt wrote: > > FWIW, this was raised before in 2011. > > http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html > http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > On 2013-09-02, at 3:44 PM, John Bradley wrote: > > AS that don't maintain state would need to encode everything into code. > I have seen a couple of implementations do that. The encoding tends to be > custom for size reasons. > Many AS maintain server state for code as it also has grants, > redirect_uri, client_id, subject etc that need to be tracked. > > The point being that the value of "tcsh" not be made available to someone > who intercepts code on the return. > > This method is being used without hashing, and just sending "tcs" however > that clearly has no resistance if the authorization request can somehow be > intercepted by an attacker as well. > > In order to stick to well understood crypto I argued that "tcsh" be a hmac > of the client_id using tcs as the key. I also think calling it a client > secret is misleading as it is a proof for the code requester not the client. > > This is intended as a early draft to document the security problem on iOS > and one possible mitigation that people are using. > > While interoperable OAuth clients like Connect may be a edge case to some, > it is desirable to have a solution to this that can work with multiple AS > rather than the client requiring custom code to talk to every AS. > > John B. > > > On 2013-09-02, at 2:14 PM, Prateek Mishra > wrote: > > Nat - is there cryptanalysis of the proposed model available anyplace? > > Extending protocols by throwing in a smidgen of hashing and a tablespoon > of encryption is often a bad idea. One of the strengths of *RFC* 6749 is > that it avoids stuff like that. > > What do you mean when you say - > > [quote] > The server MUST NOT include the "tcsh" value in the form that any entity > but itself can extract it. > [\quote] > > Is this even theoretically achievable without a stateful server that > maintains a table of [code x tcsh] pairs? > > If not, how should the server embed tcsh in "code" and what constructions > are recommended? > > - prateek > > As some of you know, passing the authorization code securely to a native > app on iOS platform is next to impossible. Malicious application may > register the same custom scheme as the victim application and hope to > obtain the code, whose success rate is rather high. > > We have discussed about it during the OpenID Conenct Meeting at IETF 87 > on Sunday, and over a lengthy thread on the OpenID AB/Connect work group > list. I have captured the discussion in the form of I-D. It is pretty short > and hopefully easy to read. > > IMHO, although it came up as an issue in OpenID Connect, this is a quite > useful extension to OAuth 2.0 in general. > > Best, > > Nat Sakimura > > ---------- Forwarded message ---------- > From: > Date: 2013/7/30 > Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt > To: Nat Sakimura , John Bradley < > jbradley@pingidentity.com>, Naveen Agarwal > > > > A new version of I-D, draft-sakimura-oauth-tcse-00.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 00 > Title: OAuth Transient Client Secret Extension for Public Clients > Creation date: 2013-07-29 > Group: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 > > > Abstract: > The OAuth 2.0 public client utilizing code flow is susceptible to the > code interception attack. This specification describe a mechanism > that acts as a control against this threat. > > > > > > 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. > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > 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 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c342ec452ab504e5889368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From the security PoV, I prefer HMAC as well.=A0
If im= plementers supports the idea, I would change it to HMAC in the next rev.=A0=
I am also open to changing the param names. As I was writing the= m, I was reading JWx specs and got influenced by their short names apparent= ly. I have no strong preference.=A0

I agree with John that we may want to avoid the name th= at is a variation on client secret as it would confuse people.=A0




2013/9/3 John Bradley <ve7jtb@ve7jtb.com>
Yes Phil it is the same sort of idea th= at you proposed in 2011.

In this proposal it is limited = to preventing an attacker who intercepts code from being able to use it eve= n if it knows the client_id and secret of the requester as is likely in a n= ative app without dynamic registration case.

I think of this as a symmetric proof of possession for = code rather than a authentication mechanism for the client. =A0Looking at t= he old thread I don't think that was clear to people.

I also don't think the problem with native apps custom redirect sc= hemes being hijacked was apparent to people. =A0

S= ending the password itself in the authorization request works assuming the = attacker can't see the request as is the case in native environments cu= rrently.
We changed it to sending a hash of the secret in the request as sendin= g passwords in the clear just seems like it will eventually bite us in the = ass.

I personally think making it a hmac is someth= ing people are more likely to have the correct code for than a truncated ha= sh, but this is a first draft.

John B.


On 2013-09-02, at 4:34 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:

FWIW, thi= s was raised before in 2011.



On 2013-09-02, at 3:44 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
AS that = don't maintain state would need to encode everything into code. =A0 I h= ave seen a couple of implementations =A0do that. =A0The encoding tends to b= e custom for size reasons.
Many AS maintain server state for code as it also has grants, redirect_uri,= client_id, subject etc that need to be tracked.

The= point being that the value of "tcsh" not be made available to so= meone who intercepts code on the return.

This method is being used without hashing, and just sen= ding "tcs" however that clearly has no resistance if the authoriz= ation request can somehow be intercepted by an attacker as well.

In order to stick to well understood crypto I argued that &q= uot;tcsh" be a hmac of the client_id using tcs as the key. =A0 =A0I al= so think calling it a client secret is misleading as it is a proof for the = code requester not the client.

This is intended as a early draft to document the secur= ity problem on iOS and one possible mitigation that people are using.
=

While interoperable OAuth clients like Connect may be a= edge case to some, it is desirable to have a solution to this that can wor= k with multiple AS rather than the client requiring custom code to talk to = every AS.

John B.


On 2013-= 09-02, at 2:14 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
=20 =20 =20
Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the fo= rm that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high.=A0

We have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read.=A0

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general.=A0

Best,=A0=

Nat Sakimura

---------- Forwarded message ----------<= br> From: <internet-drafts@ietf.org>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sakimura-oauth-tcse
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 OAuth Transient Client Secret Extensio= n for Public Clients
Creation date: =A0 2013-07-29
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 7
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-sakimura-oauth-tcse
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-sakimura-oauth-tcse-00


Abstract:
=A0 =A0The OAuth 2.0 public client utilizing code flow is susceptible to the
=A0 =A0code interception attack. =A0This specification describe a mechanism
=A0 =A0that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat= .sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c342ec452ab504e5889368-- From phil.hunt@oracle.com Wed Sep 4 07:13:18 2013 Return-Path: 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 8960521F9DFA for ; Wed, 4 Sep 2013 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvZYUH5H1RQp for ; Wed, 4 Sep 2013 07:13:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 80DDD21F9346 for ; Wed, 4 Sep 2013 07:13:13 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r84ED9kg027875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 14:13:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r84ED8xI025590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 14:13:08 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r84ED7qa007135; Wed, 4 Sep 2013 14:13:08 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Sep 2013 07:13:07 -0700 References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> <84562CC3-8456-4FF4-8EEB-53DEE0246CCD@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7048A1DE-1357-47E3-848F-7347B892C7D5 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Wed, 4 Sep 2013 07:13:05 -0700 To: Nat Sakimura X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 14:13:18 -0000 --Apple-Mail-7048A1DE-1357-47E3-848F-7347B892C7D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable How about request identifier? Phil On 2013-09-03, at 23:04, Nat Sakimura wrote: > =46rom the security PoV, I prefer HMAC as well.=20 > If implementers supports the idea, I would change it to HMAC in the next r= ev.=20 > I am also open to changing the param names. As I was writing them, I was r= eading JWx specs and got influenced by their short names apparently. I have n= o strong preference.=20 >=20 > I agree with John that we may want to avoid the name that is a variation o= n client secret as it would confuse people.=20 >=20 >=20 >=20 >=20 > 2013/9/3 John Bradley >> Yes Phil it is the same sort of idea that you proposed in 2011. >>=20 >> In this proposal it is limited to preventing an attacker who intercepts c= ode from being able to use it even if it knows the client_id and secret of t= he requester as is likely in a native app without dynamic registration case.= >>=20 >> I think of this as a symmetric proof of possession for code rather than a= authentication mechanism for the client. Looking at the old thread I don't= think that was clear to people. >>=20 >> I also don't think the problem with native apps custom redirect schemes b= eing hijacked was apparent to people. =20 >>=20 >> Sending the password itself in the authorization request works assuming t= he attacker can't see the request as is the case in native environments curr= ently. >> We changed it to sending a hash of the secret in the request as sending p= asswords in the clear just seems like it will eventually bite us in the ass.= >>=20 >> I personally think making it a hmac is something people are more likely t= o have the correct code for than a truncated hash, but this is a first draft= . >>=20 >> John B. >>=20 >>=20 >> On 2013-09-02, at 4:34 PM, Phil Hunt wrote: >>=20 >>> FWIW, this was raised before in 2011. >>>=20 >>> http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html >>> http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2013-09-02, at 3:44 PM, John Bradley wrote: >>>=20 >>>> AS that don't maintain state would need to encode everything into code.= I have seen a couple of implementations do that. The encoding tends to b= e custom for size reasons. >>>> Many AS maintain server state for code as it also has grants, redirect_= uri, client_id, subject etc that need to be tracked. >>>>=20 >>>> The point being that the value of "tcsh" not be made available to someo= ne who intercepts code on the return. >>>>=20 >>>> This method is being used without hashing, and just sending "tcs" howev= er that clearly has no resistance if the authorization request can somehow b= e intercepted by an attacker as well. >>>>=20 >>>> In order to stick to well understood crypto I argued that "tcsh" be a h= mac of the client_id using tcs as the key. I also think calling it a clie= nt secret is misleading as it is a proof for the code requester not the clie= nt. >>>>=20 >>>> This is intended as a early draft to document the security problem on i= OS and one possible mitigation that people are using. >>>>=20 >>>> While interoperable OAuth clients like Connect may be a edge case to so= me, it is desirable to have a solution to this that can work with multiple A= S rather than the client requiring custom code to talk to every AS. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>> On 2013-09-02, at 2:14 PM, Prateek Mishra w= rote: >>>>=20 >>>>> Nat - is there cryptanalysis of the proposed model available anyplace?= >>>>>=20 >>>>> Extending protocols by throwing in a smidgen of hashing and a tablespo= on of encryption is often a bad idea. One of the strengths of RFC 6749 is th= at it avoids stuff like that. >>>>>=20 >>>>> What do you mean when you say -=20 >>>>>=20 >>>>> [quote] >>>>> The server MUST NOT include the "tcsh" value in the form that any e= ntity but itself can extract it. >>>>> [\quote] >>>>>=20 >>>>> Is this even theoretically achievable without a stateful server that m= aintains a table of [code x tcsh] pairs?=20 >>>>>=20 >>>>> If not, how should the server embed tcsh in "code" and what constructi= ons are recommended? >>>>>=20 >>>>> - prateek >>>>>=20 >>>>>> As some of you know, passing the authorization code securely to a nat= ive app on iOS platform is next to impossible. Malicious application may reg= ister the same custom scheme as the victim application and hope to obtain th= e code, whose success rate is rather high.=20 >>>>>>=20 >>>>>> We have discussed about it during the OpenID Conenct Meeting at IETF 8= 7 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group l= ist. I have captured the discussion in the form of I-D. It is pretty short a= nd hopefully easy to read.=20 >>>>>>=20 >>>>>> IMHO, although it came up as an issue in OpenID Connect, this is a qu= ite useful extension to OAuth 2.0 in general.=20 >>>>>>=20 >>>>>> Best,=20 >>>>>>=20 >>>>>> Nat Sakimura >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: 2013/7/30 >>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-00.tx= t >>>>>> To: Nat Sakimura , John Bradley , Naveen Agarwal >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >>>>>> has been successfully submitted by Nat Sakimura and posted to the >>>>>> IETF repository. >>>>>>=20 >>>>>> Filename: draft-sakimura-oauth-tcse >>>>>> Revision: 00 >>>>>> Title: OAuth Transient Client Secret Extension for Public C= lients >>>>>> Creation date: 2013-07-29 >>>>>> Group: Individual Submission >>>>>> Number of pages: 7 >>>>>> URL: http://www.ietf.org/internet-drafts/draft-sakimura-o= auth-tcse-00.txt >>>>>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth= -tcse >>>>>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse= -00 >>>>>>=20 >>>>>>=20 >>>>>> Abstract: >>>>>> The OAuth 2.0 public client utilizing code flow is susceptible to t= he >>>>>> code interception attack. This specification describe a mechanism= >>>>>> that acts as a control against this threat. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of sub= mission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail-7048A1DE-1357-47E3-848F-7347B892C7D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
How about request identifier?

Phil

On 2013-09-03, at 23:04, Nat Sakimura <sakimura@gmail.com> wrote:

From the security PoV, I prefer HMAC as well. 
If implementers supports the idea, I would change it to HMAC in the next rev. 
I am also open to changing the param names. As I was writing them, I was reading JWx specs and got influenced by their short names apparently. I have no strong preference. 

I agree with John that we may want to avoid the name that is a variation on client secret as it would confuse people. 




2013/9/3 John Bradley <ve7jtb@ve7jtb.com>
Yes Phil it is the same sort of idea that you proposed in 2011.

In this proposal it is limited to preventing an attacker who intercepts code from being able to use it even if it knows the client_id and secret of the requester as is likely in a native app without dynamic registration case.

I think of this as a symmetric proof of possession for code rather than a authentication mechanism for the client.  Looking at the old thread I don't think that was clear to people.

I also don't think the problem with native apps custom redirect schemes being hijacked was apparent to people.  

Sending the password itself in the authorization request works assuming the attacker can't see the request as is the case in native environments currently.
We changed it to sending a hash of the secret in the request as sending passwords in the clear just seems like it will eventually bite us in the ass.

I personally think making it a hmac is something people are more likely to have the correct code for than a truncated hash, but this is a first draft.

John B.


On 2013-09-02, at 4:34 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

FWIW, this was raised before in 2011.



On 2013-09-02, at 3:44 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

AS that don't maintain state would need to encode everything into code.   I have seen a couple of implementations  do that.  The encoding tends to be custom for size reasons.
Many AS maintain server state for code as it also has grants, redirect_uri, client_id, subject etc that need to be tracked.

The point being that the value of "tcsh" not be made available to someone who intercepts code on the return.

This method is being used without hashing, and just sending "tcs" however that clearly has no resistance if the authorization request can somehow be intercepted by an attacker as well.

In order to stick to well understood crypto I argued that "tcsh" be a hmac of the client_id using tcs as the key.    I also think calling it a client secret is misleading as it is a proof for the code requester not the client.

This is intended as a early draft to document the security problem on iOS and one possible mitigation that people are using.

While interoperable OAuth clients like Connect may be a edge case to some, it is desirable to have a solution to this that can work with multiple AS rather than the client requiring custom code to talk to every AS.

John B.


On 2013-09-02, at 2:14 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:

Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. 

We have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. 

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general. 

Best, 

Nat Sakimura

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-tcse
Revision:        00
Title:           OAuth Transient Client Secret Extension for Public Clients
Creation date:   2013-07-29
Group:           Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00


Abstract:
   The OAuth 2.0 public client utilizing code flow is susceptible to the
   code interception attack.  This specification describe a mechanism
   that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
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

_______________________________________________
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




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--Apple-Mail-7048A1DE-1357-47E3-848F-7347B892C7D5-- From sakimura@gmail.com Thu Sep 5 16:34:45 2013 Return-Path: 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 773FB11E81E6 for ; Thu, 5 Sep 2013 16:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKUvV5brlRQO for ; Thu, 5 Sep 2013 16:34:44 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id F015311E811E for ; Thu, 5 Sep 2013 16:34:43 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ev20so2163273lab.39 for ; Thu, 05 Sep 2013 16:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QX8YkuW5QWTiuR0Ny7fRJzYeFswy/oPVNeZn5+cy8eo=; b=sdwd/vjLm9Mu6p2njYrzvpYYpAYWugg28/lRmgcgKd22hGxMtsGG6bH+1TgOjDLxit vXN9Em+V+/BdBIf0B70TrnDKzsK3Y+UbqWRqGysp2NCXhGp76vrjH+TNxVYIph4vqp5s xDHIVUYURw/gczV261GETUOEoWbPguPuvKaEbmxl4i2q3swJhTzncWAriqbyQvQ0GZdU dhg7Nb+f8KjTZ3lRgK8XtzWD5oKfDQtJGvGyBmsWV3pxubcaherHBS+75YkkQi3xPBBB /iRYEYKRei9GcaIXs+H54T5oNirD+WI7WsLVyaqi6gXfnMompM8ytoyuJttrI0tMW19t YG9g== MIME-Version: 1.0 X-Received: by 10.152.88.74 with SMTP id be10mr9496962lab.4.1378424082894; Thu, 05 Sep 2013 16:34:42 -0700 (PDT) Received: by 10.112.11.37 with HTTP; Thu, 5 Sep 2013 16:34:42 -0700 (PDT) In-Reply-To: <5224FFBB.9050400@oracle.com> References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> Date: Fri, 6 Sep 2013 08:34:42 +0900 Message-ID: From: Nat Sakimura To: Prateek Mishra Content-Type: multipart/alternative; boundary=001a11c34e6ccf971104e5ab5d10 Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 23:34:45 -0000 --001a11c34e6ccf971104e5ab5d10 Content-Type: text/plain; charset=ISO-8859-1 Depending on the level of assurance that you might want to achieve, it could have been a random string. That's how some of the existing but widely deployed implementations are doing. I have taken a step forward to do the hashing to give a little more protection that even if a malware on the device captures the request, it would not be able to use it in time. That's a kind of man-in-the-middle and by that time happens, your device is fairly badly compromised so there are opinion that it would not matter much by that time that just a random string would suffice. If the WG feels that way, I am happy to change it to a random string as well. The current "hash" design was a middle ground between a random string and HMAC etc. 2013/9/3 Prateek Mishra > Nat - is there cryptanalysis of the proposed model available anyplace? > > Extending protocols by throwing in a smidgen of hashing and a tablespoon > of encryption is often a bad idea. One of the strengths of *RFC* 6749 is > that it avoids stuff like that. > > What do you mean when you say - > > [quote] > The server MUST NOT include the "tcsh" value in the form that any entity > but itself can extract it. > [\quote] > > Is this even theoretically achievable without a stateful server that > maintains a table of [code x tcsh] pairs? > > If not, how should the server embed tcsh in "code" and what constructions > are recommended? > > - prateek > > As some of you know, passing the authorization code securely to a native > app on iOS platform is next to impossible. Malicious application may > register the same custom scheme as the victim application and hope to > obtain the code, whose success rate is rather high. > > We have discussed about it during the OpenID Conenct Meeting at IETF 87 > on Sunday, and over a lengthy thread on the OpenID AB/Connect work group > list. I have captured the discussion in the form of I-D. It is pretty short > and hopefully easy to read. > > IMHO, although it came up as an issue in OpenID Connect, this is a quite > useful extension to OAuth 2.0 in general. > > Best, > > Nat Sakimura > > ---------- Forwarded message ---------- > From: > Date: 2013/7/30 > Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt > To: Nat Sakimura , John Bradley < > jbradley@pingidentity.com>, Naveen Agarwal > > > > A new version of I-D, draft-sakimura-oauth-tcse-00.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 00 > Title: OAuth Transient Client Secret Extension for Public Clients > Creation date: 2013-07-29 > Group: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 > > > Abstract: > The OAuth 2.0 public client utilizing code flow is susceptible to the > code interception attack. This specification describe a mechanism > that acts as a control against this threat. > > > > > > 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. > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c34e6ccf971104e5ab5d10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Depending on the level of assurance that you might want to= achieve, it could have been a random string. That's how some of the ex= isting but widely deployed implementations are doing.=A0

I have taken a step forward to do the hashing to give a little more protect= ion that even if a malware on the device captures the request, it would not= be able to use it in time. That's a kind of man-in-the-middle and by t= hat time happens, your device is fairly badly compromised so there are opin= ion that it would not matter much by that time that just a random string wo= uld suffice. If the WG feels that way, I am happy to change it to a random = string as well.=A0

The current "hash" design was a middle ground= between a random string and HMAC etc.=A0


2013/9/3 Prateek Mishra <prateek.mishra@oracle.com>
=20 =20 =20
Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the fo= rm that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high.=A0

We have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read.=A0

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general.=A0

Best,=A0=

Nat Sakimura

---------- Forwarded message ----------<= br> From: <internet-drafts@ietf.org>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sakimura-oauth-tcse
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 OAuth Transient Client Secret Extensio= n for Public Clients
Creation date: =A0 2013-07-29
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 7
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-sakimura-oauth-tcse
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-sakimura-oauth-tcse-00


Abstract:
=A0 =A0The OAuth 2.0 public client utilizing code flow is susceptible to the
=A0 =A0code interception attack. =A0This specification describe a mechanism
=A0 =A0that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat= .sakimura.org/
@_nat_en


__________________________________=
_____________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c34e6ccf971104e5ab5d10-- From ve7jtb@ve7jtb.com Thu Sep 5 16:44:32 2013 Return-Path: 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 63FE011E8216 for ; Thu, 5 Sep 2013 16:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCOfD2USH-7l for ; Thu, 5 Sep 2013 16:44:27 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0936611E810D for ; Thu, 5 Sep 2013 16:44:26 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so2526417pab.25 for ; Thu, 05 Sep 2013 16:44:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RZJm1naA15ai7FM3xYJ2OZL/4dspr2rpS4PanuTB9Q4=; b=KO+3/E3poVi/J5C2+F6e1i3cWOWubyWziRlXJeuBVE7pv+1T+aCMs9HlMEF2RLMbus MLeEL4FiQ7gtY6noP5NYatDw+gdj3ayyI3fE824CxcycHdzm/q+m4IYwuviFpyGq9iO4 0W1OjjcHQNa0RNBJ7KQSHimjWoZd7VmVZ4qHuQhjH+DY9w23OFr/KXNs0nSxx31YAENP PZ4Vng0KcWHWQRzuTlJevHi2SBQj/XLRQ5KGT8zpr5j3gqrguKflEA/zfzImlyE7jT9U otDS9ZATTnIxqiyEKuJnluvCV9OFZXifxse0wobJohSn6pCHPn1JSuiCSZEBg6mNZg1k 7x0A== X-Gm-Message-State: ALoCoQlnICPG27OLMnwI5l/RrswUvd0mcTZ+aSFYlKl48guKYZkEKgkMibi8jqmnpMyZhf00GagV X-Received: by 10.66.250.47 with SMTP id yz15mr659573pac.154.1378424666610; Thu, 05 Sep 2013 16:44:26 -0700 (PDT) Received: from [172.26.23.193] ([207.225.82.209]) by mx.google.com with ESMTPSA id lm2sm426133pab.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 16:44:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1213DA81-F2B1-41B8-B6D4-FECB03142EDF"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: John Bradley In-Reply-To: Date: Thu, 5 Sep 2013 16:44:26 -0700 Message-Id: <72735227-DF50-41F0-B744-9ED1706339B5@ve7jtb.com> References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1508) Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 23:44:32 -0000 --Apple-Mail=_1213DA81-F2B1-41B8-B6D4-FECB03142EDF Content-Type: multipart/alternative; boundary="Apple-Mail=_B2C03D3E-37BC-4CEF-A26B-838BC87BDFCB" --Apple-Mail=_B2C03D3E-37BC-4CEF-A26B-838BC87BDFCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 At this point we don't know of any attack against the request, however = that is not guaranteed to remain the case. =20 If we send the secret in plain text through the browser it likely will = never get IETF acceptance.=20 We use HMAC a fair bit already I don't think that would be a significant = hurdle for clients. The quoted text is trying to prevent the AS from leaking the value back = to the attacker, that would be fatal flaw if it is plaintext, and not = optimal if it is a HMAC. AS could do something like include it in code unencrypted etc, just = trying to prevent that. On 2013-09-05, at 4:34 PM, Nat Sakimura wrote: > Depending on the level of assurance that you might want to achieve, it = could have been a random string. That's how some of the existing but = widely deployed implementations are doing.=20 >=20 > I have taken a step forward to do the hashing to give a little more = protection that even if a malware on the device captures the request, it = would not be able to use it in time. That's a kind of man-in-the-middle = and by that time happens, your device is fairly badly compromised so = there are opinion that it would not matter much by that time that just a = random string would suffice. If the WG feels that way, I am happy to = change it to a random string as well.=20 >=20 > The current "hash" design was a middle ground between a random string = and HMAC etc.=20 >=20 >=20 > 2013/9/3 Prateek Mishra > Nat - is there cryptanalysis of the proposed model available anyplace? >=20 > Extending protocols by throwing in a smidgen of hashing and a = tablespoon of encryption is often a bad idea. One of the strengths of = RFC 6749 is that it avoids stuff like that. >=20 > What do you mean when you say -=20 >=20 > [quote] > The server MUST NOT include the "tcsh" value in the form that any = entity but itself can extract it. > [\quote] >=20 > Is this even theoretically achievable without a stateful server that = maintains a table of [code x tcsh] pairs?=20 >=20 > If not, how should the server embed tcsh in "code" and what = constructions are recommended? >=20 > - prateek >=20 >> As some of you know, passing the authorization code securely to a = native app on iOS platform is next to impossible. Malicious application = may register the same custom scheme as the victim application and hope = to obtain the code, whose success rate is rather high.=20 >>=20 >> We have discussed about it during the OpenID Conenct Meeting at IETF = 87 on Sunday, and over a lengthy thread on the OpenID = AB/Connect work group list. I have captured the discussion in the form = of I-D. It is pretty short and hopefully easy to read.=20 >>=20 >> IMHO, although it came up as an issue in OpenID Connect, this is a = quite useful extension to OAuth 2.0 in general.=20 >>=20 >> Best,=20 >>=20 >> Nat Sakimura >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: 2013/7/30 >> Subject: New Version Notification for = draft-sakimura-oauth-tcse-00.txt >> To: Nat Sakimura , John Bradley = , Naveen Agarwal >>=20 >>=20 >>=20 >> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >> has been successfully submitted by Nat Sakimura and posted to the >> IETF repository. >>=20 >> Filename: draft-sakimura-oauth-tcse >> Revision: 00 >> Title: OAuth Transient Client Secret Extension for Public = Clients >> Creation date: 2013-07-29 >> Group: Individual Submission >> Number of pages: 7 >> URL: = http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >> Htmlized: = http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 >>=20 >>=20 >> Abstract: >> The OAuth 2.0 public client utilizing code flow is susceptible to = the >> code interception attack. This specification describe a mechanism >> that acts as a control against this threat. >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B2C03D3E-37BC-4CEF-A26B-838BC87BDFCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 At = this point we don't know of any attack against the request, however that = is not guaranteed to remain the case.   

If = we send the secret in plain text through the browser it likely will = never get IETF acceptance. 

We use HMAC a = fair bit already I don't think that would be a significant hurdle for = clients.

The quoted text is trying to prevent = the AS from leaking the value back to the attacker,  that would be = fatal flaw if it is plaintext, and not optimal if it is a = HMAC.

AS could do something like include it in = code unencrypted etc, just trying to prevent = that.

On 2013-09-05, at 4:34 PM, Nat Sakimura = <sakimura@gmail.com> = wrote:

Depending on the level of assurance that = you might want to achieve, it could have been a random string. That's = how some of the existing but widely deployed implementations are = doing. 

I have taken a step forward to do the hashing to give a little more = protection that even if a malware on the device captures the request, it = would not be able to use it in time. That's a kind of man-in-the-middle = and by that time happens, your device is fairly badly compromised so = there are opinion that it would not matter much by that time that just a = random string would suffice. If the WG feels that way, I am happy to = change it to a random string as well. 

The current "hash" design was a middle ground = between a random string and HMAC etc. 


2013/9/3 = Prateek Mishra <prateek.mishra@oracle.com>
=20 =20 =20
Nat - is there cryptanalysis of the proposed model available anyplace?

Extending protocols by throwing in a smidgen of hashing and a tablespoon of encryption is often a bad idea. One of the strengths of RFC 6749 is that it avoids stuff like that.

What do you mean when you say -

[quote]
The server MUST NOT include the "tcsh" value in the form that any entity but itself can extract it.
[\quote]

Is this even theoretically achievable without a stateful server that maintains a table of [code x tcsh] pairs?

If not, how should the server embed tcsh in "code" and what constructions are recommended?

- prateek

As some of you know, passing the authorization code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. 

We = have discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday, and over a lengthy thread on the OpenID AB/Connect work group list. I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. 

IMHO, although it came up as an issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in general. 

Best, 

Nat Sakimura

---------- Forwarded message = ----------
From: <internet-drafts@ietf.org>
Date: 2013/7/30
Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>



A new version of I-D, draft-sakimura-oauth-tcse-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:       =  draft-sakimura-oauth-tcse
Revision:        00
Title:           OAuth Transient = Client Secret Extension for Public Clients
Creation date:   2013-07-29
Group:           Individual = Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth= -tcse-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcs= e
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00<= /a>


Abstract:
   The OAuth 2.0 public client utilizing code flow = is susceptible to the
   code interception attack.  This = specification describe a mechanism
   that acts as a control against this threat.





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.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_B2C03D3E-37BC-4CEF-A26B-838BC87BDFCB-- --Apple-Mail=_1213DA81-F2B1-41B8-B6D4-FECB03142EDF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTA1MjM0NDI3WjAjBgkqhkiG9w0BCQQxFgQU95E31pDH h1W9wq1HF6AhqGcwfL0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAUVOvuU4Z7eyxjQYjehKYoqC0Ao9ywZ/xANwoQ7tX SISDaICjj15hOkxs+KvZdy3/CRsx7NhKoXdyUNu1cU+lzQ6rxuWMkPjCub+8ji8+jy+Cy64/S2xE Eq5hAGNSgdgE84tfmOfxLRF3p1Dk/0j+HkTcucCOtsBrECtKyOP9VodmMBF1EqnVg4bXHYEQhDg3 eXTDB3fBuh8ZbiEN68NJqERMhD3hvhPMALek2rVrsMKJPubVgCQA/D1ihgj5IAguC+HJh3fPCEnh p0GDUxbl1KyzBL2F/7dcjo7EKLnYX6JZ2CAGOsf13CVBY9Sne+oyUGYUl6gwRVt/VakkKcHI+gAA AAAAAA== --Apple-Mail=_1213DA81-F2B1-41B8-B6D4-FECB03142EDF-- From hardjono@mit.edu Mon Sep 9 10:11:26 2013 Return-Path: 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 2F97E11E8201 for ; Mon, 9 Sep 2013 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W40u-6SFPF3K for ; Mon, 9 Sep 2013 10:11:17 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BA11E81D6 for ; Mon, 9 Sep 2013 10:11:13 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-38-522e01308f61 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.3E.02359.0310E225; Mon, 9 Sep 2013 13:11:12 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r89HBB6w001210 for ; Mon, 9 Sep 2013 13:11:12 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (w92exedge6.exchange.mit.edu [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id r89HBBZT001691 for ; Mon, 9 Sep 2013 13:11:11 -0400 Received: from W92EXHUB14.exchange.mit.edu (18.7.73.25) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 9 Sep 2013 13:09:59 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.167]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0158.001; Mon, 9 Sep 2013 13:10:58 -0400 From: Thomas Hardjono To: "oauth@ietf.org" Thread-Topic: Personal Data Conference at MIT (October 7th, 2013) - MIT-KIT and Media Lab Thread-Index: Ac6tf4sL5x7yDNOfSRaa+KlSs6PjFg== Date: Mon, 9 Sep 2013 17:10:58 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A3225AF57@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.189.26.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUixG6nomvAqBdk8HqrssXJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseSAWcFG7orFy9cxNzA+4+hi5OCQEDCReHI1s4uRE8gUk7hw bz1bFyMXh5DAPkaJxs3fWSCcK4wSn65+g8rcYpQ4/KqREcLZBuRM3APlrGKUWHlmCwvIMDYB DYlzv/eyg9giAqoS+45eAbOFBcIklvYeYYGIR0tsvPeKEeQOEQE9iUOt+SBhFgEViU0nD7KB 2LwCQRI9v2aBtTIC3ff91BomEJtZQFzi1pP5TBB3C0osmr2HGeaHf7seskHYChKTLq1ih6jX kViw+xMbhK0tsWzha2aI+YISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkbZlNwq3dzEzJzi 1GTd4uTEvLzUIl0jvdzMEr3UlNJNjKDo4ZTk3cH47qDSIUYBDkYlHt6AY7pBQqyJZcWVuYcY JTmYlER5n/8HCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh3fMRKMebklhZlVqUD5OS5mBREud9 +vRsoJBAemJJanZqakFqEUxWhoNDSYI3m0EvSEiwKDU9tSItM6cEIc3EwQkynAdouC9IDW9x QWJucWY6RP4Uo6KUOK8OSEIAJJFRmgfXC0turxjFgV4R5g0FqeIBJka47ldAg5mABotkgVxd XJKIkJJqYLy4dMfUWbuvNCxckPEo+o5V0mY3Yb0amWQVVd/GKhdbeYapIh67rtW8/yV8p3FX T40F4/SbLxdVytstKJit7/DKncX54eX7gYv0ijR4eif9fHPc6/6Ns3M5o/l2bTz7M8hgy2bx MhPvxbtvvv+X/WdfZlR+b/vO7OgHMgsLPVU/eZ3QkzfTOK7EUpyRaKjFXFScCAAjiHh1SQMA AA== Subject: [OAUTH-WG] Personal Data Conference at MIT (October 7th, 2013) - MIT-KIT and Media Lab X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:11:26 -0000 Folks, The MIT-KIT annual conference will be on "Personal Data on the Internet", a topic which is getting intense interest recently in the news media. The date is Monday 7 October 2013, at the MIT Media Lab. You are cordially invited. Registration is free. Please email me (hardjono[AT]mit.edu) if you are interested in attending. cheers, /thomas/ --------------------------------------------- 2013 MIT Kerberos & Internet Trust Conference --------------------------------------------- Theme: "Personal Data on the Internet: The New Deal on Data" Co-hosted by Prof Sandy Pentland from the MIT Media Lab Date: 7 October 2013 (Monday) Time: 9AM - 6PM Venue: MIT Media Lab, Building E14 Multifunction Room, 6th Floor Corner of Ames & Amherst Sts. Map: http://whereis.mit.edu/?go=3DE14 Social Event: 6PM to 8PM, MIT Media Lab, Bldg E14 Silverman Skyline room (6th Floor) Program: http://kit.mit.edu/conference-program Registration (free): http://kit.mit.edu/events http://kit.mit.edu/events/annual-conference We look forward to seeing you at the 2013 MIT-KIT Conference. Regards. /thomas/ ____________________________________________ Thomas Hardjono MIT Consortium for Kerberos & Internet Trust e: hardjono[at]mit.edu m: +1 781 729 9559 w: kit.mit.edu ____________________________________________ From hannes.tschofenig@nsn.com Mon Sep 9 23:36:53 2013 Return-Path: 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 9E22011E8171 for ; Mon, 9 Sep 2013 23:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlYAEsZYzPgy for ; Mon, 9 Sep 2013 23:36:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3416921F9BC3 for ; Mon, 9 Sep 2013 23:36:49 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r8A6alLn008488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Sep 2013 08:36:47 +0200 Received: from USCHHTC002.nsn-intra.net ([10.159.161.15]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r8A6aOGf029250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 08:36:46 +0200 Received: from USCHHTC003.nsn-intra.net (10.159.161.16) by USCHHTC002.nsn-intra.net (10.159.161.15) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Sep 2013 01:36:35 -0500 Received: from USCHMBX001.nsn-intra.net ([169.254.1.11]) by USCHHTC003.nsn-intra.net ([10.159.161.16]) with mapi id 14.03.0123.003; Tue, 10 Sep 2013 01:36:34 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: ext Thomas Hardjono , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Personal Data Conference at MIT (October 7th, 2013) - MIT-KIT and Media Lab Thread-Index: Ac6tf4sL5x7yDNOfSRaa+KlSs6PjFgAcHkOw Date: Tue, 10 Sep 2013 06:36:34 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2AA336E9@USCHMBX001.nsn-intra.net> References: <5E393DF26B791A428E5F003BB6C5342A3225AF57@OC11EXPO24.exchange.mit.edu> In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A3225AF57@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2312 X-purgate-ID: 151667::1378795007-00003561-C95E5464/0-0/0-0 Subject: Re: [OAUTH-WG] Personal Data Conference at MIT (October 7th, 2013) - MIT-KIT and Media Lab X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 06:36:53 -0000 Hi Thomas,=20 Thanks for sharing.=20 I am wondering whether you can state a bit more about the theme of the conf= erence since the topic is incredibly broad.=20 Ciao Hannes > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of ext Thomas Hardjono > Sent: Monday, September 09, 2013 8:11 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Personal Data Conference at MIT (October 7th, 2013) > - MIT-KIT and Media Lab >=20 >=20 > Folks, >=20 > The MIT-KIT annual conference will be on "Personal Data on the > Internet", > a topic which is getting intense interest recently in the news media. >=20 > The date is Monday 7 October 2013, at the MIT Media Lab. > You are cordially invited. Registration is free. >=20 > Please email me (hardjono[AT]mit.edu) if you are interested in > attending. >=20 >=20 > cheers, >=20 > /thomas/ >=20 >=20 > --------------------------------------------- > 2013 MIT Kerberos & Internet Trust Conference > --------------------------------------------- >=20 > Theme: "Personal Data on the Internet: The New Deal on Data" >=20 > Co-hosted by Prof Sandy Pentland from the MIT Media Lab >=20 > Date: 7 October 2013 (Monday) >=20 > Time: 9AM - 6PM >=20 > Venue: MIT Media Lab, Building E14 > Multifunction Room, 6th Floor > Corner of Ames & Amherst Sts. >=20 > Map: http://whereis.mit.edu/?go=3DE14 >=20 >=20 > Social Event: 6PM to 8PM, MIT Media Lab, Bldg E14 > Silverman Skyline room (6th Floor) >=20 > Program: >=20 > http://kit.mit.edu/conference-program >=20 >=20 > Registration (free): >=20 > http://kit.mit.edu/events >=20 > http://kit.mit.edu/events/annual-conference >=20 >=20 > We look forward to seeing you at the 2013 MIT-KIT Conference. >=20 >=20 > Regards. >=20 > /thomas/ >=20 >=20 >=20 >=20 >=20 > ____________________________________________ > Thomas Hardjono > MIT Consortium for Kerberos & Internet Trust > e: hardjono[at]mit.edu > m: +1 781 729 9559 > w: kit.mit.edu > ____________________________________________ >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Tue Sep 10 07:26:57 2013 Return-Path: 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 B234D11E81D0 for ; Tue, 10 Sep 2013 07:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Boh7bCaacDyA for ; Tue, 10 Sep 2013 07:26:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 636C411E81B7 for ; Tue, 10 Sep 2013 07:26:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r8AEQXGg008925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Sep 2013 16:26:33 +0200 Received: from USCHHTC001.nsn-intra.net ([10.159.161.14]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r8AEQO05003655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Sep 2013 16:26:33 +0200 Received: from USCHHTC004.nsn-intra.net (10.159.161.17) by USCHHTC001.nsn-intra.net (10.159.161.14) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Sep 2013 09:26:30 -0500 Received: from USCHMBX001.nsn-intra.net ([169.254.1.11]) by USCHHTC004.nsn-intra.net ([10.159.161.17]) with mapi id 14.03.0123.003; Tue, 10 Sep 2013 09:26:30 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "oauth@ietf.org" Thread-Topic: Next steps on the OAuth Assertion Drafts Thread-Index: Ac6uKyKB5V+iuMO1SeCJM7UwusBI5A== Date: Tue, 10 Sep 2013 14:26:29 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1855 X-purgate-ID: 151667::1378823193-00003561-146DF74B/0-0/0-0 Subject: [OAUTH-WG] Next steps on the OAuth Assertion Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:26:58 -0000 Hi all,=20 I am trying to wrap up the assertion documents and I took a look at the mee= ting minutes from the Berlin IETF meeting and the actions are as follows: ** John & Torsten: Please post your document review to the list. ** Authors of draft-ietf-oauth-saml2-bearer: Please provide the additional = SAML related text (as discussed during the meeting) and submit an updated d= ocument.=20 Ciao Hannes ------- copy from the minutes -------- * Assertions (BC) https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ - WGLC ends by 8/8 - BL on WGLC comments: talked to MJ about how to achieve interop. - BL: describe how you could combine specifications to make at least on= e interoperable specification - MJ: profiles exists for both SAML and OpenIDC. those are not IETF spe= cifications though - BL: ok to point to external doc from either of the I-Ds in question - MJ: very achievable - BL: all should go to the IESG at the same time to establish context - PHO: is this for the IESG benefit or for future developers - BL: the latter - PHO: talk to Heather Flanagan or the IANA - they have talked about ha= ving long-term access to external documents - BL: ok will consider that - or we can copy text into WG wiki - BC: interop does not require external profiles actually - TL: same experience at DT with the JSON-based assertion format - no a= ddl profiles are needed - MJ: a SAML deployment needs agreement on certain SAML-specific conven= tions - this is what BL is referring to - BC: right - TN: so just refer to the SAML specs - BL: maybe enough - JB and TL volunteered to make a review. From hannes.tschofenig@nsn.com Tue Sep 10 07:27:22 2013 Return-Path: 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 D3C8511E81D1 for ; Tue, 10 Sep 2013 07:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+srRer9J0tb for ; Tue, 10 Sep 2013 07:27:18 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1411E81D2 for ; Tue, 10 Sep 2013 07:26:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r8AEQr5B001731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Sep 2013 16:26:53 +0200 Received: from USCHHTC002.nsn-intra.net ([10.159.161.15]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r8AEQXqb003858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Sep 2013 16:26:53 +0200 Received: from USCHMBX001.nsn-intra.net ([169.254.1.11]) by USCHHTC002.nsn-intra.net ([10.159.161.15]) with mapi id 14.03.0123.003; Tue, 10 Sep 2013 09:26:31 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "oauth@ietf.org" Thread-Topic: Next Steps for the JSON Web Token Document Thread-Index: Ac6uLCi0s+NnkeGAQiKoedy9ftGvOA== Date: Tue, 10 Sep 2013 14:26:31 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2AA3396C@USCHMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 725 X-purgate-ID: 151667::1378823214-0000471E-72CFB4C0/0-0/0-0 Subject: [OAUTH-WG] Next Steps for the JSON Web Token Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:27:23 -0000 Hi again,=20 I also checked the minutes from IETF#87 regarding the JWT and here are the = action items: ** I issued a WGLC, as discussed during the meeting: http://www.ietf.org/ma= il-archive/web/oauth/current/msg11894.html=20 ** We got some reviews from James, and Prateek. Thanks, guys! Here are the reviews: http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html (James) http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html (Prateek) During the meeting a few others, namely Torsten, Karen, Paul Hoffman, and = Brian volunteered to provide their review comments. Please send your review= to the list.=20 ** I will have to do my shepherd write-up as well.=20 Ciao Hannes From torsten@lodderstedt.net Tue Sep 10 10:37:42 2013 Return-Path: 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 A1A0421E815F for ; Tue, 10 Sep 2013 10:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTnzZuZ2Zrc0 for ; Tue, 10 Sep 2013 10:37:38 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by ietfa.amsl.com (Postfix) with ESMTP id AB60821E8164 for ; Tue, 10 Sep 2013 10:37:34 -0700 (PDT) Received: from [80.187.106.174] (helo=[100.88.61.187]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1VJRsY-0000LH-BU; Tue, 10 Sep 2013 19:37:31 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2AA3396C@USCHMBX001.nsn-intra.net> References: <1373E8CE237FCC43BCA36C6558612D2AA3396C@USCHMBX001.nsn-intra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----OYMFZ7A8YWMTBDGTSMXEJC4QMPHNIE" From: Torsten Lodderstedt Date: Tue, 10 Sep 2013 19:37:23 +0200 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "oauth@ietf.org" Message-ID: <674edbf8-2891-45ef-bc26-fc6dd3399e78@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] Next Steps for the JSON Web Token Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:37:42 -0000 ------OYMFZ7A8YWMTBDGTSMXEJC4QMPHNIE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit No comments - everything is fine "Tschofenig, Hannes (NSN - FI/Espoo)" schrieb: >Hi again, > >I also checked the minutes from IETF#87 regarding the JWT and here are >the action items: > >** I issued a WGLC, as discussed during the meeting: >http://www.ietf.org/mail-archive/web/oauth/current/msg11894.html > >** We got some reviews from James, and Prateek. Thanks, guys! >Here are the reviews: >http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html >(James) >http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html >(Prateek) > >During the meeting a few others, namely Torsten, Karen, Paul Hoffman, >and Brian volunteered to provide their review comments. Please send >your review to the list. > >** I will have to do my shepherd write-up as well. > >Ciao >Hannes > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------OYMFZ7A8YWMTBDGTSMXEJC4QMPHNIE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No comments - everything is fine



"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> schrieb:
Hi again, 

I also checked the minutes from IETF#87 regarding the JWT and here are the action items:

** I issued a WGLC, as discussed during the meeting: http://www.ietf.org/mail-archive/web/oauth/current/msg11894.html 

** We got some reviews from James, and Prateek. Thanks, guys!
Here are the reviews:
http://www.ietf.org/mail-archive/web/oauth/current/msg11905.html (James)
http://www.ietf.org/mail-archive/web/oauth/current/msg12003.html (Prateek)

During the meeting a few others, namely Torsten, Karen, Paul Hoffman, and Brian volunteered to provide their review comments. Please send your review to the list. 

** I will have to do my shepherd write-up as wel
 l. 

Ciao
Hannes


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------OYMFZ7A8YWMTBDGTSMXEJC4QMPHNIE-- From bcampbell@pingidentity.com Tue Sep 10 11:38:44 2013 Return-Path: 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 0664B21F9B66 for ; Tue, 10 Sep 2013 11:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwCPX2TdU56a for ; Tue, 10 Sep 2013 11:38:39 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id 31EF621F9CC6 for ; Tue, 10 Sep 2013 11:38:38 -0700 (PDT) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKUi9nLmZrKzEpIJKae56JmR0BVnLDmVat@postini.com; Tue, 10 Sep 2013 11:38:39 PDT Received: by mail-ie0-f174.google.com with SMTP id k10so8627606iea.33 for ; Tue, 10 Sep 2013 11:38:38 -0700 (PDT) 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:content-transfer-encoding; bh=p7mgWzDR9adNWJPh0FuVxMpulkOxzuj4DaQqnl9+LB0=; b=AeHYEKVNhw42Rdh5vlqPpjAUrdaNnv6vFwTQKSPuvJ7est8/aNwxmyn8yYVc1ONslA +bXQ5Vew58KjwPRTzx7ZTpRkTXaK5aLl11Mm5dBshrDH6ByMXk0zdiTIKNtA8WgAZ4F4 8OJLRvtU1CKJja/kqfP3A3dDfsuqNtRTyzNhWqHSg6qqbTr9oXzlPKshF9VroriY4Xjk qMZk9q3G5NeXOO/+TVKyp/KyFpJZtL+z2cmpqF8pPQ40RVhBihMq/Pew6GtTSL9NTjM1 kLyupIZmuJv1u6wml3S5wJw4bvDYg9xHtcPV/goHKpki9Pt8Ee9g+NAzq0tEu8ZQxQ4M QKog== X-Gm-Message-State: ALoCoQmErLw7O2hmGi9srqg5/0Q9tzHWjjFbBmrMIiptXZvb3DW7UNiy4MMZ+8oR0j+kVoQExhhnu3T3BZkjzHdBN8MRL7mJqC6/ody3exApyh7AvspgTW1W07ePSB70EFHup3ok8RZaN4vL9Wx4pt2lmwDMm+s/mA== X-Received: by 10.50.36.5 with SMTP id m5mr11068308igj.3.1378838318255; Tue, 10 Sep 2013 11:38:38 -0700 (PDT) X-Received: by 10.50.36.5 with SMTP id m5mr11068305igj.3.1378838318110; Tue, 10 Sep 2013 11:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.232.229 with HTTP; Tue, 10 Sep 2013 11:38:08 -0700 (PDT) In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> References: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> From: Brian Campbell Date: Tue, 10 Sep 2013 12:38:08 -0600 Message-ID: To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:38:44 -0000 Regarding the second item about additional SAML related text - such text already exists in the document in =A75 [quoted and linked below]. It's unclear to me what else is being asked for here? I'd like to request that some specific and concrete text be proposed, if anyone believes the current wording is insufficient. from tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-17#section-5 "5. Interoperability Considerations Agreement between system entities regarding identifiers, keys, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: values for the issuer and audience identifiers, the location of the token endpoint, and the key used to apply and verify the digital signature over the assertion. The exchange of such information is explicitly out of scope for this specification and typical deployment of it will be done alongside existing SAML Web SSO deployments that have already established a means of exchanging such information. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common method of exchanging SAML related information about system entities." Thanks, Brian On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > I am trying to wrap up the assertion documents and I took a look at the m= eeting minutes from the Berlin IETF meeting and the actions are as follows: > > ** John & Torsten: Please post your document review to the list. > > ** Authors of draft-ietf-oauth-saml2-bearer: Please provide the additiona= l SAML related text (as discussed during the meeting) and submit an updated= document. > > Ciao > Hannes > > ------- copy from the minutes -------- > > * Assertions (BC) > https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > - WGLC ends by 8/8 > - BL on WGLC comments: talked to MJ about how to achieve interop. > - BL: describe how you could combine specifications to make at least = one interoperable specification > - MJ: profiles exists for both SAML and OpenIDC. those are not IETF s= pecifications though > - BL: ok to point to external doc from either of the I-Ds in question > - MJ: very achievable > - BL: all should go to the IESG at the same time to establish context > - PHO: is this for the IESG benefit or for future developers > - BL: the latter > - PHO: talk to Heather Flanagan or the IANA - they have talked about = having long-term access to external documents > - BL: ok will consider that - or we can copy text into WG wiki > - BC: interop does not require external profiles actually > - TL: same experience at DT with the JSON-based assertion format - no= addl profiles are needed > - MJ: a SAML deployment needs agreement on certain SAML-specific conv= entions - this is what BL is referring to > - BC: right > - TN: so just refer to the SAML specs > - BL: maybe enough > - JB and TL volunteered to make a review. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sunilpal73@gmail.com Wed Sep 11 23:22:19 2013 Return-Path: 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 8551711E8173 for ; Wed, 11 Sep 2013 23:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRHGgzGR3d4w for ; Wed, 11 Sep 2013 23:22:14 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39BFF11E8160 for ; Wed, 11 Sep 2013 23:22:09 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id mz10so3944273bkb.17 for ; Wed, 11 Sep 2013 23:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CA/vtfRHWTx7fAizt87Muoz3uhIb/jNegLoR/4P1f1Y=; b=q7Yshy5OkRf62ubTrF5avjiChXQjsf4sFTJuSDTuPclepih1VSvCcghEaWM3M+33CM 4yY6EsS0k4ypc2U2HZyN8LfGlc6hIUBsgSws0x91a5WkhGPcY+CVxPDrtJILLaCwkhOV 3U3KECbLpyUzLCJQfBXHI6epx5KAqVai4BqeYe4K8f2iTLSF6MOXrxRUnt8vY8QhtNGK asjn8N/cu4U54xSwSPzZeoyaxrAkPYbLQhLEaTGzL6CNzXQbQXeY5XfvXN1QxKPBHSLF d8baMH61IES98eRr21MUgoyUed539lfaXISFuKA0sxjcC/VCFgZ6RuVRtbNg0DZDkAnt auuQ== MIME-Version: 1.0 X-Received: by 10.205.65.208 with SMTP id xn16mr47837bkb.31.1378966928261; Wed, 11 Sep 2013 23:22:08 -0700 (PDT) Received: by 10.204.103.3 with HTTP; Wed, 11 Sep 2013 23:22:08 -0700 (PDT) Date: Thu, 12 Sep 2013 11:52:08 +0530 Message-ID: From: Sunil Pal To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary=bcaec5430dd6eab74504e629c19a Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 07:03:06 -0000 --bcaec5430dd6eab74504e629c19a Content-Type: text/plain; charset=ISO-8859-1 --- Thanks And Warm Regards Sunil Kumar Pal --bcaec5430dd6eab74504e629c19a Content-Type: text/html; charset=ISO-8859-1

---
Thanks And Warm Regards
Sunil Kumar Pal

--bcaec5430dd6eab74504e629c19a-- From sunilpal73@gmail.com Thu Sep 12 00:05:40 2013 Return-Path: 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 D9EDC11E824C for ; Thu, 12 Sep 2013 00:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.767 X-Spam-Level: X-Spam-Status: No, score=0.767 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, NO_RELAYS=-0.001, SARE_URI_CONS9=1.666, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcuCFPhaGdKa for ; Thu, 12 Sep 2013 00:05:39 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85A11E8175 for ; Thu, 12 Sep 2013 00:05:38 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id e11so3911652bkh.39 for ; Thu, 12 Sep 2013 00:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O/FuLsr6rYT6rQk7lb7Axb9g4FdeDfEXsLjMm41i9GY=; b=sjUS/Qeey1MdSRuwqQ02vEwjwKnPgN1CXY0aYBzxStMrsyfr++CPzaqV+WTORNmAnZ 51kmGF8yjcNUMog+17u8l5VsIzAOOdSXDPS4cmBxAaI5KJR1mb6R9wh2KksLDK1kpSGb CzDdCLml6rrZ//OIJVbHmyV6Sw+j13XuNYJn6dXgKpExSlAgCCQukkghlKFJBOUAURqB uvzF5Va1d5RCFxTH5A8Exjm4zF74xOfLlMq4Zu5Soaa/tnsr05nL6qYMFzGcDC88kMxa Q8beqoDtNIVyfzuDdb7UVV40L6elIO5q5ROdm7CU2P+i/GUW6ZVcZxliGc+ZML92lwS0 DO6A== MIME-Version: 1.0 X-Received: by 10.204.71.133 with SMTP id h5mr5179905bkj.0.1378969537392; Thu, 12 Sep 2013 00:05:37 -0700 (PDT) Received: by 10.204.103.3 with HTTP; Thu, 12 Sep 2013 00:05:37 -0700 (PDT) Date: Thu, 12 Sep 2013 12:35:37 +0530 Message-ID: From: Sunil Pal To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b8747ca6ee1e704e62a5d73 Subject: [OAUTH-WG] Oauth signature problem X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 07:05:41 -0000 --047d7b8747ca6ee1e704e62a5d73 Content-Type: text/plain; charset=ISO-8859-1 How to generate the correct oauth_signature in apex.Here is the code for generating oauth_nonce, oauth_timestamp and oauth_signature. But not getting the correct oauth_signature // Generate a unique combination of numbers and alphabets for oauth-nonce String nonce = String.valueOf(Crypto.getRandomLong()); Blob key = Blob.valueOf(nonce); String Keyy = 'XXXXXXXXXXXXXXXX'; Long timee=DateTime.now().getTime(); Integer random = Crypto.getRandomInteger(); Integer time2 = integer.valueOf(timee) +random; String str2= string.valueOf(time2); Blob key2= Blob.valueOf(str2); Blob keyHash = Crypto.generateDigest('MD5',key2); String hexDigest = EncodingUtil.convertToHex(keyHash); // Generate timestamp for current time String timestamp = String.valueOf(DateTime.now().getTime()/1000); // Create map for maintaining the parameters used to create signature map parameters = new Map(); parameters.put('oauth_consumer_key','ZZZZZZZZZZZZ'); parameters.put('oauth_signature_method','HMAC-SHA1'); parameters.put('oauth_timestamp',timestamp); parameters.put('oauth_nonce',hexDigest); parameters.put('oauth_version','1.0'); // Form the gneral HttpRequest Http h = new Http(); HttpRequest req = new HttpRequest(); req.setMethod('GET'); req.setEndpoint('https://YYYYYYYYYYY.com/people/1234567/identity'); String host = req.getEndpoint(); Integer n = host.indexOf('?'); List keys = new List(); keys.addAll(parameters.keySet()); keys.sort(); String str = keys.get(0)+'='+parameters.get(keys.get(0)); for(Integer i=1;iHow to generate= the correct oauth_signature in apex.Here is the code for generating oauth_= nonce, oauth_timestamp and oauth_signature. But not getting the correct oau= th_signature

// Generate a unique combination of numbers and alphabets for oauth-nonce
String nonce =3D String.valueOf(Crypto.getRandomLong());
Blob key =3D Blob.valueOf(nonce);
String Keyy =3D 'XXXXXXXXXXXXXXXX';
Long timee=3DDateTime.now().getTime();
Integer random =3D Crypto.getRandomInteger();
Integer time2 =3D integer.valueOf(timee) +random;
String str2=3D string.valueOf(time2);
Blob key2=3D Blob.valueOf(str2);
Blob keyHash =3D Crypto.generateDigest('MD5',key2);
String hexDigest =3D EncodingUtil.convertToHex(keyHash);
// Generate timestamp for current time
String timestamp =3D String.valueOf(DateTime.now().getTime()/1000);
// Create map for maintaining the parameters used to create signature
map<String, String> parameters =3D new Map<String, String>();
parameters.put('oauth_consumer_key','ZZZZZZZZZZZZ');
parameters.put('oauth_signature_method','HMAC-SHA1');
parameters.put('oauth_timestamp',timestamp);
parameters.put('oauth_nonce',hexDigest);
parameters.put('oauth_version','1.0');
// Form the gneral HttpRequest
Http h =3D new Http();
HttpRequest req =3D new HttpRequest();
req.setMethod('GET');
req.setEndpoint('https://YYYYYYYYYYY.com/people/1234567/identity');
String host =3D req.getEndpoint();
Integer n =3D host.indexOf('?');
List<String> keys =3D new List<String>();
keys.addAll(parameters.keySet());
keys.sort();
String str =3D keys.get(0)+'=3D'+parameters.get(keys.get(0));
for(Integer i=3D1;i<keys.size();i++)=20
{
    str =3D str +'&'+keys.get(i)+'=3D'+parameters.get(k=
eys.get(i));
}
String s =3D  req.getMethod().toUpperCase()+ '&' +=20
			EncodingUtil.urlEncode(host, 'UTF-8') +'&'+
			EncodingUtil.urlEncode(str, 'UTF-8');
Blob sig =3D Crypto.generateMac('Hmac-SHA1', Blob.valueOf(s), Blob.=
valueOf(Keyy));
Blob signature1 =3D Blob.valueOf(EncodingUtil.convertToHex(sig));
String signature =3D EncodingUtil.base64encode(signature1);
req.setEndpoint('https://XXXXXXXXX.com/people/1234567/identity?oauth_version=3D1.0=
&oauth_nonce=3D'+hexDigest+'&oauth_timestamp=3D'+timest=
amp+'&oauth_consumer_key=3DZZZZZZZZZZZZZ&oauth_signature_method=
=3DHMAC-SHA1&oauth_signature=3D'+signature+'');
HttpResponse res =3D h.send(req);
System.debug('Response from request token request: ('+res.getStatus=
Code()+')'+res.getBody());

---
Thanks And Warm Regards
S= unil Kumar Pal

--047d7b8747ca6ee1e704e62a5d73-- From hannes.tschofenig@nsn.com Thu Sep 12 01:07:16 2013 Return-Path: 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 8E87721E814C for ; Thu, 12 Sep 2013 01:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8J3mTM56kJB for ; Thu, 12 Sep 2013 01:07:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD9311E8160 for ; Thu, 12 Sep 2013 01:07:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r8C876cp005746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Sep 2013 10:07:06 +0200 Received: from USCHHTC002.nsn-intra.net ([10.159.161.15]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r8C874Hm028372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Sep 2013 10:07:05 +0200 Received: from USCHHTC003.nsn-intra.net (10.159.161.16) by USCHHTC002.nsn-intra.net (10.159.161.15) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Sep 2013 03:07:03 -0500 Received: from USCHMBX001.nsn-intra.net ([169.254.1.11]) by USCHHTC003.nsn-intra.net ([10.159.161.16]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 03:07:03 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: oauth mailing list Thread-Topic: My review of draft-ietf-oauth-json-web-token-11 Thread-Index: Ac6vjw+PfFfBOYKFQc62YXcVMPsr5Q== Date: Thu, 12 Sep 2013 08:07:02 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2AA347D1@USCHMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.161.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7274 X-purgate-ID: 151667::1378973226-0000471E-4DDD8149/0-0/0-0 Subject: [OAUTH-WG] My review of draft-ietf-oauth-json-web-token-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 08:07:16 -0000 Hi Mike, Hi all,=20 As part of preparing the shepherd write-up I have read the draft and here a= re a few comments.=20 In general, the draft looks good. The comments are fairly minor.=20 1. Section 4: JWT Claims In the first paragraph you write:=20 "=20 The Claim Names within a JWT Claims Set MUST be unique; recipients MUST eit= her reject JWTs with duplicate Claim Names or use a JSON parser that return= s only the lexically last duplicate member name "=20 I think what you want to write here is that the sender of a JWT must ensure= that the claims are unique. If a JWT is, however, received with non-unique= claims then some decision must be taken. You list two choices and I am won= dering why not just have one. Let's just reject the JWT if that happens to = ensure consistent behavior.=20 I believe it might be good to clarify that unique here means that claims ma= y appear more than once in a JWT but you are concerned about having two cla= ims that actually have a different semantic. Correct?=20 You write: "However, in the absence of such requirements, all claims that a= re not understood by implementations SHOULD be ignored." The 'SHOULD' is not good enough here. Either you ignore claims that you don= 't understand or you do something else. Since there does not seem to be a w= ay to declare claims as "critical" to understand I suggest to turn this int= o a MUST.=20 With every claim you add "Use of this claim is OPTIONAL.". I would suggest = to move that sentence to the front and avoid repeating it with every claim.= In fact you have that necessary sentence currently in Section 4.1 "None of= the claims defined below are intended to be mandatory to use, but rather, = provide a starting point for a set of useful, interoperable claims." Since you describe the "use" there is obviously the question about the "imp= lementation". So, what claims in this document are mandatory to implement? = All? None? Claim Types: You distinguish between three types of claims, namely Reserved= Claim Names, Public Claim Names, and Private Claim Names.=20 - Reserved claims are those that are registered with IANA.=20 - Public Claims are (interestingly enough) also registered via IANA or use= a Collision Resistant Namespace.=20 - Private Claims are those that may produce collisions Clear I would suggest to change the definition of a public claim. Let's jus= t call the claims that are registered via IANA reserved claims.=20 I also wonder why we need private claims at all when it is so easy to const= ruct public claims?=20 Section 4.1.1: "iss" (Issuer) Claim You write: " The iss (issuer) claim identifies the principal that issued the JWT. The pr= ocessing of this claim is generally application specific. " Would it be useful to say what people use this claim for. It might also be = useful to indicate that this value cannot be relied on for any trust or acc= ess control decisions without proper cryptographic assurance. I can already= see people who base their security decisions on this value without any rel= ationship to the actual crypto of the JWT. So, one might wonder what the re= lationship of the crypto and the iss claim is.=20 Section 4.1.3: "aud" (Audience) Claim You write: " The aud (audience) claim identifies the audiences that the JWT is intended = for. " That's not a good description. You could instead write: "The aud (audience)= claim identifies the recipient the JWT is intended for."=20 You write: " In the special case when the JWT has one audience, the aud value MAY be a s= ingle case sensitive string containing a StringOrURI value. " Shouldn't this read: " In the special case when the JWT has one audience, the aud value is a singl= e case sensitive string containing a StringOrURI value. " Section 4.1.8. "typ" (Type) Claim You write: " The typ (type) claim MAY be used to declare a type for the contents of this= JWT Claims Set in an application-specific manner in contexts where this is= useful to the application. The typ value is a case sensitive string. Use o= f this claim is OPTIONAL. The values used for the typ claim come from the same value space as the typ= header parameter, with the same rules applying. " I believe the first sentence should say: "The typ (type) claim is used to d= eclare a type for the contents of this JWT Claims Set ....". I don't unders= tand what the "MAY" here was supposed to indicate since if it does not decl= are the type of the claims then what else does it do?=20 Why is the typ claim actually there when there is already the same claim in= the header?=20 Section 5.1. "typ" (Type) Header Parameter You write: " The typ (type) header parameter MAY be used to declare the type of this JWT= in an application-specific manner in contexts where this is useful to the = application. This parameter has no effect upon the JWT processing. If prese= nt, it is RECOMMENDED that its value be either JWT or urn:ietf:params:oauth= :token-type:jwt to indicate that this object is a JWT. "=20 Here again I would write: " The typ (type) header parameter is used to decl= are the type of this JWT in an application-specific manner in contexts wher= e this is useful to the application." Why doesn't this value have any impact on the processing? It appears to be = useless? Would it be good to mandate that it is set to JWT or urn:ietf:para= ms:oauth:token-type:jwt when the content is a JWT? Why do you leave two opt= ions for what the value is set to? Why would anyone use the longer string?= =20 Section 5.2. "cty" (Content Type) Header Parameter What is the relationship between cty and typ?=20 Section 5.3. Replicating Claims as Header Parameters I am not sure why you would want to have encryption of the claims and then = again include them in cleartext. That would defeat the purpose of encryptio= n. Then, you could as well just provide them in cleartext (only signed, for= example).=20 Putting the sub value into the header does not seem to be a good idea since= this may be personal data. Putting these fields into the header in general does not strike me as a goo= d idea since you loose the ability to sign these values. They will be expos= ed to all security threats since they cannot be protected. Why not use a ne= sted JWT instead?=20 The 'SHOULD' in this sentence particularly makes me nervous: "If such repli= cated Claims are present, the application receiving them SHOULD verify that= their values are identical." This essentially means that if you have prote= cted claims and someone adds unprotected stuff into the header it may mean = that an application would accept that. Not a good idea! Section 6 Plaintext JWTs Why do we want plaintext JWTs? I thought that the threat analysis concluded= that sending this stuff of information around without any security protect= ion is a bad idea. Section 7. Rules for Creating and Validating a JWT I am curious why this section is so extensive given that we are essentially= just applying JWS and JWE here. Wouldn't a pointer to the JWS/JWE spec be = sufficient?=20 Ciao Hannes From Michael.Jones@microsoft.com Thu Sep 19 07:49:56 2013 Return-Path: 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 CF21021F9371 for ; Thu, 19 Sep 2013 07:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXiroIQEMYAk for ; Thu, 19 Sep 2013 07:49:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 825B321F938E for ; Thu, 19 Sep 2013 07:49:51 -0700 (PDT) Received: from BLUPR03CA032.namprd03.prod.outlook.com (10.141.30.25) by BLUPR03MB034.namprd03.prod.outlook.com (10.255.209.146) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 19 Sep 2013 14:49:49 +0000 Received: from BY2FFO11FD003.protection.gbl (2a01:111:f400:7c0c::198) by BLUPR03CA032.outlook.office365.com (2a01:111:e400:879::25) with Microsoft SMTP Server (TLS) id 15.0.775.9 via Frontend Transport; Thu, 19 Sep 2013 14:49:49 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.775.5 via Frontend Transport; Thu, 19 Sep 2013 14:49:48 +0000 Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.39]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Thu, 19 Sep 2013 14:48:39 +0000 From: Mike Jones To: Brian Campbell , "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [OAUTH-WG] Next steps on the OAuth Assertion Drafts Thread-Index: Ac6uKyKB5V+iuMO1SeCJM7UwusBI5AAKcJUAAbuZleA= Date: Thu, 19 Sep 2013 14:48:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394371FEB121@TK5EX14MBXC290.redmond.corp.microsoft.com> References: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(377454003)(53754006)(164054003)(24454002)(13464003)(199002)(189002)(74662001)(69226001)(47446002)(81342001)(31966008)(79102001)(74502001)(53806001)(76482001)(50986001)(66066001)(6806004)(80022001)(51856001)(4396001)(44976005)(33656001)(77982001)(49866001)(46102001)(47976001)(47776003)(47736001)(19580395003)(56816003)(83072001)(83322001)(54316002)(74366001)(74876001)(74706001)(80976001)(59766001)(20776003)(15975445006)(56776001)(55846006)(63696002)(76786001)(81542001)(76796001)(50466002)(19580405001)(23756003)(77096001)(65816001)(81816001)(81686001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB034; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09749A275C X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:49:56 -0000 I also think that the text is already there and these specs are ready to pr= ogress as-is. If anyone disagrees, please let us know what text needs to b= e changed or added. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Tuesday, September 10, 2013 11:38 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts Regarding the second item about additional SAML related text - such text al= ready exists in the document in =A75 [quoted and linked below]. It's unclear to me what else is being asked for here? I'd like to request that some specific and concrete text be proposed, if an= yone believes the current wording is insufficient. from tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-17#section-5 "5. Interoperability Considerations Agreement between system entities regarding identifiers, keys, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: values for the issuer and audience identifiers, the location of the token endpoint, and the key used to apply and verify the digital signature over the assertion. The exchange of such information is explicitly out of scope for this specification and typical deployment of it will be done alongside existing SAML Web SSO deployments that have already established a means of exchanging such information. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common method of exchanging SAML related information about system entities." Thanks, Brian On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > I am trying to wrap up the assertion documents and I took a look at the m= eeting minutes from the Berlin IETF meeting and the actions are as follows: > > ** John & Torsten: Please post your document review to the list. > > ** Authors of draft-ietf-oauth-saml2-bearer: Please provide the additiona= l SAML related text (as discussed during the meeting) and submit an updated= document. > > Ciao > Hannes > > ------- copy from the minutes -------- > > * Assertions (BC) > https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > - WGLC ends by 8/8 > - BL on WGLC comments: talked to MJ about how to achieve interop. > - BL: describe how you could combine specifications to make at least = one interoperable specification > - MJ: profiles exists for both SAML and OpenIDC. those are not IETF s= pecifications though > - BL: ok to point to external doc from either of the I-Ds in question > - MJ: very achievable > - BL: all should go to the IESG at the same time to establish context > - PHO: is this for the IESG benefit or for future developers > - BL: the latter > - PHO: talk to Heather Flanagan or the IANA - they have talked about = having long-term access to external documents > - BL: ok will consider that - or we can copy text into WG wiki > - BC: interop does not require external profiles actually > - TL: same experience at DT with the JSON-based assertion format - no= addl profiles are needed > - MJ: a SAML deployment needs agreement on certain SAML-specific conv= entions - this is what BL is referring to > - BC: right > - TN: so just refer to the SAML specs > - BL: maybe enough > - JB and TL volunteered to make a review. > _______________________________________________ > 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 From hannes.tschofenig@gmx.net Thu Sep 19 08:10:09 2013 Return-Path: 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 BB97121F9767 for ; Thu, 19 Sep 2013 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPb0fS1f-13d for ; Thu, 19 Sep 2013 08:10:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7239C21F994A for ; Thu, 19 Sep 2013 08:10:03 -0700 (PDT) Received: from [10.255.130.67] ([194.251.119.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MMYZG-1VGcOV0n1S-008NFu for ; Thu, 19 Sep 2013 17:10:01 +0200 Message-ID: <523B13BE.7020007@gmx.net> Date: Thu, 19 Sep 2013 18:09:50 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> <4E1F6AAD24975D4BA5B168042967394371FEB121@TK5EX14MBXC290.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394371FEB121@TK5EX14MBXC290.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wNWj0WYQ+AotbFBWpd0mCIwyd1e8bafDaVqpsfW4rhxBgZHbB1A TbmysXO1jL9M+aWavE2qY+4ayPi9HiUIacMWwcyMpea52R5QdUQANWUEnJToMPn1rdju8IG Y5/tNJJ1zRyqWEphakRa5vvJ3aEum+Xx1nhzm9zrsISEaSnG2ZI1A+xmnu00LoBmmegIJLb 7U5wRe5SE1gQqmM41RAEA== Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:10:09 -0000 On 19.09.2013 17:48, Mike Jones wrote: > I also think that the text is already there and these specs are ready > to progress as-is. If anyone disagrees, please let us know what text > needs to be changed or added. I dropped Barry a mail and I will have to carefully re-read the documents myself in preparation for the shepherd writeup. Ciao Hannes From odonoghue@isoc.org Fri Sep 20 08:35:31 2013 Return-Path: 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 0B8E721F9BB6 for ; Fri, 20 Sep 2013 08:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQCeL3U+vEFr for ; Fri, 20 Sep 2013 08:35:26 -0700 (PDT) Received: from smtp142.ord.emailsrvr.com (smtp142.ord.emailsrvr.com [173.203.6.142]) by ietfa.amsl.com (Postfix) with ESMTP id EED0C21F9BB1 for ; Fri, 20 Sep 2013 08:35:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id CEC3F200978; Fri, 20 Sep 2013 11:35:23 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp22.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 607C020087E; Fri, 20 Sep 2013 11:35:23 -0400 (EDT) Message-ID: <523C6B3A.50208@isoc.org> Date: Fri, 20 Sep 2013 11:35:22 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Derek Atkins' Subject: [OAUTH-WG] Call for participation - OAuth interoperability and deployment activities X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:35:31 -0000 OAuth community, As some of you are aware, there was an initial plan to have an OAuth 2.0 Interop event at MIT on 31 Oct - 1 Nov 2013. After further discussion, we have decided to postpone this event to early 2014. Instead, we would like to begin discussions related to the planning of this event and a broader range activities supporting oauth interoperability and deployment. The objectives of this activity are to: 1. collect oauth use cases (in particular those beyond OIDC and UMA), 2. develop a generic oauth test API for interoperability testing, 3. develop a test suite for use in interoperability testing, and 4. conduct an open oauth interop event. To this end, we plan to: 1. Establish a mailing list for conversations related to oauth interoperability and deployment. Please join the list and contribute to these activities. oauth-interop@elists.isoc.org 2. Hold a oauth interop planning meeting in Vancouver in conjunction with IETF#88. This meeting is planned for: Sunday, 3 November, 2013, 2:00 pm - 4:00 pm PST (exact location TBD) Further information and documents will be forthcoming. Please join the mailing list and contribute to the conversations. Regards, Karen O'Donoghue Thomas Hardjono Roland Hedberg From hannes.tschofenig@gmx.net Fri Sep 20 09:47:38 2013 Return-Path: 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 9577B21F9A7D for ; Fri, 20 Sep 2013 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCpbbyo8TkQQ for ; Fri, 20 Sep 2013 09:47:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D20F621F9C0D for ; Fri, 20 Sep 2013 09:47:33 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LZhsq-1VkFax1FMa-00lRWz for ; Fri, 20 Sep 2013 18:47:32 +0200 Message-ID: <523C7C17.5080108@gmx.net> Date: Fri, 20 Sep 2013 19:47:19 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: odonoghue@isoc.org References: <523C6B3A.50208@isoc.org> In-Reply-To: <523C6B3A.50208@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OLhVP03C1bCwR48lskR4muoBxqooJdNDThZNwKHthdPclnVB9xD TmdYUV3SkUL4f1XNZdlB3dkcEjJwENdkvbkQRfGsOCMUQc+AFZ8S2UF4zmGbYopdwQCemjj KGuCM7UUi6UZggoFR8OHNC1G4TFl2Q2TvdPcrpLNKuA8xw4nrimuKSgExvkurrk4NLp/1jV d0KVxdwFZEQ4wmbQELDhw== Cc: 'Derek Atkins' , oauth@ietf.org Subject: Re: [OAUTH-WG] Call for participation - OAuth interoperability and deployment activities X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:47:38 -0000 Hi Karen, Roland, Thomas, thanks for putting effort on this interoperability event. The work you are doing (and also the work on the automatic test procedures Roland is involved in) is highly appreciated. I hope that many folks from this group are going to participate in this event and help with the planning. Events like this will help us to improve the quality of our specifications and will give all participants useful insight into the maturity of their implementations. I have always enjoyed these events and you have my full support! Ciao Hannes PS: To sign up to the planning mailing list you can just go to this Webpage and subscribe: https://elists.isoc.org/mailman/listinfo/oauth-interop On 20.09.2013 18:35, Karen O'Donoghue wrote: > OAuth community, > > As some of you are aware, there was an initial plan to have an OAuth 2.0 > Interop event at MIT on 31 Oct - 1 Nov 2013. After further discussion, > we have decided to postpone this event to early 2014. Instead, we would > like to begin discussions related to the planning of this event and a > broader range activities supporting oauth interoperability and deployment. > > The objectives of this activity are to: > 1. collect oauth use cases (in particular those beyond OIDC and UMA), > 2. develop a generic oauth test API for interoperability testing, > 3. develop a test suite for use in interoperability testing, and > 4. conduct an open oauth interop event. > > To this end, we plan to: > > 1. Establish a mailing list for conversations related to oauth > interoperability and deployment. > Please join the list and contribute to these activities. > oauth-interop@elists.isoc.org > > 2. Hold a oauth interop planning meeting in Vancouver in conjunction > with IETF#88. > This meeting is planned for: > Sunday, 3 November, 2013, 2:00 pm - 4:00 pm PST (exact location TBD) > > Further information and documents will be forthcoming. Please join the > mailing list and contribute to the conversations. > > Regards, > Karen O'Donoghue > Thomas Hardjono > Roland Hedberg > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Axel.Nennker@telekom.de Mon Sep 23 04:53:44 2013 Return-Path: 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 9F8CE21F9E54 for ; Mon, 23 Sep 2013 04:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16vG9Xa-OPMS for ; Mon, 23 Sep 2013 04:53:35 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8021F9DD0 for ; Mon, 23 Sep 2013 04:52:25 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 23 Sep 2013 13:52:13 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE113415.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 23 Sep 2013 13:52:11 +0200 From: To: , Date: Mon, 23 Sep 2013 13:52:11 +0200 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt Thread-Index: Ac6qkenYTtQW3aq0THabqnepVgffKQNveMHQ Message-ID: References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> <72735227-DF50-41F0-B744-9ED1706339B5@ve7jtb.com> In-Reply-To: <72735227-DF50-41F0-B744-9ED1706339B5@ve7jtb.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40258D0E7E892HE111541eme_" MIME-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:53:44 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40258D0E7E892HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think that draft-sakimura-oauth-tcse should reference http://tools.ietf.o= rg/html/rfc6819 and especially reference the sections that this draft addre= sses. Regarding Prateek's comment about stateful servers: I think that a stateful= server is the price the AS pays to ensure that the requestor of the code (= A or section 3.3 in http://tools.ietf.org/html/draft-sakimura-oauth-tcse-01= ) is the same as the requestor of the access token (C or 3.5 in the draft)= . It is my interpretation of the purpose of this draft to achieve this goal= (requestor A=3D=3D requestor C). Regarding the hashing: I think that the length of tcs should be restricted.= The draft assumes that an attacker is not able to create a tcs to be used = in step 3.5 that generates the same tcsh that was used in step 3.3. I think= that if the length of tcs is unrestricted then it is easier for the attack= er to generate a new tcs that matches tcsh. The was the case in an attack a= gainst md5. I have no prove for this "feeling" but I think it is harder for= an attacker to find a matching tcs for a given tcsh if the length of tcs i= s fixed or limited. -Axel 1.2. Protocol Flow +--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ Figure 1: Abstract Protocol Flow From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ohn Bradley Sent: Friday, September 06, 2013 1:44 AM To: Nat Sakimura Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oa= uth-tcse-00.txt At this point we don't know of any attack against the request, however that= is not guaranteed to remain the case. If we send the secret in plain text through the browser it likely will neve= r get IETF acceptance. We use HMAC a fair bit already I don't think that would be a significant hu= rdle for clients. The quoted text is trying to prevent the AS from leaking the value back to = the attacker, that would be fatal flaw if it is plaintext, and not optimal= if it is a HMAC. AS could do something like include it in code unencrypted etc, just trying = to prevent that. On 2013-09-05, at 4:34 PM, Nat Sakimura > wrote: Depending on the level of assurance that you might want to achieve, it coul= d have been a random string. That's how some of the existing but widely dep= loyed implementations are doing. I have taken a step forward to do the hashing to give a little more protect= ion that even if a malware on the device captures the request, it would not= be able to use it in time. That's a kind of man-in-the-middle and by that = time happens, your device is fairly badly compromised so there are opinion = that it would not matter much by that time that just a random string would = suffice. If the WG feels that way, I am happy to change it to a random stri= ng as well. The current "hash" design was a middle ground between a random string and H= MAC etc. 2013/9/3 Prateek Mishra > Nat - is there cryptanalysis of the proposed model available anyplace? Extending protocols by throwing in a smidgen of hashing and a tablespoon of= encryption is often a bad idea. One of the strengths of RFC 6749 is that i= t avoids stuff like that. What do you mean when you say - [quote] The server MUST NOT include the "tcsh" value in the form that any entity bu= t itself can extract it. [\quote] Is this even theoretically achievable without a stateful server that mainta= ins a table of [code x tcsh] pairs? If not, how should the server embed tcsh in "code" and what constructions a= re recommended? - prateek As some of you know, passing the authorization code securely to a native ap= p on iOS platform is next to impossible. Malicious application may register= the same custom scheme as the victim application and hope to obtain the co= de, whose success rate is rather high. We have discussed about it during the OpenID Conenct Meeting at IETF 87 on = Sunday, and over a lengthy thread on the OpenID AB/Connect work group list.= I have captured the discussion in the form of I-D. It is pretty short and = hopefully easy to read. IMHO, although it came up as an issue in OpenID Connect, this is a quite us= eful extension to OAuth 2.0 in general. Best, Nat Sakimura ---------- Forwarded message ---------- From: > Date: 2013/7/30 Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt To: Nat Sakimura >, John Brad= ley >, Naveen A= garwal > A new version of I-D, draft-sakimura-oauth-tcse-00.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Filename: draft-sakimura-oauth-tcse Revision: 00 Title: OAuth Transient Client Secret Extension for Public Clients Creation date: 2013-07-29 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-t= cse-00.txt Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 Abstract: The OAuth 2.0 public client utilizing code flow is susceptible to the code interception attack. This specification describe a mechanism that acts as a control against this threat. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CE8995AB5D178F44A2154F5C9A97CAF40258D0E7E892HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I think that draft-sakimura-oauth-tcse should refe= rence http://tools.ietf.org/= html/rfc6819 and especially reference the sections that this draft addr= esses.

 

Regarding Prateek’s comment abou= t stateful servers: I think that a stateful server is the price the AS pays= to ensure that the requestor of the code (A or section 3.3 in http://tools.ietf.o= rg/html/draft-sakimura-oauth-tcse-01 ) is the same as the requestor of = the access token (C or 3.5 in the draft). It is my interpretation of the pu= rpose of this draft to achieve this goal (requestor A=3D=3D requestor C).

 

Regarding the hashing: I think that the length= of tcs should be restricted. The draft assumes that an attacker is not abl= e to create a tcs to be used in step 3.5 that generates the same tcsh that = was used in step 3.3. I think that if the length of tcs is unrestricted the= n it is easier for the attacker to generate a new tcs that matches tcsh. Th= e was the case in an attack against md5. I have no prove for this “fe= eling” but I think it is harder for an attacker to find a matching tc= s for a given tcsh if the length of tcs is fixed or limited.

 

-Axel

 

1.2.  Protocol Flow

 

 

     |  =       |--(A)- Authorization Request ->| &n= bsp; Resource    |

  &nb= sp;  |        |   &n= bsp;            = ;            &n= bsp;  |     Owner     |

     |     = ;   |<-(B)-- Authorization Grant ---|    &= nbsp;          |

     |      =   |           &= nbsp;           &nbs= p;       +---------------+<= /p>

     |       = ; |

     |   &= nbsp;    |        &n= bsp;            &nbs= p;         +---------------+

     |    =     |--(C)-- Authorization Grant -->| Authorization |

     | Client |   = ;            &n= bsp;            = ;   |     Server    |

     |     &= nbsp;  |<-(D)----- Access Token -------|    &nb= sp;          |

     |      &n= bsp; |           &nb= sp;             = ;      +---------------+

     |        = |

     |   &nb= sp;    |        &nbs= p;            &= nbsp;         +---------------+

     |    &n= bsp;   |--(E)----- Access Token ------>|    Res= ource   |

     |&= nbsp;       |     &n= bsp;            = ;             |=      Server    |

&nb= sp;    +--------+       &= nbsp;           &nbs= p;           +-----------= ----+

 

 &nbs= p;            &= nbsp;      Figure 1: Abstract Protocol Flow

 

 

 

From:= oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Joh= n Bradley
Sent: Friday, September 06, 2013 1:44 AM
To: = Nat Sakimura
Cc: oauth
Subject: Re: [OAUTH-WG] Fwd: New= Version Notification for draft-sakimura-oauth-tcse-00.txt

 

At this point we don't know of any attack against the request, however= that is not guaranteed to remain the case.   

 

= If we send the secret in plain text through the browser it likely will neve= r get IETF acceptance. 

=  

We use HMAC a fair bit= already I don't think that would be a significant hurdle for clients.=

 

<= p class=3DMsoNormal>The quoted text is trying to prevent the AS from leakin= g the value back to the attacker,  that would be fatal flaw if it is p= laintext, and not optimal if it is a HMAC.

 

AS could= do something like include it in code unencrypted etc, just trying to preve= nt that.

 

On 2013-09-05, at 4:34 PM, Nat Sakimura <= ;sakimura@gmail.com> wrote:



Depending on the level of assurance that you might want to ach= ieve, it could have been a random string. That's how some of the existing b= ut widely deployed implementations are doing. 

 

I hav= e taken a step forward to do the hashing to give a little more protection t= hat even if a malware on the device captures the request, it would not be a= ble to use it in time. That's a kind of man-in-the-middle and by that time = happens, your device is fairly badly compromised so there are opinion that = it would not matter much by that time that just a random string would suffi= ce. If the WG feels that way, I am happy to change it to a random string as= well. 

 

The current "hash" design wa= s a middle ground between a random string and HMAC etc. 

=  

2013/9/3 Prateek Mishra <prateek.mishra@or= acle.com>

Nat - is there cry= ptanalysis of the proposed model available anyplace?

Extending proto= cols by throwing in a smidgen of hashing and a tablespoon of encryption is = often a bad idea. One of the strengths of RFC 6749 is that it avoi= ds stuff like that.

What do you mean when you say -

[quote]<= br>The server MUST NOT include the "tcsh" value in the form that = any entity but itself can extract it.

[\quote]

Is this even theoretical= ly achievable without a stateful server that maintains a table of [code x t= csh] pairs?

If not, how should the server embed tcsh in "code&= quot; and what constructions are recommended?=

- prateek

As some of you know, passing the authorization code securely to a = native app on iOS platform is next to impossible. Malicious application may= register the same custom scheme as the victim application and hope to obta= in the code, whose success rate is rather high. 

 

We hav= e discussed about it during the OpenID Conenct Meeting at IETF 87 on Sunday= , and over a lengthy thread on the OpenID AB/Connect work group list. I hav= e captured the discussion in the form of I-D. It is pretty short and hopefu= lly easy to read. 

&n= bsp;

IMHO, although it came up as an= issue in OpenID Connect, this is a quite useful extension to OAuth 2.0 in = general. 

 

Best, 

<= div>

 

Nat Saki= mura

 

<= div>

---------- Forwarde= d message ----------
From: <internet-drafts@ietf.org>
Date: 2013/7/30Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
= To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Navee= n Agarwal <naa@googl= e.com>



A new version of I-D, draft-sakimura-oauth-tcs= e-00.txt
has been successfully submitted by Nat Sakimura and posted to t= he
IETF repository.

Filename:        draft-sa= kimura-oauth-tcse
Revision:        00
Title: &nbs= p;         OAuth Transient Client Secret Extension for = Public Clients
Creation date:   2013-07-29
Group:     =       Individual Submission
Number of pages: 7
URL: &n= bsp;           http://www.= ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
Status: &n= bsp;        http://datatracker.ietf.org/do= c/draft-sakimura-oauth-tcse
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00

=
Abstract:
   The OAuth 2.0 public client utilizing code fl= ow is susceptible to the
   code interception attack.  Th= is specification describe a mechanism
   that acts as a contro= l against this threat.





Please note that it may take = a couple of minutes from the time of submission
until the htmlized versi= on and diff are available at tools.ietf.org.

The IETF Secretariat

=



 

--
Nat Sakimura = (=3Dnat)

Chairman, OpenID Foundati= on
http://nat.sak= imura.org/
@_nat_en

<= br>

_______________________________=
________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

=



 

--
Nat Sak= imura (=3Dnat)

Chairman, OpenID Fou= ndation
http://na= t.sakimura.org/
@_nat_en

_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth

 

<= /div>= --_000_CE8995AB5D178F44A2154F5C9A97CAF40258D0E7E892HE111541eme_-- From asanso@adobe.com Tue Sep 24 05:08:49 2013 Return-Path: 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 7B34411E811A for ; Tue, 24 Sep 2013 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkrhHdjo4pB6 for ; Tue, 24 Sep 2013 05:08:44 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4219711E8116 for ; Tue, 24 Sep 2013 05:08:44 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUkGAzHXZvFy2uJjmGR11cJJTK5fRMg4i@postini.com; Tue, 24 Sep 2013 05:08:44 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OC56iH014434 for ; Tue, 24 Sep 2013 05:05:06 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OC8h6A011975 for ; Tue, 24 Sep 2013 05:08:43 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Sep 2013 05:08:43 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Tue, 24 Sep 2013 13:08:39 +0100 From: Antonio Sanso Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> Date: Tue, 24 Sep 2013 14:08:33 +0200 To: "oauth@ietf.org WG" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:08:49 -0000 Hi *, apologis to be back to this argument :). Let me try to better explain one use case that IMHO would be really good = to have in the OAuth specification family :) At the moment the only "OAuth standard" way I know to do OAuth server to = server is to use [0] namely Resource Owner Password Credentials Grant. Let me tell I am not a big fun of this particular flow :) (but this is = another story). An arguable better way to solve this scenario is to user (and why not to = standardise :S?) the method used by Google (or a variant of it) see [1]. Couple of more things: - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) - I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft?? Thanks and regards Antonio [0] http://tools.ietf.org/html/rfc6749#section-4.3 [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount= From bcampbell@pingidentity.com Tue Sep 24 05:36:24 2013 Return-Path: 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 CD6D711E8121 for ; Tue, 24 Sep 2013 05:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23INZIpoEljP for ; Tue, 24 Sep 2013 05:36:10 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 94F3A21F9946 for ; Tue, 24 Sep 2013 05:36:00 -0700 (PDT) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUkGHL9La60z/FNV1oSwFHKgxewmHTjnV@postini.com; Tue, 24 Sep 2013 05:36:00 PDT Received: by mail-ie0-f170.google.com with SMTP id x13so8954940ief.1 for ; Tue, 24 Sep 2013 05:35:59 -0700 (PDT) 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=h1K7Jzw+8jjNA1tdk51TXTOyVUt7T02njiJVCZH1mAY=; b=ApYmYxVXNCI+GpqCfW1cwu46hmAXUzBGWqg+Wu1VDWQbz+r61C6kKTc5xo0WKRg/FW 6eCtb3qQ5z0HJRNtCtoKbsRoEnpAkuBesTJ/sLJnpvQp2IqX1KEjlloU8UPmKGrDj71v FE/pQgbuDARb8ve/c633HfpbpjNJeOgFnXKFWkA00XN2AjVDZagwKltkBpo4hMQH3riE 9aWWX8GSR981gW4YT4EUM4CxHHVERy/08XVak0zYeS/cDBE96OQzqZ9t1gkrOFWuxc6r cx+BPXkKRIBzaueapbOAaJcf/RnRZpjGDOsWFOGU2ONauZbTVzk5qoqE1y1ws2xjiZwH Q9Dg== X-Gm-Message-State: ALoCoQk6Wfi/SJpqu29XcI1XN8X4io5yw4zHEWCNRC3piggueFKTiL0lOHiQ5AmLOyY0P8ERYF33S299BeOx+gSnyHMuuCXpNRQ3bFXHndyN/uSoejw7nbtE/p3rCW2+z1wmIdxaPT5CQ8e42zdeFWJzf+jLnHZnIg== X-Received: by 10.43.104.73 with SMTP id dl9mr9700242icc.39.1380026159719; Tue, 24 Sep 2013 05:35:59 -0700 (PDT) X-Received: by 10.43.104.73 with SMTP id dl9mr9700226icc.39.1380026159576; Tue, 24 Sep 2013 05:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.232.229 with HTTP; Tue, 24 Sep 2013 05:35:29 -0700 (PDT) In-Reply-To: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> From: Brian Campbell Date: Tue, 24 Sep 2013 06:35:29 -0600 Message-ID: To: Antonio Sanso Content-Type: multipart/alternative; boundary=bcaec5171bf105cdc704e720611b Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:36:25 -0000 --bcaec5171bf105cdc704e720611b Content-Type: text/plain; charset=ISO-8859-1 Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking for? On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso wrote: > Hi *, > > apologis to be back to this argument :). > > Let me try to better explain one use case that IMHO would be really good > to have in the OAuth specification family :) > > At the moment the only "OAuth standard" way I know to do OAuth server to > server is to use [0] namely Resource Owner Password Credentials Grant. > > Let me tell I am not a big fun of this particular flow :) (but this is > another story). > > An arguable better way to solve this scenario is to user (and why not to > standardise :S?) the method used by Google (or a variant of it) see [1]. > > Couple of more things: > > - I do not know if Google would be interested to put some effort to > standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in > consideration such proposal draft?? > > Thanks and regards > > Antonio > > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --bcaec5171bf105cdc704e720611b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <= span dir=3D"ltr"><= asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good to= have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth se= rver to server is to use [0] namely Resource Owner Password Credentials Gra= nt.

Let me tell I am not a big fun of this particular flow :) (but this is anot= her story).

An arguable better way to solve this scenario is to user (and why not to st= andardise :S?) the method used by Google (or a variant of it) see [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to standar= dise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in consi= deration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2S= erviceAccount
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--bcaec5171bf105cdc704e720611b-- From asanso@adobe.com Tue Sep 24 05:57:34 2013 Return-Path: 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 E6CEC11E8121 for ; Tue, 24 Sep 2013 05:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULRorKz2FdKE for ; Tue, 24 Sep 2013 05:57:29 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7821F8FAC for ; Tue, 24 Sep 2013 05:57:29 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUkGMNnMbhAWFfJ+X/r94t1m9nHww/MeO@postini.com; Tue, 24 Sep 2013 05:57:29 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OCrniH018263; Tue, 24 Sep 2013 05:53:49 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OCvL6H024919; Tue, 24 Sep 2013 05:57:25 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Sep 2013 05:57:23 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Tue, 24 Sep 2013 13:57:02 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_8084DA08-14E7-4FB0-9113-736999ED950A" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: Date: Tue, 24 Sep 2013 14:56:56 +0200 Message-ID: <7558541E-3517-4F71-A049-6143D4247738@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> To: Brian Campbell X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:57:35 -0000 --Apple-Mail=_8084DA08-14E7-4FB0-9113-736999ED950A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Brian, thanks a lot for your pointer. What the custom Google flow provides more than the oauth jwt bearer = draft is IMHO an explicit way to build JWT without any 'human = interaction' so a server can handle the construction of an expired JWT = bearer token on his own. This can of course be figured out by any implementer (as the Google = folks obviously did) but it would be nice to provide this black on white = on a spec IMHO regards Antonio On Sep 24, 2013, at 2:35 PM, Brian Campbell = wrote: > Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be = what you're looking for? >=20 >=20 > On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso = wrote: > Hi *, >=20 > apologis to be back to this argument :). >=20 > Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >=20 > At the moment the only "OAuth standard" way I know to do OAuth server = to server is to use [0] namely Resource Owner Password Credentials = Grant. >=20 > Let me tell I am not a big fun of this particular flow :) (but this is = another story). >=20 > An arguable better way to solve this scenario is to user (and why not = to standardise :S?) the method used by Google (or a variant of it) see = [1]. >=20 > Couple of more things: >=20 > - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft?? >=20 > Thanks and regards >=20 > Antonio >=20 > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_8084DA08-14E7-4FB0-9113-736999ED950A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Hi = Brian,

thanks a lot for your = pointer.

What the custom Google flow provides = more than the oauth jwt bearer draft is IMHO an explicit way to build = JWT without any 'human interaction' so a server can handle the = construction of an expired JWT bearer token on his = own.

This can of course be figured out by any = implementer (as the Google folks obviously did) but it would be nice to = provide this black on white on a spec = IMHO

regards

Antonio


On Sep 24, 2013, at 2:35 = PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

Might this http://too= ls.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking = for?


On Tue, Sep 24, 2013 at 6:08 AM, Antonio = Sanso <asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good = to have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth server to = server is to use [0] namely Resource Owner Password Credentials = Grant.

Let me tell I am not a big fun of this particular flow :) (but this is = another story).

An arguable better way to solve this scenario is to user (and why not to = standardise :S?) the method used by Google (or a variant of it) see = [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2Servic= eAccount
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_8084DA08-14E7-4FB0-9113-736999ED950A-- From cmortimore@salesforce.com Tue Sep 24 07:57:47 2013 Return-Path: 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 D3A5A11E8139 for ; Tue, 24 Sep 2013 07:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byX4MKeuZ7vZ for ; Tue, 24 Sep 2013 07:57:43 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9562F11E8145 for ; Tue, 24 Sep 2013 07:57:41 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq15so3940022wib.6 for ; Tue, 24 Sep 2013 07:57:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:from:mime-version:in-reply-to:date :message-id:subject:to:cc:content-type; bh=twA/rua7B78EAYqvAjzE3OP373mtHyBQmUnU72ga8mQ=; b=DKdJ7K0WF/2TlYy7cPzzMmdbPceb4ER/82HFTLX1a0pemaop80oynY1gDR/WoF92i8 D4xugUaDYr78yNeg05RgDJ1l4fve35JUgkuWf2rPsGFpKVqQqvydc4lnJtwr8jU/eKrk tXNsUmdz6K2dLob1cB6wYoR2R/ZtYLB3hWEEKiJyKypAlNA2DZlLabAnosN3rf03Q80F TAIMiq+M8UAXjKPsC0oJve0ebjdily2fqylP49T7dapYzWfuMsUJt2FnRU5G0Phupweu Ba6UxEFKxfuOr+QlAMDqy3Ih6aTj8YRlThOoOioQZzMMXuO8BD9GKHC/A2HQiG9NYY/x SfiA== X-Gm-Message-State: ALoCoQle/60BNGdzKUUeZaezK/yj8aQxwq3Nueyl/Lhb8I13z1TVMfLLkd0jY9B114Uvx4cgzc7k X-Received: by 10.194.78.78 with SMTP id z14mr22514568wjw.32.1380034660129; Tue, 24 Sep 2013 07:57:40 -0700 (PDT) References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> From: Chuck Mortimore Mime-Version: 1.0 (1.0) In-Reply-To: <7558541E-3517-4F71-A049-6143D4247738@adobe.com> Date: Tue, 24 Sep 2013 07:57:36 -0700 Message-ID: <1510634430014420341@unknownmsgid> To: Antonio Sanso Content-Type: multipart/alternative; boundary=047d7bf0d524b1f65b04e7225b03 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:57:48 -0000 --047d7bf0d524b1f65b04e7225b03 Content-Type: text/plain; charset=ISO-8859-1 I'm not sure I understand your point here. I don't believe there is anything custom or special about the google implementation here vs JWT. It looks identical to our implementation. Can you elaborate? - cmort On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: Hi Brian, thanks a lot for your pointer. What the custom Google flow provides more than the oauth jwt bearer draft is IMHO an explicit way to build JWT without any 'human interaction' so a server can handle the construction of an expired JWT bearer token on his own. This can of course be figured out by any implementer (as the Google folks obviously did) but it would be nice to provide this black on white on a spec IMHO regards Antonio On Sep 24, 2013, at 2:35 PM, Brian Campbell wrote: Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking for? On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso wrote: > Hi *, > > apologis to be back to this argument :). > > Let me try to better explain one use case that IMHO would be really good > to have in the OAuth specification family :) > > At the moment the only "OAuth standard" way I know to do OAuth server to > server is to use [0] namely Resource Owner Password Credentials Grant. > > Let me tell I am not a big fun of this particular flow :) (but this is > another story). > > An arguable better way to solve this scenario is to user (and why not to > standardise :S?) the method used by Google (or a variant of it) see [1]. > > Couple of more things: > > - I do not know if Google would be interested to put some effort to > standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in > consideration such proposal draft?? > > Thanks and regards > > Antonio > > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > 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 --047d7bf0d524b1f65b04e7225b03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not sure I understand your= point here. =A0 I don't believe there is anything custom or special ab= out the google implementation here vs JWT. =A0 It looks identical to our im= plementation. =A0

Can you elaborate?

- cmort

On Sep = 24, 2013, at 5:57 AM, Antonio Sanso <asanso@adobe.com> wrote:

Hi Brian,

thanks a lot for your pointer.
What the custom Google flow provides more than the oauth jwt be= arer draft is IMHO an explicit way to build JWT without any 'human inte= raction' so a server can handle the construction of an expired JWT bear= er token on his own.

This can of course be figured out by any implementer (a= s the Google folks obviously did) but it would be nice to provide this blac= k on white on a spec IMHO

regards

Antonio


On Sep= 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Might this http://tools.ietf.org/html/dr= aft-ietf-oauth-jwt-bearer be what you're looking for?


On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <= span dir=3D"ltr"><= asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good to= have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth se= rver to server is to use [0] namely Resource Owner Password Credentials Gra= nt.

Let me tell I am not a big fun of this particular flow :) (but this is anot= her story).

An arguable better way to solve this scenario is to user (and why not to st= andardise :S?) the method used by Google (or a variant of it) see [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to standar= dise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in consi= deration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2S= erviceAccount
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


<= div>_______________________________________________
O= Auth mailing list
OAuth@i= etf.org
https://www.i= etf.org/mailman/listinfo/oauth
--047d7bf0d524b1f65b04e7225b03-- From asanso@adobe.com Tue Sep 24 08:17:57 2013 Return-Path: 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 2E6FA21F9642 for ; Tue, 24 Sep 2013 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9PUHDUqzu66 for ; Tue, 24 Sep 2013 08:17:52 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 555B511E813F for ; Tue, 24 Sep 2013 08:17:50 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUkGtGuCYEuzBSgF24vp+JYORMEbJ4lRN@postini.com; Tue, 24 Sep 2013 08:17:51 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OFHg49025947; Tue, 24 Sep 2013 08:17:43 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OFHd6E013784; Tue, 24 Sep 2013 08:17:41 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Sep 2013 08:17:35 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Tue, 24 Sep 2013 16:17:24 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_3C0BF93F-DE5E-4B87-ADF4-C784D698D4BC" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: <1510634430014420341@unknownmsgid> Date: Tue, 24 Sep 2013 17:17:17 +0200 Message-ID: <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> To: Chuck Mortimore X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:17:57 -0000 --Apple-Mail=_3C0BF93F-DE5E-4B87-ADF4-C784D698D4BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi chuck, On Sep 24, 2013, at 4:57 PM, Chuck Mortimore = wrote: > I'm not sure I understand your point here. I don't believe there is = anything custom or special about the google implementation here vs JWT. = It looks identical to our implementation. =20 >=20 > Can you elaborate? sure. What is novel IMHO in the Google approach is not the bearer format , = that is still JWT (or JWS in this case) but the overall scenario. As I see OAuth 2 is really good to cover use cases where there is human = interaction (so an user namely the resource owner can provider username = and password to the AS but not to the client and get back the Bearer = Token). This is obviously covered from [2] and [3] namely Authorization Code = Grant and Implicit grant flow. When there is not human interaction involved what RFC6749 offers is the = already cited Resource Owner Password Credentials Grant that IMHO is a = no go since it required the resource owner to share his password with = the client. The way as Google offers to solve the same situation (namely obtain , or = create in this case, a bearer token without having the resource owner = password) is using asymmetric cryptography. What is happening is that = quoting "During the creation of a Service Account, you will be prompted to = download a private key. Be sure to save this private key in a secure = location. After the Service Account has been created, you will also have = access to the client_id associated with the private key." An alternative mentioned from John Bradley previously is that clients = can securely generate key pairs but in terms of security would be = identical. I hope is a bit clearer now :) regards antonio [2] http://tools.ietf.org/html/rfc6749#section-4.1 [3] http://tools.ietf.org/html/rfc6749#section-4.2 >=20 > - cmort >=20 > On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: >=20 >> Hi Brian, >>=20 >> thanks a lot for your pointer. >>=20 >> What the custom Google flow provides more than the oauth jwt bearer = draft is IMHO an explicit way to build JWT without any 'human = interaction' so a server can handle the construction of an expired JWT = bearer token on his own. >>=20 >> This can of course be figured out by any implementer (as the Google = folks obviously did) but it would be nice to provide this black on white = on a spec IMHO >>=20 >> regards >>=20 >> Antonio >>=20 >>=20 >> On Sep 24, 2013, at 2:35 PM, Brian Campbell = wrote: >>=20 >>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be = what you're looking for? >>>=20 >>>=20 >>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso = wrote: >>> Hi *, >>>=20 >>> apologis to be back to this argument :). >>>=20 >>> Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >>>=20 >>> At the moment the only "OAuth standard" way I know to do OAuth = server to server is to use [0] namely Resource Owner Password = Credentials Grant. >>>=20 >>> Let me tell I am not a big fun of this particular flow :) (but this = is another story). >>>=20 >>> An arguable better way to solve this scenario is to user (and why = not to standardise :S?) the method used by Google (or a variant of it) = see [1]. >>>=20 >>> Couple of more things: >>>=20 >>> - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>> - I am not too familiar with IETF process. Would the OAuth WG take = in consideration such proposal draft?? >>>=20 >>> Thanks and regards >>>=20 >>> Antonio >>>=20 >>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3C0BF93F-DE5E-4B87-ADF4-C784D698D4BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Hi = chuck,


On Sep 24, 2013, at 4:57 PM, = Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

I'm not sure I understand your = point here.   I don't believe there is anything custom or special = about the google implementation here vs JWT.   It looks identical = to our implementation.  

Can you = elaborate?

sure.

What is novel IMHO in the Google approach is not the = bearer format , that is still JWT (or JWS in this case) but the overall = scenario.

As I see OAuth 2 is really good to = cover use cases where there is human interaction (so an user namely the = resource owner can provider username and password to the AS but not to = the client and get back the Bearer Token).
This is obviously = covered from [2] and [3] namely Authorization Code Grant and = Implicit grant flow.

When there is not human = interaction involved what RFC6749 offers is the already = cited Resource Owner Password Credentials Grant that IMHO is a no = go since it required the resource owner to share his password with the = client.

The way as Google offers to solve the = same situation (namely obtain , or create in this case, a bearer token = without having the resource owner password) is using asymmetric = cryptography. What is happening is that = quoting

"During the creation of a Service = Account, you will be prompted to=20 download a private key. Be sure to save this private key in a secure=20 location. After the Service Account has been created, you will also have access to the client_id associated with the private = key."

An alternative mentioned from John = Bradley previously is that clients can securely generate key pairs = but in terms of security would be identical.

I = hope is a bit clearer now =  :)

regards

antonio=




- cmort

On Sep 24, 2013, at 5:57 AM, = Antonio Sanso <asanso@adobe.com> = wrote:

Hi Brian,

thanks a lot for your = pointer.

What the custom Google flow provides = more than the oauth jwt bearer draft is IMHO an explicit way to build = JWT without any 'human interaction' so a server can handle the = construction of an expired JWT bearer token on his own.

This can of course be figured out by any implementer = (as the Google folks obviously did) but it would be nice to provide this = black on white on a spec = IMHO

regards

Antonio


On = Sep 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

Might this http://too= ls.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking = for?


On Tue, Sep 24, 2013 at 6:08 AM, Antonio = Sanso <asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good = to have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth server to = server is to use [0] namely Resource Owner Password Credentials = Grant.

Let me tell I am not a big fun of this particular flow :) (but this is = another story).

An arguable better way to solve this scenario is to user (and why not to = standardise :S?) the method used by Google (or a variant of it) see = [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2Servic= eAccount
_______________________________________________
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

= --Apple-Mail=_3C0BF93F-DE5E-4B87-ADF4-C784D698D4BC-- From wmills_92105@yahoo.com Tue Sep 24 08:23:01 2013 Return-Path: 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 AD29011E8151 for ; Tue, 24 Sep 2013 08:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzihe8t8W+Rq for ; Tue, 24 Sep 2013 08:22:55 -0700 (PDT) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 196C811E814E for ; Tue, 24 Sep 2013 08:22:51 -0700 (PDT) Received: from [98.139.214.32] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 15:22:51 -0000 Received: from [98.139.212.220] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 15:22:51 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 15:22:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 229001.72660.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 40116 invoked by uid 60001); 24 Sep 2013 15:22:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380036171; bh=O0CcsKsEs8HX/vObh98EaApCzxi6cFyijiNzXxFmSJs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bU2x93QNnfhFW1idsS+4/MN1QZ6/V/kRpFc6vT7Z81XP9BMtcK0aQiOiWFptf3wOXQvrvwZ4LL8iVLh09Eex9jVXg+nuMR5Gy406BLbCMgS1Sd2YN+UxALetGGeJuZ41gxWKOZ+v4cYAnfdCO2q+mEQHejNsAghDi0EuAwuILew= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xmjal+CpyWTSSc8FS9sCVTmJwDMcrUz9N8RIxntU+/HAUbxeyEvneiu3UUK50N887YGS3ifw3mQvRaHvDq2adkzheQBMpCI9hHiaH1QI5NheYVJkgQtRi+sQQ9LTKslkPpACLlsWSX58hj7M702Er/yN8hTwDQorZL4L97x7h0c=; X-YMail-OSG: jVmkxYcVM1nb2T0wNN43OiMl43lh9qiYsgXiK4Rwo0bceHR JhfbUT06IbMf0FQeVxgmIyRZNrbUbM5hONfWmauNwum6..NvfgyqcgHBhquF WjG1OihrrPzq9HB1VtiEl.8UssYLefv4ResUgIkcJWMSRdqUWZ8Wjx7awy.G 72qDGG0I4CSdUvd.hZdFsdBWoYHHaBjdzunDAtoBq9L7YoOraC65iqdSiPyc FG2YdOYVqjN1nJnNbA9fzEm71KA37CnAwbQNL3rixp7Nrw_Ptd5ec0pAtp0p sbQjKtBHG.PUWLuyfWVZio5vGAyTYpRAy0Y1Y4z9TS7ve33oQrNajRHF5L0U jgv8gPkd_cUThjXL1XhFKNJke8q6Suf5c28JQMDRichrJvts4.RvDMxDWl8K 2dxkdtVLfRQOv9nlGgQb4m0fDDxF6gHf.FEBj8q4EUvR.VHRqmsVvBI0O8Wt ArV133ncd4bSM1N_pU_g70de880_5YuCiB1Td18336NtXWlh_fY_Vp_.BMgO rcWmKoVIMiKxkFr16M6jzjow22Tz2fqDQN5LFq2Mm6HuQbsMWrQtuP2R5Iog JrZOOYwlkczI6bws_Dhkh.jYXJCMDVPfDo.RgGy1ZjkDwImBk1b18_EGM7Tq vpPb2zBlmek1x7yFh9TL8mm23jeeXe5EAHuFjdOplov6dd.gih_z6R8spRCp BJaXsCqjn8nxqTjgAFjQd0kqXP.KWvQ5XD8S92zU14Qm50nWPRJuapg8hdZA SBE0ejM.hkg-- Received: from [209.131.62.115] by web142802.mail.bf1.yahoo.com via HTTP; Tue, 24 Sep 2013 08:22:51 PDT X-Rocket-MIMEInfo: 002.001, U28gdGhleSBhcmUgdXNpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzIGRlZmluZWQgb24gT0F1dGggMiB0aGVuPwoKCgpPbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTMgODoxOCBBTSwgQW50b25pbyBTYW5zbyA8YXNhbnNvQGFkb2JlLmNvbT4gd3JvdGU6CiAKSGkgY2h1Y2ssCgoKCk9uIFNlcCAyNCwgMjAxMywgYXQgNDo1NyBQTSwgQ2h1Y2sgTW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiB3cm90ZToKCkknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgeW91ciBwb2ludCBoZXJlLiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> Message-ID: <1380036171.35016.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Tue, 24 Sep 2013 08:22:51 -0700 (PDT) From: Bill Mills To: Antonio Sanso , Chuck Mortimore In-Reply-To: <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-2067535939-1380036171=:35016" Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:23:01 -0000 --1397251415-2067535939-1380036171=:35016 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So they are using client authentication as defined on OAuth 2 then?=0A=0A= =0A=0AOn Tuesday, September 24, 2013 8:18 AM, Antonio Sanso wrote:=0A =0AHi chuck,=0A=0A=0A=0AOn Sep 24, 2013, at 4:57 PM, Chuck Mo= rtimore wrote:=0A=0AI'm not sure I understand y= our point here. =A0 I don't believe there is anything custom or special abo= ut the google implementation here vs JWT. =A0 It looks identical to our imp= lementation. =A0=0A>=0A>=0A>Can you elaborate?=0A>=0A=0Asure.=0A=0AWhat is = novel IMHO in the Google approach is not the bearer format , that is still = JWT (or JWS in this case) but the overall scenario.=0A=0AAs I see OAuth 2 i= s really good to cover use cases where there is human interaction (so an us= er namely the resource owner can provider username and password to the AS b= ut not to the client and get back the Bearer Token).=0AThis is obviously co= vered from [2] and [3] namely=A0Authorization Code Grant and Implicit grant= flow.=0A=0AWhen there is not human interaction involved what RFC6749 offer= s is the already cited=A0Resource Owner Password Credentials Grant that IMH= O is a no go since it required the resource owner to share his password wit= h the client.=0A=0AThe way as Google offers to solve the same situation (na= mely obtain , or create in this case, a bearer token without having the res= ource owner password) is using asymmetric cryptography. What is happening i= s that quoting=0A=0A"During the creation of a Service Account, you will be = prompted to =0Adownload a private key. Be sure to save this private key in = a secure =0Alocation. After the Service Account has been created, you will = also have access to the client_id associated with the private key."=0A=0AAn= alternative mentioned from John Bradley previously is that=A0clients can s= ecurely generate key pairs but in terms of security would be identical.=0A= =0AI hope is a bit clearer now =A0:)=0A=0Aregards=0A=0Aantonio=0A=0A=0A[2]= =A0http://tools.ietf.org/html/rfc6749#section-4.1=0A[3]=A0http://tools.ietf= .org/html/rfc6749#section-4.2=0A=0A=0A>- cmort=0A>=0A>On Sep 24, 2013, at 5= :57 AM, Antonio Sanso wrote:=0A>=0A>=0A>Hi Brian,=0A>>= =0A>>=0A>>thanks a lot for your pointer.=0A>>=0A>>=0A>>What the custom Goog= le flow provides more than the oauth jwt bearer draft is IMHO an explicit w= ay to build JWT without any 'human interaction' so a server can handle the = construction of an expired JWT bearer token on his own.=0A>>=0A>>=0A>>This = can of course be figured out by any implementer (as the Google folks obviou= sly did) but it would be nice to provide this black on white on a spec IMHO= =0A>>=0A>>=0A>>regards=0A>>=0A>>=0A>>Antonio=0A>>=0A>>=0A>>=0A>>=0A>>On Sep= 24, 2013, at 2:35 PM, Brian Campbell wrote:= =0A>>=0A>>Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer= be what you're looking for?=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>On Tue, Sep 24, 2= 013 at 6:08 AM, Antonio Sanso wrote:=0A>>>=0A>>>Hi *,=0A= >>>>=0A>>>>apologis to be back to this argument :).=0A>>>>=0A>>>>Let me try= to better explain one use case that IMHO would be really good to have in t= he OAuth specification family :)=0A>>>>=0A>>>>At the moment the only "OAuth= standard" way I know to do OAuth server to server is to use [0] namely Res= ource Owner Password Credentials Grant.=0A>>>>=0A>>>>Let me tell I am not a= big fun of this particular flow :) (but this is another story).=0A>>>>=0A>= >>>An arguable better way to solve this scenario is to user (and why not to= standardise :S?) the method used by Google (or a variant of it) see [1].= =0A>>>>=0A>>>>Couple of more things:=0A>>>>=0A>>>>- I do not know if Google= would be interested to put some effort to standardise it (is anybody from = Google lurking :) e.g.Tim Bray :D )=0A>>>>- I am not too familiar with IETF= process. Would the OAuth WG take in consideration such proposal draft??=0A= >>>>=0A>>>>Thanks and regards=0A>>>>=0A>>>>Antonio=0A>>>>=0A>>>>[0] http://= tools.ietf.org/html/rfc6749#section-4.3=0A>>>>[1] https://developers.google= .com/accounts/docs/OAuth2ServiceAccount=0A>>>>_____________________________= __________________=0A>>>>OAuth mailing list=0A>>>>OAuth@ietf.org=0A>>>>http= s://www.ietf.org/mailman/listinfo/oauth=0A>>>>=0A>>>=0A>>=0A>______________= _________________________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org= =0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=0A=0A________________= _______________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/oauth --1397251415-2067535939-1380036171=:35016 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So they are using client authentication as defined on OAuth 2 = then?

On Tuesday, September 24, 2013 8:18 AM, Antonio Sanso <a= sanso@adobe.com> wrote:
Hi chuck,


On Sep 24, 2013, at 4:57 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

I'm not sure I understand your point here. &nbs= p; I don't believe there is anything custom or special about the google imp= lementation here vs JWT.   It looks identical to our implementation. &= nbsp;
=0A

Can you elaborate?

sure.

What is novel IMHO= in the Google approach is not the bearer format , that is still JWT (or JW= S in this case) but the overall scenario.

As I see= OAuth 2 is really good to cover use cases where there is human interaction= (so an user namely the resource owner can provider username and password t= o the AS but not to the client and get back the Bearer Token).
Th= is is obviously covered from [2] and [3] namely Authorization Code Gra= nt and Implicit grant flow.

When there is not huma= n interaction involved what RFC6749 offers is the already cited Resour= ce Owner Password Credentials Grant that IMHO is a no go since it required = the resource owner to share his password with the client.

The way as Google offers to solve the same situation (namely obtain= , or create in this case, a bearer token without having the resource owner pass= word) is using asymmetric cryptography. What is happening is that quoting

"During the creation of a Service Account, you will= be prompted to =0Adownload a private key. Be sure to save this private key= in a secure =0Alocation. After the Service Account has been created, you w= ill also have=0A access to the client_id associated with the private key."<= /div>

An alternative mentioned from John Bradley previou= sly is that clients can securely generate key pairs but in terms of se= curity would be identical.

I hope is a bit clearer= now  :)

regards

ant= onio




- cmort

On Sep 24, 2013= , at 5:57 AM, Antonio Sanso <asanso@adob= e.com> wrote:

=0A Hi Brian,

=
thanks a lot for your pointer.

What the custo= m Google flow provides more than the oauth jwt bearer draft is IMHO an expl= icit way to build JWT without any 'human interaction' so a server can handl= e the construction of an expired JWT bearer token on his own.
=0A
=
This can of course be figured out by any implementer (as the= Google folks obviously did) but it would be nice to provide this black on = white on a spec IMHO

regards

=0A
Antonio


On Sep 24,= 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

=0A
Might this http://tools.ietf.org/html= /draft-ietf-oauth-jwt-bearer be what you're looking for?
=0A

=0A=0A
On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <asanso@adobe.com> wrote:
=0A=0A=0AHi *,
=0A
=0Aap= ologis to be back to this argument :).
=0A
=0ALet me try to better ex= plain one use case that IMHO would be really good to have in the OAuth spec= ification family :)
=0A
=0AAt the moment the only "OAuth standard" wa= y I know to do OAuth server to server is to use [0] namely Resource Owner P= assword Credentials Grant.
=0A
=0ALet me tell I am not a big fun of t= his particular flow :) (but this is another story).
=0A
=0AAn arguabl= e better way to solve this scenario is to user (and why not to standardise = :S?) the method used by Google (or a variant of it) see [1].
=0A
=0AC= ouple of more things:
=0A
=0A- I do not know if Google would be inter= ested to put some effort to standardise it (is anybody from Google lurking = :) e.g.Tim Bray :D )
=0A- I am not too familiar with IETF process. Would= the OAuth WG take in consideration such proposal draft??
=0A
=0AThan= ks and regards
=0A
=0AAntonio
=0A
=0A[0] htt= p://tools.ietf.org/html/rfc6749#section-4.3
=0A[1] https://developers.google.com/accounts/docs/OAuth2Servi= ceAccount
=0A_______________________________________________
=0AO= Auth mailing list
=0AOAuth@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A

=0A

______________________________________________= _
OAuth mailing list
OAuth@ietf.org
=0Ahttps://www.iet= f.org/mailman/listinfo/oauth
=0A


________________________________________= _______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


<= /html> --1397251415-2067535939-1380036171=:35016-- From asanso@adobe.com Tue Sep 24 08:30:06 2013 Return-Path: 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 1425921F979E for ; Tue, 24 Sep 2013 08:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdoNKQw-oBKN for ; Tue, 24 Sep 2013 08:30:00 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5312721F9195 for ; Tue, 24 Sep 2013 08:30:00 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUkGv9p8+CKZelpcUYSN97qFQZl1J8U+F@postini.com; Tue, 24 Sep 2013 08:30:00 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OFTu49028397; Tue, 24 Sep 2013 08:29:57 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OFTtOU027886; Tue, 24 Sep 2013 08:29:56 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Sep 2013 08:29:54 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Tue, 24 Sep 2013 16:29:51 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2BEEB460-229D-4F04-AF71-CA973AF79388" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: <1380036171.35016.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Tue, 24 Sep 2013 17:29:45 +0200 Message-ID: <8C5FDFD6-81CE-4675-82FA-11ABCB8FB0BC@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> <1380036171.35016.YahooMailNeo@web142802.mail.bf1.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:30:06 -0000 --Apple-Mail=_2BEEB460-229D-4F04-AF71-CA973AF79388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Sep 24, 2013, at 5:22 PM, Bill Mills wrote: > So they are using client authentication as defined on OAuth 2 then? good point indeed :) My main point is that all the pieces of the puzzle = to solve this scenario are probably there beetwen the OAuth core the JWT = and the JWT bearer token specifications but it would be tough to an = OAuth newbie to figure out all this on his own=85. regards antonio >=20 >=20 > On Tuesday, September 24, 2013 8:18 AM, Antonio Sanso = wrote: > Hi chuck, >=20 >=20 > On Sep 24, 2013, at 4:57 PM, Chuck Mortimore = wrote: >=20 >> I'm not sure I understand your point here. I don't believe there is = anything custom or special about the google implementation here vs JWT. = It looks identical to our implementation. =20 >>=20 >> Can you elaborate? >=20 > sure. >=20 > What is novel IMHO in the Google approach is not the bearer format , = that is still JWT (or JWS in this case) but the overall scenario. >=20 > As I see OAuth 2 is really good to cover use cases where there is = human interaction (so an user namely the resource owner can provider = username and password to the AS but not to the client and get back the = Bearer Token). > This is obviously covered from [2] and [3] namely Authorization Code = Grant and Implicit grant flow. >=20 > When there is not human interaction involved what RFC6749 offers is = the already cited Resource Owner Password Credentials Grant that IMHO is = a no go since it required the resource owner to share his password with = the client. >=20 > The way as Google offers to solve the same situation (namely obtain , = or create in this case, a bearer token without having the resource owner = password) is using asymmetric cryptography. What is happening is that = quoting >=20 > "During the creation of a Service Account, you will be prompted to = download a private key. Be sure to save this private key in a secure = location. After the Service Account has been created, you will also have = access to the client_id associated with the private key." >=20 > An alternative mentioned from John Bradley previously is that clients = can securely generate key pairs but in terms of security would be = identical. >=20 > I hope is a bit clearer now :) >=20 > regards >=20 > antonio >=20 >=20 > [2] http://tools.ietf.org/html/rfc6749#section-4.1 > [3] http://tools.ietf.org/html/rfc6749#section-4.2 >=20 >>=20 >> - cmort >>=20 >> On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: >>=20 >>> Hi Brian, >>>=20 >>> thanks a lot for your pointer. >>>=20 >>> What the custom Google flow provides more than the oauth jwt bearer = draft is IMHO an explicit way to build JWT without any 'human = interaction' so a server can handle the construction of an expired JWT = bearer token on his own. >>>=20 >>> This can of course be figured out by any implementer (as the Google = folks obviously did) but it would be nice to provide this black on white = on a spec IMHO >>>=20 >>> regards >>>=20 >>> Antonio >>>=20 >>>=20 >>> On Sep 24, 2013, at 2:35 PM, Brian Campbell = wrote: >>>=20 >>>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer = be what you're looking for? >>>>=20 >>>>=20 >>>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso = wrote: >>>> Hi *, >>>>=20 >>>> apologis to be back to this argument :). >>>>=20 >>>> Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >>>>=20 >>>> At the moment the only "OAuth standard" way I know to do OAuth = server to server is to use [0] namely Resource Owner Password = Credentials Grant. >>>>=20 >>>> Let me tell I am not a big fun of this particular flow :) (but this = is another story). >>>>=20 >>>> An arguable better way to solve this scenario is to user (and why = not to standardise :S?) the method used by Google (or a variant of it) = see [1]. >>>>=20 >>>> Couple of more things: >>>>=20 >>>> - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>>> - I am not too familiar with IETF process. Would the OAuth WG take = in consideration such proposal draft?? >>>>=20 >>>> Thanks and regards >>>>=20 >>>> Antonio >>>>=20 >>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>>> [1] = https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_2BEEB460-229D-4F04-AF71-CA973AF79388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" wmills_92105@yahoo.com> = wrote:



On Tuesday, September 24, = 2013 8:18 AM, Antonio Sanso <asanso@adobe.com> wrote:
=
Hi chuck,


On Sep = 24, 2013, at 4:57 PM, Chuck Mortimore <cmortimore@salesforce.com>= ; wrote:

I'm not sure I understand your point here.   I = don't believe there is anything custom or special about the google = implementation here vs JWT.   It looks identical to our = implementation.  

Can you = elaborate?

sure.

<= /div>
What is novel IMHO in the Google approach is not the bearer = format , that is still JWT (or JWS in this case) but the overall = scenario.

As I see OAuth 2 is really good to = cover use cases where there is human interaction (so an user namely the = resource owner can provider username and password to the AS but not to = the client and get back the Bearer Token).
This is obviously = covered from [2] and [3] namely Authorization Code Grant and = Implicit grant flow.

When there is not human = interaction involved what RFC6749 offers is the already = cited Resource Owner Password Credentials Grant that IMHO is a no = go since it required the resource owner to share his password with the = client.

The way as Google offers to solve the = same situation (namely obtain , or create in this case, a bearer token without having the resource owner = password) is using asymmetric cryptography. What is happening is that = quoting

"During the creation of a Service = Account, you will be prompted to=20 download a private key. Be sure to save this private key in a secure=20 location. After the Service Account has been created, you will also have access to the client_id associated with the private = key."

An alternative mentioned from John = Bradley previously is that clients can securely generate key pairs = but in terms of security would be identical.

I = hope is a bit clearer now =  :)

regards

antonio=




- cmort

On Sep 24, 2013, at = 5:57 AM, Antonio Sanso <asanso@adobe.com> wrote:

Hi Brian,

thanks a lot for your = pointer.

What the custom Google flow provides = more than the oauth jwt bearer draft is IMHO an explicit way to build = JWT without any 'human interaction' so a server can handle the = construction of an expired JWT bearer token on his own.

This can of course be figured out by any implementer = (as the Google folks obviously did) but it would be nice to provide this = black on white on a spec = IMHO

regards

Antonio


On = Sep 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

Might this http://too= ls.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking = for?


On Tue, Sep 24, 2013 at 6:08 AM, = Antonio Sanso <asanso@adobe.com> = wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good = to have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth server to = server is to use [0] namely Resource Owner Password Credentials = Grant.

Let me tell I am not a big fun of this particular flow :) (but this is = another story).

An arguable better way to solve this scenario is to user (and why not to = standardise :S?) the method used by Google (or a variant of it) see = [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.= org/html/rfc6749#section-4.3
[1] = https://developers.google.com/accounts/docs/OAuth2ServiceAccount
_______________________________________________
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
=


___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=

= --Apple-Mail=_2BEEB460-229D-4F04-AF71-CA973AF79388-- From phil.hunt@oracle.com Tue Sep 24 09:05:53 2013 Return-Path: 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 75BF721F967F for ; Tue, 24 Sep 2013 09:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t9wHZZe2y3u for ; Tue, 24 Sep 2013 09:05:48 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2511E8169 for ; Tue, 24 Sep 2013 09:05:32 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8OG5MCG013434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Sep 2013 16:05:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8OG5LAN025403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Sep 2013 16:05:22 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8OG5LM7013521; Tue, 24 Sep 2013 16:05:21 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Sep 2013 09:05:20 -0700 References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> Mime-Version: 1.0 (1.0) In-Reply-To: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <02B18626-39F5-4AC5-9AB9-DBB580428946@oracle.com> X-Mailer: iPhone Mail (11A465) From: Phil Hunt Date: Tue, 24 Sep 2013 09:05:17 -0700 To: Antonio Sanso X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 16:05:53 -0000 Just looking at your subject line, and I may have this wrong but are you not= asking about chaining? In server to server you need a way for the second se= rver to accept a token from the first to propagate the authorization correct= ? Phil > On Sep 24, 2013, at 5:08, Antonio Sanso wrote: >=20 > Hi *, >=20 > apologis to be back to this argument :). >=20 > Let me try to better explain one use case that IMHO would be really good t= o have in the OAuth specification family :) >=20 > At the moment the only "OAuth standard" way I know to do OAuth server to s= erver is to use [0] namely Resource Owner Password Credentials Grant. >=20 > Let me tell I am not a big fun of this particular flow :) (but this is ano= ther story). >=20 > An arguable better way to solve this scenario is to user (and why not to s= tandardise :S?) the method used by Google (or a variant of it) see [1]. >=20 > Couple of more things: >=20 > - I do not know if Google would be interested to put some effort to standa= rdise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in cons= ideration such proposal draft?? >=20 > Thanks and regards >=20 > Antonio >=20 > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From cmortimore@salesforce.com Tue Sep 24 09:56:23 2013 Return-Path: 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 7ADA521F9C4C for ; Tue, 24 Sep 2013 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-U7yG2NaFVR for ; Tue, 24 Sep 2013 09:56:19 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B83321F95D0 for ; Tue, 24 Sep 2013 09:56:18 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id b13so4794261wgh.11 for ; Tue, 24 Sep 2013 09:56:17 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=78mZF8AYdkFvWZAYygoIEyhusrCW4ojQyDRa0jqLxtE=; b=DcFEyMHada7cuNAB6m5QLaVIRmE6gk5DLOf2dztNDLcIanE4itHxqNaYrNtVXL0K72 gjXUimf24Gab5/zMs3ki4iS3dWcdLGruka6AZ88thmUmJV/bHsPxiJdp5tTSfqpQbeyQ LHIvVdQHMMGAt+GOm1dM1uGGsLsSkwMg5pdO14GHhx9O560UgoqLDTcTHGU6YI+QuFxi fPIGf5pGbW3W666D5btk6nlTmxYTMcT7Y4rKNhkp1jc785DL8wxOysH0h+nrnp3FWVdU i+bxW8nE4lhxbsCkuGHgQVFwpjJ6tohA19bXIvt5H6ORIdtgQCholjA0fdgGrv4g1vWa CGyQ== X-Gm-Message-State: ALoCoQkZVGOqa/z5AszdkhkjXof5JL9xBcCIpnVdsrRHWxVqxx2/yNm8D85IxitdTu+XYsd2NCgK MIME-Version: 1.0 X-Received: by 10.194.240.101 with SMTP id vz5mr1247187wjc.69.1380041777624; Tue, 24 Sep 2013 09:56:17 -0700 (PDT) Received: by 10.217.85.200 with HTTP; Tue, 24 Sep 2013 09:56:17 -0700 (PDT) In-Reply-To: <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> Date: Tue, 24 Sep 2013 09:56:17 -0700 Message-ID: From: Chuck Mortimore To: Antonio Sanso Content-Type: multipart/alternative; boundary=001a11c28a40ee4b2804e72403fb Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 16:56:23 -0000 --001a11c28a40ee4b2804e72403fb Content-Type: text/plain; charset=ISO-8859-1 What you're describing is exactly what the JWT bearer flow specs out http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer We've got the exact same flow, and there are other implementations out there. http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso wrote: > Hi chuck, > > > On Sep 24, 2013, at 4:57 PM, Chuck Mortimore > wrote: > > I'm not sure I understand your point here. I don't believe there is > anything custom or special about the google implementation here vs JWT. > It looks identical to our implementation. > > Can you elaborate? > > > sure. > > What is novel IMHO in the Google approach is not the bearer format , that > is still JWT (or JWS in this case) but the overall scenario. > > As I see OAuth 2 is really good to cover use cases where there is human > interaction (so an user namely the resource owner can provider username and > password to the AS but not to the client and get back the Bearer Token). > This is obviously covered from [2] and [3] namely Authorization Code Grant > and Implicit grant flow. > > When there is not human interaction involved what RFC6749 offers is the > already cited Resource Owner Password Credentials Grant that IMHO is a no > go since it required the resource owner to share his password with the > client. > > The way as Google offers to solve the same situation (namely obtain , or > create in this case, a bearer token without having the resource owner > password) is using asymmetric cryptography. What is happening is that > quoting > > "During the creation of a Service Account, you will be prompted to > download a private key. Be sure to save this private key in a secure > location. After the Service Account has been created, you will also have > access to the client_id associated with the private key." > > An alternative mentioned from John Bradley previously is that clients can > securely generate key pairs but in terms of security would be identical. > > I hope is a bit clearer now :) > > regards > > antonio > > > [2] http://tools.ietf.org/html/rfc6749#section-4.1 > [3] http://tools.ietf.org/html/rfc6749#section-4.2 > > > - cmort > > On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: > > Hi Brian, > > thanks a lot for your pointer. > > What the custom Google flow provides more than the oauth jwt bearer draft > is IMHO an explicit way to build JWT without any 'human interaction' so a > server can handle the construction of an expired JWT bearer token on his > own. > > This can of course be figured out by any implementer (as the Google folks > obviously did) but it would be nice to provide this black on white on a > spec IMHO > > regards > > Antonio > > > On Sep 24, 2013, at 2:35 PM, Brian Campbell > wrote: > > Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what > you're looking for? > > > On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso wrote: > >> Hi *, >> >> apologis to be back to this argument :). >> >> Let me try to better explain one use case that IMHO would be really good >> to have in the OAuth specification family :) >> >> At the moment the only "OAuth standard" way I know to do OAuth server to >> server is to use [0] namely Resource Owner Password Credentials Grant. >> >> Let me tell I am not a big fun of this particular flow :) (but this is >> another story). >> >> An arguable better way to solve this scenario is to user (and why not to >> standardise :S?) the method used by Google (or a variant of it) see [1]. >> >> Couple of more things: >> >> - I do not know if Google would be interested to put some effort to >> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >> - I am not too familiar with IETF process. Would the OAuth WG take in >> consideration such proposal draft?? >> >> Thanks and regards >> >> Antonio >> >> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >> _______________________________________________ >> 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 > > > --001a11c28a40ee4b2804e72403fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What you're describing is exactly what the JWT bearer = flow specs out


=
We've got the exact same flow, and there are other implementations o= ut there. =A0=A0http://log= in.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm


On Tue,= Sep 24, 2013 at 8:17 AM, Antonio Sanso <asanso@adobe.com> wr= ote:
Hi chuck= ,


On Sep 24, 2013, at 4:= 57 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

I'm not sure I und= erstand your point here. =A0 I don't believe there is anything custom o= r special about the google implementation here vs JWT. =A0 It looks identic= al to our implementation. =A0

Can you elaborate?
sure.

What is novel IMHO in the = Google approach is not the bearer format , that is still JWT (or JWS in thi= s case) but the overall scenario.

As I see OAuth 2 is really good to cover use cases wher= e there is human interaction (so an user namely the resource owner can prov= ider username and password to the AS but not to the client and get back the= Bearer Token).
This is obviously covered from [2] and [3] namely=A0Authorization Code= Grant and Implicit grant flow.

When there is not = human interaction involved what RFC6749 offers is the already cited=A0Resou= rce Owner Password Credentials Grant that IMHO is a no go since it required= the resource owner to share his password with the client.

The way as Google offers to solve the same situation (n= amely obtain , or create in this case, a bearer token without having the re= source owner password) is using asymmetric cryptography. What is happening = is that quoting

"During the creation of a Service Account, you wil= l be prompted to=20 download a private key. Be sure to save this private key in a secure=20 location. After the Service Account has been created, you will also have access to the client_id associated with the private key."
<= br>
An alternative mentioned from John Bradley previously is that= =A0clients can securely generate key pairs but in terms of security would b= e identical.

I hope is a bit clearer now =A0:)

<= div>regards

antonio


<= /div>
<= div class=3D"h5">

-= cmort

On Sep 24, 2013, at 5:57 AM, Antonio Sanso <asanso@adobe.com> wrote:

<= /div>
Hi Brian,

thanks a lot for your pointer.

<= /div>
What the custom Google flow provides more than the oauth jwt bear= er draft is IMHO an explicit way to build JWT without any 'human intera= ction' so a server can handle the construction of an expired JWT bearer= token on his own.

This can of course be figured out by any implementer (a= s the Google folks obviously did) but it would be nice to provide this blac= k on white on a spec IMHO

regards

Antonio


On Sep= 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Might this http://tool= s.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking = for?


On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <= span dir=3D"ltr"><= asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good to= have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth se= rver to server is to use [0] namely Resource Owner Password Credentials Gra= nt.

Let me tell I am not a big fun of this particular flow :) (but this is anot= her story).

An arguable better way to solve this scenario is to user (and why not to st= andardise :S?) the method used by Google (or a variant of it) see [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to standar= dise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in consi= deration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2S= erviceAccount
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_= ______________________________________________
OAuth mailin= g list
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--001a11c28a40ee4b2804e72403fb-- From asanso@adobe.com Tue Sep 24 11:39:12 2013 Return-Path: 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 4CAF611E80E4 for ; Tue, 24 Sep 2013 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7-B0BPj-Hgp for ; Tue, 24 Sep 2013 11:39:07 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 589EB21F9B9F for ; Tue, 24 Sep 2013 11:39:07 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUkHcSPKIpftVOyUXZcatDcupanORJzcp@postini.com; Tue, 24 Sep 2013 11:39:07 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OIZQiH007895; Tue, 24 Sep 2013 11:35:27 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OId3OU003576; Tue, 24 Sep 2013 11:39:03 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Sep 2013 11:39:02 -0700 Received: from [10.136.132.253] (10.136.132.253) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Tue, 24 Sep 2013 19:39:00 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_72149C2C-E699-4A16-83E5-03B97F677A20" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: Date: Tue, 24 Sep 2013 20:38:54 +0200 Message-ID: References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> To: Chuck Mortimore X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:39:12 -0000 --Apple-Mail=_72149C2C-E699-4A16-83E5-03B97F677A20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Chuck, On Sep 24, 2013, at 6:56 PM, Chuck Mortimore = wrote: > What you're describing is exactly what the JWT bearer flow specs out >=20 > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer=20 >=20 > We've got the exact same flow, and there are other implementations out = there. = http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm thanks this is indeed the same :) What it looks to me though is that the = information contained in the second link you shared = (http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm) = are complementary to the jet bearer spec draft. People that will only read that spec would need to figure out all on = their own . Is there any chance the oauth bearer draft will cover the = actual use case as well or it would be too much ? Regards Antonio >=20 >=20 > On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso = wrote: > Hi chuck, >=20 >=20 > On Sep 24, 2013, at 4:57 PM, Chuck Mortimore = wrote: >=20 >> I'm not sure I understand your point here. I don't believe there is = anything custom or special about the google implementation here vs JWT. = It looks identical to our implementation. =20 >>=20 >> Can you elaborate? >=20 > sure. >=20 > What is novel IMHO in the Google approach is not the bearer format , = that is still JWT (or JWS in this case) but the overall scenario. >=20 > As I see OAuth 2 is really good to cover use cases where there is = human interaction (so an user namely the resource owner can provider = username and password to the AS but not to the client and get back the = Bearer Token). > This is obviously covered from [2] and [3] namely Authorization Code = Grant and Implicit grant flow. >=20 > When there is not human interaction involved what RFC6749 offers is = the already cited Resource Owner Password Credentials Grant that IMHO is = a no go since it required the resource owner to share his password with = the client. >=20 > The way as Google offers to solve the same situation (namely obtain , = or create in this case, a bearer token without having the resource owner = password) is using asymmetric cryptography. What is happening is that = quoting >=20 > "During the creation of a Service Account, you will be prompted to = download a private key. Be sure to save this private key in a secure = location. After the Service Account has been created, you will also have = access to the client_id associated with the private key." >=20 > An alternative mentioned from John Bradley previously is that clients = can securely generate key pairs but in terms of security would be = identical. >=20 > I hope is a bit clearer now :) >=20 > regards >=20 > antonio >=20 >=20 > [2] http://tools.ietf.org/html/rfc6749#section-4.1 > [3] http://tools.ietf.org/html/rfc6749#section-4.2 >=20 >>=20 >> - cmort >>=20 >> On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: >>=20 >>> Hi Brian, >>>=20 >>> thanks a lot for your pointer. >>>=20 >>> What the custom Google flow provides more than the oauth jwt bearer = draft is IMHO an explicit way to build JWT without any 'human = interaction' so a server can handle the construction of an expired JWT = bearer token on his own. >>>=20 >>> This can of course be figured out by any implementer (as the Google = folks obviously did) but it would be nice to provide this black on white = on a spec IMHO >>>=20 >>> regards >>>=20 >>> Antonio >>>=20 >>>=20 >>> On Sep 24, 2013, at 2:35 PM, Brian Campbell = wrote: >>>=20 >>>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer = be what you're looking for? >>>>=20 >>>>=20 >>>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso = wrote: >>>> Hi *, >>>>=20 >>>> apologis to be back to this argument :). >>>>=20 >>>> Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >>>>=20 >>>> At the moment the only "OAuth standard" way I know to do OAuth = server to server is to use [0] namely Resource Owner Password = Credentials Grant. >>>>=20 >>>> Let me tell I am not a big fun of this particular flow :) (but this = is another story). >>>>=20 >>>> An arguable better way to solve this scenario is to user (and why = not to standardise :S?) the method used by Google (or a variant of it) = see [1]. >>>>=20 >>>> Couple of more things: >>>>=20 >>>> - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>>> - I am not too familiar with IETF process. Would the OAuth WG take = in consideration such proposal draft?? >>>>=20 >>>> Thanks and regards >>>>=20 >>>> Antonio >>>>=20 >>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>>> [1] = https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_72149C2C-E699-4A16-83E5-03B97F677A20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Hi = Chuck,

On Sep 24, 2013, at 6:56 PM, Chuck Mortimore = <cmortimore@salesforce.com>= ; wrote:

What you're describing is exactly what = the JWT bearer flow specs out


We've got = the exact same flow, and there are other implementations out there. =   http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow= .htm


thanks this is indeed the same :) What it looks to me though is that = the information contained in the second link you shared (


On = Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso <asanso@adobe.com> wrote:
Hi = chuck,


On Sep 24, = 2013, at 4:57 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

I'm not sure I = understand your point here.   I don't believe there is anything = custom or special about the google implementation here vs JWT.   It = looks identical to our implementation.  

Can you = elaborate?

sure.

What is novel IMHO in the Google approach is not = the bearer format , that is still JWT (or JWS in this case) but the = overall scenario.

As I see OAuth 2 is really good to cover use cases = where there is human interaction (so an user namely the resource owner = can provider username and password to the AS but not to the client and = get back the Bearer Token).
This is obviously covered from [2] and [3] = namely Authorization Code Grant and Implicit grant = flow.

When there is not human interaction = involved what RFC6749 offers is the already cited Resource Owner = Password Credentials Grant that IMHO is a no go since it required the = resource owner to share his password with the client.

The way as Google offers to solve the same situation = (namely obtain , or create in this case, a bearer token without having = the resource owner password) is using asymmetric cryptography. What is = happening is that quoting

"During the creation of a Service Account, you will = be prompted to=20 download a private key. Be sure to save this private key in a secure=20 location. After the Service Account has been created, you will also have access to the client_id associated with the private = key."

An alternative mentioned from John = Bradley previously is that clients can securely generate key pairs = but in terms of security would be identical.

I hope is a bit clearer now =  :)

regards

antonio=


= =


- cmort

On Sep 24, 2013, at 5:57 AM, Antonio Sanso <asanso@adobe.com> = wrote:

Hi Brian,

thanks a lot for your = pointer.

What the custom Google flow provides = more than the oauth jwt bearer draft is IMHO an explicit way to build = JWT without any 'human interaction' so a server can handle the = construction of an expired JWT bearer token on his own.

This can of course be figured out by any implementer = (as the Google folks obviously did) but it would be nice to provide this = black on white on a spec = IMHO

regards

Antonio


On = Sep 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:



On Tue, Sep 24, 2013 at 6:08 AM, Antonio = Sanso <asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good = to have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth server to = server is to use [0] namely Resource Owner Password Credentials = Grant.

Let me tell I am not a big fun of this particular flow :) (but this is = another story).

An arguable better way to solve this scenario is to user (and why not to = standardise :S?) the method used by Google (or a variant of it) see = [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2Servic= eAccount
_______________________________________________
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
=



= --Apple-Mail=_72149C2C-E699-4A16-83E5-03B97F677A20-- From cmortimore@salesforce.com Tue Sep 24 11:43:55 2013 Return-Path: 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 1DDB621F9C4C for ; Tue, 24 Sep 2013 11:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYWGPK6mVbpn for ; Tue, 24 Sep 2013 11:43:51 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E979211E80E4 for ; Tue, 24 Sep 2013 11:43:48 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hn9so4288241wib.5 for ; Tue, 24 Sep 2013 11:43:47 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=/w0+k81ouE5n/+I0QLjSjDSdJMQizyYU+e3b6ACXbWU=; b=bzfLIWdntSVX6xgTgha5YoNA1+xtU51cXQsSjT26/GcQz2OJ47p7MLHmnJjcjt3isR l3bBgIWdzMcF87kuvS4txfQ9m2E2YEtDD9WV+D2U9ZKVZWgmpx/KtdB04CHoNXHD//vG 7nMt4WhKjaIDYl6VgmtxPAVT56s5W/KHYdnsxez3w9342K88YOqcYC9mRnK0TC48vVdY +JeIElYbuqxvQqAnPkBx1LjCEaTIJWX6D9Te0qCslVWHFNrAhAKdGRVN3k/U1tCLdL4v Axp4UHWPnQSgC/i3K9JWfNXsxALaOuBnPK70P2I0aF85XDd0pLcKBYivpwzgGWtF7qWp 4Mlg== X-Gm-Message-State: ALoCoQnO8PpmB3J/5VJOuMnN2xlxxuni/fxnnjBAYQeWtH01y3P8JAf981TYdijEQ74hHxwFcGgD MIME-Version: 1.0 X-Received: by 10.180.187.236 with SMTP id fv12mr10982984wic.20.1380048227814; Tue, 24 Sep 2013 11:43:47 -0700 (PDT) Received: by 10.217.85.200 with HTTP; Tue, 24 Sep 2013 11:43:47 -0700 (PDT) In-Reply-To: References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> Date: Tue, 24 Sep 2013 11:43:47 -0700 Message-ID: From: Chuck Mortimore To: Antonio Sanso Content-Type: multipart/alternative; boundary=001a11c25cec64612804e7258411 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:43:55 -0000 --001a11c25cec64612804e7258411 Content-Type: text/plain; charset=ISO-8859-1 Open to how it can be improved. What information do you think would be helpful? ( we may be too close to the situation to know what's missing ) On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso wrote: > Hi Chuck, > > On Sep 24, 2013, at 6:56 PM, Chuck Mortimore > wrote: > > What you're describing is exactly what the JWT bearer flow specs out > > http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer > > We've got the exact same flow, and there are other implementations out > there. > http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm > > > > thanks this is indeed the same :) What it looks to me though is that the > information contained in the second link you shared ( > http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm) > are complementary to the jet bearer spec draft. > > People that will only read that spec would need to figure out all on their > own . Is there any chance the oauth bearer draft will cover the actual use > case as well or it would be too much ? > > Regards > > Antonio > > > > On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso wrote: > >> Hi chuck, >> >> >> On Sep 24, 2013, at 4:57 PM, Chuck Mortimore >> wrote: >> >> I'm not sure I understand your point here. I don't believe there is >> anything custom or special about the google implementation here vs JWT. >> It looks identical to our implementation. >> >> Can you elaborate? >> >> >> sure. >> >> What is novel IMHO in the Google approach is not the bearer format , that >> is still JWT (or JWS in this case) but the overall scenario. >> >> As I see OAuth 2 is really good to cover use cases where there is human >> interaction (so an user namely the resource owner can provider username and >> password to the AS but not to the client and get back the Bearer Token). >> This is obviously covered from [2] and [3] namely Authorization Code >> Grant and Implicit grant flow. >> >> When there is not human interaction involved what RFC6749 offers is the >> already cited Resource Owner Password Credentials Grant that IMHO is a no >> go since it required the resource owner to share his password with the >> client. >> >> The way as Google offers to solve the same situation (namely obtain , or >> create in this case, a bearer token without having the resource owner >> password) is using asymmetric cryptography. What is happening is that >> quoting >> >> "During the creation of a Service Account, you will be prompted to >> download a private key. Be sure to save this private key in a secure >> location. After the Service Account has been created, you will also have >> access to the client_id associated with the private key." >> >> An alternative mentioned from John Bradley previously is that clients can >> securely generate key pairs but in terms of security would be identical. >> >> I hope is a bit clearer now :) >> >> regards >> >> antonio >> >> >> [2] http://tools.ietf.org/html/rfc6749#section-4.1 >> [3] http://tools.ietf.org/html/rfc6749#section-4.2 >> >> >> - cmort >> >> On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: >> >> Hi Brian, >> >> thanks a lot for your pointer. >> >> What the custom Google flow provides more than the oauth jwt bearer draft >> is IMHO an explicit way to build JWT without any 'human interaction' so a >> server can handle the construction of an expired JWT bearer token on his >> own. >> >> This can of course be figured out by any implementer (as the Google folks >> obviously did) but it would be nice to provide this black on white on a >> spec IMHO >> >> regards >> >> Antonio >> >> >> On Sep 24, 2013, at 2:35 PM, Brian Campbell >> wrote: >> >> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be >> what you're looking for? >> >> >> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso wrote: >> >>> Hi *, >>> >>> apologis to be back to this argument :). >>> >>> Let me try to better explain one use case that IMHO would be really good >>> to have in the OAuth specification family :) >>> >>> At the moment the only "OAuth standard" way I know to do OAuth server to >>> server is to use [0] namely Resource Owner Password Credentials Grant. >>> >>> Let me tell I am not a big fun of this particular flow :) (but this is >>> another story). >>> >>> An arguable better way to solve this scenario is to user (and why not to >>> standardise :S?) the method used by Google (or a variant of it) see [1]. >>> >>> Couple of more things: >>> >>> - I do not know if Google would be interested to put some effort to >>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>> - I am not too familiar with IETF process. Would the OAuth WG take in >>> consideration such proposal draft?? >>> >>> Thanks and regards >>> >>> Antonio >>> >>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>> _______________________________________________ >>> 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 >> >> >> > > --001a11c25cec64612804e7258411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Open to how it can be improved. =A0 What information do yo= u think would be helpful? =A0 ( we may be too close to the situation to kno= w what's missing )


On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso <asanso@adobe.com> wrote:
Hi Chuck,

On Sep 24, 2013, at 6:56 PM, Chuck Mortimore <cmortimore@salesforce.com&g= t; wrote:

What you're describing i= s exactly what the JWT bearer flow specs out


=
We've got the exact same flow, and there are other implementations o= ut there. =A0=A0http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow= .htm


thanks this is = indeed the same :) What it looks to me though is that the information conta= ined in the second link you shared (http://login.salesforce.com/help/doc/en/remoteac= cess_oauth_jwt_flow.htm) are complementary to the jet bearer spec draft= .

People that will only read that spec would need to figu= re out all on their own . Is there any chance the oauth bearer draft will c= over the actual use case as well or it would be too much ?

Regards

Antonio



On Tue,= Sep 24, 2013 at 8:17 AM, Antonio Sanso <asanso@adobe.com> wr= ote:
Hi chuck= ,


On Sep 24, 2013, at 4:57 PM, Chuck = Mortimore <cmortimore@salesforce.com> wrote:

I'm not sure I und= erstand your point here. =A0 I don't believe there is anything custom o= r special about the google implementation here vs JWT. =A0 It looks identic= al to our implementation. =A0

Can you elaborate?
sure.

What is novel IMHO in the = Google approach is not the bearer format , that is still JWT (or JWS in thi= s case) but the overall scenario.

As I see OAuth 2 is really good to cover use cases wher= e there is human interaction (so an user namely the resource owner can prov= ider username and password to the AS but not to the client and get back the= Bearer Token).
This is obviously covered from [2] and [3] namely=A0Authorization Code= Grant and Implicit grant flow.

When there is not = human interaction involved what RFC6749 offers is the already cited=A0Resou= rce Owner Password Credentials Grant that IMHO is a no go since it required= the resource owner to share his password with the client.

The way as Google offers to solve the same situation (n= amely obtain , or create in this case, a bearer token without having the re= source owner password) is using asymmetric cryptography. What is happening = is that quoting

"During the creation of a Service Account, you wil= l be prompted to=20 download a private key. Be sure to save this private key in a secure=20 location. After the Service Account has been created, you will also have access to the client_id associated with the private key."
<= br>
An alternative mentioned from John Bradley previously is that= =A0clients can securely generate key pairs but in terms of security would b= e identical.

I hope is a bit clearer now =A0:)

<= div>regards

antonio


<= /div>
<= div>

- cmort

On Sep 24, 2013, at 5:57 AM, Antonio Sanso <asanso@adobe.com> wrote:

<= /div>
Hi Brian,

thanks a lot for your pointer.

<= /div>
What the custom Google flow provides more than the oauth jwt bear= er draft is IMHO an explicit way to build JWT without any 'human intera= ction' so a server can handle the construction of an expired JWT bearer= token on his own.

This can of course be figured out by any implementer (a= s the Google folks obviously did) but it would be nice to provide this blac= k on white on a spec IMHO

regards

Antonio


On Sep= 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Might this http://tool= s.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking = for?


On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <= span dir=3D"ltr"><= asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good to= have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth se= rver to server is to use [0] namely Resource Owner Password Credentials Gra= nt.

Let me tell I am not a big fun of this particular flow :) (but this is anot= her story).

An arguable better way to solve this scenario is to user (and why not to st= andardise :S?) the method used by Google (or a variant of it) see [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to standar= dise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in consi= deration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2S= erviceAccount
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_= ______________________________________________
OAuth mailin= g list
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--001a11c25cec64612804e7258411-- From sberyozkin@gmail.com Thu Sep 26 05:34:35 2013 Return-Path: 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 92B4321F8FAC for ; Thu, 26 Sep 2013 05:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aalNPWOnmYGm for ; Thu, 26 Sep 2013 05:34:35 -0700 (PDT) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9A19A21F9F01 for ; Thu, 26 Sep 2013 05:34:30 -0700 (PDT) Received: by mail-bk0-f47.google.com with SMTP id mx12so384267bkb.34 for ; Thu, 26 Sep 2013 05:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ddQR4zz5LRvpnYCRI2ruPqQzz7N8sVcXZZBwgtTvVJ8=; b=R23ekiyBKUWPR1elc/p6leewHWPzL7smI6DHueHyiRAUtDLlIpnhHr82KgggJyiye9 KaanxAoRAtuFP52sqSzarku6UetrPQ5U9xThO5yMuI2JhJdR4cn57MceYCSEp823oTv4 C4EMLb4dXzoGwr/uugir/bQNYfNLeEPvRYdVTbk93eq+KCm9ktukoA+rmTY7XOvU8pQp Dt0EKmmP6ov0XQKp97KOfZUCQ+ImDTRCuAjlnvLAVhehg5wZT/x3SBt+CsETErXfZ6i8 kaJq/qPVfStoPgJKNfqusk5rIoNjgjazLAllBR1bkU2VbiKQhEO5z8GsaY+ftYN1laHt +7Dg== X-Received: by 10.204.103.199 with SMTP id l7mr429200bko.11.1380198868494; Thu, 26 Sep 2013 05:34:28 -0700 (PDT) Received: from [192.168.2.5] ([89.100.141.107]) by mx.google.com with ESMTPSA id w9sm878234bkn.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 05:34:27 -0700 (PDT) Message-ID: <524429D2.3010008@gmail.com> Date: Thu, 26 Sep 2013 13:34:26 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: oauth@ietf.org References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> In-Reply-To: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:34:35 -0000 On 24/09/13 13:08, Antonio Sanso wrote: > Hi *, > > apologis to be back to this argument :). > > Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :) > > At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant. > > Let me tell I am not a big fun of this particular flow :) (but this is another story). > > An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1]. 2-way TLS and Resource Owner Password Credentials should be secure enough, right ? Cheers, Sergey > > Couple of more things: > > - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft?? > > Thanks and regards > > Antonio > > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From sberyozkin@gmail.com Thu Sep 26 05:40:28 2013 Return-Path: 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 3AD2A21F995F for ; Thu, 26 Sep 2013 05:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkhPs9q6onbL for ; Thu, 26 Sep 2013 05:40:27 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BDA0E21F9998 for ; Thu, 26 Sep 2013 05:40:26 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hn9so6971798wib.17 for ; Thu, 26 Sep 2013 05:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hTdVS+Dej5ylvX92snr9ctVHiyiII5fIoMTsl5mQApg=; b=fMXCVsk2GrrzhHBDAI4s7OqCeuI7GtgE9pqk0lML9iDQXjwdfAgxYKtLFEoa14QfDa 1Bopj0U/7OOKLebSqdfhGKIDVoZBeMOdwW++Hf236BtPUhOeOsgk79xBYGpJIS6wwI/u 3iJCXGsyIxIN4PgGfkpZd3K6J50hV4eVQ+35fGOVbIjSGqTlRl0vMo7R2Id9LCgt2Zey 1eMDVCLkzP5S7rux1uQPucMAzddoXy3DAO4Anq0AcqnvNRxD5b5oNHzLTpuq4SAb62s3 DalH9w0PvKSoTO+LvPWkVH94FQttx+SFVlnvcE9Mw/7we6/LjUW0+Y4B+ii4A9N//D2k lLyw== X-Received: by 10.180.208.97 with SMTP id md1mr596058wic.41.1380199219483; Thu, 26 Sep 2013 05:40:19 -0700 (PDT) Received: from [192.168.2.5] ([89.100.141.107]) by mx.google.com with ESMTPSA id mb7sm3127790wic.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 05:40:18 -0700 (PDT) Message-ID: <52442B31.6060602@gmail.com> Date: Thu, 26 Sep 2013 13:40:17 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Bradley References: <20130730095129.29309.12243.idtracker@ietfa.amsl.com> <5224FFBB.9050400@oracle.com> <72735227-DF50-41F0-B744-9ED1706339B5@ve7jtb.com> In-Reply-To: <72735227-DF50-41F0-B744-9ED1706339B5@ve7jtb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:40:28 -0000 Hi On 06/09/13 00:44, John Bradley wrote: > At this point we don't know of any attack against the request, however > that is not guaranteed to remain the case. > > If we send the secret in plain text through the browser it likely will > never get IETF acceptance. > > We use HMAC a fair bit already I don't think that would be a significant > hurdle for clients. > > The quoted text is trying to prevent the AS from leaking the value back > to the attacker, that would be fatal flaw if it is plaintext, and not > optimal if it is a HMAC. > > AS could do something like include it in code unencrypted etc, just > trying to prevent that. > Given that Resource owner credentials grant did get IETF acceptance without any problems (due to HTTPS being recommended I guess) and due to the comment below that if we have a case where the device is compromised then passing a transient sensitive value in clear does not really makes the device client any more insecure than it already is, would it make sense to keep the current approach in place ? I did a quick try at implementing it few weeks ago and it was easy to do... Sergey > On 2013-09-05, at 4:34 PM, Nat Sakimura > wrote: > >> Depending on the level of assurance that you might want to achieve, it >> could have been a random string. That's how some of the existing but >> widely deployed implementations are doing. >> >> I have taken a step forward to do the hashing to give a little more >> protection that even if a malware on the device captures the request, >> it would not be able to use it in time. That's a kind of >> man-in-the-middle and by that time happens, your device is fairly >> badly compromised so there are opinion that it would not matter much >> by that time that just a random string would suffice. If the WG feels >> that way, I am happy to change it to a random string as well. >> >> The current "hash" design was a middle ground between a random string >> and HMAC etc. >> >> >> 2013/9/3 Prateek Mishra > > >> >> Nat - is there cryptanalysis of the proposed model available anyplace? >> >> Extending protocols by throwing in a smidgen of hashing and a >> tablespoon of encryption is often a bad idea. One of the strengths >> of /RFC/ 6749 is that it avoids stuff like that. >> >> What do you mean when you say - >> >> [quote] >> The server MUST NOT include the "tcsh" value in the form that any >> entity but itself can extract it. >> [\quote] >> >> Is this even theoretically achievable without a stateful server >> that maintains a table of [code x tcsh] pairs? >> >> If not, how should the server embed tcsh in "code" and what >> constructions are recommended? >> >> - prateek >> >>> As some of you know, passing the authorization code securely to a >>> native app on iOS platform is next to impossible. Malicious >>> application may register the same custom scheme as the victim >>> application and hope to obtain the code, whose success rate is >>> rather high. >>> >>> We have discussed about it during the OpenID Conenct Meeting at >>> IETF 87 on Sunday, and over a lengthy thread on the OpenID >>> AB/Connect work group list. I have captured the discussion in the >>> form of I-D. It is pretty short and hopefully easy to read. >>> >>> IMHO, although it came up as an issue in OpenID Connect, this is >>> a quite useful extension to OAuth 2.0 in general. >>> >>> Best, >>> >>> Nat Sakimura >>> >>> ---------- Forwarded message ---------- >>> From: > >>> Date: 2013/7/30 >>> Subject: New Version Notification for >>> draft-sakimura-oauth-tcse-00.txt >>> To: Nat Sakimura >> >, John Bradley >>> >, >>> Naveen Agarwal > >>> >>> >>> >>> A new version of I-D, draft-sakimura-oauth-tcse-00.txt >>> has been successfully submitted by Nat Sakimura and posted to the >>> IETF repository. >>> >>> Filename: draft-sakimura-oauth-tcse >>> Revision: 00 >>> Title: OAuth Transient Client Secret Extension for >>> Public Clients >>> Creation date: 2013-07-29 >>> Group: Individual Submission >>> Number of pages: 7 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse >>> Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00 >>> >>> >>> Abstract: >>> The OAuth 2.0 public client utilizing code flow is susceptible >>> to the >>> code interception attack. This specification describe a mechanism >>> that acts as a control against this threat. >>> >>> >>> >>> >>> >>> 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 . >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> 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 > From jricher@mitre.org Thu Sep 26 06:40:56 2013 Return-Path: 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 CA1A821E8096 for ; Thu, 26 Sep 2013 06:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHghhZdH3iyL for ; Thu, 26 Sep 2013 06:40:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 68BD721E809B for ; Thu, 26 Sep 2013 06:40:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6D3F21F0623; Thu, 26 Sep 2013 09:40:32 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 51CD21F061F; Thu, 26 Sep 2013 09:40:32 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Sep 2013 09:40:32 -0400 Message-ID: <52443944.6040308@mitre.org> Date: Thu, 26 Sep 2013 09:40:20 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Antonio Sanso References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> In-Reply-To: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 13:40:56 -0000 From what I read, it sounds like you want either the assertion flow (which is defined in extensions) or the client credentials flow (not the resource owner password flow). In either of these, the client authenticates on its own behalf and gets a token directly with no user involved, and both are fully specified. -- Justin On 09/24/2013 08:08 AM, Antonio Sanso wrote: > Hi *, > > apologis to be back to this argument :). > > Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :) > > At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant. > > Let me tell I am not a big fun of this particular flow :) (but this is another story). > > An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1]. > > Couple of more things: > > - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft?? > > Thanks and regards > > Antonio > > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lainhart@us.ibm.com Thu Sep 26 07:55:40 2013 Return-Path: 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 BB45B11E8101 for ; Thu, 26 Sep 2013 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.143 X-Spam-Level: X-Spam-Status: No, score=-8.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUSIR2QnCQRH for ; Thu, 26 Sep 2013 07:55:30 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2677721E8094 for ; Thu, 26 Sep 2013 07:55:02 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Sep 2013 10:54:54 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 26 Sep 2013 10:54:51 -0400 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 49AF2C90046; Thu, 26 Sep 2013 10:54:50 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8QEso2C38207610; Thu, 26 Sep 2013 14:54:50 GMT Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8QEsngG001961; Thu, 26 Sep 2013 10:54:50 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8QEsmtH001806; Thu, 26 Sep 2013 10:54:48 -0400 In-Reply-To: <52443944.6040308@mitre.org> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <52443944.6040308@mitre.org> To: Justin Richer MIME-Version: 1.0 X-KeepSent: CC5897C9:41C026FF-85257BF2:0051A3B1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP4 SHF39 May 13, 2013 Message-ID: From: Todd W Lainhart Date: Thu, 26 Sep 2013 10:54:46 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 09/26/2013 10:54:47, Serialize complete at 09/26/2013 10:54:47 Content-Type: multipart/alternative; boundary="=_alternative 0051EB4785257BF2_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13092614-0320-0000-0000-0000012309CA Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:55:40 -0000 This is a multipart message in MIME format. --=_alternative 0051EB4785257BF2_= Content-Type: text/plain; charset="US-ASCII" > From what I read, it sounds like you want either the assertion flow (which is defined in extensions) or the client credentials flow (not the resource owner password flow). I thought the same re "client credentials flow", but on a quick reading of Google's spec, their impl also allows for impersonation, assuming that the client has been registered to allow such (unclear if the original poster also wanted this functionality). We have a similar feature in our impl - client creds flow w/ impersonation (with supporting registration). Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com From: Justin Richer To: Antonio Sanso , Cc: "oauth@ietf.org WG" Date: 09/26/2013 09:41 AM Subject: Re: [OAUTH-WG] Oauth Server to Server Sent by: oauth-bounces@ietf.org From what I read, it sounds like you want either the assertion flow (which is defined in extensions) or the client credentials flow (not the resource owner password flow). In either of these, the client authenticates on its own behalf and gets a token directly with no user involved, and both are fully specified. -- Justin On 09/24/2013 08:08 AM, Antonio Sanso wrote: > Hi *, > > apologis to be back to this argument :). > > Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :) > > At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant. > > Let me tell I am not a big fun of this particular flow :) (but this is another story). > > An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1]. > > Couple of more things: > > - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) > - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft?? > > Thanks and regards > > Antonio > > [0] http://tools.ietf.org/html/rfc6749#section-4.3 > [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount > _______________________________________________ > 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 --=_alternative 0051EB4785257BF2_= Content-Type: text/html; charset="US-ASCII" >  From what I read, it sounds like you want either the assertion flow
(which is defined in extensions) or the client credentials flow (not the
resource owner password flow).

I thought the same re "client credentials flow", but on a quick reading of Google's spec, their impl also allows for impersonation, assuming that the client has been registered to allow such (unclear if the original poster also wanted this functionality).  We have a similar feature in our impl - client creds flow w/ impersonation (with supporting registration).



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com





From:        Justin Richer <jricher@mitre.org>
To:        Antonio Sanso <asanso@adobe.com>,
Cc:        "oauth@ietf.org WG" <oauth@ietf.org>
Date:        09/26/2013 09:41 AM
Subject:        Re: [OAUTH-WG] Oauth Server to Server
Sent by:        oauth-bounces@ietf.org



 From what I read, it sounds like you want either the assertion flow
(which is defined in extensions) or the client credentials flow (not the
resource owner password flow). In either of these, the client
authenticates on its own behalf and gets a token directly with no user
involved, and both are fully specified.

 -- Justin

On 09/24/2013 08:08 AM, Antonio Sanso wrote:
> Hi *,
>
> apologis to be back to this argument :).
>
> Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :)
>
> At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant.
>
> Let me tell I am not a big fun of this particular flow :) (but this is another story).
>
> An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1].
>
> Couple of more things:
>
> - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
> - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft??
>
> Thanks and regards
>
> Antonio
>
> [0] http://tools.ietf.org/html/rfc6749#section-4.3
> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
> _______________________________________________
> 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
--=_alternative 0051EB4785257BF2_=-- From asanso@adobe.com Fri Sep 27 01:33:32 2013 Return-Path: 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 6951B11E8137 for ; Fri, 27 Sep 2013 01:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+Tl4ZeMMY1d for ; Fri, 27 Sep 2013 01:33:27 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id ED95C11E80D1 for ; Fri, 27 Sep 2013 01:33:25 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUkVC0thJvFnD9Z/EF4nmzkvl4RQgZmH4@postini.com; Fri, 27 Sep 2013 01:33:26 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8ThiH007107; Fri, 27 Sep 2013 01:29:44 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8XL6A016890; Fri, 27 Sep 2013 01:33:21 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Sep 2013 01:33:20 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Fri, 27 Sep 2013 09:33:18 +0100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: <524429D2.3010008@gmail.com> Date: Fri, 27 Sep 2013 10:33:13 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <04F773FD-E099-4FB6-9BB0-6E5F910EA205@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <524429D2.3010008@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:33:32 -0000 On Sep 26, 2013, at 2:34 PM, Sergey Beryozkin = wrote: > On 24/09/13 13:08, Antonio Sanso wrote: >> Hi *, >>=20 >> apologis to be back to this argument :). >>=20 >> Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >>=20 >> At the moment the only "OAuth standard" way I know to do OAuth server = to server is to use [0] namely Resource Owner Password Credentials = Grant. >>=20 >> Let me tell I am not a big fun of this particular flow :) (but this = is another story). >>=20 >> An arguable better way to solve this scenario is to user (and why not = to standardise :S?) the method used by Google (or a variant of it) see = [1]. >=20 > 2-way TLS and Resource Owner Password Credentials should be secure=20 > enough, right ? >=20 secure is secure what I do not like of that flow though is the fact that = the resource owner should give the AS username/password to the client regards antonio > Cheers, Sergey >>=20 >> Couple of more things: >>=20 >> - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >> - I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft?? >>=20 >> Thanks and regards >>=20 >> Antonio >>=20 >> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From asanso@adobe.com Fri Sep 27 01:35:28 2013 Return-Path: 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 1CF0821F9ADD for ; Fri, 27 Sep 2013 01:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.78 X-Spam-Level: X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+oB90xL3V0m for ; Fri, 27 Sep 2013 01:35:23 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFE011E8131 for ; Fri, 27 Sep 2013 01:35:20 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUkVDSHAo52GiInI9Npp1FrzU3/F/9Ea3@postini.com; Fri, 27 Sep 2013 01:35:21 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8ZI49005368; Fri, 27 Sep 2013 01:35:18 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8ZH6A017521; Fri, 27 Sep 2013 01:35:17 -0700 (PDT) Received: from SJ1GWM332.corp.adobe.com (10.5.79.97) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Sep 2013 01:35:17 -0700 Received: from eurcas01.eur.adobe.com (10.128.4.27) by SJ1GWM332.corp.adobe.com (10.5.79.97) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 01:35:17 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Fri, 27 Sep 2013 09:35:13 +0100 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: <52443944.6040308@mitre.org> Date: Fri, 27 Sep 2013 10:35:08 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <52443944.6040308@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:35:28 -0000 On Sep 26, 2013, at 3:40 PM, Justin Richer wrote: > =46rom what I read, it sounds like you want either the assertion flow=20= > (which is defined in extensions) I do agree the assertion flow + JWT bearer token will suffice > or the client credentials flow not too sure about this though since it requires human interaction on = input username/password regards antonio > (not the=20 > resource owner password flow). In either of these, the client=20 > authenticates on its own behalf and gets a token directly with no user=20= > involved, and both are fully specified. >=20 > -- Justin >=20 > On 09/24/2013 08:08 AM, Antonio Sanso wrote: >> Hi *, >>=20 >> apologis to be back to this argument :). >>=20 >> Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >>=20 >> At the moment the only "OAuth standard" way I know to do OAuth server = to server is to use [0] namely Resource Owner Password Credentials = Grant. >>=20 >> Let me tell I am not a big fun of this particular flow :) (but this = is another story). >>=20 >> An arguable better way to solve this scenario is to user (and why not = to standardise :S?) the method used by Google (or a variant of it) see = [1]. >>=20 >> Couple of more things: >>=20 >> - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >> - I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft?? >>=20 >> Thanks and regards >>=20 >> Antonio >>=20 >> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From sberyozkin@gmail.com Fri Sep 27 01:48:55 2013 Return-Path: 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 93DBA21F9998 for ; Fri, 27 Sep 2013 01:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAjes+m0z7us for ; Fri, 27 Sep 2013 01:48:54 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3121F9798 for ; Fri, 27 Sep 2013 01:48:54 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so1054310eek.19 for ; Fri, 27 Sep 2013 01:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cjVYYJzXNt9nHn9/CW2/M/I+N/9IywDe8N6LNMJBj+A=; b=RGu90JLg/UBmivaAVH4PZzjFxpf+NgZOyyhygxDVDIFKc77r+L59BezTKBrpDOloed 1Y9m86tpTwYWOejuL9rPibnE5dc34brsL9pCt622plVbEhIqJj/CFFHP2NYmfEhzy7mW 9m64nNh69lXK1xlhgkTAKmtGTQe9LJXjPYWjs+YEP61EYs9yzmORXdcPeQu5ETpFDtjV dbVRskmmFU+xj+Cb98JYeW562DmDMRWQuFbKcn3NxVEMn/Npry9QFMfCq/vSxTV3UhUN emdWyNw+7JQNPbSGZ585A4q2DnZg3OXW/T6CYIBcbY9iIfcWwCMq8DDXc+On+W/gbHen m8ww== X-Received: by 10.14.210.195 with SMTP id u43mr671916eeo.80.1380271733707; Fri, 27 Sep 2013 01:48:53 -0700 (PDT) Received: from [10.36.226.2] ([217.173.99.61]) by mx.google.com with ESMTPSA id a43sm13602730eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 01:48:52 -0700 (PDT) Message-ID: <52454668.8060904@gmail.com> Date: Fri, 27 Sep 2013 09:48:40 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Antonio Sanso References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <524429D2.3010008@gmail.com> <04F773FD-E099-4FB6-9BB0-6E5F910EA205@adobe.com> In-Reply-To: <04F773FD-E099-4FB6-9BB0-6E5F910EA205@adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:48:55 -0000 On 27/09/13 09:33, Antonio Sanso wrote: > > On Sep 26, 2013, at 2:34 PM, Sergey Beryozkin wrote: > >> On 24/09/13 13:08, Antonio Sanso wrote: >>> Hi *, >>> >>> apologis to be back to this argument :). >>> >>> Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :) >>> >>> At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant. >>> >>> Let me tell I am not a big fun of this particular flow :) (but this is another story). >>> >>> An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1]. >> >> 2-way TLS and Resource Owner Password Credentials should be secure >> enough, right ? >> > > secure is secure what I do not like of that flow though is the fact that the resource owner should give the AS username/password to the client > Sure I agree to some extent; FYI, the integration scenarios I've been aware of (ex, Big Query server to server with no user having to sit in front of the application, with the application design being driven from a tooling studio) would work IMHO perfectly well with RO grant due to the clients & resource owners being most likely in the same organization; working with a json token complicates things quite a lot in our particular case :-), obviously it is more secure on the Web at large, Cheers, Sergey > regards > > antonio > >> Cheers, Sergey >>> >>> Couple of more things: >>> >>> - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>> - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft?? >>> >>> Thanks and regards >>> >>> Antonio >>> >>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>> _______________________________________________ >>> 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 > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com From asanso@adobe.com Fri Sep 27 01:56:08 2013 Return-Path: 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 69FC011E8133 for ; Fri, 27 Sep 2013 01:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.669 X-Spam-Level: X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VqehdkrsL07 for ; Fri, 27 Sep 2013 01:56:03 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9A21F967F for ; Fri, 27 Sep 2013 01:55:59 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUkVIHw1PrNpTNYsgTUHtf4Vvar8DhJoD@postini.com; Fri, 27 Sep 2013 01:56:02 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8tv49007103; Fri, 27 Sep 2013 01:55:58 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8tu6A023235; Fri, 27 Sep 2013 01:55:57 -0700 (PDT) Received: from SJ1GWM332.corp.adobe.com (10.5.79.97) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Sep 2013 01:55:56 -0700 Received: from eurcas01.eur.adobe.com (10.128.4.27) by SJ1GWM332.corp.adobe.com (10.5.79.97) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 01:55:56 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Fri, 27 Sep 2013 09:55:53 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_B916AFED-B615-4A8E-8F95-C53E1731236A" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: Date: Fri, 27 Sep 2013 10:55:48 +0200 Message-ID: <067007A7-1CDD-4623-B23F-CAF0BE5A21C9@adobe.com> References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <7558541E-3517-4F71-A049-6143D4247738@adobe.com> <1510634430014420341@unknownmsgid> <4AEF7FF7-06A2-4A2E-92D4-B18DDBC07B21@adobe.com> To: Chuck Mortimore X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:56:08 -0000 --Apple-Mail=_B916AFED-B615-4A8E-8F95-C53E1731236A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Thanks Chuck On Sep 24, 2013, at 6:56 PM, Chuck Mortimore = wrote: > Open to how it can be improved. What information do you think would = be helpful? ( we may be too close to the situation to know what's = missing ) I am reading carefully the 2 specs now (assertion and JWT bearer) and = will try to provide my feedback :) A couple of (early) consideration so far: - in order for somebody to easily achieve/understand what is clearly = described in = http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm = only reading the IETF materials is needed to read 3 specs (OAuth Core, = Assertion spec and JWT bearer). IT would be nice for example if the JWT = bearer spec would add some more hands on example (I do not know if it is = possible though) - The assertion spec = (http://tools.ietf.org/html/draft-ietf-oauth-assertions-12) contains = terms like and include those terms in the flow charts as Relying party , = Token Service that I know are really common in the Identity jargon (or = Open ID Connect specs) but this nomenclature doesn't match with the = OAuth core specs (namely RFC 6749) just my 0.02 $ so far (more to come) regards antonio >=20 >=20 > On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso = wrote: > Hi Chuck, >=20 > On Sep 24, 2013, at 6:56 PM, Chuck Mortimore = wrote: >=20 >> What you're describing is exactly what the JWT bearer flow specs out >>=20 >> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer=20 >>=20 >> We've got the exact same flow, and there are other implementations = out there. = http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm >=20 >=20 > thanks this is indeed the same :) What it looks to me though is that = the information contained in the second link you shared = (http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm) = are complementary to the jet bearer spec draft. >=20 > People that will only read that spec would need to figure out all on = their own . Is there any chance the oauth bearer draft will cover the = actual use case as well or it would be too much ? >=20 > Regards >=20 > Antonio >=20 >>=20 >>=20 >> On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso = wrote: >> Hi chuck, >>=20 >>=20 >> On Sep 24, 2013, at 4:57 PM, Chuck Mortimore = wrote: >>=20 >>> I'm not sure I understand your point here. I don't believe there = is anything custom or special about the google implementation here vs = JWT. It looks identical to our implementation. =20 >>>=20 >>> Can you elaborate? >>=20 >> sure. >>=20 >> What is novel IMHO in the Google approach is not the bearer format , = that is still JWT (or JWS in this case) but the overall scenario. >>=20 >> As I see OAuth 2 is really good to cover use cases where there is = human interaction (so an user namely the resource owner can provider = username and password to the AS but not to the client and get back the = Bearer Token). >> This is obviously covered from [2] and [3] namely Authorization Code = Grant and Implicit grant flow. >>=20 >> When there is not human interaction involved what RFC6749 offers is = the already cited Resource Owner Password Credentials Grant that IMHO is = a no go since it required the resource owner to share his password with = the client. >>=20 >> The way as Google offers to solve the same situation (namely obtain , = or create in this case, a bearer token without having the resource owner = password) is using asymmetric cryptography. What is happening is that = quoting >>=20 >> "During the creation of a Service Account, you will be prompted to = download a private key. Be sure to save this private key in a secure = location. After the Service Account has been created, you will also have = access to the client_id associated with the private key." >>=20 >> An alternative mentioned from John Bradley previously is that clients = can securely generate key pairs but in terms of security would be = identical. >>=20 >> I hope is a bit clearer now :) >>=20 >> regards >>=20 >> antonio >>=20 >>=20 >> [2] http://tools.ietf.org/html/rfc6749#section-4.1 >> [3] http://tools.ietf.org/html/rfc6749#section-4.2 >>=20 >>>=20 >>> - cmort >>>=20 >>> On Sep 24, 2013, at 5:57 AM, Antonio Sanso wrote: >>>=20 >>>> Hi Brian, >>>>=20 >>>> thanks a lot for your pointer. >>>>=20 >>>> What the custom Google flow provides more than the oauth jwt bearer = draft is IMHO an explicit way to build JWT without any 'human = interaction' so a server can handle the construction of an expired JWT = bearer token on his own. >>>>=20 >>>> This can of course be figured out by any implementer (as the Google = folks obviously did) but it would be nice to provide this black on white = on a spec IMHO >>>>=20 >>>> regards >>>>=20 >>>> Antonio >>>>=20 >>>>=20 >>>> On Sep 24, 2013, at 2:35 PM, Brian Campbell = wrote: >>>>=20 >>>>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer = be what you're looking for? >>>>>=20 >>>>>=20 >>>>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso = wrote: >>>>> Hi *, >>>>>=20 >>>>> apologis to be back to this argument :). >>>>>=20 >>>>> Let me try to better explain one use case that IMHO would be = really good to have in the OAuth specification family :) >>>>>=20 >>>>> At the moment the only "OAuth standard" way I know to do OAuth = server to server is to use [0] namely Resource Owner Password = Credentials Grant. >>>>>=20 >>>>> Let me tell I am not a big fun of this particular flow :) (but = this is another story). >>>>>=20 >>>>> An arguable better way to solve this scenario is to user (and why = not to standardise :S?) the method used by Google (or a variant of it) = see [1]. >>>>>=20 >>>>> Couple of more things: >>>>>=20 >>>>> - I do not know if Google would be interested to put some effort = to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>>>> - I am not too familiar with IETF process. Would the OAuth WG take = in consideration such proposal draft?? >>>>>=20 >>>>> Thanks and regards >>>>>=20 >>>>> Antonio >>>>>=20 >>>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>>>> [1] = https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 --Apple-Mail=_B916AFED-B615-4A8E-8F95-C53E1731236A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" cmortimore@salesforce.com>= ; wrote:
Open to how it can be improved.   = What information do you think would be helpful?   ( we may be too = close to the situation to know what's missing = )

I am reading carefully the 2 = specs now (assertion and JWT bearer) and will try to provide my feedback = :)

A couple of (early) consideration so = far:

- in order for somebody to easily = achieve/understand what is clearly described in http://= tools.ietf.org/html/draft-ietf-oauth-assertions-12) contains terms = like and include those terms in the flow charts as Relying party , Token = Service that I know are really common in the Identity jargon (or Open ID = Connect specs) but this nomenclature doesn't match with the OAuth core = specs (namely RFC 6749)

just my 0.02 $ so far = (more to = come)

regards

antonio


On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso <asanso@adobe.com> wrote:


thanks this = is indeed the same :) What it looks to me though is that the information = contained in the second link you shared (http://login.salesforce.com/help/doc/en/remoteaccess_oau= th_jwt_flow.htm) are complementary to the jet bearer spec = draft.

People that will only read that spec would need to = figure out all on their own . Is there any chance the oauth bearer draft = will cover the actual use case as well or it would be too much = ?

Regards

Antonio



On = Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso <asanso@adobe.com> wrote:
Hi = chuck,


On Sep 24, 2013, at 4:57 = PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

I'm not sure I = understand your point here.   I don't believe there is anything = custom or special about the google implementation here vs JWT.   It = looks identical to our implementation.  

Can you = elaborate?

sure.

What is novel IMHO in the Google approach is not = the bearer format , that is still JWT (or JWS in this case) but the = overall scenario.

As I see OAuth 2 is really good to cover use cases = where there is human interaction (so an user namely the resource owner = can provider username and password to the AS but not to the client and = get back the Bearer Token).
This is obviously covered from [2] and [3] = namely Authorization Code Grant and Implicit grant = flow.

When there is not human interaction = involved what RFC6749 offers is the already cited Resource Owner = Password Credentials Grant that IMHO is a no go since it required the = resource owner to share his password with the client.

The way as Google offers to solve the same situation = (namely obtain , or create in this case, a bearer token without having = the resource owner password) is using asymmetric cryptography. What is = happening is that quoting

"During the creation of a Service Account, you will = be prompted to=20 download a private key. Be sure to save this private key in a secure=20 location. After the Service Account has been created, you will also have access to the client_id associated with the private = key."

An alternative mentioned from John = Bradley previously is that clients can securely generate key pairs = but in terms of security would be identical.

I hope is a bit clearer now =  :)

regards

antonio=


= =


- = cmort

On Sep 24, 2013, at 5:57 AM, Antonio Sanso <asanso@adobe.com> = wrote:

Hi Brian,

thanks a lot for your = pointer.

What the custom Google flow provides = more than the oauth jwt bearer draft is IMHO an explicit way to build = JWT without any 'human interaction' so a server can handle the = construction of an expired JWT bearer token on his own.

This can of course be figured out by any implementer = (as the Google folks obviously did) but it would be nice to provide this = black on white on a spec = IMHO

regards

Antonio


On = Sep 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:



On Tue, Sep 24, 2013 at 6:08 AM, Antonio = Sanso <asanso@adobe.com> wrote:
Hi *,

apologis to be back to this argument :).

Let me try to better explain one use case that IMHO would be really good = to have in the OAuth specification family :)

At the moment the only "OAuth standard" way I know to do OAuth server to = server is to use [0] namely Resource Owner Password Credentials = Grant.

Let me tell I am not a big fun of this particular flow :) (but this is = another story).

An arguable better way to solve this scenario is to user (and why not to = standardise :S?) the method used by Google (or a variant of it) see = [1].

Couple of more things:

- I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
- I am not too familiar with IETF process. Would the OAuth WG take in = consideration such proposal draft??

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/rfc6749#section-4.3
[1] https://developers.google.com/accounts/docs/OAuth2Servic= eAccount
_______________________________________________
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


=



= --Apple-Mail=_B916AFED-B615-4A8E-8F95-C53E1731236A-- From asanso@adobe.com Fri Sep 27 02:45:34 2013 Return-Path: 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 F41CD21E80F1 for ; Fri, 27 Sep 2013 02:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.604 X-Spam-Level: X-Spam-Status: No, score=-4.604 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb9Y1Oo9zxEy for ; Fri, 27 Sep 2013 02:45:25 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id D125021E80E7 for ; Fri, 27 Sep 2013 02:45:21 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUkVTsNEmkwvXYSzLruL5vBgSOJEql9o4@postini.com; Fri, 27 Sep 2013 02:45:22 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R9jJ49013465; Fri, 27 Sep 2013 02:45:19 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R9jIOU007372; Fri, 27 Sep 2013 02:45:18 -0700 (PDT) Received: from SJ1GWM333.corp.adobe.com (10.5.79.98) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Sep 2013 02:45:18 -0700 Received: from eurcas01.eur.adobe.com (10.128.4.27) by SJ1GWM333.corp.adobe.com (10.5.79.98) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 02:45:18 -0700 Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Fri, 27 Sep 2013 10:45:04 +0100 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Antonio Sanso In-Reply-To: Date: Fri, 27 Sep 2013 11:44:57 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <52443944.6040308@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1510) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Oauth Server to Server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 09:45:34 -0000 On Sep 27, 2013, at 10:35 AM, Antonio Sanso wrote: >=20 > On Sep 26, 2013, at 3:40 PM, Justin Richer wrote: >=20 >> =46rom what I read, it sounds like you want either the assertion flow=20= >> (which is defined in extensions) >=20 > I do agree the assertion flow + JWT bearer token will suffice >=20 >> or the client credentials flow >=20 > not too sure about this though since it requires human interaction on = input username/password ops apologies you are off course right. I wrongly mixed the client = credentials flow with the implicit grant (sometime also called = client-side... :s) regards Antonio >=20 > regards >=20 > antonio >=20 >> (not the=20 >> resource owner password flow). In either of these, the client=20 >> authenticates on its own behalf and gets a token directly with no = user=20 >> involved, and both are fully specified. >>=20 >> -- Justin >>=20 >> On 09/24/2013 08:08 AM, Antonio Sanso wrote: >>> Hi *, >>>=20 >>> apologis to be back to this argument :). >>>=20 >>> Let me try to better explain one use case that IMHO would be really = good to have in the OAuth specification family :) >>>=20 >>> At the moment the only "OAuth standard" way I know to do OAuth = server to server is to use [0] namely Resource Owner Password = Credentials Grant. >>>=20 >>> Let me tell I am not a big fun of this particular flow :) (but this = is another story). >>>=20 >>> An arguable better way to solve this scenario is to user (and why = not to standardise :S?) the method used by Google (or a variant of it) = see [1]. >>>=20 >>> Couple of more things: >>>=20 >>> - I do not know if Google would be interested to put some effort to = standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >>> - I am not too familiar with IETF process. Would the OAuth WG take = in consideration such proposal draft?? >>>=20 >>> Thanks and regards >>>=20 >>> Antonio >>>=20 >>> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From phil.hunt@oracle.com Fri Sep 27 12:33:34 2013 Return-Path: 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 9BE9A11E8104 for ; Fri, 27 Sep 2013 12:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2qWaewdv0Rq for ; Fri, 27 Sep 2013 12:33:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E544221F9ED4 for ; Fri, 27 Sep 2013 12:33:27 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8RJXQxf032645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Sep 2013 19:33:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8RJXO2T023247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Sep 2013 19:33:25 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8RJXODl002741 for ; Fri, 27 Sep 2013 19:33:24 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Sep 2013 12:33:24 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_E714BC51-9632-490F-B2BB-5F1574579C3F" Message-Id: <211F3FEE-3481-4D63-B4EC-8AD7DBFB1638@oracle.com> Date: Fri, 27 Sep 2013 12:33:23 -0700 To: "oauth@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [OAUTH-WG] New Software Statement and Client Association Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:33:35 -0000 --Apple-Mail=_E714BC51-9632-490F-B2BB-5F1574579C3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As promised, Tony and I have put together a draft proposal as an = alternative to the dynamic registration draft. The relevant links are: http://datatracker.ietf.org/doc/draft-hunt-oauth-software-statement/ http://datatracker.ietf.org/doc/draft-hunt-oauth-client-association The two draft proposal provides equivalent functionality to dyn reg. = Instead of a new RESTful/json endpoint, this proposal is an assertion = centric proposal that adds the following features: 1. Provides a way to recognize client software and ensure all copies = register the same way (e.g. redirect_url may be locked for all copies of = a mobile app) 2. Registration can be implemented in a stateless fashion (using signed = assertions) if desired 3. The association draft uses the normal OAuth token endpoint to issue = tokens (improving extensibility for future token types) 4. Has simpler implementation logic resulting from defining 3 different = client types and a simple method for each 5. Statements allow service providers to pre-approve client software and = set policy (or conversely set broadly open policy) 6. Management API can be supported as an extension if desired (e.g. a = version of draft-richer-oauth-dyn-reg-management) 7. Makes bearer tokens the default client credential to "raise the bar" = security wise and enable stateless registration (though, client_secret = could still be supported -- we should discuss) Note: the term "association" is meant to have broader scope than the = term "registration". It acknowledges that not all clients may actually = "register" prior to accessing services (see next paragraph). The association draft defines 3 client types, each of which is = relatively simple to implement (and one of which is just the current = "static" registration practice). The other two are "dynamic" and = "transient". The big difference is that "transient" is intended for = implicit flow (javascript) clients and eliminates the need to go through = a registration step. "Dynamic" functions by leveraging the token = endpoint to exchange software statement and instance specific parameters = for a client credential and client registration information and an = optional management API endpoint. We have also tried to provide equivalent functionality as dyn reg by = providing approaches for: * An initial registration token=20 * Client credential rotation * Should work for UMA and OpenID use cases as well as published = software cases Thanks everyone for your contributions and comments! Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_E714BC51-9632-490F-B2BB-5F1574579C3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As = promised, Tony and I have put together a draft proposal as an = alternative to the dynamic registration draft.  The relevant links = are:

The two draft proposal provides equivalent = functionality to dyn reg. Instead of a new RESTful/json endpoint, this = proposal is an assertion centric proposal that adds the following = features:

1. Provides a way to recognize client = software and ensure all copies register the same way (e.g. redirect_url = may be locked for all copies of a mobile app)
2. Registration can be = implemented in a stateless fashion (using signed assertions) if = desired
3. The association draft uses the normal OAuth token endpoint = to issue tokens (improving extensibility for future token types)
4. = Has simpler implementation logic resulting from defining 3 different = client types and a simple method for each
5. Statements allow service = providers to pre-approve client software and set policy (or conversely = set broadly open policy)
6. Management API can be supported as an = extension if desired (e.g. a version of = draft-richer-oauth-dyn-reg-management)
7. Makes bearer tokens = the default client credential to "raise the bar" security wise and = enable stateless registration (though, client_secret could still be = supported -- we should discuss)

Note: the term = "association" is meant to have broader scope than the term = "registration". It acknowledges that not all clients may actually = "register" prior to accessing services (see next = paragraph).

The association draft defines 3 = client types, each of which is relatively simple to implement (and one = of which is just the current "static" registration practice). The = other two are "dynamic" and "transient".  The big = difference is that "transient" is intended for implicit flow = (javascript) clients and eliminates the need to go through a = registration step.  "Dynamic" functions by leveraging the token = endpoint to exchange software statement and instance specific parameters = for a client credential and client registration information and an = optional management API endpoint.

We have also = tried to provide equivalent functionality as dyn reg by providing = approaches for:
*  An initial registration = token 
*  Client credential rotation
* =  Should work for UMA and OpenID use cases as well as published = software cases

Thanks everyone for your = contributions and comments!

Phil
= --Apple-Mail=_E714BC51-9632-490F-B2BB-5F1574579C3F-- From torsten@lodderstedt.net Sat Sep 28 06:36:48 2013 Return-Path: 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 C588921F9CE3 for ; Sat, 28 Sep 2013 06:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t59KJlDYsLO for ; Sat, 28 Sep 2013 06:36:44 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8182121E80DB for ; Sat, 28 Sep 2013 06:36:39 -0700 (PDT) Received: from [91.2.95.180] (helo=[192.168.71.139]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VPuhE-0006yN-VJ; Sat, 28 Sep 2013 15:36:33 +0200 Message-ID: <5246DB60.7080109@lodderstedt.net> Date: Sat, 28 Sep 2013 15:36:32 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2AA33964@USCHMBX001.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 13:36:48 -0000 Hi all, here are my comments: --- Assertion Draft --- section 4.1. "Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of client authentication that relies on the parameter is used." I'm a bit confused about this statement because RFC6749, Section 3.2.1. states: "Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint." The client_id is optional but recommended for public clients, only. Same text can be found in SAML/section 2.1 and JWT/section 2.1 section 5.1. "the Issuer should identify the STS in a manner recognized by the Authorization Server." Shouldn't the "should" be normative language? I would even prefer MUST instead of should. "Issuer values SHOULD be compared using the Simple String Comparison" - better MUST? "When using assertions for client authentication, the Subject MUST identify the client to the authorization server, typically by using the value of the "client_id" of the OAuth client." Why not just "For client authentication, the subject MUST be the "client_id" of the OAuth client" as in the JWT Bearer and SAML assertion drafts? Audience - "The URL of the Token Endpoint, as defined in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate that the authorization server as a valid intended audience of the assertion." Who uses this approach? We don't use the concrete URL of the tokens endpoint but the AS's base URL. I would prefer to have _a_ single, mandated way of identifying the AS instead of a recommendation in order to facilitate interop. section 6.2 Please replace "Client Credentials flow" by "Client Credentials _Grant_" PLEASE NOTE: most comments on the assertion draft hold for JWT and SAML as well because a lot of text is duplicated/shared among these drafts. --- JWT bearer token --- section 4 the example request is missing any client identifier/credentials, please add BASIC header or client_id GENERAL NOTE: HTML links referencing to RFC 6749 are generally linked to the respective drafts itself regards, Torsten. Am 10.09.2013 16:26, schrieb Tschofenig, Hannes (NSN - FI/Espoo): > Hi all, > > I am trying to wrap up the assertion documents and I took a look at the meeting minutes from the Berlin IETF meeting and the actions are as follows: > > ** John & Torsten: Please post your document review to the list. > > ** Authors of draft-ietf-oauth-saml2-bearer: Please provide the additional SAML related text (as discussed during the meeting) and submit an updated document. > > Ciao > Hannes > > ------- copy from the minutes -------- > > * Assertions (BC) > https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > - WGLC ends by 8/8 > - BL on WGLC comments: talked to MJ about how to achieve interop. > - BL: describe how you could combine specifications to make at least one interoperable specification > - MJ: profiles exists for both SAML and OpenIDC. those are not IETF specifications though > - BL: ok to point to external doc from either of the I-Ds in question > - MJ: very achievable > - BL: all should go to the IESG at the same time to establish context > - PHO: is this for the IESG benefit or for future developers > - BL: the latter > - PHO: talk to Heather Flanagan or the IANA - they have talked about having long-term access to external documents > - BL: ok will consider that - or we can copy text into WG wiki > - BC: interop does not require external profiles actually > - TL: same experience at DT with the JSON-based assertion format - no addl profiles are needed > - MJ: a SAML deployment needs agreement on certain SAML-specific conventions - this is what BL is referring to > - BC: right > - TN: so just refer to the SAML specs > - BL: maybe enough > - JB and TL volunteered to make a review. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth