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

[Takahiko Kawasaki <[e-mail]>]

Hello,

(1) RFC 6749
  grant_type=authorization_code
  response={"access_token":...}

(2) OpenID Connect Core
  grant_type=authorization_code
  response={"access_token":..., "id_token":...}

(3) Currently being discussed
  (3)-1
    grant_type=authorization_code
    response_type=id_token  (a new parameter for the token endpoint)
    response={"id_token":...}

  (3)-2
    grant_type=something_new  (a new value for the token endpoint)
    response={"id_token":...}

  (3)-3
    response_type=something_new (a new value for the authz endpoint)
    grant_type=something_new

However, taking a logical expansion below into account,

(4) Not being discussed yet, but logically possible
  grant_type=password
  response={"id_token":...}

it seems "grant_type" should be treated as a parameter to specify
just a 'flow'. IMHO, what tokens should be included in the response
from the token endpoint should be specified by another different means.
For example, "response_type" (a new parameter for the *token* endpoint)
as suggested by Nat.

Nat> response_type
Nat>   OPTIONAL. A string that expresses what tokens are to be returned
Nat>   from the Token Endpoint. Extension specifications may use this
Nat>   parameter to explicitly expressing the desire to  obtain a
Nat>   particular type of token.

If asked, I would add the following:

  The default value of "response_type" is "token" which means that
  an access token is requested. However, when the following conditions
  are satisfied, the default value is "token id_token".

    Condition-1:
      grant_type=authorization_code

    Condition-2:
      The authorization code was issued at the authorization endpoint
      with 'openid' scope.

--
Best Regards,
Takahiko Kawasaki



2014-07-24 2:39 GMT+09:00 Mike Jones <[e-mail]>:

>  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:[e-mail]] *On Behalf Of *John Bradley
> *Sent:* Wednesday, July 23, 2014 10:33 AM
> *To:* [e-mail]
>
> *Cc:* [e-mail]
> *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, [e-mail] 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 <[e-mail]>:
>
> 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. <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
> 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.
> 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:[e-mail]] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, July 23, 2014 7:09 AM
> *To:* Nat Sakimura
> *Cc:* <[e-mail]>
> *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
>
> [e-mail]
>
>
>
>
>
>
>
> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <[e-mail]> 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 <[e-mail]>:
>
> The draft is very clear.
>
> Phil
>
>
> On Jul 23, 2014, at 0:46, Nat Sakimura <[e-mail]> 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 <[e-mail]>:
>
> 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 <[e-mail]> wrote:
> >
> > What about just defining a new grant type in this WG?
> >
> >
> > 2014-07-22 12:56 GMT-04:00 Phil Hunt <[e-mail]>:
> >>
> >> 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 <[e-mail]> wrote:
> >>
> >>> +1 to Justin.
> >>>
> >>>
> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <[e-mail]>:
> >>>>
> >>>> 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 <[e-mail]>
> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <
> [e-mail]> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Nat Sakimura (=nat)
> >>> Chairman, OpenID Foundation
> >>> http://nat.sakimura.org/
> >>> @_nat_en
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [e-mail]
> >>> 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
> [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> --
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>  _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>