Phil,
> What if strong authentication of client (between client and
> AM) happened OOB? Instead of passing a client_assertion, why
> not pass a client_token? In a sense we would be repeating
> the pattern for users and applying it to clients. A client
> use its own client_token to obtain access t
What if strong authentication of client (between client and AM) happened OOB?
Instead of passing a client_assertion, why not pass a client_token? In a sense
we would be repeating the pattern for users and applying it to clients. A
client use its own client_token to obtain access tokens.
I can
I absolutely don't want to drop credentials being passed as parameters. I think
that's more widely deployed than using the BASIC style auth as well.
I do think that Torsten's approach below has a certain elegance to it, but it
would require deeper access to queries that not all deployment framew
+1 to making BASIC optional. I don't think we were going to be supporting it
in general, either.
-- Justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
Sent: Saturday, January 15, 2011 1:53 AM
That text still seems more restrictive than what is in the framework
specification. And it's probably unnecessary - to the point James made
previously, any mention of the AS (beyond specifying the token_type) in a
"using a token" specification should probably be avoided unless there is a
very spec
One more reason to remove the half-baked text from the spec and reintroduce it
with a full specification elsewhere.
EHL
From: Francisco Corella [mailto:fcore...@pomcor.com]
Sent: Sunday, January 16, 2011 11:31 PM
To: Eran Hammer-Lahav; David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal:
