The problem is the password grant. Clients that support it would potentially
deliver the username and password without asking the user, or by prompting in
the UI itself and not through a web interaction with the AS.
>________________________________
> From: "Manger, James H" <james.h.man...@team.telstra.com>
>To: William Mills <wmi...@yahoo-inc.com>; "oauth@ietf.org" <oauth@ietf.org>
>Sent: Wednesday, May 16, 2012 5:55 AM
>Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>
>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
