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 <phil.h...@oracle.com> 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 <ve7...@ve7jtb.com> 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 <phil.h...@oracle.com> wrote: >>> >>> Sigh. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>> >>> >>> >>>> On Nov 2, 2014, at 10:33 AM, John Bradley <ve7...@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.h...@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 <tors...@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.tschofe...@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 >> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
