Oh yea, real different, give me a freaking break
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 24, 2014 6:31 PM
To: Anthony Nadalin
Cc: John Bradley; oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-v2-user-a4c-05.txt
The s
The situations are rather different.
On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin
wrote:
> OMG, how can you say that when the Dynamkc Reg does the same thing
> (duplicates) but that is OK to do
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:*
2014-07-24 14:17 GMT-04:00 Bill Mills :
> Then why aren't people using this instead of (mis)using OAuth for this?
Even with a spec this short, IMHO, developers would not read it.
What they want is easy to read description with sample code, I suppose.
It also does not have adequate amount of public
Then why aren't people using this instead of (mis)using OAuth for this?
Different question, if we do define AC4 will people move to that, or continue
doing the wrong thing anyway?
On Thursday, July 24, 2014 8:57 AM, Nat Sakimura wrote:
2014-07-24 10:30 GMT-04:00 Phil Hunt :
I’m not at a
This could also be solved by explicitly defining a scope for access tokens
specific to the needed (no-op?) behavior for ac4.
On Thursday, July 24, 2014 8:34 AM, "tors...@lodderstedt.net"
wrote:
I honestely don't understand why you care about omiting the access token on the
token endpoint
Connect needed to be completed. To do that some things that were not Identity
specific but required for Connect to be interoperable also needed to be
completed in a stable form.
The fact that with some tweaking based on input from the IETF community like
software statements Connect's dynamic r
OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates)
but that is OK to do
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notifica
I'm sorry to miss what will likely be a very engaging meeting today.
The premise that some developers are using OAuth in a insecure way to do
authentication is something we can probably all agree on.
It doesn't necessarily follow from that premise, however, that the solution
is yet another spec w
We do the same thing with well-known (ie, whitelisted) client apps for both
OIDC and vanilla OAuth. These are cases where the consent decision isn't in the
users' hands, so we don't ask them. But here's the thing: that's an
implementation detail of our AS policy, the clients are all just doing O
My comments are not motivated in any way by my employer. The probably wish like
you I would drop it.
I am simply reporting what I see in the wild.
Phil
> On Jul 24, 2014, at 12:47, Bill Burke wrote:
>
>
>
>> On 7/24/2014 10:30 AM, Phil Hunt wrote:
>> Horseshit.
>
> Horseshit to your hors
On 7/24/2014 10:30 AM, Phil Hunt wrote:
Horseshit.
Horseshit to your horseshit.
Ian failed to mention that we’re responding to bad use of 6749 by
assuming receipt of access token == authentication.
The OAuth WG is not creating a new feature and we are not re-inventing
here. If anyone is,
Phil,
I thoroughly enjoy working with you whenever I can, and I really liked
your work on SCIM, but from the perspective of the web developers I work
with, I have a few concerns about what you wrote:
1. Developer experience and usability of the standards
You keep mentioning that web develope
Nat,
You don't have to convince me.
You have to sell all the people not implementing OpenId who think OAuth is
sufficient.
I agree A4C is currently too long. I think Mike and John may be on to something
even better.
Phil
> On Jul 24, 2014, at 11:50, Nat Sakimura wrote:
>
>
> 2014-07-24
2014-07-24 10:30 GMT-04:00 Phil Hunt :
> I’m not at all saying that OpenID is bad. If you want an IDP, its fine.
> But if all a client wants is authentication, they think why can’t I just
> use RFC6749?
If all what one wants is to build a simple client, there is a standing
document called OpenI
The audience of a access token is a RS, and we have a principal of the token
being opaque to the client.
On the other hand that is in line with what In was thinking. It is a access
token with no scopes that confers no access to a resource.
We can define a sting for that or perhaps a JWT with
I honestely don't understand why you care about omiting the access token
on the token endpoint response. You want to omit user consent? Fine, do
it. There is no text in the spec that forces an AS to explicitely
acquire user consent. Authorization from the resource owner can be
acquired in many w
Here’s a point of technical discussion for your consideration about the current
content of a4c and a possible simplification.
Having thought about the views expressed about defining the new response type
and grant type values, I came up with a possible syntax change that would be
much more mi
+1
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jul 24, 2014, at 10:25 AM, John Bradley wrote:
> I am not against discussion in the WG.
>
> I happen to agree with Phil's fundamental premise that some developers are
> using OAuth in a insecure way to do authentication.
Horseshit.
Ian failed to mention that we’re responding to bad use of 6749 by assuming
receipt of access token == authentication.
The OAuth WG is not creating a new feature and we are not re-inventing here. If
anyone is, one could argue that would be OpenID —> at least in the minds of the
web d
I am not against discussion in the WG.
I happen to agree with Phil's fundamental premise that some developers are
using OAuth in a insecure way to do authentication.
That raises the question of how to best educate them, and or address technical
barriers.
It is on the second point that people's
There is a lot of spin being applied, yes. But not from Ian.
On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin
wrote:
> I’m sure it was spun in a way that could be true since there was no
> technical value to Ian’s statement and I’m sure that folks had not read or
> understand the usage.
>
>
>
I'll second this sentiment. Ian's overall talk was about when reinventing
wheels was a good thing (like XML -> JSON), and he called out A4C specifically
as an example of reinvention for its own sake, a harmful and wasteful practice.
It was a very good keynote talk, and I highly recommend that pe
I’m sure it was spun in a way that could be true since there was no technical
value to Ian’s statement and I’m sure that folks had not read or understand the
usage.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc:
I'd note that the reaction at the conference to Ian's statement was
overwhelmingly positive. There was a wide range of industry people here -
implementers, practitioners, deployers, strategists, etc. - and it seems
pretty clear that the "rough consensus" of the industry at large is that
a4c is not
if we take Ian’s non technical advice then most of the work in Oauth should be
put down.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 24, 2014 5:29 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for
draf
And here is a quote from Ian's blog.
And although the authentication wheel is round, that doesn’t mean it isn’t
> without its lumps. First, we do see some reinventing the wheel just to
> reinvent the wheel. OAuth A4C is simply not a fruitful activity and should
> be put down.
> (Source)
> http:
26 matches
Mail list logo
