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
