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

[Chuck Mortimore]

Will do.

-cmort


On Wed, Feb 12, 2014 at 1:20 PM, Paul Madsen <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> 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>
>> 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> 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
>>>>
>>>>
>>>
>>  _______________________________________________
>> 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/20140212/34af13c1/attachment.html>