So is the intent to provide an enterprise authentication claim? I would think
that the proposal would use JWT as the token and then define the appropriate
claim in the JWT
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Monday, July 29, 2013 1:14 AM
As some of you know, passing the authorization code securely to a native
app on iOS platform is next to impossible. Malicious application may
register the same custom scheme as the victim application and hope to
obtain the code, whose success rate is rather high.
We have discussed about it during
From what I read, you've defined something that uses an OAuth 2 code flow to
get an extra token which is specified as a JWT. You named it session_token
instead of id_token, and you've left off the User Information Endpoint --
but other than that, this is exactly the Basic Client for OpenID
The oidc specs do not allow this simple an implementation. The spec members
have not shown interest in making changes as they say they are too far down the
road.
I have tried to make my draft as close as possible to oidc but maybe it
shouldn't be clarity wise. I am interested in what the group
What do you mean? You absolutely can implement a compliant OIDC server nearly
as simply as this. The things that you're missing I think are necessary for
basic interoperable functionality, and are things that other folks using OAuth
for authentication have also implemented. Namely:
- Signing
Forgot reply all.
Phil
Begin forwarded message:
From: Phil Hunt phil.h...@oracle.com
Date: 30 July, 2013 17:25:46 GMT+02:00
To: Richer, Justin P. jric...@mitre.org
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-v2-user-a4c-00.txt
The whole point is authn only.
Hi.
I had to fix a few issues with the previous draft text.
No normative changes, but just removed some extra text.
Nat
-- Forwarded message --
From: internet-dra...@ietf.org
Date: 2013/7/31
Subject: New Version Notification for draft-sakimura-oauth-tcse-01.txt
To: Nat Sakimura
That's what people thought with OpenID 2.0, and they were wrong then, too, if
you ask me. Even then, userinfo endpoint isn't MTI anyway.
-- Justin
On Jul 30, 2013, at 11:25 AM, Phil Hunt
phil.h...@oracle.commailto:phil.h...@oracle.com
wrote:
The whole point is authn only. Many do not want
Connect dosen't require a userinfo endpoint. It is required for
interoperability if you are building an open IdP. For an enterprise type
deployment discovery, registration, userifo are all optional.
The server is required to pass the nonce which is equivalent to a request ID
through to the
I have written a short blog post titled Write an OpenID Connect server in
three simple
stepshttp://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/
.
Really, there is not much you need to on top of OAuth 2.0.
It puzzles me why you need to create a draft with only
Yes, that.
On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. jric...@mitre.orgwrote:
Yes, I agree that the giant stack of documents is intimidating and in my
opinion it's a bit of a mess with Messages and Standard split up (but I
lost that argument years ago).
I always think I pretty much understand OIDC until I see the specs list
On 7/30/13 12:39 PM, Brian Campbell wrote:
Yes, that.
On Tue, Jul 30, 2013 at 4:46 PM, Richer, Justin P. jric...@mitre.org
mailto:jric...@mitre.org wrote:
Yes, I agree that the giant stack of documents is
So it's not the protocol that's the problem, it's the documentation. For that
I'm 100% with you all. However, I really don't think that the right response to
that is we'll just invent something new and incompatible with slightly
different names -- it's to document the protocol better.
--
I always think I pretty much understand OIDC until I see the specs list
It's not just me, then.
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com
From: Paul Madsen paul.mad...@gmail.com
To:
Right. Anyone who agreed to IPR could have proposed the text in the work
group.
Re: Messages and Standard
Messages were supposed to be the collection of terminology and parameters
sets.
Standard was meant to be HTTP binding, which would effectively make it
OAuth 2.0 + authentication + identity.
Nat -
your blog posting is helpful to those of us who are looking for a
minimal extension of OAuth with
an authenticator. Many implementors are seeking a modest extension of
OAuth, not an entire new protocol
stack. I believe that is the point of Phil Hunt's proposal to the
OAuth committee.
Here it is: A presentation on the transient client secret extension.
http://www.slideshare.net/nat_sakimura/transient-client-secret-extension
At the end of it, it has 2 pages for OAuth Meta Extension that was prepared
for IETF 86 per the discussion and chairs' request at IETF 85.
Cheers,
Nat
Inline:
2013/7/31 Prateek Mishra prateek.mis...@oracle.com
Nat -
your blog posting is helpful to those of us who are looking for a minimal
extension of OAuth with
an authenticator. Many implementors are seeking a modest extension of
OAuth, not an entire new protocol
stack. I believe
18 matches
Mail list logo
