<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">guys, care to swimlane that model out at
websequencediagrams?<br>
<br>
paul<br>
</font>
<div class="moz-cite-prefix">On 2/12/14, 3:52 PM, Chuck Mortimore
wrote:<br>
</div>
<blockquote
cite="mid:CA+wnMn99U-vONCOJQRy+EMtk27bQug0_LV0jWuVvWzHx25r-VQ@mail.gmail.com"
type="cite">
<div dir="ltr">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
<div>
<br>
</div>
<div>-cmort</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 12, 2014 at 12:39 PM, John
Bradley <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi Chuck,
<div><br>
</div>
<div>I will get to this over the next couple of days. </div>
<div>
<br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So I suppose the type of token would depend on if the
app directly accepted access tokens from the AS of the
napps agent.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>John B.</div>
<div>
<div class="h5">
<div><br>
</div>
<div>
<div>
<div>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:</div>
<br>
<blockquote type="cite">
<div dir="ltr">One other thought - Perhaps
instead of opaque access tokens for the apps,
we should issue id_tokens that are audience
restricted </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Wed, Feb 5, 2014 at 3:58 PM, Chuck
Mortimore <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:cmortimore@salesforce.com"
target="_blank">cmortimore@salesforce.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><b>Comments on Agent Core 1.0</b></div>
<div><br>
</div>
<div>5.0 - Do we need to make client
credentials mandatory? Can we make
this a MAY?</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>7.1.1 - Why is response_type=code
MUST? Is this oauth carry over?
(same as my question on 5.0 I think)</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div><br>
</div>
<div><b>Comments on Agent API bindings
1.0</b></div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>
<div>On Wed, Feb 5, 2014 at 1:18 PM,
Paul Madsen <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com"
target="_blank">paul.madsen@gmail.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>
<div bgcolor="#FFFFFF"
text="#000000"> <font
face="Arial">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><font
color="#888888"><br>
<br>
Paul<br>
</font></span></font> </div>
<br>
</div>
</div>
_______________________________________________<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><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
_______________________________________________<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><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>