[Openid-specs-native-apps] Please review specs

Wed Feb 12 21:20:16 UTC 2014

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/20140212/09b99b07/attachment-0001.html>