Hi Torsten
On 27/12/12 18:22, Torsten Lodderstedt wrote:
Am 27.12.2012 10:57, schrieb Sergey Beryozkin:
sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:
Hi all,
any other opinion regarding having or not having a token type parameter?
I would like to go with #1 as it is rather late in the pr
Sounds reasonable to me.
-- Justin
On 12/25/2012 08:19 AM, Torsten Lodderstedt wrote:
Hi Peter,
your proposal sounds reasonable.
Since it involves a change to the interface spec (400 instead of 403
in case of unauthorized access) I would like to ask the working group
for feedback.
What d
Hi Amanda,
I incoporated your comments. I'm waiting for feedback on the other
threads before I will post another revision.
http://www.ietf.org/mail-archive/web/oauth/current/msg10334.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10331.html
http://www.ietf.org/mail-archive/web/oaut
Am 27.12.2012 10:57, schrieb Sergey Beryozkin:
sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:
Hi all,
any other opinion regarding having or not having a token type parameter?
I would like to go with #1 as it is rather late in the process to
(re-)introduce a mandatory parameter. And making
Hi Torsten,
Responses inline in blue.
On 12/25/2012 08:11 AM, Torsten Lodderstedt wrote:
Hi Amanda,
thank you for reviewing the draft. Comments inline.
Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
Here is my review of the Toke Revocation draft
(http://datatracker.ietf.org/doc/draft-ietf-o
sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:
Hi all,
any other opinion regarding having or not having a token type parameter?
I would like to go with #1 as it is rather late in the process to
(re-)introduce a mandatory parameter. And making it an optional
parameter (#4) seems not really us
I agree that #1 is currently the best option.Tokens are supposed to be
opaque to the client in principal. The AS is in the best position to sort it
out of required. Nothing stops the token from being structured if it is an
issue for the AS.
John B.
On 2012-12-25, at 9:41 AM, Torsten Lod
Hi Peter,
your proposal sounds reasonable.
Since it involves a change to the interface spec (400 instead of 403 in
case of unauthorized access) I would like to ask the working group for
feedback.
What do you think? I especially would like to gain feedback from
implementors of the draft (e.g
Hi Amanda,
thank you for reviewing the draft. Comments inline.
Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
Here is my review of the Toke Revocation draft
(http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
Section 1. Introduction
First paragraph has the following definition in
Hi all,
any other opinion regarding having or not having a token type parameter?
I would like to go with #1 as it is rather late in the process to
(re-)introduce a mandatory parameter. And making it an optional
parameter (#4) seems not really useful to me.
regards,
Torsten.
The way I see it
During the last week I had the chance to implement the non optional
features of the token revokation draft. I would be glad if the document
would get a closer connection to the refrenced RFC6749 regarding the
error handling.
The draft states to use HTTP status 401 and 403 for certain error
co
An early draft of the revocation spec had this token type field, for
this purpose. From an early conversation on the list with Torsten, we
decided that most of the time it didn't matter, as different classes of
token would be recognizable as different by the AS. In some
implementations (like ou
Here is my review of the Toke Revocation draft
(http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
Section 1. Introduction
First paragraph has the following definition in it: "A token is the external
representation of an access grant issued by a resource owner to a particular
client
13 matches
Mail list logo
