Hey Marius,
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Sunday, January 30, 2011 2:45 PM
> To: Eran Hammer-Lahav
> Cc: Mike Jones; OAuth WG
> Subject: Re: [OAUTH-WG] Update required for bearer token spec
>
> On Thu, Jan 27, 2011 at 6:23 PM, Eran Ha
Hey Marius,
It is critical for us to discuss the client assertion credentials separately
from the assertion authorization grant. The two have nothing to do with one
another.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Marius Sc
On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav wrote:
> As for the open issues: the bearer token scheme name - if it wasn’t clear, I
> plan to use every mean available to me to block the bearer token draft from
> using the ‘OAuth2’ scheme name, and will raise this issue in the WGLC, Area
> Dir
I would like to bring up one more argument to keep the assertion,
client_assertion_type and client_assertion parameters in core.
If I understood correctly, the main argument to remove them from core
was that they are underspecified and extensions are needed anyhow
before they are useful.
First of
Representing a provider who will be issuing both bearer and mac token types,
I'll state a preference on behalf of clarity for our developers to use the
"oauth_" prefix for both specifications. Both types will be referred to as
"OAuth" tokens in developer documentation regardless of specification
I was also thinking providers could specify a redirect_url on their own domain,
such as
http://www.kiva.org/oauth/callback/oob
But an urn or custom scheme (either is fine) that everyone can agree upon would
my preference, primarily to reduce developer confusion, but similarly for the
p
