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.
Thi
I'm ok with that text, and actually thought we had something along those lines
already.
--Justin
/sent from my phone/
On Jul 22, 2014 3:27 PM, tors...@lodderstedt.net wrote:
>
> Hi all,
>
> I don't think this parameter adds any security (as it is self declarded by
> the caller). I think the co
Hi all,
I don't think this parameter adds any security (as it is self declarded
by the caller). I think the constraints on redirect_uris can be
specified without the need for another registration parameter. As far as
I understand, they merely depend on the grant type. So we could some
text to
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, 2
Speaking for myself, yes. Defining the simple ID_token grant showing how an ID
token only can be returned is my minimum objective.
I think there needs to be some discussion in the WG on certain features which
may be better suited only within OIDC and those features which fit better as a
founda
What about just defining a new grant type in this WG?
2014-07-22 12:56 GMT-04:00 Phil Hunt :
> 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 wrote:
>
> +1 to Justin.
>
>
> 2014-07-22 9:
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 wrote:
>
> +1 to Justin.
>
>
> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. :
>> Errors like these make it clear to me that it would make much
+1 to Justin.
2014-07-22 9:54 GMT-04:00 Richer, Justin P. :
> 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 r
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 wha
On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones
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 C
10 matches
Mail list logo
