Native application SSO Working Group
Paul Madsen
paulmadsen at rogers.com
Tue Jul 2 17:25:43 UTC 2013
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:*openid-specs-bounces at lists.openid.net
> [mailto:openid-specs-bounces at lists.openid.net] *On Behalf Of *Torsten
> Lodderstedt
> *Sent:* Tuesday, July 2, 2013 9:53 AM
> *To:* Paul Madsen
> *Cc:* John Bradley; ashishjain at vmware.com; openid-specs at lists.openid.net
> *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 <pmadsen at pingidentity.com
> <mailto: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> <mailto: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
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130702/205293f5/attachment.html>
More information about the specs
mailing list