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.
I do have some questions for about the statements made in the blog -
A) Can you direct me to a single OpenID Connect draft specification
document where steps 1 and 2 are described?
B) If I implement steps 1 and 2, do I then have a conformant OpenID
Connect implementation? Are there no
other MTI protocol exchanges in OpenID Connect?
Thanks,
prateek
I have written a short blog post titled "Write an OpenID Connect
server in three simple steps
<http://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 minor variances
in parameter names.
e.g.,
session instead of id_token
lat instead of iat
alv instead of acr
etc.
If you change those parameter names, you will have a conformant
profile of OpenID Connect.
Nat
2013/7/31 John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>
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 JWT if the client sends it in the request.
Justin is correct.
John B.
On 2013-07-30, at 5:30 PM, Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
Forgot reply all.
Phil
Begin forwarded message:
*From:* Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>
*Date:* 30 July, 2013 17:25:46 GMT+02:00
*To:* "Richer, Justin P." <jric...@mitre.org
<mailto: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. Many do not want or need the
userinfo endpoint.
Phil
On 2013-07-30, at 17:17, "Richer, Justin P." <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
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 the ID token (OIDC specifies the RS256 flavor of
JWS, which is easy to do with JWT). Without a signed and
verifiable ID token or equivalent, you're asking for all kinds
of token injection problems.
- Session management requests (max auth age, auth time)
- Not fall over with other parameters that you don't support
(display, prompt, etc).
See here for more information:
http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI
Additionally, something that's really important to support is
the User Info Endpoint, so you can actually get user profile
information beyond just the simple "someone was here" claim --
this was the real value of Facebook Connect from an RP's
perspective. Some people will probably want to use SCIM for
this, too, and that's fine.
-- Justin
On Jul 30, 2013, at 10:54 AM, Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>
wrote:
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 feels is clearest.
From an ietf perspective the concern is improper use of the
6749 for authn. Is this a bug or gap we need to address?
Phil
On 2013-07-30, at 16:46, "Richer, Justin P."
<jric...@mitre.org <mailto:jric...@mitre.org>> wrote:
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
Connect. In other words, if you change the names on things
you've got OIDC, but without the capabilities to go beyond a
very basic "hey there's a user here" claim. This is the same
place that OpenID 2.0 started, and it was very, very quickly
extended with SREG, AX, PAPE, and others for it to be useful
in the real world of distributed logins. You've also left out
discovery and registration which are required for distributed
deployments, but I'm guessing that those would be modular
components that could be added in (like they are in OIDC).
I've heard complaints that OIDC is complicated, but it's
really not. 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). However, at the core, you've got an OAuth2
authorization server that spits out access tokens and id
tokens. The id token is a JWT with some known claims (iss,
sub, etc) and is issued along side the access token, and its
audience is the *client* and not the *protected resource*.
The access token is a regular old access token and its format
is undefined (so you can use it with an existing OAuth2
server setup, like we have), and it can be used at the User
Info Endpoint to get profile information about the user who
authenticated. It could also be used for other services if
your AS/IdP protects multiple things.
So I guess what I'm missing is what's the value proposition
in this spec when we have something that can do this already?
And this doesn't seem to do anything different (apart from
syntax changes)?
-- Justin
On Jul 29, 2013, at 4:14 AM, Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
FYI. I have been noticing a substantial number of sites
acting as OAuth Clients using OAuth to authenticate users.
I know several of us have blogged on the issue over the past
year so I won't re-hash it here. In short, many of us
recommended OIDC as the correct methodology.
Never-the-less, I've spoken with a number of service
providers who indicate they are not ready to make the jump
to OIDC, yet they agree there is a desire to support
authentication only (where as OIDC does IDP-like services).
This draft is intended as a minimum authentication only
specification. I've tried to make it as compatible as
possible with OIDC.
For now, I've just posted to keep track of the issue so we
can address at the next re-chartering.
Happy to answer questions and discuss.
Phil
@independentid
www.independentid.com <http://www.independentid.com/>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
Begin forwarded message:
*From: *internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>
*Subject: **New Version Notification for
draft-hunt-oauth-v2-user-a4c-00.txt*
*Date: *29 July, 2013 9:49:41 AM GMT+02:00
*To: *Phil Hunt <phil.h...@yahoo.com
<mailto:phil.h...@yahoo.com>>, Phil Hunt
<n...@ietfa.amsl.com <mailto:n...@ietfa.amsl.com>>, Phil
Hunt <>
A new version of I-D, draft-hunt-oauth-v2-user-a4c-00.txt
has been successfully submitted by Phil Hunt and posted to the
IETF repository.
Filename:draft-hunt-oauth-v2-user-a4c
Revision:00
Title:OAuth 2.0 User Authentication For Client
Creation date:2013-07-29
Group:Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt
Status:
http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
Htmlized:
http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00
Abstract:
This specification defines a new OAuth2 endpoint that
enables user
authentication session information to be shared with client
applications.
Please note that it may take a couple of minutes from the
time of submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org/>.
The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
