Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

From: Justin Richer <[email-masked]>
Date: Mon, 13 Oct 2014 10:17:50 -0400

You certainly can do authentication without using an access token, but then I would argue that's no longer OAuth. Basically you're making tofu carob fudge.

-- Justin

/ Sent from my phone /

-------- Original message --------
From: Sergey Beryozkin <[email-masked]> 
Date:10/13/2014  9:00 AM  (GMT-05:00) 
To: Justin Richer <[email-masked]>, [email-masked] 
Cc:  
Subject: Re: [OAUTH-WG] New Version Notification for  draft-hunt-oauth-v2-user-a4c-05.txt 

Hi Justin,
On 13/10/14 12:53, Justin Richer wrote:
> You are correct in that OAuth 2 and OpenID Connect are not the same
> thing, but your user is correct that OIDC adds a few pieces on top of
> OAuth to add authentication capabilities. OIDC was designed very
> explicitly to be compatible with vanilla OAuth, partially do that people
> would be able to deploy it on top of existing OAuth infrastructure and
> code. But the very fact that OIDC adds a few things on top of OAuth to
> give more functionality should be sufficient evidence that they're not
> equivalent.
>
> It's more proper to say that OpenID Connect is an extension and
> application of OAuth. One that provides an authentication and identity API.
>
I agree and this is more or less how I answered.

Though the 'borders' can be blurred, one can claim that if a user 
actually logs on into a confidential OAuth2 client web application which 
redirects this user to AS requesting a code with some scopes such as "a 
b" then when it uses "a b openid profile" it is basically does a pure 
OAuth2 code flow where the client requests 'a b' plus also a scope 
allowing it later to query the identity system on behalf of a user.

I like the "The extension and application of OAuth2" characteristic of 
OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO 
into non-OAuth2 servers, when it is the case then there's no 'feeling' 
that OIDC is just a case of the confidential client adding the extra 
scopes and getting the extra (authentication) info back. A standalone 
OIDC RP protecting such non OAuth2 servers is very much about the 
authentication/identity.

I also thought that having some OID profile (as opposed updating OAuth2 
to support no access tokens) where no access but only id token was 
returned (as suggested in this thread) would probably make sense too.

> The way I like to explain it (which I stole from someone else) is that
> OAuth is like chocolate and authentication is like fudge. They are not
> the same thing. You can make chocolate into fudge out you can make it
> into something else or you can just have it on its own. You can make
> fudge with chocolate or you can make it with peanut butter or you can
> make it with potatoes if you want to, but it needs a couple ingredients
> and a very common one is chocolate. OpenID Connect is a recipe for
> chocolate fudge that a lot of people like. And it makes my fudge
> compatible with your fudge, which is where the metaphor breaks down. :-)
>
Thanks for sharing this colourful explanation :-). Perhaps I should 
borrow it :-),
Cheers, Sergey

