Looking at draft 20, the public/confidential (replacing private) terms still
seem awkward. I still had a "huh" reaction.
It appears that the major qualities are: how wide is the client distributed
and shared and how well the client app is controlled.
How about widely-distributed vs. controlled
Or even: closed-systems and open-systems, though "open" has alot of baggage.
On 26 July 2011 13:10, Phil Hunt wrote:
> Looking at draft 20, the public/confidential (replacing private) terms
> still seem awkward. I still had a "huh" reaction.
>
> It appears that the major qualities are: how wide
Trying a different DL...
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Wed, Jul 20, 2011 at 6:38 AM, Andrew Arnott wrote:
> The recent OAuth 2 specs seem to omit the scenario of a client that cannot
> hos
I believe Google is working on a proposal for an oob URI value to use as the
redirection URI.
EHL
On Jul 26, 2011, at 9:18, "Andrew Arnott"
mailto:andrewarn...@gmail.com>> wrote:
Trying a different DL...
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the dea
I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16. I'm okay with the change but feel it's wroth
mentioning that it's like
Not exactly.
The current setup was pretty stable up to –15. In –16 I tried to clean it up by
moving the parameter into each token endpoint type definition. That didn't work
and was more confusing so in –17 I reverted back to the –15 approach.
What makes this stand out in –20 is that all the exa
I think you are describing the device profile:
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
Is that correct?
Marius
On Tue, Jul 26, 2011 at 12:18 PM, Andrew Arnott wrote:
> Trying a different DL...
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll de
Would it be possible to consider adding this to the list of security
considerations?
Of course, the spec cannot cover all possible security threats, but
this appears to be a realistic one which could easily be exploited if
overlooked by developers (evident in the lack of scraping defense
mechanisms
