Bill, >> A WWW-Authenticate response header that identifies an authorization >> server (AS) would be a great hypermedia-driven solution. >> It tells the client app which AS a service trusts. >> The client app can then get a token. ...
> Yeah, unfortunately the WWW-Authenticate solution advertising an AS > has bad (fatal) security problems. Is phishing the fatal security problem? It doesn't sound quite like "normal" phishing. Are there still fatal problems if phishing-resistant user authentication mechanisms are used? I would really appreciate any further explanation (or pointers to explanations). > That's the underlying reason/urgency behind a separate services > discovery mechanism. It's not that we ignored WWW-Authenticate, > and in fact I'm in process of ripping that mechanism out of a > draft I'm working on. > > This is not hard when the protected resource or user identifier > is in a domain where WebFinger (WF) will work. Is this because we assume a domain controls its webfinger URI, but we don't want to assume a domain controls all its other URIs (perhaps because some will serve user-generated content)? > The problem comes when we have, for example, N email domain names > all served by the same AS, and you have to discover that way. > The solution there may be that you take an indirect path through > the MX record (one suggestion), determine the domain from that, > and do the WF lookup based on the MX domain. This doesn't sound like Sergey’s situation where the client app has made a web request -- so it knows the URI it wants. > For arbitrary webservices running on a domain where they can't > run their own WF endpoint we don't yet have a solution. > At some point the client may well be expected to know something > about the identity it expects to use for a site. Could you clarify "the identity it expects to use for a site"? I'm not sure if this is talking about the user's identity, the client app's identity or the site's identity. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
