<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">Hi Mike, my understanding is that Connect defines
this token format and NAPPS can just leverage<br>
<br>
Earlier I asked John for the spec reference<br>
<br>
paul<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/14/14, 9:58 AM, Mike Varley wrote:<br>
</div>
<blockquote
cite="mid:D40ACA3E-E725-45E3-92A9-7FF2C3CEB946@securekey.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Great feedback from all, thanks!
<div><br>
</div>
<div>
<div>Is the next step to define an id_token format that the TE
can issue such that 3rd party TE will be able to consume? Or
is that already defined in some OAuth flow? (I haven't been
following OAuth too closely so a URL reference would be
awesome) </div>
<div><br>
</div>
<div>The implication is that 3rd party TEs would have to meet
the spec in order to interoperate… The other option is NAPPS
does not stipulate an id_token format, and the various AS/TE
implementations are left integrating to 3rd party systems;
seems like a chicken and egg problem. Is there a direction you
were thinking of moving?</div>
<div><br>
</div>
<div>It seems like we are moving in the direction of defining an
id_token format, but I just want to make sure I understand.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>MV</div>
<div><br>
<div><br>
</div>
<div><br>
<div>
<div>On Feb 13, 2014, at 4:49 PM, Paul Madsen <<a
moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"
style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width:
0px;">
<font face="Arial">hi Adam, definitely agree.<span
class="Apple-converted-space"> </span><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">
<div class="WordSection1" style="page:
WordSection1;">
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">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></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);"> </span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">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></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);"> </span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">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></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);"> </span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">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></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);"> </span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">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></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);"> </span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">FWIW.<o:p></o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);">adam<o:p></o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<span style="font-size: 11pt; font-family:
Calibri, sans-serif; color: rgb(31, 73, 125);"> </span></div>
<div>
<div style="border-style: solid none none;
border-top-color: rgb(181, 196, 223);
border-top-width: 1pt; padding: 3pt 0in 0in;">
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif;">
<b><span style="font-size: 10pt;
font-family: Tahoma, sans-serif;">From:</span></b><span
style="font-size: 10pt; font-family:
Tahoma, sans-serif;"><span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openid-specs-native-apps-bounces@lists.openid.net"
style="color: purple; text-decoration:
underline;">openid-specs-native-apps-bounces@lists.openid.net</a><span
class="Apple-converted-space"> </span>[<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:openid-specs-native-apps-bounces@lists.openid.net"
style="color: purple; text-decoration:
underline;">mailto:openid-specs-native-apps-bounces@lists.openid.net</a>]<b>On
Behalf Of<span
class="Apple-converted-space"> </span></b>Mike
Varley<br>
<b>Sent:</b><span
class="Apple-converted-space"> </span>Thursday,
February 13, 2014 2:52 PM<br>
<b>To:</b><span
class="Apple-converted-space"> </span>John
Bradley<br>
<b>Cc:</b><span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openid-specs-native-apps@lists.openid.net"
style="color: purple; text-decoration:
underline;">openid-specs-native-apps@lists.openid.net</a><br>
<b>Subject:</b><span
class="Apple-converted-space"> </span>Re:
[Openid-specs-native-apps] Please review
specs<o:p></o:p></span></div>
</div>
</div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
Hi John,<o:p></o:p></div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
Thanks,<o:p></o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
MV<o:p></o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
<div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif;">
On Feb 13, 2014, at 11:19 AM, John Bradley
<<a moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com"
style="color: purple; text-decoration:
underline;">ve7jtb@ve7jtb.com</a>>
wrote:<o:p></o:p></div>
</div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif;">
<br>
<br>
<o:p></o:p></div>
<div>
<div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
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"
style="color: purple;
text-decoration: underline;">http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html</a><o:p></o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
This may work better if the Token
Agent is doing the exchange rather
than the app.<o:p></o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
</div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
<div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
On Feb 12, 2014, at 6:20 PM, Paul
Madsen <<a moz-do-not-send="true"
href="mailto:paul.madsen@gmail.com" style="color: purple;
text-decoration: underline;">paul.madsen@gmail.com</a>>
wrote:<o:p></o:p></div>
</div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<br>
<br>
<o:p></o:p></div>
<div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<span style="font-family: Arial,
sans-serif;">guys, care to
swimlane that model out at
websequencediagrams?<br>
<br>
paul</span><o:p></o:p></div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New Roman',
serif;">
On 2/12/14, 3:52 PM, Chuck
Mortimore wrote:<o:p></o:p></div>
</div>
<blockquote style="margin-top: 5pt;
margin-bottom: 5pt;">
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New Roman',
serif;">
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></div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
-cmort<o:p></o:p></div>
</div>
</div>
<div>
<p class="MsoNormal"
style="margin: 0in 0in 12pt;
font-size: 12pt; font-family:
'Times New Roman', serif;">
<o:p> </o:p></p>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
On Wed, Feb 12, 2014 at 12:39
PM, John Bradley <<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com"
target="_blank"
style="color: purple;
text-decoration: underline;">ve7jtb@ve7jtb.com</a>>
wrote:<o:p></o:p></div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
Hi Chuck,<o:p></o:p></div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
I will get to this over
the next couple of days. <o:p></o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
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></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New
Roman', serif;">
John B.<o:p></o:p></div>
</div>
<div>
<div>
<div style="margin: 0in
0in 0.0001pt; font-size:
12pt; font-family:
'Times New Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div>
<div>
<div style="margin:
0in 0in 0.0001pt;
font-size: 12pt;
font-family: 'Times
New Roman', serif;">
On Feb 5, 2014, at
11:48 PM, Chuck
Mortimore <<a
moz-do-not-send="true"
href="mailto:cmortimore@salesforce.com" target="_blank" style="color:
purple;
text-decoration:
underline;">cmortimore@salesforce.com</a>>
wrote:<o:p></o:p></div>
</div>
<div style="margin: 0in
0in 0.0001pt;
font-size: 12pt;
font-family: 'Times
New Roman', serif;">
<br>
<br>
<o:p></o:p></div>
<div>
<div style="margin:
0in 0in 0.0001pt;
font-size: 12pt;
font-family: 'Times
New Roman', serif;">
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></div>
</div>
<div>
<p class="MsoNormal"
style="margin: 0in
0in 12pt; font-size:
12pt; font-family:
'Times New Roman',
serif;">
<o:p> </o:p></p>
<div>
<div style="margin:
0in 0in 0.0001pt;
font-size: 12pt;
font-family:
'Times New Roman',
serif;">
On Wed, Feb 5,
2014 at 3:58 PM,
Chuck Mortimore
<<a
moz-do-not-send="true"
href="mailto:cmortimore@salesforce.com" target="_blank" style="color:
purple;
text-decoration:
underline;">cmortimore@salesforce.com</a>>
wrote:<o:p></o:p></div>
<div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<b>Comments on
Agent Core 1.0</b><o:p></o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
5.0 - Do we
need to make
client
credentials
mandatory?
Can we make
this a MAY?<o:p></o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<b>Comments on
Agent API
bindings 1.0</b><o:p></o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
</div>
<div>
<p
class="MsoNormal"
style="margin:
0in 0in 12pt;
font-size: 12pt;
font-family:
'Times New
Roman', serif;">
<o:p> </o:p></p>
<div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
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"
style="color:
purple;
text-decoration:
underline;">paul.madsen@gmail.com</a>>
wrote:<o:p></o:p></div>
</div>
<blockquote
style="border-style:
none none none
solid;
border-left-color:
rgb(204, 204,
204);
border-left-width:
1pt; padding:
0in 0in 0in
6pt;
margin-left:
4.8pt;
margin-right:
0in;">
<div>
<div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<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"
style="color:
purple;
text-decoration:
underline;">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:
rgb(136, 136,
136);"><br>
<br>
Paul</span></span><o:p></o:p></div>
</div>
<div
style="margin:
0in 0in
0.0001pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
<o:p> </o:p></div>
</div>
<p
class="MsoNormal"
style="margin:
0in 0in 12pt;
font-size:
12pt;
font-family:
'Times New
Roman',
serif;">
_______________________________________________<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"
style="color:
purple;
text-decoration:
underline;">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" style="color: purple; text-decoration: underline;">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><o:p></o:p></p>
</blockquote>
</div>
<div
style="margin:
0in 0in
0.0001pt;
font-size: 12pt;
font-family:
'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
</div>
<div style="margin:
0in 0in 0.0001pt;
font-size: 12pt;
font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
<div style="margin: 0in
0in 0.0001pt;
font-size: 12pt;
font-family: 'Times
New Roman', serif;">
_______________________________________________<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"
style="color:
purple;
text-decoration:
underline;">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"
style="color:
purple;
text-decoration:
underline;">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><o:p></o:p></div>
</div>
<div style="margin: 0in
0in 0.0001pt; font-size:
12pt; font-family:
'Times New Roman',
serif;">
<o:p> </o:p></div>
</div>
</div>
</div>
</div>
<div style="margin: 0in 0in
0.0001pt; font-size: 12pt;
font-family: 'Times New Roman',
serif;">
<o:p> </o:p></div>
</div>
</blockquote>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times
New Roman', serif;">
<o:p> </o:p></div>
</div>
</div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif;">
<o:p> </o:p></div>
</div>
</div>
<div style="margin: 0in 0in 0.0001pt;
font-size: 12pt; font-family: 'Times New
Roman', serif;">
<NAPPS access to 3rd party based on JWT
assertion..svg><smime.p7s><o:p></o:p></div>
</div>
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;">
<o:p> </o:p></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-native-apps mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-native-apps@lists.openid.net" style="color: purple; text-decoration: underline;">Openid-specs-native-apps@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" style="color: purple; text-decoration: underline;">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
<br>
</div>
<br class="Apple-interchange-newline">
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>