Correct and feedback from the specs list can and should influence the final charters scope.
I agree that we need to consider how a agent would work with multiple authorization servers rather than being hardcoded to only one. Google's play store is an example of a authorization agent that is getting ether access tokens for Google API, or id_token/assertions for 3rd party API. At the moment it is up to the app in the 3rd party case to decide if it wants to use the id_token as a access token or in a JWT assertion flow at a 3rd party AS to get a access token. I think the changes we made to connect to support the use of id_tokens as JWT allows us some flexibility. In some cases the AZA might perform the function of trading a id_token/assertion to a 3rd party AS and getting back a access token to give to the app. I think the charter should allow for all of those scenarios, though the WG may decide to only support a subset of options in a specification. John B. On 2013-07-02, at 1:55 PM, Anthony Nadalin <[email protected]> wrote: > Just saying that ultimatly the WG decides what the work product is regardless > of input but constrained by the charter > > Sent from my Windows Phone > From: Paul Madsen > Sent: β7/β2/β2013 10:26 AM > To: Anthony Nadalin > Cc: Torsten Lodderstedt; Paul Madsen; John Bradley; [email protected]; > [email protected] > Subject: Re: Native application SSO Working Group > > Hi Tony, not sure I understand your point. > > Are you saying that we (the proposers of the new WG) *technically* needn't > account for feedback such as Torsten's in this review cycle? > > Paul > > On 7/2/13 1:03 PM, Anthony Nadalin wrote: >> Since this is slated to be an OpenID WG, itβs what the WG wants to do. >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Torsten >> Lodderstedt >> Sent: Tuesday, July 2, 2013 9:53 AM >> To: Paul Madsen >> Cc: John Bradley; [email protected]; [email protected] >> Subject: Re: Native application SSO Working Group >> >> 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]> >> 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 list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> >> _______________________________________________ >> specs mailing list >> [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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
