Native application SSO Working Group
Torsten Lodderstedt
torsten at lodderstedt.net
Tue Jul 2 16:52:51 UTC 2013
Hi Paul,
got it :-) Would it make sense to add this assumption to the charter?
Does this mean:
- a single AZA manages access to multiple authz servers?
- an app needs to be able to register its authz server/idp at the AZA?
Thanks,
Torsten.
Paul Madsen <pmadsen at pingidentity.com> schrieb:
>Hi Torsten, wrt the possibility of an id_token being used against a
>'home' IdP, the current model is that it would be the AZA that would
>perform this exchange, not the native app itself - this because the
>overarching assumption being that the AZA should do as much of the
>heavy
>lifting as possible - and thereby simplify life for the native apps.
>
>But that is separate I think from the use case of an native app wanting
>
>to consume an id_token directly (for access control, customization etc)
>
>and so i will look at charter to make sure this scenario is supported.
>
>paul
>
>
>On 7/2/13 11:31 AM, Torsten Lodderstedt wrote:
>> 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
>> <mailto: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
>>> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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 list
>>>>>> specs at lists.openid.net
><mailto:specs at lists.openid.net>
>>>>>>
>http://lists.openid.net/mailman/listinfo/openid-specs
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net <mailto:specs at lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net <mailto: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/da20b852/attachment-0001.html>
More information about the specs
mailing list