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 <[email protected]> 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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> >> >> 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 <[email protected] >>> <mailto:[email protected]>> >>> >>> 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 >>>>> <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>>> [email protected] ><mailto:[email protected]> >>>>>> >http://lists.openid.net/mailman/listinfo/openid-specs >>>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] <mailto:[email protected]> >>> 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 >>
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
