I assume you refer to the openid parameter. This parameter is not general
purpose but problem specific. Thus it is in my opinion not suited as an example
for a general purpose standard.
regards,
Torsten.
Marius Scurtescu schrieb:
On Fri, Jun 17, 2011 at 12:13 PM, David Recordon wrote:
> +1
On Wed, Jun 15, 2011 at 7:36 PM, Manger, James H
wrote:
> It seems like an authorization server receiving a request with an
> unregistered redirect_uri of https://example.org/ can tell the user:
>
>
>
> “Permission will be passed to your browser then onto *example.org*”
>
>
>
> An authorization
On Wed, Jun 15, 2011 at 6:09 PM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Shane B Weeden [mailto:swee...@au1.ibm.com]
>> Sent: Wednesday, June 15, 2011 3:19 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
>>
>> > Fr
On Fri, Jun 17, 2011 at 12:13 PM, David Recordon wrote:
> +1 Eran
>
> On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav
> wrote:
>> OAuth has been successful because of its simple architecture and because it
>> is based on actual deployment experience. Offering multi-token responses
>> would
+1
Seems a reasonable approach/requirement.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-06-17, at 1:02 PM, William J. Mills wrote:
> This feels right to me. Additionally, any client consuming multiple tokens
> (whcih would be new) shoudl be able to add somethin
This feels right to me. Additionally, any client consuming multiple tokens
(whcih would be new) shoudl be able to add something onto the token request
indicating they are capable of such. This means we never break existing
clients.
From: Justin Richer
To: o
-1 on the reason not to discuss the issue now.
The current limited deployment case experience of OAuth does not necessarily
indicate the expected use in the future. We already know it to be MUCH broader
as the password anti-pattern is very large indeed.
I will also point out that this is a V. 2
Incidentally, I'd like to clarify my position that the below or any
other kind of multi-token formatting doesn't belong in the core spec.
-- Justin
On 6/17/2011 9:46 AM, Justin Richer wrote:
I completely agree that the single-token case needs to be left alone,
and I rather like this idea. The
+1 Eran
On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav wrote:
> OAuth has been successful because of its simple architecture and because it
> is based on actual deployment experience. Offering multi-token responses
> would be premature standardization. I am not convinced that adding it lat
Shane B Weeden schrieb:
>As I understand it, what you've described is precisely the intent of
>the
>refresh token. The online registration process you refer to is a
>corresponding one-time authorization code flow. The authorization code
>effectively becomes a one-time-use, short-lived credential
I completely agree that the single-token case needs to be left alone,
and I rather like this idea. The AS would return something like:
{
access_token: [
{
access_token: "1234656",
expires_in: 3600,
token_type: bearer
},
{
access_token: "abcdefg",
expire
As I understand it, what you've described is precisely the intent of the
refresh token. The online registration process you refer to is a
corresponding one-time authorization code flow. The authorization code
effectively becomes a one-time-use, short-lived credential for the client
instance which i
> If you aren't willing to accept the risk of native apps that can't keep
> secrets, don't support such apps.
We continue to say "can't keep secrets". I think what we mean is
"can't keep secrets that are embedded in the code". One could imagine
an install-time, leap-of-faith binding to a remotel
OAuth has been successful because of its simple architecture and because it is
based on actual deployment experience. Offering multi-token responses would be
premature standardization. I am not convinced that adding it later would entail
any real technical difficulty.
EHL
> -Original Mess
this is kind of a self-fulfilling prophecy. If we do not encourage
implementors to use service-specific tokens by supporting it in OAuth
most people will not consider it.
As James pointed out, there are good reasons to use service-specific
tokens in multi-service environments. That's why De
15 matches
Mail list logo
