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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
