<div dir="ltr"><div>OpenID AB/Connect Call Notes (2016-01-25)</div><div>==========================================</div><div>Date: 2016-01-25 23:00 UTC - 2016-01-26 00:10 UTC</div><div>Attendee: John, Nat, George, Nov, Edmund</div><div>Regrets: Mike (due to Fido meetings) </div><div><br></div><div>Events</div><div>--------</div><div>John is preparing the events in Santiago, Chile, </div><div>right before the IETF BA. </div><div>There are handful of committed people to come. </div><div>Local participants are also expected. </div><div><br></div><div>Mix-up & Other OAuth related threats</div><div>-------------------------------------</div><div>The group spent most of the time discussing it. </div><div><br></div><div>Apparently, there has to be some kind of discovery </div><div>to fix the attack. </div><div>George pointed out that we are adding a lot of </div><div>little things like client registration, PKCE, </div><div>discovery, etc. to try and mitigate these attacks </div><div>in OAuth2 and it's confusing when they are needed </div><div>and when they aren't.</div><div><br></div><div>It would be simpler to say that OAuth2 with </div><div>a single pre-configured AS is fine. </div><div>If a client wants to support multiple Authorization Servers </div><div>(a la dynamic client registration or some other method) </div><div>then here are all the things that need to be done. </div><div>Maybe this would be simpler as a profile of </div><div>OAuth2 (in the vein of OpenID Connect) that adds </div><div>the necessary requirements to mitigate these attacks. </div><div><br></div><div>While it is a good idea to issue a short patch speck, </div><div>it may be better to do a OAuth 2.1. </div><div><br></div><div>The group agreed. </div><div><br></div><div>For two types of discovery([1],[2]), </div><div>John and George pointed out that, in many cases, </div><div>the AS does not know where the code or </div><div>tokens are going to be used. This is especially </div><div>true in the case of resources that there apparently </div><div>are multiple resource end point popping up on a </div><div>single logical resource represented by a scope. </div><div>The access tokens cannot be bound even to a domain. </div><div><br></div><div>Thus, in many cases, the AS cannot supply the list of </div><div>token endpoints nor resource endpoints and it is the </div><div>client's responsibility to behave responsibly. </div><div><br></div><div>Nat pointed out that seems to be violating the assumption </div><div>that the access tokens are as good as cookie, which is </div><div>at least bound to a domain, but if that is the case </div><div>in the wild, requiring even a domain based audience </div><div>restriction on the tokens as in oauth-meta draft </div><div>would break a lot of application. Also, he pointed out </div><div>that if that is the state of the bearer token, </div><div>we need to beware of it and regard the bearer token </div><div>based system accordingly. For a higher level risk </div><div>case, we cannot rely on the model that we potentially </div><div>need to consider the PoP token instead. </div><div><br></div><div>As a related issue, the group talked about </div><div>the issue of bad client registering and users </div><div>granting access to them. Simply requiring developers </div><div>to register a client does not stop attackers. </div><div>It used to be easier for them to take other venues </div><div>but the proliferation of the second factor authenticator </div><div>and so on has pressured them to move to this direction </div><div>as well. This is a trust framework issue and what a </div><div>protocol can do is to provide a hook so that </div><div>the trust framework can make use of it. </div><div><br></div><div>Other Issues</div><div>-------------</div><div>The time has run out in this meeting and the group </div><div>could not address the session management and logout </div><div>related issues. In the next call, they are going to </div><div>get the priority. </div><div><br></div><div>Next Meeting</div><div>--------------</div><div>The next meeting will be at 15:00 UTC on Feb. 4. </div><div>(Feb.4 7am PST, Feb.5 Midnight JST)</div><div><br></div><div>References</div><div>--------------</div><div>[1] <a href="https://tools.ietf.org/html/draft-sakimura-oauth-meta-05">https://tools.ietf.org/html/draft-sakimura-oauth-meta-05</a></div><div>[2] <a href="https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01">https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01</a></div><div><br></div><div><br></div><div>END</div><div><br></div></div>