Native application SSO Working Group

Torsten Lodderstedt torsten at lodderstedt.net
Tue Jul 2 15:31:05 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130702/1c3839e4/attachment.html>


More information about the specs mailing list