[OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany

Hi all, early this year we announced our plans to organize an OAuth security workshop. In the meanwhile we have made progress in the planning activities and we are happy to announce that the workshop will take place July 14th and 15th 2016 in Trier/Germany. The date fits nicely with the IETF meeti

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Step 0 is something we need to discuss. An OAuth protected resource can be hacked if a client uses an evil discovery and it returns a proxied resource server. Just as a token server can be proxied, so can a resource server. So the OAuth server may be issuing tokens in a secure way, but then

Re: [OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany

Thanks Hannes. That’s great news! Phil @independentid www.independentid.com phil.h...@oracle.com > On Feb 19, 2016, at 3:12 AM, Hannes Tschofenig > wrote: > > Hi all, > > early this year we announced our plans to organize an

[OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps

Hi, we use the OAuth 2.0 Implicit grant to issue access_tokens to client applications such as HTML 5 web apps that have no secure means to securely authenticating themselves. Even if the credentials would be obfuscated, any user could extract them from the HTTP requests their User Agent makes w

[OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Early February I posted a mail to the list to make progress on the solution to the OAuth Authorization Server Mix-Up problem discovered late last year. Here is my mail about the Authorization Server Mix-Up: http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html Here is my mail to the li

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Option A. I have higher confidence that this specification solves the problems because it was designed during a 4-day security meeting dedicated to this task by a group of over 20 OAuth security experts, including both sets of researchers in Germany who originally identified the problem. This

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Option A: I agree with Mike that the complexity and implementation cost of Option B will make adoption harder, which was also a concern with the first iteration of Option A. To be honest, I'm not sure most people would even understand why the complexity would be required and just forget about

[OAUTH-WG] OAuth 2.0 Discovery Location

The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 On 19/02/16 23:59, Justin Richer wrote: > The newly-trimmed OAuth Discovery document is helpful and moving in the right > direction. It does, however, still have too many vestiges of its OpenID > Connect origins. One issue in particular still really bothers me: the use of > “/.well-known/ope

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Option A Phil > On Feb 19, 2016, at 13:39, Hans Zandbelt wrote: > > Option A: I agree with Mike that the complexity and implementation cost of > Option B will make adoption harder, which was also a concern with the first > iteration of Option A. > > To be honest, I'm not sure most people wou