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. Many do not want or need the userinfo > endpoint. > > Phil > > On 2013-07-30, at 17:17, "Richer, Justin P." <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> >> 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> 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> 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 >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: 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>, Phil Hunt <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. >>>>>> >>>>>> The IETF Secretariat >>>>> >>>>> _______________________________________________ >>>>> 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
