Phil, When you write that article, just let me know and I'll add a link to it from this one.
Thanks, -- Justin On Nov 2, 2014, at 6:52 PM, Phil Hunt <phil.h...@oracle.com> wrote: > John > > I am trying to establish how a client app org should assess an AS org and > their approach. > > Why is fb/connect or oidc, or other approaches good or bad? > > The client org has to do this. We shouldn't be in the business of assessing > goodness or compliance. > > Phil > >> On Nov 2, 2014, at 15:14, John Bradley <ve7...@ve7jtb.com> wrote: >> >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
