<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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 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></body></html>