-- Justin
/ Sent from my phone /
-------- Original message --------
From: Sergey Beryozkin <sberyoz...@gmail.com>
Date:10/13/2014 9:00 AM (GMT-05:00)
To: Justin Richer <jric...@mit.edu>, oauth@ietf.org
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 <sberyoz...@gmail.com>
Date:10/13/2014 6:33 AM (GMT-05:00)
To: oauth@ietf.org
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
<bcampb...@pingidentity.com
> <mailto:bcampb...@pingidentity.com>> 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 <sakim...@gmail.com
>> <mailto:sakim...@gmail.com>> 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 <ve7...@ve7jtb.com
>> <mailto:ve7...@ve7jtb.com>>:
>>
>> 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, tors...@lodderstedt.net
>> <mailto:tors...@lodderstedt.net> 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
>>>> <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>
>>>> 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
>>>>> <t.bro...@gmail.com <mailto:t.bro...@gmail.com>>:
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
_______________________________________________
>>>>>>
