On Sun, May 9, 2010 at 1:56 PM, Eran Hammer-Lahav wrote:
> The authorization server can issue an access token with any expiration but
> should not issue expiration
> later than that of the assertion. But still, there is nothing to prevent that.
Wait, why shouldn't the authorization server issue
Thanks for the clarity Eran and I understand.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Sunday, May 09, 2010 1:57 PM
To: Foiles, Doug; OAuth WG
Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial)
> -Original Mess
> -Original Message-
> From: Foiles, Doug [mailto:doug_foi...@intuit.com]
> Sent: Sunday, May 09, 2010 1:07 PM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: [OAUTH-WG] Autonomous clients and resource owners
> (editorial)
>
> Thanks for addressing my ques
TH-WG] Autonomous clients and resource owners (editorial)
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Foiles, Doug
> Sent: Sunday, May 02, 2010 8:41 AM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Autonomous clients and resou
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Foiles, Doug
> Sent: Sunday, May 02, 2010 8:41 AM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
> (editorial)
>
> I wanted
flow" would
work where the credential is something different than the username and
password.
Thanks.
Doug
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Chuck Mortimore
Sent: Tuesday, April 27, 2010 5:46 PM
To: Keenan, Bill; OAuth WG
Subject: Re: [OA
sday, April 27, 2010 9:06 AM
To: Torsten Lodderstedt; Brian Eaton
Cc: Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)
Same here - we don't intend to issue refresh tokens for either of these
flows, and we'll only be accep
2010 9:06 AM
To: Torsten Lodderstedt; Brian Eaton
Cc: Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)
Same here - we don't intend to issue refresh tokens for either of these
flows, and we'll only be accepting 1 time use
Cc: Chuck Mortimore; Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)
returning access token would suffice in this flow, from my point of
view.
regards,
Torsten.
Am 27.04.2010 um 08:33 schrieb Brian Eaton :
> From my perspective, the main thin
returning access token would suffice in this flow, from my point of
view.
regards,
Torsten.
Am 27.04.2010 um 08:33 schrieb Brian Eaton :
From my perspective, the main thing is that the assertion flow can be
used to connect existing authentication systems with APIs that are
using OAuth2 for
>From my perspective, the main thing is that the assertion flow can be
used to connect existing authentication systems with APIs that are
using OAuth2 for authorization.
This will let us leverage existing trust relationships across systems.
Note that this breaks, however, if the flow returns a re
+1
we need the assertion flow for the same purpose. Can we add a variant of
the flow to section "End User Credentials Flows"?
regards,
Torsten.
Am 26.04.2010 23:17, schrieb Chuck Mortimore:
+1.
Our primary use-cases for the assertion flow are for clients acting on
behalf of users, and not
In UMA, we've got use cases for "person-to-service" sharing that can act much
like the user-delegated OAuth patterns of today (essentially introducing two
services to interact on your own behalf), and also use cases for
"person-to-person" sharing that involve a "separate resource owner", hence o
+1.
Our primary use-cases for the assertion flow are for clients acting on behalf
of users, and not autonomously. I believe Eran already has this on his list
of feedback when the assertion flow gets edited.
We also have need for a 2 legged Oauth model, and are looking at the client
credentia
I have a bit of confusion on the Autonomous Client Flows … and specifically
related to Eve’s comment below that suggests to me that the autonomous client
is NOT ALWAYS the resource owner.
Can the Autonomous Client Flows support clients that ARE NOT the actual
resource owner? For example for
15 matches
Mail list logo
