Subject: [OAUTH-WG] Metadata about Authorization Servers

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Oct 2016 23:49:46 +0200

Hi all,

I need the feedback from the group on one of our working group items,
namely https://tools.ietf.org/html/draft-ietf-oauth-discovery-04

Despite the name (discovery) the document really only describes
configuration information about an authorization server in a machine
readable form, which today a developer would typically retrieve from an
HTML page. The confirmation information includes things like endpoint
URIs, issuer identifiers, etc..

In the discussions the concern that surfaced was about the envisioned
message flow on when a client would obtain such information:

* One group was of the opinion that a client would already know what
resource server it wants to talk to before reaching out to the
authorization server to obtain this meta data.

* The second group was under the believe that a resource server would
tell the client what authorization server to contact.

There was no conclusion about which message interaction is more likely
or better but in any case there are security concerns that arise. I
don't think that there is a conclusion that the message interaction
actually matters for the context of this work since the information
about resource servers is available already today although not in an
machine readable form.

The main concern is that a resource server gets the client to obtain a
token that he can then re-use with other resource servers.

Quite naturally this is a bad thing and we have developed two solution
approaches to deal with this problem, namely

* Audience restricted access tokens (see
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01),
and

* PoP tokens (with the current token binding solution as a WG item)

Since token binding will need a bit of time before it gets widely
deployed I believe that we need to mandate the use of audience
restrictions for use with the resource meta data (which IMHO should have
been mandated already in the OAuth core specification).

I don't think we have a conclusion whether these security issues are
really tied to the metadata document since the security concern about
tokens getting replayed at other resource servers was a concern long
before the meta-data work was even considered in OAuth.

So, how should we move forward with the metadata document? Your views
are appreciated!

Ciao
Hannes