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

[Chuck Mortimore]

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>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> 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
>> 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/20140205/6dcc3b5c/attachment.html>