Native application SSO Working Group
George Fletcher
gffletch at aol.com
Tue Jul 2 18:23:38 UTC 2013
+1
On 7/2/13 2:15 PM, John Bradley wrote:
> 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 <tonynad at microsoft.com
> <mailto:tonynad at microsoft.com>> 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 <mailto:paulmadsen at rogers.com>
>> Sent: ?7/?2/?2013 10:26 AM
>> To: Anthony Nadalin <mailto:tonynad at microsoft.com>
>> Cc: Torsten Lodderstedt <mailto:torsten at lodderstedt.net>; Paul Madsen
>> <mailto:pmadsen at pingidentity.com>; John Bradley
>> <mailto:ve7jtb at ve7jtb.com>; ashishjain at vmware.com
>> <mailto:ashishjain at vmware.com>; openid-specs at lists.openid.net
>> <mailto:openid-specs at lists.openid.net>
>> 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:*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
>>
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
--
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130702/0b51e960/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 79140 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20130702/0b51e960/attachment-0001.png>
More information about the specs
mailing list