[Openid-specs-native-apps] Please review specs
Paul Madsen
paul.madsen at gmail.com
Thu Feb 13 17:17:43 UTC 2014
can you give an example of what this sort of structured scope would look
like?
On 2/13/14, 12:09 PM, John Bradley wrote:
> The example that's been deployed is Google. They are using structured
> scopes to request id_tokens for registered audiences.
>
> So each native app can have some number of other client_id that it can
> request id_tokens for via the scope value.
>
> Connect is silent about how you make that request. Connect defines
> that the returned id_token must have the client that requested the
> token as the "azp" in the token with the target as the "aud".
>
> the refresh token call is unchanged, , however the format of the scope
> to request a id_token with a different audience needs to be defined.
>
> The format of the id_token itself is defined, though some 3rd parties
> may want additional claims (like role or consent) in the id_token
> beyond just the subject. That would need to preconfigured as a start.
>
> The assertion exchange is specified in OAuth:
> http://tools.ietf.org/html/draft-ietf-oauth-assertions and
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
>
>
> Using AppInfo the aud for the third party would be configured along
> with the token endpoint etc so there would not be a requirement to
> define a structured scope.
>
> John B.
>
>
> On Feb 13, 2014, at 1:32 PM, Paul Madsen <paul.madsen at gmail.com
> <mailto:paul.madsen at gmail.com>> wrote:
>
>> 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/3dbf02ea/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list