[Openid-specs-ab] OpenID AB/Connect Call Notes (2016-01-25)

Nat Sakimura sakimura at gmail.com
Tue Jan 26 01:06:18 UTC 2016

OpenID AB/Connect Call Notes (2016-01-25)
Date: 2016-01-25 23:00 UTC - 2016-01-26 00:10 UTC
Attendee: John, Nat, George, Nov, Edmund
Regrets: Mike (due to Fido meetings)

John is preparing the events in Santiago, Chile,
right before the IETF BA.
There are handful of committed people to come.
Local participants are also expected.

Mix-up & Other OAuth related threats
The group spent most of the time discussing it.

Apparently, there has to be some kind of discovery
to fix the attack.
George pointed out that we are adding a lot of
little things like client registration, PKCE,
discovery, etc. to try and mitigate these attacks
in OAuth2 and it's confusing when they are needed
and when they aren't.

It would be simpler to say that OAuth2 with
a single pre-configured AS is fine.
If a client wants to support multiple Authorization Servers
(a la dynamic client registration or some other method)
then here are all the things that need to be done.
Maybe this would be simpler as a profile of
OAuth2 (in the vein of OpenID Connect) that adds
the necessary requirements to mitigate these attacks.

While it is a good idea to issue a short patch speck,
it may be better to do a OAuth 2.1.

The group agreed.

For two types of discovery([1],[2]),
John and George pointed out that, in many cases,
the AS does not know where the code or
tokens are going to be used. This is especially
true in the case of resources that there apparently
are multiple resource end point popping up on a
single logical resource represented by a scope.
The access tokens cannot be bound even to a domain.

Thus, in many cases, the AS cannot supply the list of
token endpoints nor resource endpoints and it is the
client's responsibility to behave responsibly.

Nat pointed out that seems to be violating the assumption
that the access tokens are as good as cookie, which is
at least bound to a domain, but if that is the case
in the wild, requiring even a domain based audience
restriction on the tokens as in oauth-meta draft
would break a lot of application. Also, he pointed out
that if that is the state of the bearer token,
we need to beware of it and regard the bearer token
based system accordingly. For a higher level risk
case, we cannot rely on the model that we potentially
need to consider the PoP token instead.

As a related issue, the group talked about
the issue of bad client registering and users
granting access to them. Simply requiring developers
to register a client does not stop attackers.
It used to be easier for them to take other venues
but the proliferation of the second factor authenticator
and so on has pressured them to move to this direction
as well. This is a trust framework issue and what a
protocol can do is to provide a hook so that
the trust framework can make use of it.

Other Issues
The time has run out in this meeting and the group
could not address the session management and logout
related issues. In the next call, they are going to
get the priority.

Next Meeting
The next meeting will be at 15:00 UTC on Feb. 4.
(Feb.4 7am PST, Feb.5 Midnight JST)

[1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-05
[2] https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160126/e0def97c/attachment.html>

More information about the Openid-specs-ab mailing list