Native application SSO Working Group

[Nat Sakimura]

Yes. The law enforcement guy's use case was exactly that.
He wanted to generated ID Token and through it to the server to login to
the server and receive service.
His application was also location sensitive.


2013/7/3 Torsten Lodderstedt <torsten at lodderstedt.net>

> Hi,
>
> I agree with Nat on this use case. Another one is that the app wants to
> use the id_token as credential on its "home" IDP (probably via JWT bearer
> token profile). This is more or less 3rd party login for apps.
>
> regards,
> Torsten.
>
>
>
> Nat Sakimura <sakimura at gmail.com> schrieb:
>
>> Yes. If the app wants the identity information to evaluate its own access
>> control, then it would probably want to know about the user identity (i.e.,
>> set of attributes related to the entity), and id_token is the right thing.
>>
>> When I was talking to some law enforcement people in EU, they were
>> talking similar things. Right now, we do not have any location data defined
>> in the claims, but we may also want to do so in such cases.
>>
>> Nat
>>
>>
>> 2013/7/3 Paul Madsen <paulmadsen at rogers.com>
>>
>>>  Hi Nat, the current AZA model does not preclude an access token being
>>> formatted as an id_token.
>>>
>>> I believe Torsten was conjecturing that there was potential value in an
>>> id_token being delivered to a native app in addition to an access token
>>> (whether formatted as id_token or not)
>>>
>>> Regards
>>>
>>> paul
>>>
>>>
>>> On 7/2/13 10:53 AM, Nat Sakimura wrote:
>>>
>>> I actually do see some utility in the access token in the format of ID
>>> Token.
>>> It can give appropriate audience restriction etc.
>>>
>>>
>>>  2013/7/2 Paul Madsen <paulmadsen at rogers.com>
>>>
>>>>  Hi Torsten, the current model is that the Authorization Agent (AZA)
>>>> may itself obtain an id_token and use it to obtain an access token, but
>>>> that only access tokens would be 'handed over' by the AZA to its
>>>> constituent native apps.
>>>>
>>>> Are you proposing that there may be value in allowing the AZA to also
>>>> hand over id_tokens (suitably targeted) as well?
>>>>
>>>> paul
>>>>
>>>>   On 7/1/13 1:38 PM, Torsten Lodderstedt wrote:
>>>>
>>>>  Hi John,
>>>>
>>>> I interpreted the text of the charter the other way around, so a client
>>>> would be able to use an(y) id_token (as a credential) to obtain an access
>>>> token. I'm fine if the mechanism is intended to support id_token issuance.
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>>  Am 01.07.2013 15:06, schrieb John Bradley:
>>>>
>>>> Hi Torsten,
>>>>
>>>>  In point 3 the charter talks about using id_tokens to get access
>>>> tokens.
>>>>
>>>>  So it is imagined that the mechanism would issue id_tokens likely
>>>> along the lines that Google is doing for the play store by having a 3rd
>>>> party as an audience and using "azp" to indicate the client the token was
>>>> issued to.   We don't want to be too specific on the solution in the
>>>> charter.
>>>>
>>>>  If you think something needs to be added let me know.
>>>>
>>>>  John B.
>>>>
>>>>   On 2013-07-01, at 2:17 AM, Torsten Lodderstedt <
>>>> torsten at lodderstedt.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> it would be great to have such a mechanism across platforms!
>>>>
>>>> I'm wondering whether the mechanism should issue id tokens as well.
>>>> Right now it seems to focus on access tokens.
>>>>
>>>> Regards,
>>>> Torsten.
>>>>
>>>>
>>>>
>>>> John Bradley <ve7jtb at ve7jtb.com> schrieb:
>>>>>
>>>>> The enclosed Work Group Charter is being sent to the Specs Council for review in anticipation of chartering the Group.
>>>>>
>>>>> It is best have this activity under the foundation IPR as soon as possible.
>>>>>
>>>>> Regards
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  ------------------------------
>>>>>
>>>>> specs mailing listspecs at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>> specs mailing listspecs at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>
>>>
>>>  --
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130703/220bd743/attachment.html>