As of earlier this evening, I've published the article that we've been
working on about dealing with OAuth and end-user authentication. It's
available here:
http://oauth.net/articles/authentication/
Huge thanks to everyone who commented on the text, both here on the list
and last week at IIW.
Sent from my T-Mobile 4G LTE Device___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Phil,
When you write that article, just let me know and I'll add a link to it from
this one.
Thanks,
-- Justin
On Nov 2, 2014, at 6:52 PM, Phil Hunt wrote:
> John
>
> I am trying to establish how a client app org should assess an AS org and
> their approach.
>
> Why is fb/connect or oid
John
I am trying to establish how a client app org should assess an AS org and their
approach.
Why is fb/connect or oidc, or other approaches good or bad?
The client org has to do this. We shouldn't be in the business of assessing
goodness or compliance.
Phil
> On Nov 2, 2014, at 15:14, Jo
Some old posts on designing a single sign-on system with OAuth 2.
They may not have been in the ones I sent to Justin.
http://www.thread-safe.com/2012/02/designing-single-sign-on-system-using.html
http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/
Are you wanting something more
Many of the threats can only be mitigated by the AS/IDP . This document
should cover that.
I didn't say the IdP must use connect only that it needs to understand and
mitigate the treats from the document, implementing Connect is one way to do
it.
Sorry I was trying to interpret "Sigh"
J
That is not what I said.
I said establish the criteria for mitigation of the threats.
Phil
> On Nov 2, 2014, at 12:53, John Bradley wrote:
>
> Your proposal required changes and extensions to the AS.
>
> Without some cooperation from the AS /API provider, they shouldn't be using
> OAuth fo
Your proposal required changes and extensions to the AS.
Without some cooperation from the AS /API provider, they shouldn't be using
OAuth for identity.
The client can't make it secure all on it's own. The API semantics might
change, the client would largely be relying on luck.
Sorry,
What
So, wrt FB, signed request is good. It can be another example to add.
On Sun, Nov 2, 2014 at 19:55 Phil Hunt wrote:
> Sigh.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Nov 2, 2014, at 10:33 AM, John Bradley wrote:
>
> > If a client developer doesn't have
Sigh.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Nov 2, 2014, at 10:33 AM, John Bradley wrote:
> If a client developer doesn't have Connect available then they need to point
> the API developer at this doc, so that they do provide Connect or some other
> API that tak
If a client developer doesn't have Connect available then they need to point
the API developer at this doc, so that they do provide Connect or some other
API that takes into account all of the security considerations.
A client developer should never make up there own identity protocol out of
so
We may have a problem with audience here.
Justin mentioned he wrote it for service providers but the threats are against
the client that wants to authenticate users.
Would be better to have recommendations for each group.
Since oidc is the only recommendation, what does a client implementer
Hi all,
I just read the document. It explains the situation, challenges/threats,
and options very clear and readable.
So +1 for publishing it soon.
kind regards,
Torsten.
Am 28.10.2014 00:21, schrieb Richer, Justin P.:
I've been incorporating peoples' feedback into the proposed oauth.net pa
13 matches
Mail list logo
