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

[Paul Madsen]

John, can you point me to the relevant piece of Connect that enables 
these 3rd party id_tokens?

thanks

paul
On 2/12/14, 3:39 PM, John Bradley 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/20140214/178f6324/attachment.html>