-- 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
>>>>>>
>>>>>>
_______________________________________________
>>>>>>
