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" <sakim...@gmail.com
<mailto:sakim...@gmail.com>> 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
<t.bro...@gmail.com <mailto:t.bro...@gmail.com>>:
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"
<sakim...@gmail.com <mailto:sakim...@gmail.com>> 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
<michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>:
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:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On
Behalf Of *John Bradley
*Sent:* Wednesday, July 23, 2014 10:33 AM
*To:* tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>
*Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
*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,
tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net> 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 <t.bro...@gmail.com
<mailto:t.bro...@gmail.com>>:
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.
<jric...@mitre.org
<mailto:jric...@mitre.org>> 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 <t.bro...@gmail.com
<mailto:t.bro...@gmail.com>> 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
<michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
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:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>]
*On Behalf Of *Phil Hunt
*Sent:* Wednesday, July 23, 2014
7:09 AM
*To:* Nat Sakimura
*Cc:* <oauth@ietf.org
<mailto:oauth@ietf.org>>
*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/>
phil.h...@oracle.com
<mailto:phil.h...@oracle.com>
On Jul 23, 2014, at 9:43 AM, Nat
Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>> 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 <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>:
The draft is very clear.
Phil
On Jul 23, 2014, at 0:46, Nat
Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>> 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 <jric...@mit.edu
<mailto:jric...@mit.edu>>:
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 <sakim...@gmail.com
<mailto:sakim...@gmail.com>>
wrote:
>
> What about just defining a
new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00
Phil Hunt
<phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>:
>>
>> 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
<sakim...@gmail.com
<mailto:sakim...@gmail.com>>
wrote:
>>
>>> +1 to Justin.
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00
Richer, Justin P.
<jric...@mitre.org
<mailto:jric...@mitre.org>>:
>>>>
>>>> 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
<t.bro...@gmail.com
<mailto:t.bro...@gmail.com>>
wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at
11:52 PM, Mike Jones
<michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
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
>>>>> OAuth@ietf.org
<mailto:OAuth@ietf.org>
>>>>>
https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
<mailto: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
<mailto:OAuth@ietf.org>
>>>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
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
OAuth@ietf.org <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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 <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
