Hi, I've been out of this for a while working on something else. To get back
in, I read through the latest draft and have some feedback. The fact that I've
been paying attention to other things for a while means my feedback has a
different slant from that of people who have been engaged. On the
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Tuesday, March 15, 2011 2:38 PM
> Having a standard set of oauth errors on the protected
> resource is a good idea. That said:
Not practical. Given the wide range of token types and schemes, each will have
to
Other use cases include the encoding extensions (such as the XML one,
and if anyone gets around to it, the form-encoded one) and a "format not
supported" error. Having a standard set of oauth errors on the protected
resource is a good idea. That said:
> I am still not convinced we need to address
Thank you.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent: Tuesday, March 15, 2011 1:17 PM
> Per the previous discussions, the use case is enabling OAuth specifications to
> be able to extend the set of interoperable er
This made me recall a formula from a middle-school textbook on physics
or something:
(IAB/I)*P = PAB.
Hint: I think in that Hilton they deliver beer to any room.
Igor
Hannes Tschofenig wrote:
...
Depending on the number of people and your exact goals you can either go to a pub or I could
Per the previous discussions, the use case is enabling OAuth specifications to
be able to extend the set of interoperable error codes. Use of an IANA
registry for this purpose is standard IETF practice. (To see *lots* of other
examples of this in practice, go to http://www.iana.org/protocols/
A reminder to send me your presentation request.
On Mar 14, 2011, at 9:13 AM, Hannes Tschofenig wrote:
> Hi all,
>
> the IETF meeting in Prague is just around the corner and we need to put the
> agenda for the face-to-face meeting together.
> If you plan to give a presentation please drop us
Am 15.03.2011 14:34, schrieb David Robinson:
Page 4 of the specification says:
The client MUST NOT make any assumptions about the timing and MUST NOT
use the token again.
In the case of a self-care portal mentioned in - 1.0 Introduction -
clients may not be aware that
tokens have been revok
Hi Torsten,
I was wondering whether you care about the JSON security discussion that is
also going to happen during the week. I think it is relevant for OAuth!
That session is on Monday.
Throughout the week there are plenty of security related activities.
Scheduling some time for OAuth secur
Congratulation!
I've got some questions:
- do you support the token_type parameter for the revocation endpoint?
- where can one find a documentation of the native app support?
- what is your approach to native apps and client secrects?
regards,
Torsten.
Am 14.03.2011 20:35, schrieb Marius Scurt
Hi Peter,
Thursday is fine with me.
I'm also open to start the dicussion around the topic earlier in one of
the beer halls Igor mentioned :-)
regards,
Torsten.
Am 14.03.2011 10:10, schrieb Mark Mcgloin:
Can we rule out Friday afternoon as people will be getting return flights.
I am trying
This specification is ready to publish.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Wednesday, March 02, 2011 12:32 AM
To: OAuth WG
Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt
This is a Last Call f
My last call feedback on draft 13 follows.
NORMATIVE FEEDBACK
2.1.1: "If no valid redirection URI is available, the authorization server
SHOULD" - I don't understand why this is a SHOULD and not a MUST
3: Restore Client Assertion Credentials
Restore the Client Assertion Credentials feature t
Page 4 of the specification says:
The client MUST NOT make any assumptions about the timing and MUST NOT use
the token again.
In the case of a self-care portal mentioned in - 1.0 Introduction -
clients may not be aware that
tokens have been revoked. In that scenario is seems probable that client
Hi Chuck,
would be cool if you implement it :-)
Wrt you proposal: during the discussions on the list, Marius and Justin
suggested to drop the parameter. I checked back with our engineers and they
gave me thumbs up as well. I probably should have issued a WG vote for that
feature before changin
15 matches
Mail list logo
