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

[Torsten Lodderstedt]

Hi John,

I'would be fine with the change you proposed.

Regards,
Torsten.

Am 29.12.2012 um 16:52 schrieb John Bradley <ve7jtb at ve7jtb.com>:

> 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/6a023686/attachment.html>