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

Thu Feb 13 21:49:15 UTC 2014

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/20140213/38277bcb/attachment-0001.html>