<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;">
I pulled this from the OAuth 2.0 Multiple Response Types spec:
<div><br>
</div>
<div>(in case others haven't seen it)</div>
<div><br>
</div>
<div>---</div>
<div>none<br>
When supplied as the response_type parameter in an OAuth 2.0 Authorization Request, the Authorization Server SHOULD NOT return an OAuth 2.0 Authorization Code, Access Token, Access Token Type, or ID Token in a successful response to the grant request. If a redirect_uri is
 supplied, the User Agent SHOULD be redirected there after granting or denying access. The request MAY include a state parameter, and if so, the Authorization Server MUST echo its value as a response parameter when issuing either a successful response or an
 error response. The default Response Mode for this Response Type is the query encoding. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.<br>
---</div>
<div><br>
</div>
<div>So it is (now) clear (to me) that the state would have to be maintained by AS2 linking the consent via the SSO token and the access token grant request with the id_token.</div>
<div><br>
</div>
<div>This doesn't seem to reduce the number of round trips, however (i.e., what is the advantage of using the 'none' response_type?)</div>
<div><br>
</div>
<div>MV</div>
<div><br>
</div>
<div> </div>
<div><br>
<div>
<div>On Apr 9, 2014, at 8:34 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">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
This is what I understood the proposal to be - but I don't understand how the browser getting nothing provides the TA with any assurance it can request an AT from AS2.
<div><br>
</div>
<div>If the IT was passed to AS2 during consent, then I suppose AS2 could keep some internal state as to the consent granted when an access token is requested…  </div>
<div><br>
</div>
<div>MV<br>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 8, 2014, at 4:14 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"><font face="Arial">for comparison, John's proposed model<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVCwgSVQALQcAXAYAMwVCb290c3RyYXAoQVQpCgB1BwAwBmJvbwAVBVVSTABmBgCBVQcAFQUALwYAFgUAgWwHAIEFBwAODgB-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXIgACkFdmFsaWRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent">http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVCwgSVQALQcAXAYAMwVCb290c3RyYXAoQVQpCgB1BwAwBmJvbwAVBVVSTABmBgCBVQcAFQUALwYAFgUAgWwHAIEFBwAODgB-BQAvCXJlZGlyZWN0IHRvIEFTMihzY29wZSArIFNTTyB0b2tlbikAQQ0yOgCBTAV6cmVxdWVzdAApBisAIQxub3RlIG92ZXI!
 gACkFdmFsa WRhdGUARwoKCkFTMgCBLwtjb25zZW4ARAcpPwBfEHllcwAiEHJldHVybiBub3RoaW5nAIFjC1RBOgANCQCDBAYyOiBleGNoYW5nZSBJVAB0BlRBOiBBAIJxB04ABgZOQS0-UlMyOiBSRVNUIGNhbGwgAIJ4BQoKCgoKAAEF&s=patent</a><br>
<br>
</font>
<div class="moz-cite-prefix">On 4/8/14, 3:49 PM, John Bradley wrote:<br>
</div>
<blockquote cite="mid:EFDEFAB2-9E37-4EFF-AD21-90EE225DA5EF@ve7jtb.com" type="cite">
<meta http-equiv="Context-Type" content="text/html;
        charset=iso-8859-1">
I was thinking of using the response_type=none for the outh flow to AS2 simply to collect consent.
<div><br>
</div>
<div>The JWT or SAML assertion flow would be used to get the access token from AS2.   The downside is that AS2 needs to support the assertion flow but the upside is that AS1 has the ability to revoke access without going thorough web redirects each time the
 AT needs to be refreshed.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 8, 2014, at 1:35 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>I think this wsd describes John's model<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVAApBwBYBgAvBUJvb3RzdHJhcChBVCkKAHEHACwGYm9vABUFVVJMAGIGAIFRBwAVBQAvBgAWBQCBaAcAgQEHAA4OAHoFAC8JcmVkaXJlY3QgdG8gQVMyKHNjb3BlICsgU1NPIHRva2VuKQBBDTI6AIFIBXpyZXF1ZXN0ACkGKwAhDG5vdGUgb3ZlciAAKQV2YWxpZGF0ZQBHCgoKQVMyAIEvC2NvbnNlbgBEByk_AF8QeWVzACIQcmV0dXJuIGNvZGUgAIFhC1RBOgAPBQCCegcyOiBleGNoYW5nZQARBgByBVRBOiBhY2Nlc3MAgQYIVEEtPk4ABhBOQS0-UlM6IFJFU1QgY2FsbCAoACoMKQoKCgoKCgABBQ&s=patent">http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDU4AAQ5BUzEAAg5wcEluZm8AFQ8yAEUNUlMyCgoKVEEtPkFTMTogZ2V0IHVzZXIgYXV0aGVudGljYXRlZApBUzEtPlRBOiBSVCxBVAApBwBYBgAvBUJvb3RzdHJhcChBVCkKAHEHACwGYm9vABUFVVJMAGIGAIFRBwAVBQAvBgAWBQCBaAcAgQEHAA4OAHoFAC8JcmVkaXJlY3QgdG8gQVMyKHNjb3BlICsgU1NPIHRva2VuKQBBDTI6AIFIBXpyZXF1ZXN0ACkGKwAhDG5vdGUgb3ZlciAAKQV2YWx
 pZGF0ZQBHCgoKQVMyAIEvC2NvbnNlbgBEByk_AF8QeWVzACIQcmV0dXJuIGNvZGUgAIFhC1RBOgAPBQCCegcyOiBleGNoYW5nZQARBgByBVRBOiBhY2Nlc3MAgQYIVEEtPk4ABhBOQS0-UlM6IFJFU1QgY2FsbCAoACoMKQoKCgoKCgABBQ&s=patent</a><br>
<br>
Question - in the step that John refers to as 'trigger the IdP initiated login via Connect or SAML' - what support is there for an authenticated authz request?<br>
<br>
Distinct from how the browser gets sent to AS2 is what AS2 returns - in this case a code, and the TA exchanges that code for the desired AT ( to be handed to the native app)<br>
<br>
John was advocating a different model<br>
<br>
paul<br>
<br>
<div class="moz-cite-prefix">On 4/8/14, 2:46 PM, John Bradley wrote:<br>
</div>
<blockquote cite="mid:18BF96E6-66B3-4811-9718-C24D4273709B@ve7jtb.com" type="cite">
For bootstrapping a web session in SAML as an example you could directly create a IdP initiated login URI + post body and have the browser send that to the third party AS directly.
<div>I think that is more problematic from a security perspective as there is no way for the home AS to say compare the ip address of the browser with the ip address of the TA or make use of other authentication factors.</div>
<div><br>
</div>
<div>Logically I prefer to have the TA bootstrap the browser to itself and from there trigger the IdP initiated login via Connect or SAML.   That is the only way you can do a IdP initiated login with connect, otherwise the user needs to authenticate to there
 home AS in the browser somewhat defeating the point.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>On Apr 8, 2014, at 12:36 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>hi Mike, inline<br>
<br>
paul<br>
<br>
<div class="moz-cite-prefix">On 4/7/14, 9:19 AM, Mike Varley wrote:<br>
</div>
<blockquote cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com" type="cite">
A couple comments/questions:
<div>1) what is the 'API' endpoint the bootstrap URL request is going to? Is this the RS?</div>
</blockquote>
would be the AppInfo endpoint (hosted by AS1) that the NAPPS spec describes<br>
<br>
To obtain application metadata information, the <em>TA</em> MAY make a GET or POST request to the AppInfo Endpoint.<br>
<br>
<br>
<blockquote cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com" type="cite">
<div>2) Seems like a lot of round-trips. On mobile, performance will suffer</div>
</blockquote>
if the round trips are performed only for gathering consent ....<br>
<blockquote cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com" type="cite">
<div>3) how does consent from the browser result in an AT to the App?</div>
</blockquote>
<br>
John proposed a model where<br>
<br>
1) the TA is delivered an id_token targeted at AS2<br>
2) the user agent is sent to AS2 for consent<br>
3) once consent is obtained, the TA exchanges the id_token for an AT <br>
4) TA hands AT to app<br>
<br>
<blockquote cite="mid:78F7F7C2-7C13-43C2-9984-0AF8743358C4@securekey.com" type="cite">
<div><br>
</div>
<div>MV</div>
<div><br>
<div>
<div>On Apr 4, 2014, at 5:53 PM, John Bradley <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="auto">
<div>If the target of the SAML IdP initiated login is the OAuth authorization Uri we shouldn't need extra attributes in the SAML assertion. <br>
<br>
Sent from my iPhone</div>
<div><br>
On Apr 4, 2014, at 3:16 PM, Paul Madsen <<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">I dont think we should preclude IdP-init SAML into the AS2 consent page - for those SaaS currently set up as SAML SPs & OAuth AS<br>
<br>
implying us defining a scope param on the SAML Response?<br>
<br>
<br>
<div class="moz-cite-prefix">On 4/4/14, 2:16 PM, John Bradley wrote:<br>
</div>
<blockquote cite="mid:0B8F5110-CD04-4ACC-8E1F-D2B03B3E5AE1@ve7jtb.com" type="cite">
Yes.
<div><br>
</div>
<div>There are two options I can think of for the last step of AS2 collecting consent.</div>
<div><br>
</div>
<div>The request can have a response_type of code and the TA gets back a code that it can use to get a AT from the AS2 token endpoint.   </div>
<div><br>
</div>
<div>The other would be to make the call to AS2 with a response-type of "none" just to collect consent, getting back nothing.</div>
<div>The TA would then use the JWT assertion flow to exchange a JWT for the access token.</div>
<div><br>
</div>
<div>I think the second option is more secure and allows a JWT issued by AS1 to be used instead of a refresh token issued by AS2.  The advantage is that AS1 has the ability to revoke access to the resource without needing a separate API to AS2.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Apr 4, 2014, at 2:00 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>John, something like <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent">http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent</a><br>
<br>
<br>
<div class="moz-cite-prefix">On 4/4/14, 1:42 PM, John Bradley wrote:<br>
</div>
<blockquote cite="mid:50B3AAE5-5023-422A-B5B4-061B0FA1690A@ve7jtb.com" type="cite">
I was thinking of a bootstrap URL that trigged idP initiated login at AS2.  That way the bootstrap URI is essentially opaque as it is both specified and consumed by the IsP/AS of the TA.
<div><br>
</div>
<div><br>
<div>
<div>On Apr 4, 2014, at 1:26 PM, Chuck Mortimore <<a moz-do-not-send="true" href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Sounds similar, yes, although working out a boostrap URL across different ASs might be quite difficult in practice</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Apr 4, 2014 at 10:25 AM, Paul Madsen <span dir="ltr">
<<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote">
<div>hey Chuck, you write <br>
<br>
'If the TA were to simply use it's primary token to initialize an OAuth authorization request for the scope of the requesting native app, we could simplify this whole thing.  '<br>
<br>
John had (in this thread) previously proposed something similar <br>
<br>
'If we have a web app bootstrap AS1 could give a bootstrap URI to the App that would create a authenticated session at AS2 for the user to do the normal OAuth consent flow.'<br>
<br>
I believe John's model accomplishes the same thing as your proposal, ie delivers the user's browser (in an authenticated state) to an AS where consent can be gathered - albeit perhaps with more steps<span class="HOEnZb"><br>
<br>
paul<br>
<br>
</span>
<div>
<div class="h5">
<div>On 4/2/14, 5:49 PM, Chuck Mortimore wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>We don't think there should at all be an "implied consent" model (i.e., authentication at the AS authorizes the App for whatever it needs).    This sound quite dangerous, and don't believe this would at all be suitable for a tightly controlled enterprise
 environment.    We do support models that "feel" like this, but consent really isn't implicit...It's simply isn't controlled or visilbe to the the user.   We always run the request through an authorization check, and it is not at all coupled to authentication.
   Picture us checking a role on the AS.</div>
<div><br>
</div>
<div>As far JIT consent model, it's a bit harder to achieve when using the Token Endpoint, unless we explicitly specify the TA is collecting consent, what to collect, etc.  Standardizing a consent UI strikes me as very difficult.</div>
<div><br>
</div>
<div>The way we've balanced the two in our environment is to always perform consent on the authorization endpoint.   Based on the configuration of the app, we're either checking server side admin defined consent, or prompting the user.   </div>
<div><br>
</div>
<div>It's possible we could continue to use this model in NAPPS - if we consider the real difficult issue for users is actually authenticating, then authorization is really not a big deal.   If the TA were to simply use it's primary token to initialize an OAuth
 authorization request for the scope of the requesting native app, we could simplify this whole thing.   </div>
<div><br>
</div>
<div>-cmort</div>
</div>
<div class="gmail_extra"><br>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>