<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br><div><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">The token format for accepting a id_token as a JWT assertion is defined in OAuth <a href="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07">http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07</a> and JWT itself <div><br></div><div>We aligned the claim names between the id_token and the JWT assertion so that they are the same. (there were originally differences) The goal was to allow a Connect issued id_token to be directly used as an assertion, given that the recipient recognizes a valid audience for itself in the id_token.</div><div><br></div><div>We didn't want to scare readers of the core spec with advanced OAuth 2 federation issues. </div><div><br></div><div>The goal was to align with JWT bearer assertions and leave the extension points.</div><div><br></div><div>In principal you don't need to use the "refesh_token" grant type you can use the existing Authorization syntax to to some interesting things.</div><div><br></div><div>In the authorization request a client called "123" can add the claims parameter to it's request with the value.</div><div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249);">{</div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249);"> "id_token":</div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249);"> {</div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249); position: static; z-index: auto;"> "aud": {"values": ["123","<a href="https://example.com/token]">https://example.com/token]</a> }</div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249); position: static; z-index: auto;"> "scope" : {"values" : ["photo-r" , "calendar-rw"] </div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249);"> }</div><div style="color: rgb(51, 51, 51); font-family: monospace; font-size: small; line-height: 18px; background-color: rgb(249, 249, 249); position: static; z-index: auto;"> }</div></div><div><br></div><div>If the AS allows client "123" to request id_tokens that are also valid for it's associated backend "<a href="https://example.com/token">https://example.com/token</a>" perhaps through pre registration then it would get back a id_token with "aud": ["123", "<a href="https://example.com/token">https://example.com/token</a>"] and "azp": "123".</div><div><br></div><div>The client may also have asked the user to consent to particular scopes using my totally made up scope claim that the initial AS prompts the user to agree to via some dialog like:</div><div>The client "123-registerd friendly name" is requesting read access to you photos and read write access to your calendar at "<a href="https://example.com/token-registerd">https://example.com/token-registerd</a> friendly name".</div><div><br></div><div>The returned id_token could be exchanged via the assertion profile at <a href="https://example.com/token">https://example.com/token</a> without needing to be a registered client with that AS.</div><div><br></div><div><br></div><div>At the moment the typical way this is done is to have the client get a client_id from "<a href="https://example.com/token">https://example.com/token</a>" then perform a authorization request to it's AS where that AS would then do the Connect authentication flow back to the home AS and get a id_token directly. It would then prompt for authorization for the API and return the Tokens to the client directly.</div><div><br></div><div>The advantage of doing it in the backchannel is that it gives the home AS much more control and audibility. There likely needs to be some sort of relationship between the 3rd party API and the home AS if it is going to be collecting consent. In some ways this is similar to UMA, though compatible as I have sketched it out.</div><div><br></div><div>Assuming the 3rd party access tokens are short lived the Enterprise home AS can simply stop issuing id_tokens if the user looses access to to a SaaS resource and the client can no longer exchange them for access tokens . Doing it the front channel way the user needs to go through a bunch of web redirects every time they use the SaaS which is less likely to happen on a regular basis. </div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Feb 14, 2014, at 11:58 AM, Mike Varley <<a href="mailto:mike.varley@securekey.com">mike.varley@securekey.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
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 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 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 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 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 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 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>
</div>
</blockquote></div><br></div></div></div></div><br></body></html>