The problem is not with the auth servers, it's with clients that support
password grant. If they trust info sent to them by a resource server they will
give up the goods.
>________________________________
> 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:33 PM
>Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>
>
>> The problem is the password grant.
>
>This doesn’t sound like a good reason to ditch AS discovery via an
>WWW-Authenticate response header. Client apps using the password grant are
>only a subset of OAuth clients, and a specialized subset at that. The spec
>[draft-ietf-oauth-v2-26#section-4.3] says the “authorization server should
>take special care when enabling this grant type, and only allow it when other
>flows are not viable”. Just tell those few “highly privileged” client apps
>using the password grant not to use AS discovery via an WWW-Authenticate
>response if it is a problem (though I’m not sure it is any worse than a
>resource returning WWW-Authenticate: BASIC ... to trigger the password being
>sent?).
>
>--
>James Manger
>
>From:William Mills [mailto:wmi...@yahoo-inc.com]
>Sent: Thursday, 17 May 2012 12:29 AM
>To: Manger, James H; oauth@ietf.org
>Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>
>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
