I don't have anything against this approach but I suspect others might. I think
a few examples would be useful to demonstrate these ideas.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, July 19, 2010
grant_type=client_credential sounds ok.
An even better approach to addressing the discussions about grant_type and
assertions would be to focus on the *token response* as a standalone media
type, instead of focusing on a common token endpoint.
I don't think requiring the same token endpoint for
On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Dirk,
>
> I have some questions concerning your proposal:
>
> - As far as I understand, the difference to "magic signatures" lays in the
> usage of a JSON token carrying issuer, not_before, not_after and a
client credentials works for me as well.
On Mon, Jul 19, 2010 at 10:17 AM, Justin Richer wrote:
> "client_credentials" is fine with me for the name of this grant type.
> I'd also like the paragraph describing its use to be pulled out into a
> subsection, to be parallel with all the other grant ty
I am not aware of the use cases where the client credentials flow is used for
authenticating anything, but a client. But the flow is used for authorizing
access to the resources other than those owned by a client.
>From OAuth2.0 -05.txt:
The client credentials flow is used when the client acts o
On Mon, Jul 19, 2010 at 8:58 AM, William Mills wrote:
> Seems like we could also simply put up a 1.0a PR that issues a 2.0
> token. That avoids wedging 1.0 stuff into 2.0.
That's exactly what the bridge endpoint is doing.
Marius
___
OAuth mailing list
"client_credentials" is fine with me for the name of this grant type.
I'd also like the paragraph describing its use to be pulled out into a
subsection, to be parallel with all the other grant types.
-- Justin
On Sat, 2010-07-17 at 15:51 -0400, Eran Hammer-Lahav wrote:
> client_credentials work
Seems like we could also simply put up a 1.0a PR that issues a 2.0
token. That avoids wedging 1.0 stuff into 2.0.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Torsten Lodderstedt
> Sent: Saturday, July 17, 2010 5:31 AM
> To: Justin R
