Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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.commailto: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.comhttp://www.independentid.com/ phil.h...@oracle.commailto:phil.h...@oracle.com Begin forwarded message: From: internet-dra...@ietf.orgmailto: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.commailto:phil.h...@yahoo.com, Phil Hunt n...@ietfa.amsl.commailto: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.orghttp://tools.ietf.org/. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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.commailto: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.orgmailto: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.commailto: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.comhttp://www.independentid.com/ phil.h...@oracle.commailto:phil.h...@oracle.com Begin forwarded message: From: internet-dra...@ietf.orgmailto: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.commailto:phil.h...@yahoo.com, Phil Hunt n...@ietfa.amsl.commailto:n...@ietfa.amsl.com, Phil Hunt A new
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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 or need the userinfo endpoint. Phil On 2013-07-30, at 17:17, Richer, Justin P. jric...@mitre.orgmailto: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.commailto: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.orgmailto: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.commailto: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
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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). ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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 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). ___ 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
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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. -- Justin On Jul 30, 2013, at 12:57 PM, Paul Madsen paul.mad...@gmail.commailto:paul.mad...@gmail.com wrote: 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.orgmailto:jric...@mitre.org wrote: 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). ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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: Brian Campbell bcampb...@pingidentity.com, Cc: oauth@ietf.org WG oauth@ietf.org Date: 07/30/2013 12:59 PM Subject:Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt Sent by:oauth-boun...@ietf.org 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 wrote: 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). ___ 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
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt
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. As such, normative portion of the standard was to be made of the HTTP protocol element, reference to the parameters sets in Messages, and the documentation on how to serialize. It should be very concise. Non-normative portions were supposed to have examples. In some sections, it is like that, but in sections like 2.2.1.1, it is currently repeating much of what the Messages have. This, to me, is suboptimal but many people wanted to be this way so that they do not have to refer to the Messages. Maybe, for the final, we might reconsider it. 2013/7/31 Richer, Justin P. jric...@mitre.org 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. -- Justin On Jul 30, 2013, at 12:57 PM, Paul Madsen paul.mad...@gmail.com wrote: 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.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). ___ OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list 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
