<html><body><span style="font-family:Verdana; color:#000; font-size:10pt;"><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);">Comments below.</span><br></div><blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;" mce_style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;"><div id="wmQuoteWrapper"><div><blockquote type="cite" style="border-left: blue 2px solid; margin-left: 8px; padding-left: 8px;" mce_style="border-left: blue 2px solid; margin-left: 8px; padding-left: 8px;"><div id="wmQuoteWrapper"><blockquote cite="mid:526554F9.1030406@aol.com" type="cite"><blockquote cite="mid:4E1F6AAD24975D4BA5B168042967394377E08131@TK5EX14MBXC286.redmond.corp.microsoft.com" type="cite"><div class="WordSection1" style="page: WordSection1; " mce_style="page: WordSection1; "><div class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.5in; font-size:12pt;; font-family: Calibri, sans-serif; " mce_style="margin: 0in 0in 0.0001pt 0.5in; font-size:12pt;; font-family: Calibri, sans-serif; "><br>"When using this flow, the redirection URI MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0; otherwise, it MUST use the https scheme" - This, surprisingly enough, is relaxed in comparison to<a target="_blank" moz-do-not-send="true" href="http://tools.ietf.org/html/rfc6749#section-10.5" mce_href="http://tools.ietf.org/html/rfc6749#section-10.5" style="color: purple; text-decoration: underline; " mce_style="color: purple; text-decoration: underline; ">http://tools.ietf.org/html/rfc6749#section-10.5</a>.<br><br>RFC 6749 states: "Authorization codes operate as plaintext bearer credentials, used to verify that the resource owner who granted authorization at the authorization server is the same resource owner returning to the client to complete the process. Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require the use of TLS."<br><br>Why is Connect, in this particular case, less restrictive than OAuth?<span mce_style="color: #1f497d;" style="color: rgb(31, 73, 125); "><o:p></o:p></span></div><div class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size:12pt;; font-family: Calibri, sans-serif; " mce_style="margin: 0in 0in 0.0001pt; font-size:12pt;; font-family: Calibri, sans-serif; "><span mce_style="color: #1f497d;" style="color: rgb(31, 73, 125); "> </span></div><div class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size:12pt;; font-family: Calibri, sans-serif; " mce_style="margin: 0in 0in 0.0001pt; font-size:12pt;; font-family: Calibri, sans-serif; "><span mce_style="color: #1f497d;" style="color: rgb(31, 73, 125); ">John, can you speak to why we’re allowing http redirect_uri values when apparently OAuth doesn’t?</span></div></div></blockquote>I had some questions on this point as well. I believe the thinking is that since the client is protecting the secret and the code is sent to the /token endpoint with client authentication, even if someone was able to hijack the code value they couldn't exchange it for the access (and possibly refresh) tokens. If we are trying to make things simpler, then just moving all of it to TLS makes sense. To me, the only exception is localhost.<span class="Apple-converted-space"> </span><br></blockquote><br>The attacker could inject the authorization code into the same application as used by the victim in order to impersonate her/him.</div><div><br><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255); ">For this to happen the attacker should also have gained control over the RP (the application), i.e. have the RPs' authentication credentials.</span><br><blockquote cite="mid:526554F9.1030406@aol.com" type="cite"><blockquote cite="mid:4E1F6AAD24975D4BA5B168042967394377E08131@TK5EX14MBXC286.redmond.corp.microsoft.com" type="cite"><div class="WordSection1"><div class="MsoNormal" style="font-family: verdana; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size:12pt;; " mce_style="font-family: verdana; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size:12pt;; "><span mce_style="color: #1f497d;" style="color: rgb(31, 73, 125); "><o:p></o:p></span></div><br class="Apple-interchange-newline"></div></blockquote></blockquote></div></blockquote></div><br><div>Early OAuth 2 inherited the idea from OAuth 1 that the client didn't need to have a TLS cert. We were matching that. At the IIW F2F we took a decision that we should match the RFC and require the client to have a TLS endpoint if using a http redirect.(not a custom scheme)</div><div><br></div><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);">I went back to RFC 6749 and there I found the following:</span></div><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);"><br></span></div><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);"><a href="http://tools.ietf.org/html/rfc6749#section-3.1.2.1">http://tools.ietf.org/html/rfc6749#section-3.1.2.1</a><br></span></div><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);"><br></span></div><div><pre class="newpage"><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);"><span class="h5"><h5><a class="selflink" name="section-3.1.2.1" href="http://tools.ietf.org/html/rfc6749#section-3.1.2.1" mce_href="http://tools.ietf.org/html/rfc6749#section-3.1.2.1">3.1.2.1</a>. [Redirection] Endpoint Request Confidentiality</h5></span></span><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);">
The redirection endpoint <b>SHOULD</b> require the use of TLS as described
in <a href="http://tools.ietf.org/html/rfc6749#section-1.6" mce_href="http://tools.ietf.org/html/rfc6749#section-1.6">Section 1.6</a> when the requested response type is "code" or "token",
or when the redirection request will result in the transmission of
sensitive credentials over an open network. This specification does
not mandate the use of TLS because at the time of this writing,
requiring clients to deploy TLS is a significant hurdle for many
client developers. If TLS is not available, the authorization server
<b>SHOULD</b> warn the resource owner about the insecure endpoint prior to
redirection (e.g., display a message during the authorization
request).</span></pre></div><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);">So with that the current OIDC spec seems to be in line with the OAuth 2.0 RFC.</span></div><div><br></div><div><span mce_style="color: #ff00ff;" style="color: rgb(255, 0, 255);">There are many websites, e.g. hosted blogs, that would not be able to use OIDC if TLS is made mandatory for clients. I think we should not forget about those use cases.</span><br></div><div><br></div></div>
</blockquote></span></body></html>