On 18/08/2010, at 3:57 PM, Brian Eaton wrote:
> On Tue, Aug 17, 2010 at 7:33 PM, John Panzer wrote:
>> Is there any legit reason other than jsonp specifically?
>
> Protected resource authors are slack and are not going to read the
> spec. That might not be a great reason, but it's not a bad on
On Tue, Aug 17, 2010 at 7:33 PM, John Panzer wrote:
> Is there any legit reason other than jsonp specifically?
Protected resource authors are slack and are not going to read the
spec. That might not be a great reason, but it's not a bad one
either.
The other reason people get funny with these s
...and tunneling protocols over HTTP have worked *so* well in the past...
*makes another drink to help forget the SOAP nightmares*
back to your regular programming...
On 18/08/2010, at 9:06 AM, John Panzer wrote:
> Sure - as long as this is tied to the very special case of a tunneled
> protoco
Is there any legit reason other than jsonp specifically?
In the wild I mean.
On Tuesday, August 17, 2010, Brian Eaton wrote:
> On Tue, Aug 17, 2010 at 11:48 AM, David Recordon wrote:
>> Luke's point still holds true of the core spec needing to allow a 200 status
>> code on an error in this scen
On Tue, Aug 17, 2010 at 11:48 AM, David Recordon wrote:
> Luke's point still holds true of the core spec needing to allow a 200 status
> code on an error in this scenario. I'd also rather see this as part of the
> core spec as it reduces the number of things that implementors will need to
> read f
Sure - as long as this is tied to the very special case of a tunneled
protocol over http.
On Tuesday, August 17, 2010, David Recordon wrote:
> Luke's point still holds true of the core spec needing to allow a 200 status
> code on an error in this scenario. I'd also rather see this as part of the
Yes, as I thought we HAD to cope with it. Anyway, both 1a and 1c look
attractive to me. (BTW, I saw a comment on overloading of DELETE, with
which I sympathize in principle, but it looks to me that all methods
have been already overloaded, while DELETE semantically resonates with
the very na
Hi,
In the most recent draft version of the spec, section 2.1. Client Password
Credentials, the following example request is given:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authoriz
Lukas,
thanks for your feedback.
I think 1c not neccessarily introduces something new to manage. I would
rather expect implementations use either a ID already contained in the
token (like the SAML assertion ID) or a base64-encoded version of the
token itself.
regards,
Torsten.
Am 17.08.20
Igor,
1c does not further narrow down the character set for tokens. It instead
establishes an additional (URL-safe) id. That way no change is needed on
existing token formats and the existing protocol definition. This could
be combined with 1a or 1b but why? To cope with URL length restrictio
Luke's point still holds true of the core spec needing to allow a 200 status
code on an error in this scenario. I'd also rather see this as part of the
core spec as it reduces the number of things that implementors will need to
read for common use cases.
--David
On Tue, Aug 17, 2010 at 9:06 AM,
Well, no, jsonp is a special transport layer inside http. Making that
fuzzy will cause (interop and security) problems.
On Tuesday, August 17, 2010, Luke Shepard wrote:
> From the perspective of OAuth, a JSONP endpoint is just another protected
> resource. I'd rather not need us to write an ext
>From the perspective of OAuth, a JSONP endpoint is just another protected
>resource. I'd rather not need us to write an extension for every type of
>protected resource we might need to access.
I think the wordsmithing you discussed is what Paul's proposing - just saying
essentially "look, thes
+2 ;)
I don't like the use of the DELETE method, it feels too much like
overloading the semantics of the HTTP definitions. And as you outline
below, there are a few obstacles on it to make it really workable
anyway.
Another option not laid out below is a parameter on the token endpoint
to sugge
Good point. The server will have to provide special JSONP support anyway. This
is the only place where the requested status code handling is needed.
+1 for a JSONP extension spec
This might also result in much cleaner JSONP support.
regards,
Torsten.
Am 17.08.2010 um 09:28 schrieb John Panzer
Except you cannot guarantee that result of course (proxies, apache
plus tomcat separate processes etc. will all result in error codes).
Doesn't this all depend on a jsonp extension in the first place - the
client has to request a special jsonp response by specifying the
callback, thus making the s
16 matches
Mail list logo
