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

[Nat Sakimura <[e-mail]>]

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