>
> -- Justin
>
> / Sent from my phone /
>
>
> -------- Original message --------
> From: Sergey Beryozkin <[email-masked]>
> Date:10/13/2014 6:33 AM (GMT-05:00)
> To: [email-masked]
> Cc:
> Subject: Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
> Hi
>
> We've had a user asserting that "OAuth2 == OpenidConnect", referring to
> the fact that the 'only' thing OIC adds on top of the authorization code
> flow is the client specifying few extra scopes like 'openid' and
> 'profile' and the authorization service returning an extra property, the
> id_token which can be sufficient in order to get the authenticated
> user's info.
>
> My understanding "OAuth2 != OpenidConnect", the latter utilizes the
> former and is an authentication mechanism which is not what OAuth2 is
> (may be except for the client credentials). But I don't feel like it is
> a convincing enough argument.
>
> I thought this thread was relevant, sorry if not, would have no problems
> starting a new one.
>
> Basically, I wonder what is the proper line of argument for a position
> such as "OAuth2 != OpenidConnect" and also what was the action to the
> list of options suggested by John below. Is having an OID profile where
> no access token is returned would be the cleanest action as far as
> breaking the ambiguity/confusion is concerned ?
>
> Cheers, Sergey
>
> On 24/07/14 15:25, John Bradley wrote:
>  > I am not against discussion in the WG.
>  >
>  > I happen to agree with Phil's fundamental premise that some developers
>  > are using OAuth in a insecure way to do authentication.
>  >
>  > That raises the question of how to best educate them, and or address
>  > technical barriers.
>  >
>  > It is on the second point that people's opinions seem to divide.
>  >
>  > Some people thing that if we have a OAuth flow that eliminates the
>  > access token (primarily to avoid asking for consent as I understand it)
>  > and just return a id_token from the token endpoint that can be done in a
>  > spec short enough to het people to read.   The subtext of this is that
>  > the Connect specification is too large that it scare people,  and they
>  > don't find the spec in the first place because it is not a RFC.
>  >
>  > An other common possession is that if you don't want to prompt the user
>  > for consent then don't ask for scopes.  Twisting the OAuth spec to not
>  > return an access token is not OAuth,  yes you could use a different
>  > endpoint rather than the token endpoint, but that is not OAuth.
>  > Connect was careful not to break the OAuth spec.    As long as you are
>  > willing to take a access token with no scopes (the client needs to
>  > understand that there are no attributes one way or another anyway or it
>  > will break) then you don't need to change OAuth.   You can publish a
>  > profile of connect that satisfies the use case.
>  >
>  > I think Mike has largely done that but it might be better being less
>  > stingy on references back to the larger spec.
>  >
>  > The questions are do we modify OAuth to not return an access token, and
>  > if so how,  and if we do is it still OAuth.
>  >
>  > The other largely separable question is do we create confusion in the
>  > market and slow the the adoption of identity federation on top of OAuth,
>  > or find a way to make this look like a positive alignment of interests
>  > around a subset of Connect.
>  >
>  > There are a number of options.
>  > 1: We can do a profile in the OIDF and publish it as a IETF document.
>  > Perhaps the cleanest from an IPR point of view.However
>  > 2:We can do a profile in the OAuth WG referencing connect.
>  > 3:We can do a AD sponsored profile that is not in the OAuth WG.
>  > 4:We can do a small spec in OAuth to add response_type to the token
>  > endpoint.  in combination with 1, 2, or 3
>  >
>  > I agree that stoping developers doing insecure things needs to be
>  > addressed somehow.
>  > I am not personally convinced that Oauth without access tokens is
> sensible.
>  >
>  > Looking forward to the meeting:)
>  >
>  > John B.
>  > On Jul 24, 2014, at 6:52 AM, Brian Campbell <[email-masked]
>  > <mailto:[email-masked]>> wrote:
>  >
>  >> I'd note that the reaction at the conference to Ian's statement was
>  >> overwhelmingly positive. There was a wide range of industry people
>  >> here - implementers, practitioners, deployers, strategists, etc. - and
>  >> it seems pretty clear that the "rough consensus" of the industry at
>  >> large is that a4c is not wanted or needed.
>  >>
>  >>
>  >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <[email-masked]
>  >> <mailto:[email-masked]>> wrote:
>  >>
>  >>     And here is a quote from Ian's blog.
>  >>
>  >>         And although the authentication wheel is round, that doesn’t
>  >>         mean it isn’t without its lumps. First, we do see some
>  >>         reinventing the wheel just to reinvent the wheel. OAuth A4C is
>  >>         simply not a fruitful activity and should be put down.
>  >>
>  >>         (Source)
>  >>
> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html
>  >>
>  >>
>  >>
>  >>     2014-07-23 16:53 GMT-04:00 John Bradley <[email-masked]
>  >>     <mailto:[email-masked]>>:
>  >>
>  >>         I thought I did post this to the list.
>  >>
>  >>         I guess I hit the wrong reply on my phone.
>  >>         John B.
>  >>         Sent from my iPhone
>  >>
>  >>         On Jul 23, 2014, at 4:50 PM, [email-masked]
>  >>         <mailto:[email-masked]> wrote:
>  >>
>  >>>         we are two, at least :-)
>  >>>
>  >>>         Why didn't you post this on the list?
>  >>>
>  >>>         When will be be arriving?
>  >>>
>  >>>         Am 23.07.2014 16:39, schrieb John Bradley:
>  >>>
>  >>>>         Ian Glazer mentioned this in his keynote at CIS yesterday.
>  >>>>         His advice was please stop,  we are creating confusion and
>  >>>>         uncertainty.
>  >>>>         We are becoming our own wort enemy. ( my view though Ian may
>  >>>>         share it)
>  >>>>         Returning just an id_ token from the token endpoint has
>  >>>>         little real value.
>  >>>>         Something really useful to do would be sorting out
>  >>>>         channel_id so we can do PoP for id tokens to make them and
>  >>>>         other cookies secure in the front channel.   I think that is
>  >>>>         a better use of time.
>  >>>>         I may be in the minority opinion on that,  it won't be the
>  >>>>         first time.
>  >>>>
>  >>>>
>  >>>>         John B.
>  >>>>         Sent from my iPhone
>  >>>>
>  >>>>         On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt
>  >>>>         <[email-masked] <mailto:[email-masked]>>
>  >>>>         wrote:
>  >>>>
>  >>>>>         You are right from a theoretical perspective. Practically
>  >>>>>         this was caused by editorial decisions during the creation
>  >>>>>         of the RFC. As far as I remember, there was a definition of
>  >>>>>         the (one) token endpoint response in early versions. No one
>  >>>>>         every considered to NOT respond with an access token from
>  >>>>>         the token endpoint. So one might call it an implicit
>  >>>>>         assumption.
>  >>>>>         I'm worried that people get totally confused if an
>  >>>>>         exception is introduced now given the broad adoption of
>  >>>>>         OAuth based on this assumption.
>  >>>>>         regards,
>  >>>>>         Torsten.
>  >>>>>
>  >>>>>         Am 23.07.2014 um 15:41 schrieb Thomas Broyer
>  >>>>>         <[email-masked] <mailto:[email-masked]>>:
>  >>>>>
>  >>>>>>         Is it said anywhere that ALL grant types MUST use Section
>  >>>>>>         5.1 responses? Each grant type references Section 5.1, and
>  >>>>>>         "access token request" is only defined in the context of
>  >>>>>>         the defined grant types. Section 2.2 doesn't talk about
>  >>>>>>         the request or response format.
>  >>>>>>
>  >>>>>>         Le 23 juil. 2014 21:32, "Nat Sakimura" <[email-masked]
>  >>>>>>         <mailto:[email-masked]>> a écrit :
>  >>>>>>
>  >>>>>>             Is it? Apart from the implicit grant that does not use
>  >>>>>>             token endpoint, all other grant references section 5.1
>  >>>>>>             for the response, i.e., all shares the same response.
>  >>>>>>
>  >>>>>>
>  >>>>>>             2014-07-23 15:18 GMT-04:00 Thomas Broyer
>  >>>>>>             <[email-masked] <mailto:[email-masked]>>:
>  >>>>>>
>  >>>>>>                 I hadn't realized the JSON response that requires
>  >>>>>>                 the access_token field is defined per grant_type,
>  >>>>>>                 so I'd be OK to "extend the semantics" as in the
>  >>>>>>                 current draft.
>  >>>>>>                 That was actually my main concern: that the token
>  >>>>>>                 endpoint mandates access_token; but its actually
>  >>>>>>                 not the case.
>  >>>>>>
>  >>>>>>                 Le 23 juil. 2014 20:46, "Nat Sakimura"
>  >>>>>>                 <[email-masked] <mailto:[email-masked]>> a
>  >>>>>>                 écrit :
>  >>>>>>
>  >>>>>>                     I agree with John that overloading
>  >>>>>>                     response_type @ authz endpoint is a bad idea.
>  >>>>>>                     It completely changes the semantics of this
>  >>>>>>                     parameter. NOTE: what I was proposing was not
>  >>>>>>                     this parameter, but a new parameter
>  >>>>>>                     response_type @ token endpoint.
>  >>>>>>                     I also think overloading grant_type is a bad
>  >>>>>>                     idea since it changes its semantics. I quote
>  >>>>>>                     the definition here again:
>  >>>>>>                     grant
>  >>>>>>                         credential representing the resource
>  >>>>>>                     owner's authorization
>  >>>>>>                     grant_type
>  >>>>>>                     type of grant sent to the token endpoint to
>  >>>>>>                     obtain the access token
>  >>>>>>                     It is not about controlling what is to be
>  >>>>>>                     returned from the token endpoint, but the hint
>  >>>>>>                     to the token endpoint describing the type of
>  >>>>>>                     credential the endpoint has received. It seems
>  >>>>>>                     the "control of what is being returned from
>  >>>>>>                     token endpoint"  is just a side effect.
>  >>>>>>                     I am somewhat ambivalent[1] in changing the
>  >>>>>>                     semantics of token endpoint, but in as much as
>  >>>>>>                     "text is the king" for a spec., we probably
>  >>>>>>                     should not change the semantics of it as
>  >>>>>>                     Torsten points out. If it is ok to change this
>  >>>>>>                     semantics, I believe defining a new parameter
>  >>>>>>                     to this endpoint to control the response would
>  >>>>>>                     be the best way to go. This is what I have
>  >>>>>>                     described previously.
>  >>>>>>                     Defining a new endpoint to send code to get ID
>  >>>>>>                     Token and forbidding the use of it against
>  >>>>>>                     token endpoint would not change the semantics
>  >>>>>>                     of any existing parameter or endpoint, which
>  >>>>>>                     is good. However, I doubt if it is not worth
>  >>>>>>                     doing. What's the point of avoiding access
>  >>>>>>                     token scoped to UserInfo endpoint after all?
>  >>>>>>                     Defining a new endpoint for just avoiding the
>  >>>>>>                     access token for userinfo endpoint seems way
>  >>>>>>                     too much the heavy wait way and it breaks
>  >>>>>>                     interoperabiliy: it defeats the purpose of
>  >>>>>>                     standardization.
>  >>>>>>                     I have started feeling that no change is the
>  >>>>>>                     best way out.
>  >>>>>>                     Nat
>  >>>>>>                     [1]  If instead of saying "Token endpoint -
>  >>>>>>                     used by the client to exchange an
>  >>>>>>                     authorization grant for an access token,
>  >>>>>>                     typically with client authentication", it were
>  >>>>>>                     saying "Token endpoint - used by the client to
>  >>>>>>                     exchange an authorization grant for tokens,
>  >>>>>>                     typically with client authentication", then it
>  >>>>>>                     would have been OK. It is an expansion of the
>  >>>>>>                     capability rather than changing the semantics.
>  >>>>>>
>  >>>>>>
>  >>>>>>                     2014-07-23 13:39 GMT-04:00 Mike Jones
>  >>>>>>                     <[email-masked]
>  >>>>>>                     <mailto:[email-masked]>>:
>  >>>>>>
>  >>>>>>                         You need the alternative response_type
>  >>>>>>                         value ("code_for_id_token" in the A4C
>  >>>>>>                         draft) to tell the Authorization Server to
>  >>>>>>                         return a code to be used with the new
>  >>>>>>                         grant type, rather than one to use with
>  >>>>>>                         the "authorization_code" grant type (which
>  >>>>>>                         is what response_type=code does).
>  >>>>>>
>  >>>>>>
>  >>>>>>                         *From:*OAuth
>  >>>>>>                         [mailto:[email-masked]
>  >>>>>>                         <mailto:[email-masked]>] *On
>  >>>>>>                         Behalf Of *John Bradley
>  >>>>>>                         *Sent:* Wednesday, July 23, 2014 10:33 AM
>  >>>>>>                         *To:* [email-masked]
>  >>>>>>                         <mailto:[email-masked]>
>  >>>>>>
>  >>>>>>
>  >>>>>>                         *Cc:* [email-masked] <mailto:[email-masked]>
>  >>>>>>                         *Subject:* Re: [OAUTH-WG] New Version
>  >>>>>>                         Notification for
>  >>>>>>                         draft-hunt-oauth-v2-user-a4c-05.txt
>  >>>>>>
>  >>>>>>
>  >>>>>>                         If we use the token endpoint then a new
>  >>>>>>                         grant_type is the best way.
>  >>>>>>
>  >>>>>>
>  >>>>>>                         It sort of overloads code, but that is
>  >>>>>>                         better than messing with response_type for
>  >>>>>>                         the authorization endpoint to change the
>  >>>>>>                         response from the token_endpoint.  That is
>  >>>>>>                         in my opinion a champion bad idea.
>  >>>>>>
>  >>>>>>
>  >>>>>>                         In discussions developing Connect we
>  >>>>>>                         decided not to open this can of worms
>  >>>>>>                         because no good would come of it.
>  >>>>>>
>  >>>>>>
>  >>>>>>                         The token_endpoint returns a access token.
>  >>>>>>                          Nothing requires scope to be associates
>  >>>>>>                         with the token.
>  >>>>>>
>  >>>>>>
>  >>>>>>                         That is the best solution.  No change
>  >>>>>>                         required.  Better interoperability in my
>  >>>>>>                         opinion.
>  >>>>>>
>  >>>>>>
>  >>>>>>                         Still on my way to TO, getting in later
>  >>>>>>                         today.
>  >>>>>>
>  >>>>>>
>  >>>>>>                         John B.
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                         Sent from my iPhone
>  >>>>>>
>  >>>>>>
>  >>>>>>                         On Jul 23, 2014, at 12:15 PM,
>  >>>>>>                         [email-masked]
>  >>>>>>                         <mailto:[email-masked]> wrote:
>  >>>>>>
>  >>>>>>                             The "response type" of the token
>  >>>>>>                             endpoint is controlled by the value of
>  >>>>>>                             the parameter "grant_type". So there
>  >>>>>>                             is no need to introduce a new parameter.
>  >>>>>>
>  >>>>>>                             wrt to a potential "no_access_token"
>  >>>>>>                             grant type. I do not consider this a
>  >>>>>>                             good idea as it changes the semantics
>  >>>>>>                             of the token endpoint (as already
>  >>>>>>                             pointed out by Thomas). This endpoint
>  >>>>>>                             ALWAYS responds with an access token
>  >>>>>>                             to any grant type. I therefore would
>  >>>>>>                             prefer to use another endpoint for the
>  >>>>>>                             intended purpose.
>  >>>>>>
>  >>>>>>                             regards,
>  >>>>>>                             Torsten.
>  >>>>>>
>  >>>>>>
>  >>>>>>                             Am 23.07.2014 13:04, schrieb Nat
> Sakimura:
>  >>>>>>
>  >>>>>>                                 IMHO, changing the semantics of
>  >>>>>>                                 "response_type" @ authz endpoint
>  >>>>>>                                 this way is not a good thing.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Instead, defining a new parameter
>  >>>>>>                                 "response_type" @ token endpoint,
>  >>>>>>                                 as I described in my previous
>  >>>>>>                                 message,
>  >>>>>>
>  >>>>>>                                 probably is better. At least, it
>  >>>>>>                                 does not change the semantics of
>  >>>>>>                                 the parameters of RFC6749.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                  Nat
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 2014-07-23 12:48 GMT-04:00 Thomas
>  >>>>>>                                 Broyer <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>>:
>  >>>>>>
>  >>>>>>                                 No, I mean response_type=none and
>  >>>>>>                                 response_type=id_token don't
>  >>>>>>                                 generate a code or access token so
>  >>>>>>                                 you don't use the Token Endpoint
>  >>>>>>                                 (which is not the same as the
>  >>>>>>                                 Authentication Endpoint BTW).
>  >>>>>>
>  >>>>>>                                 With
>  >>>>>>                                 response_type=code_for_id_token,
>  >>>>>>                                 you get a code and exchange it for
>  >>>>>>                                 an id_token only, rather than an
>  >>>>>>                                 access_token, so you're changing
>  >>>>>>                                 the semantics of the Token Endpoint.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 I'm not saying it's a bad thing,
>  >>>>>>                                 just that you can't really compare
>  >>>>>>                                 none and id_token with
>  >>>>>>                                 code_for_id_token.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 On Wed, Jul 23, 2014 at 6:45 PM,
>  >>>>>>                                 Richer, Justin P.
>  >>>>>>                                 <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>> wrote:
>  >>>>>>
>  >>>>>>                                 It's only "not using the token
>  >>>>>>                                 endpoint" because the token
>  >>>>>>                                 endpoint copy-pasted and renamed
>  >>>>>>                                 the authentication endpoint.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                  -- Justin
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 On Jul 23, 2014, at 9:30 AM,
>  >>>>>>                                 Thomas Broyer <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>> wrote:
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Except that these are about not
>  >>>>>>                                 using the Token Endpoint at all,
>  >>>>>>                                 whereas the current proposal is
>  >>>>>>                                 about the Token Endpoint not
>  >>>>>>                                 returning an access_token field in
>  >>>>>>                                 the JSON.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 On Wed, Jul 23, 2014 at 4:26 PM,
>  >>>>>>                                 Mike Jones
>  >>>>>>                                 <[email-masked]
>  >>>>>>
> <mailto:[email-masked]>>
>  >>>>>>                                 wrote:
>  >>>>>>
>  >>>>>>                                 The response_type "none" is
>  >>>>>>                                 already used in practice, which
>  >>>>>>                                 returns no access token.  It was
>  >>>>>>                                 accepted by the designated experts
>  >>>>>>                                 and registered in the IANA OAuth
>  >>>>>>                                 Authorization Endpoint Response
>  >>>>>>                                 Types registry at
>  >>>>>>
> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint
>  >>>>>>
> <http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint>.
>  >>>>>>                                 The registered "id_token" response
>  >>>>>>                                 type also returns no access token.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 So I think the question of whether
>  >>>>>>                                 response types that result in no
>  >>>>>>                                 access token being returned are
>  >>>>>>                                 acceptable within OAuth 2.0 is
>  >>>>>>                                 already settled, as a practical
>  >>>>>>                                 matter.  Lots of OAuth
>  >>>>>>                                 implementations are already using
>  >>>>>>                                 such response types.
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 -- Mike
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 *From:*OAuth
>  >>>>>>                                 [mailto:[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>]
>  >>>>>>                                 *On Behalf Of *Phil Hunt
>  >>>>>>                                 *Sent:* Wednesday, July 23, 2014
>  >>>>>>                                 7:09 AM
>  >>>>>>                                 *To:* Nat Sakimura
>  >>>>>>                                 *Cc:* <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>>
>  >>>>>>                                 *Subject:* Re: [OAUTH-WG] New
>  >>>>>>                                 Version Notification for
>  >>>>>>                                 draft-hunt-oauth-v2-user-a4c-05.txt
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Yes. This is why it has to be
>  >>>>>>                                 discussed in the IETF.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Phil
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 @independentid
>  >>>>>>
>  >>>>>>                                 www.independentid.com
>  >>>>>>                                 <http://www.independentid.com/>
>  >>>>>>
>  >>>>>>                                 [email-masked]
>  >>>>>>                                 <mailto:[email-masked]>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 On Jul 23, 2014, at 9:43 AM, Nat
>  >>>>>>                                 Sakimura <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>> wrote:
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Reading back the RFC6749, I am not
>  >>>>>>                                 sure if there is a good way of
>  >>>>>>                                 suppressing access token from the
>  >>>>>>                                 response and still be OAuth. It
>  >>>>>>                                 will break whole bunch of implicit
>  >>>>>>                                 definitions like:
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 authorization server
>  >>>>>>                                       The server issuing access
>  >>>>>>                                 tokens to the client after
>  >>>>>>                                 successfully
>  >>>>>>                                       authenticating the resource
>  >>>>>>                                 owner and obtaining authorization.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 After all, OAuth is all about
>  >>>>>>                                 issuing access tokens.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Also, I take back my statement on
>  >>>>>>                                 the grant type in my previous mail.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 The definition of grant and
>  >>>>>>                                 grant_type are respectively:
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 grant
>  >>>>>>
>  >>>>>>                                     credential representing the
>  >>>>>>                                 resource owner's authorization
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 grant_type
>  >>>>>>
>  >>>>>>                                     (string representing the) type
>  >>>>>>                                 of grant sent to the token
>  >>>>>>                                 endpoint to obtain the access token
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Thus, the grant sent to the token
>  >>>>>>                                 endpoint in this case is still
>  >>>>>>                                 'code'.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Response type on the other hand is
>  >>>>>>                                 not so well defined in RFC6749,
>  >>>>>>                                 but it seems it is representing
>  >>>>>>                                 what is to be returned from the
>  >>>>>>                                 authorization endpoint. To express
>  >>>>>>                                 what is to be returned from token
>  >>>>>>                                 endpoint, perhaps defining a new
>  >>>>>>                                 parameter to the token endpoint,
>  >>>>>>                                 which is a parallel to the
>  >>>>>>                                 response_type to the Authorization
>  >>>>>>                                 Endpoint seems to be a more
>  >>>>>>                                 symmetric way, though I am not
>  >>>>>>                                 sure at all if that is going to be
>  >>>>>>                                 OAuth any more. One straw-man is
>  >>>>>>                                 to define a new parameter called
>  >>>>>>                                 response_type to the token
>  >>>>>>                                 endpoint such as:
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 response_type
>  >>>>>>
>  >>>>>>                                     OPTIONAL. A string
>  >>>>>>                                 representing what is to be
>  >>>>>>                                 returned from the token endpoint.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Then define the behavior of the
>  >>>>>>                                 endpoint according to the values
>  >>>>>>                                 as the parallel to the
>  >>>>>>                                 multi-response type spec.
>  >>>>>>
>  >>>>>>
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 Nat
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 2014-07-23 7:21 GMT-04:00 Phil
>  >>>>>>                                 Hunt <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>>:
>  >>>>>>
>  >>>>>>                                 The draft is very clear.
>  >>>>>>
>  >>>>>>                                 Phil
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 On Jul 23, 2014, at 0:46, Nat
>  >>>>>>                                 Sakimura <[email-masked]
>  >>>>>>                                 <mailto:[email-masked]>> wrote:
>  >>>>>>
>  >>>>>>                                     The new grant type that I was
>  >>>>>>                                     talking about was
>  >>>>>>
>  >>>>>>
> "authorization_code_but_do_not_return_access_nor_refresh_token",
>  >>>>>>                                     so to speak.
>  >>>>>>
>  >>>>>>                                     It does not return anything
>  >>>>>>                                     per se, but an extension can
>  >>>>>>                                     define something on top of it.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     Then, OIDC can define a
>  >>>>>>                                     binding to it so that the
>  >>>>>>                                     binding only returns ID Token.
>  >>>>>>
>  >>>>>>                                     This binding work should be
>  >>>>>>                                     done in OIDF. Should there be
>  >>>>>>                                     such a grant type,
>  >>>>>>
>  >>>>>>                                     it will be an extremely short
>  >>>>>>                                     spec.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     At the same time, if any other
>  >>>>>>                                     specification wanted to define
>  >>>>>>
>  >>>>>>                                     other type of tokens and have
>  >>>>>>                                     it returned from the token
>  >>>>>>                                     endpoint,
>  >>>>>>
>  >>>>>>                                     it can also use this grant type.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     If what you want is to define
>  >>>>>>                                     a new grant type that returns
>  >>>>>>                                     ID Token only,
>  >>>>>>
>  >>>>>>                                     then, I am with Justin. Since
>  >>>>>>                                     "other response than ID Token"
>  >>>>>>                                     is only
>  >>>>>>
>  >>>>>>                                     theoretical, this is a more
>  >>>>>>                                     plausible way forward, I
> suppose.
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     Nat
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     2014-07-22 14:30 GMT-04:00
>  >>>>>>                                     Justin Richer <[email-masked]
>  >>>>>>                                     <mailto:[email-masked]>>:
>  >>>>>>
>  >>>>>>                                     So the draft would literally
>  >>>>>>                                     turn into:
>  >>>>>>
>  >>>>>>                                     "The a4c response type and
>  >>>>>>                                     grant type return an id_token
>  >>>>>>                                     from the token endpoint with
>  >>>>>>                                     no access token. All
>  >>>>>>                                     parameters and values are
>  >>>>>>                                     defined in OIDC."
>  >>>>>>
>  >>>>>>                                     Seems like the perfect mini
>  >>>>>>                                     extension draft for OIDF to do.
>  >>>>>>
>  >>>>>>                                     --Justin
>  >>>>>>
>  >>>>>>                                     /sent from my phone/
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     On Jul 22, 2014 10:29 AM, Nat
>  >>>>>>                                     Sakimura <[email-masked]
>  >>>>>>                                     <mailto:[email-masked]>>
>  >>>>>>                                     wrote:
>  >>>>>>                                     >
>  >>>>>>                                     > What about just defining a
>  >>>>>>                                     new grant type in this WG?
>  >>>>>>                                     >
>  >>>>>>                                     >
>  >>>>>>                                     > 2014-07-22 12:56 GMT-04:00
>  >>>>>>                                     Phil Hunt
>  >>>>>>                                     <[email-masked]
>  >>>>>>                                     <mailto:[email-masked]>>:
>  >>>>>>                                     >>
>  >>>>>>                                     >> That would be nice. However
>  >>>>>>                                     oidc still needs the new grant
>  >>>>>>                                     type in order to implement the
>  >>>>>>                                     same flow.
>  >>>>>>                                     >>
>  >>>>>>                                     >> Phil
>  >>>>>>                                     >>
>  >>>>>>                                     >> On Jul 22, 2014, at 11:35,
>  >>>>>>                                     Nat Sakimura
>  >>>>>>                                     <[email-masked]
>  >>>>>>                                     <mailto:[email-masked]>>
>  >>>>>>                                     wrote:
>  >>>>>>                                     >>
>  >>>>>>                                     >>> +1 to Justin.
>  >>>>>>                                     >>>
>  >>>>>>                                     >>>
>  >>>>>>                                     >>> 2014-07-22 9:54 GMT-04:00
>  >>>>>>                                     Richer, Justin P.
>  >>>>>>                                     <[email-masked]
>  >>>>>>                                     <mailto:[email-masked]>>:
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>> Errors like these make it
>  >>>>>>                                     clear to me that it would make
>  >>>>>>                                     much more sense to develop
>  >>>>>>                                     this document in the OpenID
>  >>>>>>                                     Foundation. It should be
>  >>>>>>                                     something that directly
>  >>>>>>                                     references OpenID Connect Core
>  >>>>>>                                     for all of these terms instead
>  >>>>>>                                     of redefining them. It's doing
>  >>>>>>                                     authentication, which is
>  >>>>>>                                     fundamentally what OpenID
>  >>>>>>                                     Connect does on top of OAuth,
>  >>>>>>                                     and I don't see a good
>  >>>>>>                                     argument for doing this work
>  >>>>>>                                     in this working group.
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>>  -- Justin
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>> On Jul 22, 2014, at 4:30
>  >>>>>>                                     AM, Thomas Broyer
>  >>>>>>                                     <[email-masked]
>  >>>>>>                                     <mailto:[email-masked]>>
>  >>>>>>                                     wrote:
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>> On Mon, Jul 21, 2014 at
>  >>>>>>                                     11:52 PM, Mike Jones
>  >>>>>>                                     <[email-masked]
>  >>>>>>
> <mailto:[email-masked]>>
>  >>>>>>                                     wrote:
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>> Thanks for your review,
>  >>>>>>                                     Thomas.  The "prompt=consent"
>  >>>>>>                                     definition being missing is an
>  >>>>>>                                     editorial error.  It should be:
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>> consent
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>> The Authorization
>  >>>>>>                                     Server SHOULD prompt the
>  >>>>>>                                     End-User for consent before
>  >>>>>>                                     returning information to the
>  >>>>>>                                     Client. If it cannot obtain
>  >>>>>>                                     consent, it MUST return an
>  >>>>>>                                     error, typically
> consent_required.
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>> I'll plan to add it in
>  >>>>>>                                     the next draft.
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>> It looks like the
>  >>>>>>                                     consent_required error needs
>  >>>>>>                                     to be defined too, and you
>  >>>>>>                                     might have forgotten to also
>  >>>>>>                                     import
>  >>>>>>                                     account_selection_required
>  >>>>>>                                     from OpenID Connect.
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>>
>  >>>>>>                                     >>>>>> I agree that there's no
>  >>>>>>                                     difference between a response
>  >>>>>>                                     with multiple "amr" values
>  >>>>>>                                     that includes "mfa" and one
>  >>>>>>                                     that doesn't.  Unless a clear
>  >>>>>>                                     use case for why "mfa" is
>  >>>>>>                                     needed can be identified, we
>  >>>>>>                                     can delete it in the next draft.
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>> Thanks.
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>> How about "pwd" then? I
>  >>>>>>                                     fully understand that I should
>  >>>>>>                                     return "pwd" if the user
>  >>>>>>                                     authenticated using a
>  >>>>>>                                     password, but what "the
>  >>>>>>                                     service if a client secret is
>  >>>>>>                                     used" means in the definition
>  >>>>>>                                     for the "pwd" value?
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>> (Nota: I know you're at
>  >>>>>>                                     IETF-90, I'm ready to wait
>  >>>>>>                                     'til you come back ;-) )
>  >>>>>>                                     >>>>>
>  >>>>>>                                     >>>>> --
>  >>>>>>                                     >>>>> Thomas Broyer
>  >>>>>>                                     >>>>> /tɔ.ma.bʁwa.je/
>  >>>>>>
> <http://xn--nna.ma.xn--bwa-xxb.je/>
>  >>>>>>                                     >>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                                     >>>>> OAuth mailing list
>  >>>>>>                                     >>>>> [email-masked]
>  >>>>>>                                     <mailto:[email-masked]>
>  >>>>>>                                     >>>>>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                                     >>>> OAuth mailing list
>  >>>>>>                                     >>>> [email-masked]
>  >>>>>>                                     <mailto:[email-masked]>
>  >>>>>>                                     >>>>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>                                     >>>>
>  >>>>>>                                     >>>
>  >>>>>>                                     >>>
>  >>>>>>                                     >>>
>  >>>>>>                                     >>> --
>  >>>>>>                                     >>> Nat Sakimura (=nat)
>  >>>>>>                                     >>> Chairman, OpenID Foundation
>  >>>>>>                                     >>> http://nat.sakimura.org/
>  >>>>>>                                     >>> @_nat_en
>  >>>>>>                                     >>>
>  >>>>>>                                     >>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                                     >>> OAuth mailing list
>  >>>>>>                                     >>> [email-masked]
>  >>>>>>                                     <mailto:[email-masked]>
>  >>>>>>                                     >>>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>                                     >
>  >>>>>>                                     >
>  >>>>>>                                     >
>  >>>>>>                                     >
>  >>>>>>                                     > --
>  >>>>>>                                     > Nat Sakimura (=nat)
>  >>>>>>                                     > Chairman, OpenID Foundation
>  >>>>>>                                     > http://nat.sakimura.org/
>  >>>>>>                                     > @_nat_en
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                     --
>  >>>>>>                                     Nat Sakimura (=nat)
>  >>>>>>
>  >>>>>>                                     Chairman, OpenID Foundation
>  >>>>>>                                     http://nat.sakimura.org/
>  >>>>>>                                     @_nat_en
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 --
>  >>>>>>                                 Nat Sakimura (=nat)
>  >>>>>>
>  >>>>>>                                 Chairman, OpenID Foundation
>  >>>>>>                                 http://nat.sakimura.org/
>  >>>>>>                                 @_nat_en
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                                 OAuth mailing list
>  >>>>>>                                 [email-masked]
> <mailto:[email-masked]>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 --
>  >>>>>>                                 Thomas Broyer
>  >>>>>>                                 /tɔ.ma.bʁwa.je/
>  >>>>>>                                 <http://xn--nna.ma.xn--bwa-xxb.je/>
>  >>>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                                 OAuth mailing list
>  >>>>>>                                 [email-masked]
> <mailto:[email-masked]>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 --
>  >>>>>>                                 Thomas Broyer
>  >>>>>>                                 /tɔ.ma.bʁwa.je/
>  >>>>>>                                 <http://xn--nna.ma.xn--bwa-xxb.je/>
>  >>>>>>
>  >>>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                                 OAuth mailing list
>  >>>>>>                                 [email-masked]
> <mailto:[email-masked]>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                                 --
>  >>>>>>                                 Nat Sakimura (=nat)
>  >>>>>>
>  >>>>>>                                 Chairman, OpenID Foundation
>  >>>>>>                                 http://nat.sakimura.org/
>  >>>>>>                                 @_nat_en
>  >>>>>>
>  >>>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>
>  >>>>>>                                 OAuth mailing list
>  >>>>>>
>  >>>>>>                                 [email-masked]
> <mailto:[email-masked]>
>  >>>>>>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                             OAuth mailing list
>  >>>>>>                             [email-masked] <mailto:[email-masked]>
>  >>>>>>
> https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>
>  >>>>>>
>  >>>>>>
> _______________________________________________
>  >>>>>>                         OAuth mailing list
>  >>>>>>                         [email-masked] <mailto:[email-masked]>
>  >>>>>>                         https://www.ietf.org/mailman/listinfo/oauth
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>                     --
>  >>>>>>                     Nat Sakimura (=nat)
>  >>>>>>                     Chairman, OpenID Foundation
>  >>>>>>                     http://nat.sakimura.org/
>  >>>>>>                     @_nat_en
>  >>>>>>
>  >>>>>>                     _______________________________________________
>  >>>>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 13 Oct 2014 15:28:49 +0100

On 13/10/14 15:17, Justin Richer wrote:
> You certainly can do authentication without using an access token, but
> then I would argue that's no longer OAuth. Basically you're making tofu
> carob fudge.

Right, the access token is there for a client to get to the UserInfo 
endpoint, as far as OIDC is concerned. What if the info in the id_token 
is sufficient ?
I guess as far as a typical OAuth2 client is concerned, requesting 
"openid profile" only effectively gives one an access token that can 
only be used with the UserInfo endpoint.

So yes, may be even though OIDC has an access token returned, unless 
other custom scopes are used, the access token would be pretty much of 
use in the OIDC context only if a client chooses to work with the 
UserInfo...I guess the id_token/at_hash is useful on its own

Cheers, Sergey

>  >  >>>>>>                                     >>>> Errors like these
> make it
>  >  >>>>>>                                     >>>>>> Thanks for your
> review,
>  >  >>>>>>                                     >>>>>> I agree that
> there's no

---

From: Phil Hunt <[email-masked]>
Date: Mon, 13 Oct 2014 12:18:23 -0700

The point to be made is if the client’s objective is to authenticate the User, the base 6749 spec does not guarantee this at all.

It simply authorizes the client to access a resource and nothing more.

It turns out that a significant part of the time authentication does occur, but the client does not have access to that information. Nor can it specifically request re-authentication.

Further, if the client doesn’t wield the access token, its might not be proof that the token received was actually an authorization. 

OpenID gives you both authen information and authorization profile information (as a resource).

This thread was more about how to do just authentication ONLY. What are the requirements for a client to know a User *was* authenticated and when.  While some flows of OpenID can achieve this, its not clear that it addresses all cases. Furhter there is discussion (as Justin mentions) that a flow that does not produce an access token is not an authorization flow and is not OAuth. I agree. It an authentication flow and should be distinct IMHO.

That said, I am in the minority with this opinion and I acknowledge as being as such.
 
Phil

@independentid
www.independentid.com
[email-masked]

On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin <[email-masked]> wrote:

> Right, the access token is there for a client to get to the UserInfo endpoint, as far as OIDC is concerned. What if the info in the id_token is sufficient ?
> I guess as far as a typical OAuth2 client is concerned, requesting "openid profile" only effectively gives one an access token that can only be used with the UserInfo endpoint.
> 
> So yes, may be even though OIDC has an access token returned, unless other custom scopes are used, the access token would be pretty much of use in the OIDC context only if a client chooses to work with the UserInfo...I guess the id_token/at_hash is useful on its own
> 
> 
> Cheers, Sergey
> 
>> 
>> 
>> -- Justin
>> 
>> / Sent from my phone /
>> 
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 13 Oct 2014 21:24:48 +0100

Hi Phil

Thanks for the clarifications,
> OpenID gives you both authen information and authorization profile information (as a resource).
Yes, I experimented with it.
> This thread was more about how to do just authentication ONLY. What are the requirements for a client to know a User *was* authenticated and when.  While some flows of OpenID can achieve this, its not clear that it addresses all cases. Furhter there is discussion (as Justin mentions) that a flow that does not produce an access token is not an authorization flow and is not OAuth. I agree.
Sure.
> It an authentication flow and should be distinct IMHO.
>
I guess that is why the idea of having an OIDC profile dedicated to the 
authentication alone (no access token) which I believe was suggested 
here caught my attention. But then it is not OAuth2 and hence not OIDC. 
The chicken in the egg situation :-). As I said in the prev email, 
having an access token which is really restricted to the OIDC resource 
(profile) seems like a good compromise...

> That said, I am in the minority with this opinion and I acknowledge as being as such.

Sorry if I hijacked this thread and started the off-topic 'flow'...I 
guess my reasoning here is a bit all over the place, but I'm pretty sure 
now I see the big picture better

Thanks, Sergey

---

From: Phil Hunt <[email-masked]>
Date: Mon, 13 Oct 2014 14:17:48 -0700

Sergey,

Actually, I think your comments are fine. They add to the discussion on why A4C is distinct from OIDC’s larger IDP role in an OAuth style flow and why *both* are needed.

Comments in line.

Phil

@independentid
www.independentid.com
[email-masked]

On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin <[email-masked]> wrote:

> I guess that is why the idea of having an OIDC profile dedicated to the authentication alone (no access token) which I believe was suggested here caught my attention. But then it is not OAuth2 and hence not OIDC. The chicken in the egg situation :-). As I said in the prev email, having an access token which is really restricted to the OIDC resource (profile) seems like a good compromise…

