<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">hey Chuck, given questions below, would you be
interested/available to write down some consent use cases to help
us tease out requirements (you see not being met as currently
described)<br>
<br>
For instance, what are consent implications of a new app being
added to the 'authz list' for an employee but not installed on
device? Or vice versa? etc<br>
<br>
What about when an app gets removed from authz list? Or device?
etc<br>
<br>
paul<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/5/14, 6:58 PM, Chuck Mortimore
wrote:<br>
</div>
<blockquote
cite="mid:CA+wnMn9FGDzjPgpLbBD9+ZmdrMjkkOWaZi+zXOt8PAQO=mNyaQ@mail.gmail.com"
type="cite">
<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">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>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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
class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></font> </div>
<br>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-native-apps@lists.openid.net">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>
<br>
</body>
</html>