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