[PH] We discussed this in Toronto and OIDC can’t do this and be compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out that the OAuth WG isn’t chartered to do authentication and that kind of killed the discussion leaving the issue hanging unresolved.

If you look at draft 00 of the A4C draft you will note that I originally proposed it as a new end-point. My feeling it should NOT be an OAuth flow - because as Justin says, if you aren’t returning an access token, you aren’t doing OAuth. The issue is that the technical redirect flow for authentication and authorization share the same security risks and counter-measures. It would be good therefore to build “in-parallel” or “underneath” OAuth to define an authn flow.

I would still recommend OIDC as a layer on top of OAuth that defines the standard way to get profile claims (the full OAuth style IDP functionality). 

> Sorry if I hijacked this thread and started the off-topic 'flow'...I guess my reasoning here is a bit all over the place, but I'm pretty sure now I see the big picture better
> 
> Thanks, Sergey
> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> [email-masked]
>> 
>> 
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 14 Oct 2014 10:25:10 +0100

Hi Phil, All,

Thanks for your positive feedback and further comments below.
My goal was really about trying to make a clear picture in my mind about 
what OIDC is with respect to OAuth2, and specifically supporting the 
point about OIDC not being just OAuth2.

As such, the idea of a specific OIDC profile where no access token was 
used appealed to me but really in light of supporting the same point 
that OIDC being not just OAuth2. I understand it 'breaks' the clean OIDC 
OAuth2-based model. Hence I also tried to suggest that even though OIDC 
does return an access token, this token does not have to be a 
full-powered token that a client can use to access something else but a 
user profile endpoint (unless custom scopes are also used). So the 
access token is there but it's only usable in the OAuth2 world.

