<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Arial">returning to NAPPS, why would the TA need a
structured scope on its request? Could it not simply designate the
relevant app in the scope and the AS interpret that to mean
'return id_token'?<br>
<br>
Or are you trying to avoid the AS having that information?<br>
<br>
paul<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/13/14, 1:24 PM, John Bradley
wrote:<br>
</div>
<blockquote
cite="mid:ADA51AE2-76BD-4A3B-999F-7AB78671C309@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
In case of Google they are passing parameters as part of scopes by
using ":" as a delimiter.
<div><br>
</div>
<div>So <span style="background-color: rgb(249, 249, 249);"><font
color="#333333" face="monospace" size="2"><span
style="line-height: 18px;">audience:server:client_id:paul123
takes paul123 as the value of the client_id for the
server audience in the id_token as I understand it.</span></font></span></div>
<div><font color="#333333" face="monospace" size="2"><span
style="line-height: 18px; background-color: rgb(249, 249,
249);"><br>
</span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="line-height: 18px; background-color: rgb(249, 249,
249);">Scope is a bit of a blunt tool so I have seen people
base64url encode json as scope values.</span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="line-height: 18px; background-color: rgb(249, 249,
249);"><br>
</span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="line-height: 18px; background-color: rgb(249, 249,
249);">Clearly that messes with any AS that treats scopes as
simple strings to do an exact string match on.</span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="line-height: 18px; background-color: rgb(249, 249,
249);"><br>
</span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;">In Connect we wanted to pass
finer grained information to the AS so that individual
claims could be requested and parameters could be sent in
the claim request.</span></span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;">We looked at overloading scope
but that was going to mess too much with existing
deployments. </span></span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;">We settled on adding
some additional paramaters to the authorization request
such as the claims parameter that is UTF-8 encoded JSON.</span></span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;"><br>
</span></span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;">If we were making a request to
the authorization endpoint we could include claims with a
value of </span></span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;">
<div>{</div>
<div> "id_token":</div>
<div> {</div>
<div> "aud": {"values": ["paul123"] }</div>
<div> }</div>
<div> }</div>
<div><br>
</div>
<div>[Note aud is an array but typically only contains a
single value.]</div>
<div><br>
</div>
<div>However the claims parameter is not currently defined
for the token endpoint. That is not to say that we
couldn't do that as an extension to downscope to
specific claims in the id_token and user_info endpoint.</div>
<div><br>
</div>
<div>John B.</div>
</span></span></font></div>
<div><font color="#333333" face="monospace" size="2"><span
style="background-color: rgb(249, 249, 249);"><span
style="line-height: 18px;"><br>
</span></span></font>
<div>
<div>On Feb 13, 2014, at 2:17 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">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> <font face="Arial">can
you give an example of what this sort of structured
scope would look like?<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/13/14, 12:09 PM, John
Bradley wrote:<br>
</div>
<blockquote
cite="mid:F08C8251-34CD-4FF8-B734-D58015144E5E@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
The example that's been deployed is Google. They are
using structured scopes to request id_tokens for
registered audiences.
<div><br>
</div>
<div>So each native app can have some number of other
client_id that it can request id_tokens for via the
scope value. </div>
<div><br>
</div>
<div>Connect is silent about how you make that request.
Connect defines that the returned id_token must have
the client that requested the token as the "azp" in
the token with the target as the "aud".</div>
<div><br>
</div>
<div>the refresh token call is unchanged, , however the
format of the scope to request a id_token with a
different audience needs to be defined.</div>
<div><br>
</div>
<div>The format of the id_token itself is defined,
though some 3rd parties may want additional claims
(like role or consent) in the id_token beyond just
the subject. That would need to preconfigured as a
start.</div>
<div><br>
</div>
<div>The assertion exchange is specified in OAuth: <a
moz-do-not-send="true"
href="http://tools.ietf.org/html/draft-ietf-oauth-assertions">http://tools.ietf.org/html/draft-ietf-oauth-assertions</a>
and <a moz-do-not-send="true"
href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer">http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer</a></div>
<div><br>
</div>
<div><br>
</div>
<div>Using AppInfo the aud for the third party would be
configured along with the token endpoint etc so there
would not be a requirement to define a structured
scope.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>On Feb 13, 2014, at 1:32 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">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> <font
face="Arial">thanks John, so the Token EP
would know to return an (appropriately
targetted) id_token rather than an access
token based on the scope?<br>
<br>
what parts remain to be spec'd out?<br>
<br>
1) the refresh call from TA is unchanged
correct?<br>
2) the returned id_token ?<br>
3) the JWT assertion exchange?<br>
<br>
paul<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/13/14, 11:19
AM, John Bradley wrote:<br>
</div>
<blockquote
cite="mid:720C6DBE-A8C3-4A09-B066-4AB9FD76904A@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<div>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.</div>
<div><br>
</div>
<div>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></div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div>This may work better if the Token Agent
is doing the exchange rather than the app.</div>
<div><br>
</div>
<div><br>
</div>
<div>For those not part of the Connect WG we
deliberately the id_token the same format as
a JWT for use in assertions. </div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<br>
<div>
<div>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:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html;
charset=ISO-8859-1"
http-equiv="Content-Type">
<div 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>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>