[Openid-specs-native-apps] Please review specs
Paul Madsen
paul.madsen at gmail.com
Thu Feb 13 16:32:24 UTC 2014
thanks John, so the Token EP would know to return an (appropriately
targetted) id_token rather than an access token based on the scope?
what parts remain to be spec'd out?
1) the refresh call from TA is unchanged correct?
2) the returned id_token ?
3) the JWT assertion exchange?
paul
On 2/13/14, 11:19 AM, John Bradley wrote:
> This shows using the token endpoint to side-scope a refresh token to
> get a id_token with a 3rd party audience using the Google Play
> example, then using the JWT assertion flow to exchange the id_token
> for a access token.
>
> This is the Google developer spec for the Play Method
> http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html
> They don't have there Token Agent do the swap for a access token, they
> are handing the id_token to the app and letting it use it as an access
> token or exchange it in some way.
>
> The other possibility may be to have the Appinfo endpoint return the
> id_token along with meta-data about what 3rd party Token endpoint
> needs to be used to exchange the id_token/JWT assertion.
> This may work better if the Token Agent is doing the exchange rather
> than the app.
>
>
> For those not part of the Connect WG we deliberately the id_token the
> same format as a JWT for use in assertions.
>
>
>
>
> On Feb 12, 2014, at 6:20 PM, Paul Madsen <paul.madsen at gmail.com
> <mailto:paul.madsen at gmail.com>> wrote:
>
>> guys, care to swimlane that model out at websequencediagrams?
>>
>> paul
>> On 2/12/14, 3:52 PM, Chuck Mortimore wrote:
>>> We've been thinking of a model where the RS could validate the
>>> id_token for access to it's services and exchange it via assertion
>>> flow if it needed to act on behalf of user at the RS associated with
>>> the original AS. This sounds inline with that
>>>
>>> -cmort
>>>
>>>
>>> On Wed, Feb 12, 2014 at 12:39 PM, John Bradley <ve7jtb at ve7jtb.com
>>> <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>
>>> Hi Chuck,
>>>
>>> I will get to this over the next couple of days.
>>>
>>> We do have the 3rd party id_tokens that can be used as JWT
>>> assertions that were added to connect for Google. In principal
>>> those should be exchanged in the assertion flow for access
>>> tokens when crossing security domains.
>>>
>>> So I suppose the type of token would depend on if the app
>>> directly accepted access tokens from the AS of the napps agent.
>>>
>>> Apps using Google Play services directly use the id_token as a
>>> access token in general but that places a potential burden on
>>> the RS to accept tokens of different types. I prefer to use
>>> the token endpoint to exchange the assertion so the RS only
>>> needs to worry about access tokens from it's AS whatever those
>>> happen to be.
>>>
>>> John B.
>>>
>>> On Feb 5, 2014, at 11:48 PM, Chuck Mortimore
>>> <cmortimore at salesforce.com <mailto:cmortimore at salesforce.com>>
>>> wrote:
>>>
>>>> One other thought - Perhaps instead of opaque access tokens
>>>> for the apps, we should issue id_tokens that are audience
>>>> restricted
>>>>
>>>>
>>>> On Wed, Feb 5, 2014 at 3:58 PM, Chuck Mortimore
>>>> <cmortimore at salesforce.com <mailto:cmortimore at salesforce.com>>
>>>> wrote:
>>>>
>>>> *Comments on Agent Core 1.0*
>>>>
>>>> 5.0 - Do we need to make client credentials mandatory?
>>>> Can we make this a MAY?
>>>>
>>>> 7.1 - in general seems redundant to oauth/openid connect,
>>>> with the exception of the AZA scope. Do we need to
>>>> respecify all of this?
>>>>
>>>> 7.1.1 - Why is response_type=code MUST? Is this oauth
>>>> carry over? (same as my question on 5.0 I think)
>>>>
>>>> 7.4.1/2 - By issuing on the token endpoint, we are
>>>> basically saying that only administrative authorization
>>>> models will work. If end-user authorized oauth is being
>>>> used, the user doesn't have a chance to approve access to
>>>> and new app. Shouldn't we be performing a new
>>>> Authorization request, rather than a straight refresh token
>>>> exchange?
>>>>
>>>>
>>>> *Comments on Agent API bindings 1.0*
>>>>
>>>> 2.0 - "Rather than the user individually authenticating and
>>>> authorizing each native application, they do so only for
>>>> the authorization agent" - same as my last comment; from
>>>> an authorization model perspective, this basically kills
>>>> off end-user approval models with this profile. There's no
>>>> way for the user to make effective authorization decisions
>>>> for future unknown applications.
>>>>
>>>> 4.0 - this seems to really be the meat of what we should
>>>> specify, but the entire section is basically silent on
>>>> detail. For this spec to be successful, shouldn't we take
>>>> a stand and actually specify interaction patterns?
>>>>
>>>> 4.1 - "The TA MUST NOT deliver a secondary access token to
>>>> an application for which it was not issued." seems at odds
>>>> with the rest of this section. For example, the custom
>>>> scheme approach would potentially violate this on iOS. I'm
>>>> not certain there is a reliable way not to violate this
>>>> when supporting an TA intiated flow.
>>>>
>>>> 4.2 - We should really spec out a Native App intiated flow.
>>>> It may be the only way we can reliably handle the security
>>>> contraint in section 4.1. One option could be to issue a
>>>> public key with the authorization request and then encrypt
>>>> the use JWE to responds, so if the Native app's custom
>>>> scheme url were hijacked, the returned token wouldn't bleed
>>>> to the wrong app.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 5, 2014 at 1:18 PM, Paul Madsen
>>>> <paul.madsen at gmail.com <mailto:paul.madsen at gmail.com>> wrote:
>>>>
>>>> Both core & bindings are available at
>>>>
>>>> http://hg.openid.net/napps/wiki/Home
>>>>
>>>> John has some editorial fixes to make but is hoping to
>>>> combine with those with any more normative changes
>>>>
>>>> Our next call is Wed feb 19 @ 6 pm EST
>>>>
>>>> Paul
>>>>
>>>> _______________________________________________
>>>> Openid-specs-native-apps mailing list
>>>> Openid-specs-native-apps at lists.openid.net
>>>> <mailto:Openid-specs-native-apps at lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-native-apps mailing list
>>>> Openid-specs-native-apps at lists.openid.net
>>>> <mailto:Openid-specs-native-apps at lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140213/4cc62899/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list