[Openid-specs-ab] Id token at token endpoint

John Bradley ve7jtb at ve7jtb.com
Sat Dec 29 15:52:09 UTC 2012


We have discussed connect and the resource owner credentials flow.

I think the decision was to try and  not preclude it but that it probably needs its own extension spec.

It is different in that many of the things that work through the front channel won't work.

It is really a type of assertion flow where the client is trading a set of credentials for an assertion & token. rather than a SSO flow.

I don't happen to like the resource owner credentials flow as it is not comparable with multi factor authentication etc.

I would be OK with changing this to say that connect only defines returning a id_token with the code grant, but other grant types may define the semantics returning a id_token if appropriate.

John B.

On 2012-12-29, at 6:30 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:

> *** taking this discussion to the list again :-) ***
> 
> In my opinion, the id token represents an authentication event and it doesn't matter whether this event took place in a web browser or during a backend call.
> 
> Regards,
> Torsten.
> 
> Am 29.12.2012 um 00:41 schrieb Brian Campbell <bcampbell at pingidentity.com>:
> 
>> So an ID Token is tied (as much as is possible) to a web session at which the end user is present, which is really only achieved though interaction with the authorization endpoint. I'm only guessing/assuming though. 
>> 
>> 
>> On Fri, Dec 28, 2012 at 3:08 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
>> Why?
>> 
>> Am 28.12.2012 um 22:56 schrieb Brian Campbell <bcampbell at pingidentity.com>:
>> 
>>> I'd always assumed that the intent was to preclude it?
>>> 
>>> 
>>> On Fri, Dec 28, 2012 at 1:25 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
>>> Hi,
>>> 
>>> I just noticed the following statement in messages:
>>> 
>>> "Note that id_token MUST NOT be returned if the grant_type is not authorization_code"
>>> 
>>> What is the rational for this restriction? I remember discussions not to allow an exchange of refresh tokens for id tokens. That's ok. But I can imagine to provide clients with id tokens based on the password grant type. Do you want to preclude this?
>>> 
>>> Regards,
>>> Torsten.
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> 
>> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121229/5b19c65b/attachment.html>


More information about the Openid-specs-ab mailing list