I respect the effort done in the a4c draft - I'm just not sure really it 
has to be a separate effort (as opposed to it being an OIDC 'exception' 
light weight profile - can be simpler for users like me to have it all 
comprehended when it is a single family of docs) should the experts like 
yourself and others really like the idea of having a pure authentication 
flow supported.

But I'll be watching with the interest how it all evolves now :-)

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 14 Oct 2014 10:26:55 +0100

Sorry for the noise,
> access token is there but it's only usable in the OAuth2 world.
meant to say in the OIDC world and as such it is a limited token

>> Actually, I think your comments are fine. They add to the discussion
>> on why A4C is distinct from OIDC’s larger IDP role in an OAuth style
>> flow and why *both* are needed.
>>
>> Comments in line.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> [email-masked]
>>
>>
>>
>>>> The point to be made is if the client’s objective is to authenticate
>>>> the User, the base 6749 spec does not guarantee this at all.
>>>>
>>>> It turns out that a significant part of the time authentication does
>>>> occur, but the client does not have access to that information. Nor
>>>> can it specifically request re-authentication.
>>>>
>>>> Further, if the client doesn’t wield the access token, its might not
>>>> be proof that the token received was actually an authorization.
>>>>
>>>> This thread was more about how to do just authentication ONLY. What
>>>> are the requirements for a client to know a User *was* authenticated
>>>> and when.  While some flows of OpenID can achieve this, its not
>>>> clear that it addresses all cases. Furhter there is discussion (as
>>>> Justin mentions) that a flow that does not produce an access token
>>>> is not an authorization flow and is not OAuth. I agree.
>>> Sure.
>>> I guess that is why the idea of having an OIDC profile dedicated to
>>> the authentication alone (no access token) which I believe was
>>> suggested here caught my attention. But then it is not OAuth2 and
>>> hence not OIDC. The chicken in the egg situation :-). As I said in
>>> the prev email, having an access token which is really restricted to
>>> the OIDC resource (profile) seems like a good compromise…
>>
>> [PH] We discussed this in Toronto and OIDC can’t do this and be
>> compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out
>> that the OAuth WG isn’t chartered to do authentication and that kind
>> of killed the discussion leaving the issue hanging unresolved.
>>
>> If you look at draft 00 of the A4C draft you will note that I
>> originally proposed it as a new end-point. My feeling it should NOT be
>> an OAuth flow - because as Justin says, if you aren’t returning an
>> access token, you aren’t doing OAuth. The issue is that the technical
>> redirect flow for authentication and authorization share the same
>> security risks and counter-measures. It would be good therefore to
>> build “in-parallel” or “underneath” OAuth to define an authn flow.
>>
>> I would still recommend OIDC as a layer on top of OAuth that defines
>> the standard way to get profile claims (the full OAuth style IDP
>> functionality).
>>
>>>
>>> guess my reasoning here is a bit all over the place, but I'm pretty
>>> sure now I see the big picture better
>>>
>>> Thanks, Sergey
>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com
>>>> [email-masked]
>>>>
>>>>
>>>>
>>>>> Right, the access token is there for a client to get to the
>>>>> UserInfo endpoint, as far as OIDC is concerned. What if the info in
>>>>> the id_token is sufficient ?
>>>>> "openid profile" only effectively gives one an access token that
>>>>> can only be used with the UserInfo endpoint.
>>>>>
>>>>> So yes, may be even though OIDC has an access token returned,
>>>>> unless other custom scopes are used, the access token would be
>>>>> pretty much of use in the OIDC context only if a client chooses to
>>>>> work with the UserInfo...I guess the id_token/at_hash is useful on
>>>>> its own
>>>>>
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>>
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>> / Sent from my phone /
>>>>>>
>>>>>>
>>>>>>>   > An other common possession is that if you don't want to
>>>>>>> prompt the
>>>>>> user
>>>>>>>   > understand that there are no attributes one way or another
>>>>>>> anyway
>>>>>> or it
>>>>>>>   > market and slow the the adoption of identity federation on
>>>>>>> top of
>>>>>> OAuth,
>>>>>>>   >> here - implementers, practitioners, deployers, strategists,
>>>>>>> etc.
>>>>>> - and
>>>>>>>   >>>>>>                     returned from the token endpoint,
>>>>>>> but the
>>>>>> hint
>>>>>>>   >>>>>>                     credential the endpoint has
>>>>>>> received. It
>>>>>> seems
>>>>>>>   >>>>>>                     Torsten points out. If it is ok to
>>>>>>> change
>>>>>> this
>>>>>>>   >>>>>>                     to this endpoint to control the
>>>>>>> response
>>>>>> would
>>>>>>>   >>>>>>                     typically with client
>>>>>>> authentication", it
>>>>>> were
>>>>>>> *On
>>>>>>> 10:33 AM
>>>>>>> Version
>>>>>>>   >>>>>>                                       The server issuing
>>>>>>> access
>>>>>>>   >>>>>>                                 the grant type in my
>>>>>>> previous
>>>>>> mail.
>>>>>>>   >>>>>>                                     (string representing
>>>>>>> the)
>>>>>> type
>>>>>>>   >>>>>>                                 endpoint to obtain the
>>>>>>> access
>>>>>> token
>>>>>>>   >>>>>>                                 sure at all if that is
>>>>>>> going
>>>>>> to be
>>>>>>>   >>>>>>                                     binding to it so
>>>>>>> that the
>>>>>>>   >>>>>>                                     At the same time, if
>>>>>>> any
>>>>>> other
>>>>>>>   >>>>>>                                     plausible way
>>>>>>> forward, I
>>>>>>>   >>>>>>                                     parameters and
>>>>>>> values are
>>>>>>>   >>>>>>                                     extension draft for
>>>>>>> OIDF
>>>>>> to do.
>>>>>>>   >>>>>>                                     oidc still needs the
>>>>>>> new
>>>>>>>   >>>>>>                                     >>> 2014-07-22 9:54
>>>>>>> GMT-04:00
>>>>>>>   >>>>>>                                     clear to me that it
>>>>>>> would
>>>>>> make
>>>>>>>   >>>>>>                                     Foundation. It
>>>>>>> should be
>>>>>>>   >>>>>>                                     references OpenID
>>>>>>> Connect
>>>>>> Core
>>>>>>>   >>>>>>                                     of redefining them.
>>>>>>> It's
>>>>>> doing
>>>>>>>   >>>>>>                                     authentication,
>>>>>>> which is
>>>>>>>   >>>>>>                                     fundamentally what
>>>>>>> OpenID
>>>>>>>   >>>>>>                                     >>>> On Jul 22,
>>>>>>> 2014, at 4:30
>>>>>>>   >>>>>>                                     >>>>> On Mon, Jul
>>>>>>> 21, 2014 at
>>>>>>>   >>>>>>                                     definition being
>>>>>>> missing
>>>>>> is an
>>>>>>>   >>>>>>                                     >>>>>> The
>>>>>>> Authorization
>>>>>>>   >>>>>>                                     Server SHOULD prompt
>>>>>>> the
>>>>>>>   >>>>>>                                     >>>>>> I'll plan to
>>>>>>> add it in
>>>>>>>   >>>>>>                                     use case for why
>>>>>>> "mfa" is
>>>>>>>   >>>>>>                                     can delete it in the
>>>>>>> next
>>>>>> draft.
>>>>>>>   >>>>>>                                     >>>>> How about
>>>>>>> "pwd" then? I
>>>>>>>   >>>>>>                                     return "pwd" if the
>>>>>>> user
>>>>>>>   >>>>>>                                     >>>>> (Nota: I know
>>>>>>> you're at
>>>>>>>   >>>>>>                                     'til you come back
>>>>>>> ;-) )
>>>>>>>   >>>>>>                                     >>>>> OAuth mailing
>>>>>>> list

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com