Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

Phil Hunt <phil.hunt@oracle.com> Sun, 02 November 2014 19:55 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9621A01CB for <oauth@ietfa.amsl.com>; Sun, 2 Nov 2014 11:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level:
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO_o4YPdEamL for <oauth@ietfa.amsl.com>; Sun, 2 Nov 2014 11:55:11 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72601A015B for <oauth@ietf.org>; Sun, 2 Nov 2014 11:55:11 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sA2Jt9UD027074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Nov 2014 19:55:10 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA2Jt8Bk014484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Nov 2014 19:55:08 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sA2Jt7A6014481; Sun, 2 Nov 2014 19:55:07 GMT
Received: from [192.168.1.8] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 02 Nov 2014 11:55:07 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <FFB09F34-19C5-4616-87DE-EE6D10305724@ve7jtb.com>
Date: Sun, 02 Nov 2014 11:55:06 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <65FB0488-88D1-4C55-B64F-071284AC6730@oracle.com>
References: <543FF850.6070409@gmx.net> <B18173FA-7AD9-40A7-98AF-8D2A4AED744D@mitre.org> <5456640C.9090404@lodderstedt.net> <DF8EF8BB-75B1-49A4-92D6-81D72D3DA807@oracle.com> <FFB09F34-19C5-4616-87DE-EE6D10305724@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.1878.6)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ysIFnCiWSg5hiebH-ELDOeCXFcM
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Nov 2014 19:55:13 -0000

Sigh.

Phil

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



On Nov 2, 2014, at 10:33 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> If a client developer doesn't have Connect available then they need to point the API developer at this doc, so that they do provide Connect or some other API that takes into account all of the security considerations.
> 
> A client developer should never make up there own identity protocol out of someone else's API that is not designed for it.
> 
> A vanilla OAuth API with no additional security considerations on the API developers part is pretty much guaranteed to go horribly wrong.
> 
> John B.
> 
> On Nov 2, 2014, at 2:15 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
>> We may have a problem with audience here. 
>> 
>> Justin mentioned he wrote it for service providers but the threats are against the client that wants to authenticate users. 
>> 
>> Would be better to have recommendations for each group. 
>> 
>> Since oidc is the only recommendation, what does a client implementer do when openid connect is not available?  Suggest we give a list of qualities developers should look for (eg is fb connect good)?
>> 
>> Phil
>> 
>>> On Nov 2, 2014, at 09:04, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> I just read the document. It explains the situation, challenges/threats, and options very clear and readable.
>>> 
>>> So +1 for publishing it soon.
>>> 
>>> kind regards,
>>> Torsten.
>>> 
>>> Am 28.10.2014 00:21, schrieb Richer, Justin P.:
>>>> I've been incorporating peoples' feedback into the proposed oauth.net page, and the current state is here:
>>>> 
>>>> https://github.com/jricher/oauth.net/blob/authentication/articles/authentication.php
>>>> 
>>>> Commentary has slowed down and I think the document's in reasonable. I would like to publish this as a draft version on oauth.net in the very near future (like, this week), so get comments and feedback to me on this soon. I'm going to be at IIW all week if anyone wants to back me into a corner and talk about this.
>>>> 
>>>> -- Justin
>>>> 
>>>>> On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>>> 
>>>>> Participants:
>>>>> 
>>>>> * Brian Campbell
>>>>> * John Bradley
>>>>> * Derek Atkins
>>>>> * Phil Hunt
>>>>> * William Kim
>>>>> * Josh Mandel
>>>>> * Hannes Tschofenig
>>>>> 
>>>>> 
>>>>> Notes:
>>>>> 
>>>>> Justin distributed a draft writeup and explained the reasoning behind
>>>>> it. The intended purpose is to put the write-up (after enough review) on
>>>>> oauth.net. See attachments. Justin solicited feedback from the
>>>>> conference call participants and from the working group.
>>>>> 
>>>>> One discussion item was specifically related to the concept of audience
>>>>> restrictions, which comes in two flavours: (a) restriction of the access
>>>>> token regarding the resource server and (b) restriction of the id token
>>>>> regarding the client. Obviously, it is necessary to have both of these
>>>>> audience restrictions in place and to actually check them.
>>>>> 
>>>>> The group then went into a discussion about the use of pseudonyms in
>>>>> authentication and the problems deployments ran into when they used
>>>>> pseudonyms together with a wide range of attributes that identified
>>>>> users nevertheless. Phil suggested to produce a write-up about this topic.
>>>>> 
>>>>> Finally, the group started a discussion about potential actions for the
>>>>> OAuth working groups. Two activities were mentioned, namely to produce
>>>>> an IETF draft of the write-up Justin has prepared as a "formal" response
>>>>> to the problems with authentication using OAuth and, as a second topic,
>>>>> potential re-chartering of the OAuth working group to work on some
>>>>> solutions in this area. Hannes suggested to postpone these discussions
>>>>> and to first finish the write-up Justin had distributed.
>>>>> 
>>>>> Ciao
>>>>> Hannes & Derek
>>>>> <Authentication with OAuth 2.doc><Authentication with OAuth 2.html><Authentication with OAuth 2.pdf>_______________________________________________
>>>>> 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
>