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

Paul Madsen paul.madsen at gmail.com
Fri Feb 14 15:06:56 UTC 2014


Hi Mike, my understanding is that Connect defines this token format and 
NAPPS can just leverage

Earlier I asked John for the spec reference

paul

On 2/14/14, 9:58 AM, Mike Varley wrote:
> Great feedback from all, thanks!
>
> Is the next step to define an id_token format that the TE can issue 
> such that 3rd party TE will be able to consume? Or is that already 
> defined in some OAuth flow? (I haven't been following OAuth too 
> closely so a URL reference would be awesome)
>
> The implication is that 3rd party TEs would have to meet the spec in 
> order to interoperate… The other option is NAPPS does not stipulate an 
> id_token format, and the various AS/TE implementations are left 
> integrating to 3rd party systems; seems like a chicken and egg 
> problem. Is there a direction you were thinking of moving?
>
> It seems like we are moving in the direction of defining an id_token 
> format, but I just want to make sure I understand.
>
> Thanks,
>
> MV
>
>
>
> On Feb 13, 2014, at 4:49 PM, Paul Madsen <paul.madsen at gmail.com 
> <mailto:paul.madsen at gmail.com>> wrote:
>
>> hi Adam, definitely agree.
>>
>> Adding NAPPS support should have minimal impact on existing apps 
>> (both the RS & native components) if we hope to see SaaS adoption 
>> (enter Chuck stage left)
>>
>> Guaranteeing a SaaS RS that it will continue to see/validate tokens 
>> only from its own local AS would be key
>>
>> paul
>>
>> On 2/13/14, 4:02 PM, Lewis Adam-CAL022 wrote:
>>> Hi all … glad to see so much activity on this list starting to take 
>>> place, this is work I’ve been looking forward to seeing matured for 
>>> some time now!
>>> As some of you know, we have implemented a token agent very much in 
>>> the same spirit of the work going on here, and went through many of 
>>> the same design choices.  Certainly having the Token Endpoint in 
>>> domain 1 issue an access_token for an RS in domain 2 is a simple 
>>> architectural model, especially since JWT is an assertion that can 
>>> cross security domains (we carefully considered this option).
>>> However, we opted for the other solution which utilized the 
>>> assertion profile grant that the OAuth WG is defining for a number 
>>> of reasons.  Namely, it follows the best known OAuth pattern that a 
>>> single AS protects the APIs exposed by the RS’s.  An AS from domain 
>>> 1 is unlikely to know what scopes are required in an access_token 
>>> meant to be consumed by an RS in domain 2.
>>> I suppose that sending the id_token to the RS and giving the RS a 
>>> choice to consume that token, or exchange it itself by sending it to 
>>> its own Token Endpoint would also be a viable option, but another 
>>> reason we tokenized all our Resource Servers was to simplify the 
>>> number of authentication methods they needed to support, taking it 
>>> down to just 1 (e.g. consume the access token generated by its own AS).
>>> OAuth was designed to get clients out of asking for passwords, but 
>>> my real interest in it was to get the RS out of needing to know a 
>>> password, and being able to abstract primary auth from secondary auth.
>>> FWIW.
>>> adam
>>> *From:*openid-specs-native-apps-bounces at lists.openid.net[mailto:openid-specs-native-apps-bounces at lists.openid.net]*On 
>>> Behalf Of*Mike Varley
>>> *Sent:*Thursday, February 13, 2014 2:52 PM
>>> *To:*John Bradley
>>> *Cc:*openid-specs-native-apps at lists.openid.net
>>> *Subject:*Re: [Openid-specs-native-apps] Please review specs
>>> Hi John,
>>> Are you saying (in the picture you provided) would (could) the call 
>>> to the 3rd party TE be optional?  i.e., the TE could return an 
>>> id_token targeted to the 3rd party API, that acts as an access token?
>>> Thanks,
>>> MV
>>> On Feb 13, 2014, at 11:19 AM, John Bradley <ve7jtb at ve7jtb.com 
>>> <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>
>>>
>>> This shows using the token endpoint to side-scope a refresh token to 
>>> get a id_token with a 3rd party audience using the Google Play 
>>> example, then using the JWT assertion flow to exchange the id_token 
>>> for a access token.
>>> This is the Google developer spec for the Play Method 
>>> http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html
>>> They don't have there Token Agent do the swap for a access token, 
>>> they are handing the id_token to the app and letting it use it as an 
>>> access token or exchange it in some way.
>>> The other possibility may be to have the Appinfo endpoint return the 
>>> id_token along with meta-data about what 3rd party Token endpoint 
>>> needs to be used to exchange the id_token/JWT assertion.
>>> This may work better if the Token Agent is doing the exchange rather 
>>> than the app.
>>> For those not part of the Connect WG we deliberately the id_token 
>>> the same format as a JWT for use in assertions.
>>> On Feb 12, 2014, at 6:20 PM, Paul Madsen <paul.madsen at gmail.com 
>>> <mailto: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 <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
>>>
>>> <NAPPS access to 3rd party based on JWT assertion..svg><smime.p7s>
>>>
>>>
>>> _______________________________________________
>>> 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/20140214/333f58dc/attachment-0001.html>


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