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
