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

Paul Madsen paul.madsen at gmail.com
Fri Feb 21 16:10:05 UTC 2014


hey Chuck, given questions below, would you be interested/available to 
write down some consent use cases to help us tease out requirements (you 
see not being met as currently described)

For instance, what are consent implications of a new app being added to 
the 'authz list' for an employee but not installed on device? Or vice 
versa? etc

What about when an app gets removed from authz list? Or device? etc

paul

On 2/5/14, 6:58 PM, Chuck Mortimore 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140221/244dceee/attachment.html>


More information about the Openid-specs-native-apps mailing list