<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">hi Adam, definitely agree. <br>
<br>
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)<br>
<br>
Guaranteeing a SaaS RS that it will continue to see/validate
tokens only from its own local AS would be key<br>
<br>
paul<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/13/14, 4:02 PM, Lewis Adam-CAL022
wrote:<br>
</div>
<blockquote
cite="mid:5a201a87da7f429db3cafd6e66db82f6@DM2PR04MB735.namprd04.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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]-->
<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"">
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-native-apps-bounces@lists.openid.net">openid-specs-native-apps-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-native-apps-bounces@lists.openid.net">mailto:openid-specs-native-apps-bounces@lists.openid.net</a>]
<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> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-native-apps@lists.openid.net">openid-specs-native-apps@lists.openid.net</a><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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-native-apps@lists.openid.net"
target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-native-apps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
<br>
</body>
</html>