Am 30.12.2012 um 13:53 schrieb Mark Wubben :
> On 25 Dec 2012, at 12:24, Torsten Lodderstedt wrote:
>> You raised an interesting point. Is it desirable to share an access grant
>> among different client instances? I would like to discuss this topic in the
>> working group.
>>
>> If we assume
On 26 Dec 2012, at 17:14, Torsten Lodderstedt wrote:
> What does this mean? I would like to focus on the revocation of the token
> actually passed to the revocation endpoint and leave the impact on other
> related tokens and the authorization itself to the authorization server's
> policy. The a
On 25 Dec 2012, at 12:24, Torsten Lodderstedt wrote:
> You raised an interesting point. Is it desirable to share an access grant
> among different client instances? I would like to discuss this topic in the
> working group.
>
> If we assume it is desirable, how would the authorization process l
Hi Torsten
On 27/12/12 18:02, Torsten Lodderstedt wrote:
Depending on the authorization server's revocation policy, the
revocation of a particular token may cause the revocation of related
tokens and the underlying authorization.
If the particular token is a refresh token and the authorization
I'm fine with this approach, though I'd leave in a RECOMMEND for the
refresh token -> access token cascading delete, since it will be a
common one.
-- Justin
On 12/26/2012 11:14 AM, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again
Am 27.12.2012 12:44, schrieb Sergey Beryozkin:
Hi again,
On 27/12/12 09:41, Sergey Beryozkin wrote:
Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec, wh
Depending on the authorization server's revocation policy, the
revocation of a particular token may cause the revocation of related
tokens and the underlying authorization.
If the particular token is a refresh token and the authorization server
supports the revocation of access tokens, then the
Hi again,
On 27/12/12 09:41, Sergey Beryozkin wrote:
Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec, which doesn't unnessarily restricts
implementations
Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec, which doesn't unnessarily restricts
implementations. OAuth leaves so much freedom to implementors (for go
Hi John,
thanks for your feedback.
After having thought through this topic again I came to the conclusion
that I want to have a simple spec, which doesn't unnessarily restricts
implementations. OAuth leaves so much freedom to implementors (for good
reasons), which we should preserve.
What d
We don't want to share grant information across multiple instances of public
client.
However we don't necessarily want to preclude multiple instances of a private
client, Though how the AS would tell them apart is a interesting side question.
>From a revocation point of view if you revoke the
Hi Mark,
thanks for reviewing the draft. Comments inline.
Am 02.12.2012 18:27, schrieb Mark Wubben:
The draft relies heavily on the definition "access grant", but no definition is provided
in the draft or RFC 6749. It's been my interpretation that an "access grant" is the
*fact* that a resour
The draft relies heavily on the definition "access grant", but no definition is
provided in the draft or RFC 6749. It's been my interpretation that an "access
grant" is the *fact* that a resource owner has authorized a client (potentially
scoped) access to the protected resources. Once access is
I have reviewed the document, and it looks ready to go.
-- Justin
On 11/24/2012 01:13 PM, Hannes Tschofenig wrote:
Hi all,
this is a working group last call for draft-ietf-oauth-revocation-03 on "Token
Revocation". The draft is available here:
http://tools.ietf.org/html/draft-ietf-oauth-rev
Hi all,
this is a working group last call for draft-ietf-oauth-revocation-03 on "Token
Revocation". The draft is available here:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
Please send you comments to the OAuth mailing list by December 10, 2012.
Thanks,
Hannes & Derek
__
15 matches
Mail list logo
