y Beryozkin
> Sent: Thursday, July 03, 2014 9:29 AM
> To: Bill Mills; oauth@ietf.org
> Subject: Re: [OAUTH-WG] refresh tokens and client instances
>
> Hi
> On 03/07/14 16:40, Bill Mills wrote:
>> Implementations may/SHOULD bind refresh tokens to specific client
>> ins
>>>> specific client instances.
> >>>>
> >>>> AFAIK refresh tokens would only go on the wire, assuming they are
> >>>> supported, when a client exchanges a grant for a new access token.
> >>>> And when the client uses a refresh t
u for your reply. Would appreciate if you consider my inline
comments below and respond again!
R,
Madjid
*From:*John Bradley [mailto:ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>]
*Sent:*Wednesday, June 25, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org <mailto:oauth@ietf.org> <
>>>> Was it really about a refresh token grant where the incoming client id
>>>> and refresh token pair can uniquely identify the actual client instance
>>>> ? That would make sense.
>>>>
>>>> Something else I'd like to clarify.
>&g
. Do you need
different grant code types for each type of token?
Thanks,
Madjid
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Sergey Beryozkin
Sent: Thursday, July 03, 2014 9:29 AM
To: Bill Mills; oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client ins
refresh token pair can uniquely identify the actual client instance
>>>> ? That would make sense.
>>>>
>>>> Something else I'd like to clarify.
>>>> John mentions a refresh token is created at the authorization grant
>>>> initia
, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org
<mailto:oauth@ietf.org>>
*Subject:*Re: [OAUTH-WG] refresh tokens and client instances
In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to
14, at 1:24 PM, Madjid Nakhjiri > <mailto:m.nakhj...@samsung.com>
>> > <mailto:m.nakhj...@samsung.com <mailto:m.nakhj...@samsung.com>>> wrote:
>> >
>> >> Hi John,
>> >> Thank you for your reply. Would appreciate if you consider my inli
ain!
> >> R,
> >> Madjid
> >> *From:*John Bradley [mailto:ve7...@ve7jtb.com
> <mailto:ve7...@ve7jtb.com>]
> >> *Sent:*Wednesday, June 25, 2014 5:56 PM
> >> *To:*Madjid Nakhjiri
> >> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> &l
gt; Thank you for your reply. Would appreciate if you consider my inline
>> comments below and respond again!
>> R,
>> Madjid
>> *From:*John Bradley [mailto:ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>]
>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>> *T
comments below and respond again!
>> R,
>> Madjid
>> *From:*John Bradley [mailto:ve7...@ve7jtb.com]
>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>> *To:*Madjid Nakhjiri
>> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
>> *Subject:*Re: [OAUTH-WG] refresh toke
25, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] refresh tokens and client instances
In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the
Authorization server effect
11:22 AM
To: Madjid Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens and client instances
Inline
On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri wrote:
Hi John,
Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again
dnesday, June 25, 2014 5:56 PM
> To: Madjid Nakhjiri
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] refresh tokens and client instances
>
> In 3.3 It is saying that the refresh token is a secret that the Authorization
> server has bound to the client_id, that the Authorization ser
Hi John,
Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!
R,
Madjid
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Wednesday, June 25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] refresh tokens
In 3.3 It is saying that the refresh token is a secret that the Authorization
server has bound to the client_id, that the Authorization server effectively
uses to differentiate between instances of that client_id.
When the refresh token is generated, it can be stored in a table with the
client_
Hi all,
I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.
I am evaluating an OAUTH 2.0 implementation that is done based on bare bone
base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a "global ID/secret" pair for all instances of
17 matches
Mail list logo
