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

[John Bradley <[e-mail]>]

Many of the threats can only be mitigated by the AS/IDP .   This document should cover that.   

I didn't say the IdP must use connect only that it needs to understand and mitigate the treats from the document,  implementing Connect is one way to do it.

Sorry I was trying to interpret "Sigh"

John B.



On Nov 2, 2014, at 6:47 PM, Phil Hunt <[e-mail]> wrote:

> That is not what I said. 
> 
> I said establish the criteria for mitigation of the threats. 
> 
> Phil
> 
>> On Nov 2, 2014, at 12:53, John Bradley <[e-mail]> wrote:
>> 
>> Your proposal required changes and extensions to the AS.
>> 
>> Without some cooperation from the AS /API provider, they shouldn't be using OAuth for identity.
>> 
>> The client can't make it secure all on it's own.   The API semantics might change,  the client would largely be relying on luck.
>> 
>> Sorry,
>> 
>> What sort of advice are you looking for that the client can implement without the cooperation of the IdP around some of the security considerations.
>> About the only thing would be to never use implicit.  However that alone in my opinion is not sufficient for real security.
>> 
>> John B.
>> 
>> 
>> 
>> 
>>> On Nov 2, 2014, at 4:55 PM, Phil Hunt <[e-mail]> wrote:
>>> 
>>> Sigh.
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> [e-mail]
>>> 
>>> 
>>> 
>>>> On Nov 2, 2014, at 10:33 AM, John Bradley <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>