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