<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">FWIW.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> openid-specs-native-apps-bounces@lists.openid.net [mailto:openid-specs-native-apps-bounces@lists.openid.net]
<b>On Behalf Of </b>Mike Varley<br>
<b>Sent:</b> Thursday, February 13, 2014 2:52 PM<br>
<b>To:</b> John Bradley<br>
<b>Cc:</b> openid-specs-native-apps@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-native-apps] Please review specs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi John, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">MV<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Feb 13, 2014, at 11:19 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is the Google developer spec for the Play Method <a href="http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html">http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This may work better if the Token Agent is doing the exchange rather than the app.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For those not part of the Connect WG we deliberately the id_token the same format as a JWT for use in assertions. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Feb 12, 2014, at 6:20 PM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">guys, care to swimlane that model out at websequencediagrams?<br>
<br>
paul</span><o:p></o:p></p>
<div>
<p class="MsoNormal">On 2/12/14, 3:52 PM, Chuck Mortimore wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">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 <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-cmort<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Feb 12, 2014 at 12:39 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Hi Chuck, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I will get to this over the next couple of days. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So I suppose the type of token would depend on if the app directly accepted access tokens from the AS of the napps agent.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On Feb 5, 2014, at 11:48 PM, Chuck Mortimore <<a href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">One other thought - Perhaps instead of opaque access tokens for the apps, we should issue id_tokens that are audience restricted <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Feb 5, 2014 at 3:58 PM, Chuck Mortimore <<a href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><b>Comments on Agent Core 1.0</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">5.0 - Do we need to make client credentials mandatory? Can we make this a MAY?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">7.1.1 - Why is response_type=code MUST? Is this oauth carry over? (same as my question on 5.0 I think)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><b>Comments on Agent API bindings 1.0</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Wed, Feb 5, 2014 at 1:18 PM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Both core & bindings are available at<br>
<br>
<a href="http://hg.openid.net/napps/wiki/Home" target="_blank">http://hg.openid.net/napps/wiki/Home</a><br>
<br>
John has some editorial fixes to make but is hoping to combine with those with any more normative changes<br>
<br>
Our next call is Wed feb 19 @ 6 pm EST<span style="color:#888888"><br>
<br>
Paul</span></span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><NAPPS access to 3rd party based on JWT assertion..svg><smime.p7s><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>