Adam, We have made some changes in the latest draft to address some input from Google that I think may also address your need to using the id_token in an assertion or possibly as an access token to a federated RS.
I can go over it with you if you like. John B. On 2013-02-06, at 9:05 AM, Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> wrote: > Hi Bill, > > My reason for using OAuth rather than OIDC is because the id_token in OIDC is > audience restricted to the client. This was clearly intended for WebSSO / > authentication to a client running on a web server. It does not help the > case where the user of a RESTful native client want to authenticate to a > RESTful web service. > > I agree that OAuth lacks a “defined” way to communicate what is in the AT (as > OAuth does not define the content of the AT), but within an enterprise domain > this is easy to solve by profiling. And in any implementation of OAuth on > the Internet, the AT must at some level identify the user to the RS. > Otherwise how else would the RS know who’s protected resources the client is > trying to access? Now whether the RS learns that through introspection or by > parsing a JWT-structured AT is of course not defined. But at the end of the > day, the AT definitely (in all cases that I can think of) identifies the > user. > > I am open minded to using OIDC if in the future if the client can request an > id_token that is audience restricted to the RS it is going to communicate. > In other words, yes I agree that OIDC is the preferred mechanism for > performing “user authentication to a client,” but I also argue that OAuth is > the best method to perform “user authentication to an RS” (if you want to get > your RS out of the password consumption business). I am not at all > advocating OAuth for authentication to a client. > > -adam > > From: William Mills [mailto:wmills_92...@yahoo.com] > Sent: Tuesday, February 05, 2013 6:49 PM > To: Lewis Adam-CAL022; Tim Bray > Cc: "WG <oauth@ietf.org>"@il06exr02.mot.com > Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ? > > Why use OAuth when OpenID does everything that OAuth can do as an > authentication method and does a few things much better? > > Specifically OAuth lacks any defined way to: > > - feed back any additional information like the real user ID (as opposed > to what the entered) > - bound an authentication event in time > - provide any form of additional SSO payload like a display name for the > user > > there's probably other things. > > It'll mostly work but there are things it doesn't do. Could you solve some > of the rest of this with token introspection or a user API that the RP could > use to fetch user info, sure, but why rebuild OpenID when OpenID exists? > > -bill > > > From: Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> > To: Tim Bray <twb...@google.com>; William Mills <wmills_92...@yahoo.com> > Cc: "oauth@ietf.org WG" <oauth@ietf.org> > Sent: Tuesday, February 5, 2013 2:27 PM > Subject: RE: [OAUTH-WG] Why OAuth it self is not an authentication framework ? > > I think this is becoming a largely academic / philosophical argument by this > time. The people who designed OAuth will likely point out that it was > conceptualized as an authorization protocol to enable a RO to delegate access > to a client to access its protected resources on some RS. And of course this > is the history of it. And the RO and end-user were typically the same > entity. But get caught up in what it was envisioned to do vs. real life use > cases that OAuth can solve (and is solving) beyond its initial use cases > misses the point … because OAuth is gaining traction in the enterprise and > will be used in all different sorts of ways, including authentication. > > This is especially true of RESTful APIs within an enterprise where the RO and > end-user are *not* the same: e.g. RO=enterprise and end-user=employee. In > this model the end-user is not authorizing anything when their client > requests a token from the AS … they authenticate to the AS and the client > gets an AT, which will likely be profiled by most enterprise deployments to > look something like an OIDC id_token. The AT will be presented to the RS > which will examine the claims (user identity, LOA, etc.) and make > authorization decisions based on business logic. The AT has not authorized > the user to do anything, it has only made an assertion that the user has been > authenticated by the AS (sort of sounds a lot like an IdP now). > > All this talked of OAuth being authorization and not authentication was > extremely confusing to me when I first started looking at OAuth for my use > cases, and I think at some point the authors of OAuth are going to have to > recognize that their baby has grown up to be multi-faceted (and I mean this > as a complement). The abstractions left in the OAuth spec (while some have > claimed of the lack of interoperability it will cause) will also enable it to > be used in ways possibly still not envisioned by any of us. I think as soon > as we can stop trying to draw the artificial line around OAuth being “an > authorization protocol” the better things will be. > > I like to say that they authors had it right when they named it “OAuth” and > not “OAuthR” J > > -adam > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tim > Bray > Sent: Tuesday, February 05, 2013 3:28 PM > To: William Mills > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ? > > OIDC seems about the most plausible candidate for a “good general solution” > that I’m aware of. -T > On Tue, Feb 5, 2013 at 1:22 PM, William Mills <wmills_92...@yahoo.com> wrote: > There are some specific design mis-matches for OAuth as an authentication > protocol, it's not what it's designed for and there are some problems you > will run into. Some have used it as such, but it's not a good general > solution. > > -bill > > From: Paul Madsen <paul.mad...@gmail.com> > To: John Bradley <ve7...@ve7jtb.com> > Cc: "oauth@ietf.org WG" <oauth@ietf.org> > Sent: Tuesday, February 5, 2013 1:12 PM > Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ? > > why pigeonhole it? > > OAuth can be deployed with no authz semantics at all (or at least as little > as any authn mechanism), e.g client creds grant type with no scopes > > I agree that OAuth is not an *SSO* protocol. > On 2/5/13 3:36 PM, John Bradley wrote: > OAuth is an Authorization protocol as many of us have pointed out. > > The post is largely correct and based on one of mine. > > John B. > > On 2013-02-05, at 12:52 PM, Prabath Siriwardena <prab...@wso2.com> wrote: > > FYI and for your comments.. > > http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html > > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > http://blog.facilelogin.com/ > http://rampartfaq.com/ > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
