Hey Torsten -
I'm trying to parse through these messages to figure out the flows
you're interested in.
I think you're aiming for rules like this one, right?
kerberos authentication -> access token
or
digest authentication -> access token
And furthermore your intended use cases are applications installed on
an end-users machine, where the end-users machine participates in some
kind of authentication service. For example, maybe the machine is
joined to some kerberos realm, or maybe the user has a smart card.
Have I identified the use cases properly? Or are you dealing with
three-legged OAuth situations, where you actually want user consent on
a web page?
Cheers,
Brian
On Tue, Jan 25, 2011 at 12:22 AM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
> Zitat von Eran Hammer-Lahav <e...@hueniverse.com>:
>
>> There is no clean way to do with without defining new HTTP authentication
>> schemes. The token endpoints takes:
>>
>> 1. Client authentication
>> 2. Authorization grant
>>
>> There is no user authentication. Even the resource owner password
>> credentials is not user authentication but only validation of "some grant
>> values".
>
> What's the difference from a conceptual point of view? In my opinion, the
> resource owners password is used for both, authenticating the resource owner
> and authorizing the token issuance.
>
>>
>> What you can do is define an authentication scheme which will authenticate
>> the client and provide the grant in one header, or
>
> the spec makes the grant type a required parameter, so a lonely
> authorization header won't be suffiencent.
>
>> define a new grant type for such credentials. But you can't use
>
> That brings us back to the mix between POST parameters and authz headers for
> credential transmission. Something you critized for good reasons.
>
>> something like Basic or Digest to provide the resource owner's
>> credentials. That's against the endpoint design.
>
> It's good to know that restriction, but I'm not happy :-( So based on that
> information I would say, the only proper way to integrate standard HTTP
> schemes would be to invent another endpoint for that purpose.
>
> Comments?
>
> regards,
> Torsten.
>
>>
>> EHL
>>
>>
>>> -----Original Message-----
>>> From: tors...@lodderstedt.net [mailto:tors...@lodderstedt.net]
>>> Sent: Monday, January 24, 2011 10:35 PM
>>> To: Eran Hammer-Lahav; OAuth WG
>>> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with
>>> tokensendpoint?
>>>
>>> Hi Eran,
>>>
>>> thanks for your response. My inquiry was about end-user authentication
>>> and
>>> not about client authentication. All http schemes I'm aware of
>>> authenticate
>>> users and I want to find a way to leverage them with OAuth to determine
>>> the
>>> token's identity.
>>>
>>> Regards,
>>> Torsten.
>>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>>
>>> -----Original Message-----
>>> From: Eran Hammer-Lahav <e...@hueniverse.com>
>>> Date: Mon, 24 Jan 2011 15:25:38
>>> To: Torsten Lodderstedt<tors...@lodderstedt.net>; OAuth
>>> WG<oauth@ietf.org>
>>> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
>>> endpoint?
>>>
>>> This is pretty straight-forward. There are no special parameters to
>>> indicated
>>> which client authentication is being used. It's either there or not,
>>> using
>>> whatever the server supports.
>>>
>>> Simply have the token endpoint return a 401 with these WWW-Authenticate
>>> headers. As long as you make it clear how to make between the client
>>> identifier and the credentials used, you are set.
>>>
>>> For example, a token response can return:
>>>
>>> 401 Unauthorized
>>> WWW-Authenticate: Basic realm="example"
>>> WWW-Authenticate: Digest realm="example"
>>>
>>> There is no discovery for support for the client_id and client_secret
>>> parameters. The client can simply try it or hardcode it based on the
>>> server's
>>> documentation.
>>>
>>> Does this help?
>>>
>>> EHL
>>>
>>> > -----Original Message-----
>>> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>>> > Of Torsten Lodderstedt
>>> > Sent: Monday, January 24, 2011 1:10 PM
>>> > To: OAuth WG
>>> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
>>> > endpoint?
>>> >
>>> > Hi all,
>>> >
>>> > I'm currently thinking about the integration of existing HTTP
>>> > authentication schemes with OAuth 2.0 for the purpose of end-user
>>> > authentication on the tokens endpoint. Possible candidates are "Digest"
>>> > for challenge-response-based username/password authentication and
>>> > "Spnego" for Kerberos-based authentication. Direct support for both
>>> > could be beneficially in enterprise and other security sensitive
>>> deployments.
>>> >
>>> > An direct integration with the tokens endpoint would allow to leverage
>>> > existing implementations and infrastructure for OAuth/HTTP-based
>>> > architectures. For example, HTTPClient has direct support for Spnego-
>>> > Authentication.
>>> >
>>> > Both HTTP authentication schemes use dedicated WWW-Authenticate and
>>> > Authorization headers for passing credential and other data between
>>> > client and server. OAuth in contrast uses grant types to indicate the
>>> > authentication method, credentials are passed as URI query parameters
>>> > and it lacks any discovery of available authentication methods/ grant
>>> > types.
>>> >
>>> > How could one integrate existing schemes into that design? What is our
>>> > story? Do we need to define a special grant type "HTTP authorization"?
>>> > Shall Authorization headers overrule URI parameters?
>>> >
>>> > Any ideas of the WG are higly appreciated.
>>> >
>>> > regards,
>>> > Torsten.
>>> >
>>> >
>>> >_______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
