158154OpenID Authentication1.11575712008-06-17T07:40:45Zhttp://openid.springnote.com/pages/1581542007-04-19T15:46:01Z<p>(스펙 원본: <a href="http://openid.net/specs/openid-authentication-1_1.html%29" title="http://openid.net/specs/openid-authentication-1_1.html)" class="external">http://openid.net/specs/openid-authentication-1_1.html)</a></p>
<p>(번역판 배포 위치: <a href="http://openid.co.kr/specs/openid-authentication-1_1.html%29" title="http://openid.co.kr/specs/openid-authentication-1_1.html)" class="external">http://openid.co.kr/specs/openid-authentication-1_1.html)</a></p>
<p>(번역에 대한 의견을 남겨주세요: <a href="http://openid.or.kr/43" title="http://openid.or.kr/43" class="external">http://openid.or.kr/43</a> )</p>
<table width="100%">
<tbody>
<tr>
<td class="header"></td>
<td class="header">
<p>D. Recordon</p>
</td>
</tr>
<tr>
<td class="header"></td>
<td class="header">
<p>B. Fitzpatrick</p>
</td>
</tr>
<tr>
<td class="header"></td>
<td class="header">
<p>May 2006</p>
</td>
</tr>
</tbody>
</table>
<p> </p>
<div style="TEXT-ALIGN: right"><span class="title">OpenID Authentication 1.1</span></div>
<h3>개요</h3>
<p>OpenID 인증은 사용자가 제시한 URL이 본인의 소유임을 증명함으로써 인증을 수행한다. 비밀번호나 전자우편주소와 같이, 어떤 다른 것도 전달하지 않고도 인증 절차를 진행할 수 있다.</p>
<p>OpenID는 완전히 분산되어 있다. 이는 누구나 Consumer 또는 Identity 제공자가 될 수 있으며, 이를 위해 중앙의 권위주체로부터 허가나 등록 또한 받을 필요가 없다는 것을 의미한다. 사용자는 자신이 사용하고 싶은 Identity 제공자를 선택할 수 있고, Identity 제공자를 변경할 경우에도 Identity를 유지할 수 있다.</p>
<p> OpenID 의 프로토콜은 JavaScript 나 최신브라우저를 요구하지는 않지만, 인증방식상 소위 "AJAX"-스타일 셋업을 깔끔하기 적용할 수 있으며, 최종사용자가 현재 페이지를 떠나지 않고도 인증을 수행할 수도 있다.(물론 보안 이슈는 있다-역자).</p>
<p> 본 OpenID 인증 스펙상에는 사용자 프로파일 정보를 교환하기 위한 어떤 방법도 제공하지 않지만, Consumer 는 해당 OpenID 페이지에 연결된 세만틱한 형식의 문서들 (FOAF, RSS, Atom, vCARD, 등)을 통해서 사용자에 대한 정보를 얻을 수 있다. 또한 프로파일 정보 교환 수단을 제공하기 위해, 현재 OpenID 인증 기반 위에서 확장 스펙들이 작성 중이다.</p>
<p> </p>
<hr />
<h3>목차<a id="toc" ></a></h3>
<p class="toc"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor1" title="1." class="external">1.</a> 요구 사항 표시법<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor2" title="2." class="external">2.</a> 용어<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor3" title="3." class="external">3.</a> 개관<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor4" title="3.1." class="external">3.1.</a> HTML 문서를 Identifier 로 바꾸기<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#delegating_authentication" title="3.1.1." class="external">3.1.1.</a> 인증 위임하기<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor6" title="3.2." class="external">3.2.</a> 제시된 Identifier 제출하기<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor8" title="3.3." class="external">3.3.</a> Consumer 사이트는 Identifier URL 내용을 구한다<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#smart_vs_dumb" title="3.4." class="external">3.4.</a> Smart 대 Dumb 모드<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor11" title="3.5." class="external">3.5.</a> Consumer 는 Identifier 를 검증한다<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor12" title="4." class="external">4.</a> Modes<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_associate" title="4.1." class="external">4.1.</a> associate<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor13" title="4.1.1." class="external">4.1.1.</a> 요청 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor14" title="4.1.2." class="external">4.1.2.</a> 응답 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor15" title="4.1.3." class="external">4.1.3.</a> 추가 사항<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_immediate" title="4.2." class="external">4.2.</a> checkid_immediate<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor16" title="4.2.1." class="external">4.2.1.</a> 요청 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor17">4.2.2.</a> 응답 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor21">4.2.3.</a> 추가 사항<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_setup">4.3.</a> checkid_setup<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor22">4.3.1.</a> 요청 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor23">4.3.2.</a> 응답 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor26">4.3.3.</a> 추가 사항<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_check_authentication">4.4.</a> check_authentication<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor27">4.4.1.</a> 요청 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor28">4.4.2.</a> 응답 인자들<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor29">4.4.3.</a> 추가 사항<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor30">5.</a> 보안 고려 사항<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#defaults">Appendix A.</a> Default Values<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#pvalue">Appendix A.1.</a> Diffie-Hellman P Value<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor31">Appendix B.</a> Error Responses<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor32">Appendix C.</a> Key-Value Format<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#limits">Appendix D.</a> Limits<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#anchor33">Appendix E.</a> Misc<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#rfc.references1">6.</a> Normative References<br />
<a href="http://openid.co.kr/specs/openid-authentication-1_1.html#rfc.authors">§</a> Authors' Addresses</p>
<p><br /></p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug">
<p><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"></a></p>
</td>
</tr>
</tbody>
</table>
<h3>1. 요구 사항 표시<a id="anchor1" ></a><a id="rfc.section.1" ></a></h3>
<p>이 문서의 요구 사항 수준을 정확히 표현하기 위해 한글 표현 이외에도, 영문 키워드들 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 을 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#RFC2119" class="info">[RFC2119] <span>(</span><span class="info">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .</span><span>)</span></a> 에 정의된 의미로 괄호안에 추가 표시 한다.</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"> TOC </a></td>
</tr>
</tbody>
</table>
<h3>2. 용어<a id="anchor2" ></a><a id="rfc.section.2" ></a></h3>
<blockquote class="text">
<dl>
<dt>최종 사용자 (End User):</dt>
<dd>Consumer 에게 자신의 아이덴티티를 증명하고자 하는 실제 사람.</dd>
<dt>Identifier:</dt>
<dd>Identifier 는 단지 하나의 URL 이다. 전체 OpenID 인증 프로토콜의 흐름은 최종 사용자가 하나의 URL 을 소유했음을 증명하는 것에 관한 것이다.</dd>
<dt>제시된 Identifier (Claimed Identifier):</dt>
<dd>Consumer 에 의해 아직 검증되지 않았지만, 최종 사용자가 자신의 것이라고 말하는 Identifier.</dd>
<dt>검증된 Identifier (Verified Identifier):</dt>
<dd>최종 사용자가 Consumer 에게 자신의 것임을 증명한 Identifier.</dd>
<dt>Consumer:</dt>
<dd>제시한 Identifier가 최종 사용자의 소유인지 검증하고 싶은 웹 서비스.</dd>
<dt>Identity 제공자 (Identity Provider):</dt>
<dd>
<p style="MARGIN-LEFT: 3em">또는 "IdP" 나 "서버" 로도 불린다. 제시한 Identifier가 최종 사용자의 소유임을 암호학적으로 증명받기 위해 Consumer 가 접속하는 OpenID 인증 서버이다. 최종 사용자가 어떻게 IdP에서 인증받는지에 대한 내용은 OpenID 인증 스펙의 범위를 벗어난다 (역주: 따라서 IdP 에 따라서 다르다).</p>
</dd>
<dt>User-Agent:</dt>
<dd>최종 사용자의 웹브라우저. 특별한 플러그인이나 자바스크립트는 필요없다.</dd>
</dl>
</blockquote>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"> TOC </a></td>
</tr>
</tbody>
</table>
<h3>3. 개관<a id="anchor3" ></a><a id="rfc.section.3" ></a></h3>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"> TOC </a></td>
</tr>
</tbody>
</table>
<h3>3.1. HTML 문서를 Identifier 로 바꾸기<a id="anchor4" ></a><a id="rfc.section.3.1" ></a></h3>
<p><em class="highlight" style="BACKGROUND-COLOR: rgb(255,247,0)"><em><em class="highlight" style="BACKGROUND-COLOR: rgb(174,255,102)"><em class="highlight" style="BACKGROUND-COLOR: rgb(255,255,255)">Identifier를 처리하는 Identity 제공자를 Consumer에게 알리기 위해,</em></em></em></em> 최종 사용자는 반드시 자신의 URL(역주: 최종 사용자의 Identifier URL) 에 위치한 HTML 문서의 HEAD 섹션에 markup 을 추가해야 한다. 이 HTML 문서의 호스트가 최종 사용자의 Identity 제공자가 되어야 할 필요는 없다(NOT REQUIRED); 그 Identifier URL 과 Identity 제공자는 완전히 분리된 서비스일 수 있다.</p>
<p> </p>
<p>최종 사용자의 Identiifer 로 http://example.com/ 을 사용하고 Identity 제공자로 http://openid.example.com 을 사용하려면, Identifier URL 을 가져올때 전송되는 HTML 문서의 HEAD 섹션에 다음 태그가 추가 될 것이다.</p>
<p> </p>
<blockquote>
<p><q><link rel="openid.server" href="http://openid.example.com/"></q></p>
</blockquote>
<p> </p>
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"> TOC </a></td>
</tr>
</tbody>
</table>
<h3>3.1.1. 인증 위임하기<a id="delegating_authentication" ></a><a id="rfc.section.3.1.1" ></a></h3>
<p>만일 최종 사용자의 호스트가 Identity 제공자를 구동할 수 없거나, 최종 사용자가 다른 호스트에서 운영되는 Identity 제공자를 사용하고자 한다면, 그들의 인증을 위임할 필요가 있다. 예를 들어, 최종 사용자는 자신의 웹사이트, http://www.example.com/, 를 자신의 Identifier로 사용하기를 원하지만 Identity 제공자를 운영할 수단이 없거나 운영하고 싶지 않을 수 있다.</p>
<p>만일 최종 사용자가 LiveJournal 계정을 하나 가지고 있고(사용자 "exampleuser" 이라 하자), LiveJournal 이 OpenID Identity 제공자를 보유하여 최종 사용자가 http://exampleuser.livejournal.com/ 이라는 Identifier를 제어함을 보증한다면, 최종 사용자들은 자신들의 인증을 LiveJournal 의 Identity 제공자에게 위임할 수 있을 것이다.</p>
<p>즉, 최종사용자는 그들의 Identifier 로 www.example.com 을 사용하지만 Consumer 들이 실제로는 http://www.livejournal.com/openid/server.bml 에 위치한 Identity 제공자를 통해 http://exampleuser.livejournal.com/ 라는 Identifier를 검증토록 하기 위해, 최종사용자의 Identifier URL (www.example.com)을 가져올 때 전송될 HTML 문서의 HEAD 섹션에 다음 태그들을 추가해야 한다.</p>
<p> </p>
<blockquote>
<p><link rel="openid.server" href="http://www.livejournal.com/openid/server.bml"></p>
<p><link rel="openid.delegate" href="http://exampleuser.livejournal.com/"></p>
</blockquote>
<p> </p>
<p>이제, Consumer 가 해당 태그를 인식하면, http://www.livejournal.com/openid/server.bml 에게 그 최종 사용자가 exampleuser.livejournal.com 인지 여부를 질의한다. 이 과정에서 www.example.com 는 전혀 언급하지 않는다.</p>
<p> </p>
<p>이 방식의 주요 장점은 최종 사용자가 자신 Identifier 를 여러 해 동안 유지할 수 있다는 것이다; 심지어 서비스들이 새로 나오고 또 사라지더라도 위임하는 Identity 제공자를 바꾸면서 같은 Identifier 를 계속 유지할 수 있다.</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"> TOC </a></td>
</tr>
</tbody>
</table>
<h3>3.1.2. 중요 사항<a id="anchor5" ></a><a id="rfc.section.3.1.2" ></a></h3>
<ul class="text">
<li>명시된 openid.server URL 은 질의 파라미터들을 포함할 수도 있으며(MAY), 추가 파라미터를 붙일 때는 기존 파라미터들이 제대로 유지되어야 한다. 예를 들어, 이미 '?' 표시가 있다면 두번째 '?' 표시는 생략되야 한다(MUST)(역주: 'http://example.com/openid?param1=asdf'에 추가 파라미터인 '?param2=asdf' 를 붙일 때. 'http://example.com/openid?param1=asdf&param2=asdf'가 되어야 한다.)</li>
<li>openid.server 와 openid.delegate URL 은 반드시(MUST) 절대 경로 형식의 URL 이어야 한다. Consumer 는 상대 경로 형식의 URL 을 해석하려고 시도하면 안된다(MUST NOT).</li>
<li>openid.server 와 openid.delegate URL 은 <strong>&,<,>,"</strong> 이외의 엔터티들은 포함하지 말아야 한다(MUST NOT). 기타 HTML 문서에서 유효하지 않은 문자나 문서의 문자인코딩(character encoding) 으로 표현될 수 없는 문자들은 반드시 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#RFC2396" class="info">[RFC2396] <span>(</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> 의 기술을 따라 %xx 방식으로 escape 되야만 한다 (MUST).</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2"> TOC </a></td>
</tr>
</tbody>
</table>
<h3>3.2. 제시된 Identifier 제출하기<a id="anchor6" ></a><a id="rfc.section.3.2" ></a></h3>
<p>위 예제에서, 최종 사용자는 OpenID 인증을 지원하는 Consumer 사이트를 방문한다. Consumer 는 최종 사용자에게 Identifier URL 입력을 위한 폼입력란을 제시한다.</p>
<p> </p>
<p>예를 들면:</p>
<pre>
----------------------------------<br />
|[logo] example.com | [Login Button]<br />
----------------------------------
</pre>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>3.2.1. 중요 사항<a id="anchor7" ></a><a id="rfc.section.3.2.1" ></a></h3>
<ul class="text">
<li>모든 Consumer 는 최종 사용자가 Identifier URL 을 입력하는 폼입력란 시작에 <a href="http://openid.net/login-bg.gif">OpenID 로고이미지</a> 를 표시할 것을 권장한다(RECOMMENDED).</li>
<li>최종 사용자는 그들의 Identifier URL 에 반드시 <span class="external">"http://"</span> 로 시작하거나 '/' 로 끝낼 필요는 없다 (NOT REQUIRED). Consumer 는 반드시(MUST) Identifier URL 을, 모든 redirect 들을 따라가는 등, 정규화(canonicalize) 하여야 한다. 최종 URL 에 주목하자. 이 최종, 정규화된 URL 이 바로 최종 사용자의 Identifier 이다.</li>
<li>폼 입력란의 이름은 "openid_url" (역주: OpenID 2.0 버전의 "openid_identifier" 를 권장함) 을 권장하며(RECOMMENDED), 따라서 전자상거래 사이트들의 "address1", "address2" 같은 관습처럼 사용자 브라우저가 최종 사용자 Identifier URL 을 자동 완성 할 수 있을 것이다.</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>3.3. Consumer 사이트는 Identifier URL 내용을 가져온다</h3>
<p>이제 Consumer 사이트는 최종 사용자가 제시한 Identifier 에 있는 문서를 읽어들인다. Consumer 는 HEAD 섹션을 파싱해서 "openid.server" 선언과 선택적으로 "openid.delegate" 선언을 가져온다.</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>3.3.1. 중요 사항<a id="anchor9" ></a><a id="rfc.section.3.3.1" ></a></h3>
<ul class="text">
<li>최종 사용자가 악의적일 수 있으므로 Consumer 를 내부 네트웤, 소위 늪(tarpit) 등, 에 접속시키려고 할 수도 있다. 이런 종류의 공격에 방어하기 위해 <a href="http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm">LWPx: : ParanoidAgent</a> 같은 paranoid HTTP 라이브러리 사용을 권장한다(RECOMMENDED).</li>
<li>Consumer 들은 반드시(MUST) <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#delegating_authentication" class="info">위임 <span>(</span><span class="info">인증 위임</span><span>하기)</span></a>을 지원을 구현해야 한다.</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>3.4. Smart 대 Dumb 모드<a id="smart_vs_dumb" ></a><a id="rfc.section.3.4" ></a></h3>
<p>OpenID 인증은 다른 성능의 Consumer 들을 수용하기 위해서 "Smart 모드" 와 "Dumb 모드" 를 지원한다. Smart Consumer 는 시작할 때 좀 더 많은 작업을 수행함으로서 나중에 적은 동작을 하지만, 상태 정보를 로컬 캐시로 유지할 필요가 있다. Dumb Consumer 는 상태를 전혀 유지하지 않지만, 한번의 HTTP 요청을 별도로 요구한다.</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>3.4.1. Smart 모드의 중요 사항<a id="anchor10" ></a><a id="rfc.section.3.4.1" ></a></h3>
<ul class="text">
<li>Consumer가 사전에 공유 보안 값을 하나 캐시하고 있지 않다면, 먼저 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_associate" class="info">associate 요청 <span>(</span><span class="info">associate</span><span>)</span></a> 을 최종 사용자의 Identity 제공자에게 보내서 공유 보안 값을 하나 요청하길 권장한다(RECOMMENDED). 이 공유 보안 값은 만료될 때 까지 이후 Identity 확인 요청에서 HMAC-SHA1 키값으로 사용되어야 한다 (SHOULD).</li>
<li>이 공유 보안 값은 평문(plain-text) 이나 Diffie-Hellman 협상된 보안 값(Diffie-Hellman-negotiated secret)으로 암호화되어 전달될 수 있다. Dffie-Hellman은 accociate mode 에서만 사용할 수 있다. <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_immediate" class="info">checkid_immediate</a> 모드와 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_setup" class="info">checkid_setup</a> 모드는 Consumer 가 이미 공유 보안 값을, 어떻게 획득했건 간에, 하나 가지고 있다고 가정한다.</li>
</ul>
<hr />
<h3>3.5. Consumer 는 Identifier 를 검증한다<a id="anchor11" ></a><a id="rfc.section.3.5" ></a></h3>
<p>이 Consumer 는 이제 Identity 제공자의 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_immediate" class="info">checkid_immediate</a> (또는 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_setup" class="info"><span class="info">checkid_setup</span></a>) URL 에 대한 URL 을 하나 구성하여 User-Agent 를 그곳으로 보낸다.</p>
<p>User-Agent 를 해당 URL로 보냄으로써, 최종 사용자의 쿠키를 비롯한 모든 로그인 증명들이 그들의 신뢰하는 Identity 제공자에게 전송된다. 이 Identity 제공자는 자신의 작업을 수행하고, 전달된 openid.return_to URL 에 자신의 응답을 추가하여 User-Agent 를 원래의 Consumer 에게 돌려 보낸다.</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4. Modes<a id="anchor12" ></a><a id="rfc.section.4" ></a></h3>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.1. associate<a id="mode_associate" ></a><a id="rfc.section.4.1" ></a></h3>
<ul class="text">
<li>설명: Consumer 와 Identity Provider 간에 하나의 공유 보안 값을 정한다.</li>
<li>HTTP method: POST</li>
<li>순서: Consumer -> IdP -> Consumer</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.1.1. 요청 인자들<a id="anchor13" ></a><a id="rfc.section.4.1.1" ></a></h3>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "associate"</p>
</blockquote>
</li>
<li>openid.assoc_type
<blockquote class="text">
<p>값: 선호되는 association type</p>
<p>기본값: "HMAC-SHA1"</p>
<p>Note: 현재는 기본 값 하나만 지원</p>
</blockquote>
</li>
<li>openid.session_type
<blockquote class="text">
<p>값: 공백 또는 "DH-SHA1"</p>
<p>기본값: 공백. (평문)</p>
<p>Note: 공유 보안 값을 암호화 하려면 DH-SHA1 모드를 사용할 것을 권장한다</p>
</blockquote>
</li>
<li>openid.dh_modulus
<blockquote class="text">
<p>값: base64(btwoc(p))</p>
<p>Note: 기본 p 값은 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#pvalue" class="info">Appendix A.1 <span>(</span><span class="info">Diffie-Hellman P Value</span><span>)</span></a> 을 참조하라.</p>
</blockquote>
</li>
<li>openid.dh_gen
<blockquote class="text">
<p>값: base64(btwoc(g))</p>
<p>기본값: g = 2</p>
<p>Note: DH-SHA1 session_type 을 사용할 때만 이용한다. openid.dh_modulus 값이 지정된 경우, 이 필드의 이 값은 반드시 지정되어야 한다.</p>
</blockquote>
</li>
<li>openid.dh_consumer_public
<blockquote class="text">
<p>값: base64(btwoc(g ^ x mod p))</p>
<p>Note: DH-SHA1 session_type 을 사용할 때는 반드시 필요하다.(REQUIRED)</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.1.2. 응답 인자들<a id="anchor14" ></a><a id="rfc.section.4.1.2" ></a></h3>
<p>응답 포맷: 키-값 쌍(pair)들</p>
<ul class="text">
<li>assoc_type
<blockquote class="text">
<p>값: 결과 핸들의 association 타입.</p>
<p>Note: 현재 유일한 모드는 HMAC-SHA1 이며, 모든 Consumer 들은 반드시 HMAC-SHA1 모드를 지원해야 한다(MUST). 이 값을 캐싱할 때, Consumer 는 반드시 하나의 assoc_handle 에 그 보안값과 assoc_type 를 모두 매핑해야 한다(MUST).</p>
</blockquote>
</li>
<li>assoc_handle
<blockquote class="text">
<p>값: 향후의 트랜잭션에 제공될 association 핸들.</p>
<p>Note: Consumer 는 아래 expires_in 값 이후에는 이 핸들을 사용하면 안된다 (MUST NOT).</p>
</blockquote>
</li>
<li>expires_in
<blockquote class="text">
<p>값: 이 association 핸들의 유효한 시간(초), 10진수로 표시.</p>
</blockquote>
</li>
<li>session_type
<blockquote class="text">
<p>값: 이 Provider 가 선택한 암호화 모드. 공백, 생략, 또는 "DH-SHA1" 일 수 있다(MAY).</p>
</blockquote>
</li>
<li>dh_server_public
<blockquote class="text">
<p>값: base64(btwoc(g ^ y mod p))</p>
<p>설명: DH-SHA1 사용시, Provider 의 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#RFC2631" class="info">Diffie-Hellman public key <span>(</span><span class="info">Rescorla, E., “Diffie-Hellman Key Agreement Method,” .</span><span>)</span></a> [RFC2631].</p>
</blockquote>
</li>
<li>
<p>enc_mac_key</p>
<blockquote class="text">
<p>값: base64(SHA1(btwoc(g ^ (xy) mod p)) XOR secret(assoc_handle))</p>
<p>설명: DH-SHA1 사용시, 암호화된 공유 보안값.</p>
</blockquote>
</li>
<li>mac_key
<blockquote class="text">
<p>값: base64(secret(assoc_handle))</p>
<p>설명: DH-SHA1 미사용시, 평문으로된(plaintext) 공유 보안값.</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.1.3. 추가 사항<a id="anchor15" ></a><a id="rfc.section.4.1.3" ></a></h3>
<ul class="text">
<li>Consumer 가 Identity 제공자에게 DH-SHA1 암호화를 요청했지만, 평문으로 된 보안 값을 받을 수도 있다. 만약 이것이 곤란하다면, 그 핸들을 사용하는 대신 그 Identity 제공자와는 dumb mode 를 사용하라.<br />
만약 누군가 그 평문으로 된 보안값을 훔쳤다해도, 해당 association 핸들을 이용한 쿼리를 결코 받지 않을 것이므로 문제가 되지 않는다. 만일 Identity 제공자가 DH-SHA1을 사용할 수 없다면, 아마 어떤 식으로든 제한되있겠지만, Dumb 모드를 사용하는 것이 속도는 좀 느려지지만 여전히 안전하다.</li>
<li>만약 Identity 제공자가 자신의 private key 를 1 <= y < p-1 로 선택한다면, 공유 DH-SHA1 보안값은 g ^ xy mod p = (g ^ x) ^ y mod p = (g ^ y) ^ x mod p 가 된다. 좀더 자세한 사항은 <a href="http://search.cpan.org/~btrott/Crypt-DH-0.06/lib/Crypt/DH.pm">Crypt::DH docs.</a> 를 참고하기 바란다.</li>
<li>기본 mac_key 는 반드시 hash 함수, H 의 출력 과 같은 길이여야 한다(MUST). 이 경우 DH-SHA1 용 160 비트 (20 바이트) 길이가 된다.</li>
<li>만약 IdP 가 DH-SHA1 을 지원하지 않는다면, 그 IdP 는 요청의 DH-SHA1 관련 필드들을 무시하고 비 DH-SHA1 요청과 똑같이 처리할 것이다.</li>
<li>DH-SHA1 를 사용할 때, 결과 키는 binary string 으로 취급되어야 한다(SHOULD).</li>
<li>모든 정수는 big-endian signed two's complement 로 표현되고, Base64 로 인코딩된다. 즉, btwoc 는 bigint 를 입력받아 그것의 가장 짧은 big-endian two's complement 표기를 출력하는 함수이다.</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2. checkid_immediate <a id="mode_checkid_immediate" ></a><a id="rfc.section.4.2" ></a></h3>
<ul class="text">
<li>설명: 제시된 Identifier 를 최종 사용자가 소유하고 있는지, Consumer는 Identity Provider 에게 질의하고, 즉각적인 "예" 또는 "답변 불가" 응답을 받는다.</li>
<li>HTTP method: GET</li>
<li>순서: Consumer -> User-Agent -> IdP -> User-Agent -> Consumer</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2.1. 요청 인자들<a id="anchor16" ></a><a id="rfc.section.4.2.1" ></a></h3>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "checkid_immediate"</p>
</blockquote>
</li>
<li>openid.identity
<blockquote class="text">
<p>값: 제시된(Claimed) Identifier</p>
</blockquote>
</li>
<li>openid.assoc_handle
<blockquote class="text">
<p>값: 앞의 associate 요청에서 받은 assoc_handle 값.</p>
<p>Note: 선택적임. association 핸들이 제공되지 않거나 Identity 제공자가 유효하지 않다고 느낄 경우, Consumer는 반드시 check_authentication을 사용해야 한다(MUST).</p>
</blockquote>
</li>
<li>openid.return_to
<blockquote class="text">
<p>값: Identity 제공자가 User-Agent 를 가급적 되돌려 보내야 하는 URL(SHOULD).</p>
</blockquote>
</li>
<li>openid.trust_root
<blockquote class="text">
<p>값: Provider 가 최종 사용자에게 신뢰여부를 확인해야(SHALL) 할 URL.</p>
<p>기본: return_to URL</p>
<p>선택: 최종 사용자가 승인하기 위해 실제로 보게 되는 URL 이어야 한다(SHALL).</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2.2. 응답 인자들<a id="anchor17" ></a><a id="rfc.section.4.2.2" ></a></h3>
<p>응답 포맷: 쿼리 문자열 파라미터들</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2.2.1. 항상 보내는 것<a id="anchor18" ></a><a id="rfc.section.4.2.2.1" ></a></h3>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "id_res"</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2.2.2. 입증(assertion) 실패시 보내는 것<a id="anchor19" ></a><a id="rfc.section.4.2.2.2" ></a></h3>
<ul class="text">
<li>openid.user_setup_url
<blockquote class="text">
<p>값: 입증(assertion)을 위해 필요한 작업들을 사용자가 수행할 수 있도록 User-Agent 를 이동시키는 URL.</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2.2.3. 긍정적 확답시 보내는 것<a id="anchor20" ></a><a id="rfc.section.4.2.2.3" ></a></h3>
<ul class="text">
<li>openid.identity
<blockquote class="text">
<p>값: 검증된(Verified ) Identifier</p>
</blockquote>
</li>
<li>openid.assoc_handle
<blockquote class="text">
<p>값: 불투명한(Opaque) association 핸들. 서명을 하기 위한 HMAC 키를 찾기 위해 사용된다.</p>
</blockquote>
</li>
<li>openid.return_to
<blockquote class="text">
<p>값: 요청 메시지의 return_to URL 파라미터로 Identity 제공자가 수정하기 전에 복사한 것.</p>
</blockquote>
</li>
<li>openid.signed
<blockquote class="text">
<p>값: 콤마로 분리된, 서명된 필드들의 목록.</p>
<p>Note: 서명된 필드명들의 "openid." 은 생략한다. 예를 들면, "mode,identity,return_to".</p>
</blockquote>
</li>
<li>openid.sig
<blockquote class="text">
<p>값: base64(HMAC(secret(assoc_handle), token_contents)<br />
Note: token_contents는 키-값 형식의 문자열로, 응답 메시지에 포함된 모든 서명된 키와 값을 가리킨다. 이 값은 openid.signed 필드에 있는 순서와 반드시 동일하게 위치되어야 한다(MUST). Consumer는 서명을 체크하기 전에 token_contents를 재생성 해야한다(SHALL). 해당 필드의 처리를 위해 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#limits" title="Appendix D (Limits)" class="external">Appendix D (Limits)</a>을 참조하기 바란다.</p>
</blockquote>
</li>
<li>openid.invalidate_handle
<blockquote class="text">
<p>값: 선택적임. 요청 메시지에서 보내진 association 핸들로서, Identity 제공자가 받아들이지 않거나 인식하지 못할 경우에 보낸다.</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.2.3. 추가 사항<a id="anchor21" ></a><a id="rfc.section.4.2.3" ></a></h3>
<ul class="text" style="MARGIN-LEFT: 1em">
<li>이 방식은 "AJAX"-스타일의 셋업에 주로 사용된다. 제시된 Identifier 를 검사하기 위한 좀 더 전통적인 방식은 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_setup" class="info">checkid_set</a><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_checkid_setup" class="info">up <span>(</span><span class="info">checkid_setup</span><span>)</span></a>이다.</li>
<li>Identity 제공자는 가급적 자신이 직접 관리/생산하는 URL 들만 입증해 주어야 한다(SHOULD). 만약 최종 사용자가 Identity 제공자 영역 밖의 URL들에 대한 인증을 원한다면, 반드시 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#delegating_authentication" class="info">위임 <span>(</span><span class="info">인증 위임</span><span>하기)</span></a> 을 이용해야 한다(MUST).</li>
<li>openid.return_to URL 은 원래 있던 쿼리문을 포함할 수 있으며(MAY), Identity 제공자는 응답 파라미터를 작성할 때 이 파라미터를 반드시 유지시켜 줘야 한다(MUST). OpenID Consumer 는 replay 공격을 막기 위해 가급적 Consumer의 시각 (Consumer-local timestamp)으로 직접 서명한 일회용 보안값(nonce)을 openid.return_to URL 파라미터로 추가해야 한다(SHOULD). 이 작업과 관련된 세부 사항은 Consumer 의 정책을 따른다.<br />
하지만, openid.return_to URL 해당 Identity 제공자에 의해 서명되었기 때문에, Consumer 는 임의의 제3자가 틀린 openid.return_to URL 과 서명을 보낸 것은 아닌지를 확인할 수 있다.</li>
<li>제공된 assoc_handle 을 Identity 제공자가 어떤 이유에서건 거부하거나 인식하지 못했다면, 자체 생성한 것을 대신 사용하고 원래 제공된 것은 openid.invalidate_handle 값으로 되돌려 보내서 Consumer가 더 이상 그 핸들을 사용하지 못하도록 지시한다. 그러면 Consumer 는 가급적 그 핸들을 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_check_authentication" class="info">check_authentication <span>(</span><span class="info">check_authentication</span><span>)</span></a> 요청에 함께 전송하여, 해당 핸들이 더 이상 올바른 것이 아닌지를 한번 더 검증해야 한다(SHOULD).</li>
<li>Identifier 입증이 실패한다면, Identity 제공자는 openid.user_setup_url 을 제공하여, 해당 URL에서 최종 사용자가 신원 입증을 하기 위해 필요한 작업들, 가령 로그인, 승인 설정 등을 할 수 있게 한다. Identity 제공자는 필요한 어떠한 것도 암시하지 않는 URL 을 제공하여, Consumer 가 입증 실패의 이유에 대해서 전혀 알 수 없게 해야 한다(SHOULD).<br />
최종적으로, Identity 제공자는 checkid_setup 처럼, "id_res" 또는 "cancel" 답변과 함께 최종 사용자를 openid.return_to URL 로 돌려보내야 한다(SHOULD).</li>
<li>openid.return_to URL 은 반드시 openid.trust_root 의 하위 URL 이어야 하며(MUST), 아니면 Identity 제공자는 오류를 반환해야 한다(SHOULD). 즉, URL scheme 과 포트는 같아야 한다(MUST). 경로 부분이 존재한다면 openid.trust_root 값과 같거나 하위 경로여야 하며, 도메인은 반드시 같거나, openid.trust_root 값이 <span class="external">http://*.example.com</span> 처럼 와일드카드(*) 를 포함하고 있으면 일치되어야 한다. 와일드카드는 오직 호스트명에만 가능하다(SHALL). Identity 제공자는 가급적 <span class="external">http://*.com/</span> 이나 <span class="external">http://*.co.uk/</span> 같은 요청으로 부터 사용자를 보호해야 한다.</li>
<li>응답 메시지에 Identity 제공자의 서명은 반드시 openid.identity 와 openid.return_to 를 포함해야 한다(MUST).</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.3. checkid_setup<a id="mode_checkid_setup" ></a><a id="rfc.section.4.3" ></a></h3>
<ul class="text">
<li>설명: Consumer는 최종 사용자가 제시된 Identifier 를 소유하고 있는지를 Identity 제공자에게 질의하고, 응답을 기다린다. Consumer 는 User-Agent 를 Identity 제공자에게 넘기며, Identity 제공자는 "yes" 나 "cancel" 응답을 돌려준다.</li>
<li>HTTP method: GET</li>
<li>순서: Consumer -> User-Agent -> [IdP -> User-Agent ->]+ Consumer</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.3.1. 요청 인자들<a id="anchor22" ></a><a id="rfc.section.4.3.1" ></a></h3>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "checkid_setup"</p>
</blockquote>
</li>
<li>openid.identity
<blockquote class="text">
<p>값: 제시된(Claimed) Identifier</p>
</blockquote>
</li>
<li>openid.assoc_handle
<blockquote class="text">
<p>값: 앞의 associate 요청에서 받은 assoc_handle 값.</p>
<p>Note: 선택적임. association 핸들이 제공되지 않거나 Identity 제공자가 유효하지 않다고 판단될 경우, Consumer는 반드시 check_authentication을 사용해야 한다(MUST).</p>
</blockquote>
</li>
<li>openid.return_to
<blockquote class="text">
<p>값: Identity 제공자가 User-Agent 를 되돌려 보내야 하는 URL(SHOULD).</p>
</blockquote>
</li>
<li>
<p>openid.trust_root</p>
<blockquote class="text">
<p>값: Identity 제공자가 최종 사용자에게 신뢰 여부를 확인해야 할 URL(SHALL).</p>
<p>기본: return_to URL</p>
<p>Note: 선택적임. 최종 사용자가 승인하기 위해 실제로 보게 되는 URL 이어야 한다(SHALL).</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.3.2. Respone Parameters<a id="anchor23" ></a><a id="rfc.section.4.3.2" ></a></h3>
<p>응답 포맷: 쿼리 문자열 파라미터들</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.3.2.1. 항상 보내는 것<a id="anchor24" ></a><a id="rfc.section.4.3.2.1" ></a></h3>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "id_res" 또는 "cancel"</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.3.2.2. 긍정적 확답에 보내는 것<a id="anchor25" ></a><a id="rfc.section.4.3.2.2" ></a></h3>
<ul class="text">
<li>openid.identity
<blockquote class="text">
<p>값: 검증된(Verified ) Identifier</p>
</blockquote>
</li>
<li>openid.assoc_handle
<blockquote class="text">
<p>값: 불투명한(Opaque) association 핸들로 서명을 위한 HMAC 키를 찾기 위해 사용된다.</p>
</blockquote>
</li>
<li>openid.return_to
<blockquote class="text">
<p>값: 요청 메시지에서 보낸 return_to URL 파라미터로 Identity 제공자가 수정하기 전에 복사한 것.</p>
</blockquote>
</li>
<li>openid.signed
<blockquote class="text">
<p>값: 콤마로 분리된, 서명된 필드들 목록.</p>
<p>Note: 서명된 필드명들의 "openid." 은 생략한다. 예를 들면, "mode, identity, return_to".</p>
</blockquote>
</li>
<li>openid.sig
<blockquote class="text">
<p>값: base64(HMAC(secret(assoc_handle), token_contents)</p>
<p>Note: token_contents는 키-값 형식의 문자열로, 응답 메시지에 포함된 모든 서명된 키와 값을 가리킨다. 이 값은 openid.signed 필드에 있는 순서와 반드시 동일하게 위치되어야 한다(MUST). consumer는 서명을 체크하기 전에 token_contents를 재생성 해야한다(SHALL). 해당 필드의 처리를 위해 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#limits" title="Appendix D (Limits)" class="external">Appendix D (Limits)</a>을 참조하기 바란다.</p>
</blockquote>
</li>
<li>openid.invalidate_handle
<blockquote class="text">
<p>값: 선택적임. 요청 메시지에서 보내진 association 핸들로서, Identity 제공자가 받아들이지 않거나 인식하지 못할 경우에 보낸다.</p>
</blockquote>
</li>
</ul>
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.3.3. 추가 사항<a id="anchor26" ></a><a id="rfc.section.4.3.3" ></a></h3>
<ul class="text">
<li>응답 메시지에 Identity 제공자의 서명은 반드시 openid.identity 와 openid.return_to 를 포함해야 한다(MUST).</li>
<li>대개의 경우, Consumer 가 cancel 모드 응답을 받지는 않을 것이다; 최종 사용자는 그냥 나가거나 브라우저에서 back 버튼을 눌러버릴 것이다. 그러나 만약 최종 사용자가 돌아온다면 Consumer 는 가급적 진행 중이던 곳으로 가야한다(SHOULD). cancle 모드의 경우에는, 나머지 응답 인자들은 생략된다.</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.4. check_authentication<a id="mode_check_authentication" ></a><a id="rfc.section.4.4" ></a></h3>
<ul class="text">
<li>설명: Identity 제공자에게 메시지가 올바른지 묻는다. 상태가 없는 Dumb 모드 Consumer 를 위해 또는 invalidate_handle 응답을 검증할 때 사용한다.<br />
<strong><span class="strong">주의: 상태없는 association 핸들을 가진 서명만 검증한다. Identity 제공자는 누군가와 공유된 보안값을 가지는 association 핸들용 서명은 결코 검증하면 안된다(MUST NOT). Identity 제공자는 상태없는 핸들과 상태있는(associated) 핸들을 구별해야만 하며(MUST), 상태없는 핸들에 대해서만</span> <span class="strong">check_authentication 서비스를 해야한다.</span></strong></li>
<li>HTTP method: POST</li>
<li>순서: Consumer -> IdP -> Consumer</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.4.1. 요청 인자들<a id="anchor27" ></a><a id="rfc.section.4.4.1" ></a></h3>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "check_authentication"</p>
</blockquote>
</li>
<li>openid.assoc_handle
<blockquote class="text">
<p>값: checkid_setup 이나 checkid_immediate 응답의 association 핸들.</p>
</blockquote>
</li>
<li>openid.sig
<blockquote class="text">
<p>값: consumer 가 검증하길 원하는 checkid_setup이나 checkid_immediate 요청의 서명.</p>
</blockquote>
</li>
<li>openid.signed
<blockquote class="text">
<p>값: consumer 가 서명을 검증 하려는 checkid_setup이나 checkid_immediate 요청에 있는 서명된 필드들 목록.</p>
</blockquote>
</li>
<li>openid.*
<blockquote class="text">
<p>값: consumer는 반드시 openid.signed 목록에 있는 모든 openid.* 응답 파라미터를 전송해야 하며(MUST), 이 목록은 checkid_setup이나 checkid_immediate 요청에서 얻은 것으로, provider로부터 받은 값을 그대로 사용해야 한다.</p>
</blockquote>
</li>
<li>openid.invalidate_handle
<blockquote class="text">
<p>값: 선택적임. invalidate_handle로 반환된 association 핸들.</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.4.2. 응답 인자들<a id="anchor28" ></a><a id="rfc.section.4.4.2" ></a></h3>
<p>응답 포맷: 키-값 쌍(pair) 들</p>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p>값: "id_res"</p>
</blockquote>
</li>
<li>is_valid
<blockquote class="text">
<p>값: "true" 또는 "false"</p>
<p>설명: Boolean 값. 서명이 유효한지 여부.</p>
</blockquote>
</li>
<li>invalidate_handle
<blockquote class="text">
<p>값: 불투명한(opaque) association 핸들</p>
<p>설명: 존재한다면, consumer는 반환된 association 핸들을 캐시에서 지워야(uncache) 한다(SHOULD).</p>
</blockquote>
</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>4.4.3. 추가 사항<a id="anchor29" ></a><a id="rfc.section.4.4.3" ></a></h3>
<ul class="text">
<li>Identity 제공자는 에러 복구 및 상태를 스스로 유지할 수 없는 Dumb consumer를 위해 이 모드를 구현해야 한다(MUST). 하지만 이 기능은 대부분 필요없기 때문에 최대한 적게 사용하길 권고한다(RECOMMANDED). 그럼에도 불구하고 당신이 Consumer 라이브러리를 직접 개발할 경우에는, 이 기능이 디버깅 과정에서 유용하게 활용된다.</li>
<li>만일 checkid_setup이나 checkid_immediate 요청에서 invalidate_handle 응답을 수신했다면, 이는 Identity 제공자가 해당 association 핸들을 인식하지 못했음을 의미하며, 아마도 분실해서 자체 핸들을 선택한 경우일 것이다.<br />
따라서, Identity 제공자가 사용하는 공유 보안값을 가지고 있지 않기 때문에, Consumer는 Dumb 모드로 대체해야 함을 뜻한다. 이 check_authentication 요청을 처리하는 과정에서, Identity 제공자의 invalidate_handle 응답을 함께 전달하면 해당 요청이 실제로 누락/조작되었는지 검사될 것이다.</li>
<li>openid.* 쿼리 값을 이용해 서명 검증할 때, openid.mode 값은 반드시 "id_res"로 변경되어야 한다.</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>5. 보안 고려 사항<a id="anchor30" ></a><a id="rfc.section.5" ></a></h3>
<ul class="text">
<li>OpenID 인증 프로토콜이 주로 HTTP를 대상으로 하지만, 추가적인 보안을 위해서 HTTPS가 사용될 수 있다. HTTPS 는 <a href="http://openid.co.kr/specs/openid-authentication-1_1.html#mode_associate" class="info">associate 모드</a>에 사용되어 man in the middle, DNS, 피싱(phishing) 공격 등에 방어를 돕도록 권고된다 (RECOMMENDED).</li>
<li>Consumer는 최종 사용자가 OpenID로 로그인할 때, IFrame이나 popup을 사용해서는 안된다 (SHOULD NOT).</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Appendix A. Default Values<a id="defaults" ></a><a id="rfc.section.A" ></a></h3>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Appendix A.1. Diffie-Hellman P Value<a id="pvalue" ></a><a id="rfc.section.A.1" ></a></h3>
<p>1551728981814736974712322577637155\ 3991572480196691540447970779531405\ 7629378541917580651227423698188993\ 7278161526466314385615958256881888\ 8995127215884267541995034125870655\ 6549803580104870537681476726513255\ 7470407658574792912915723345106432\ 4509471500722962109419434978392598\ 4760375594985848253359305585439638443</p>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Appendix B. Error Responses<a id="anchor31" ></a><a id="rfc.section.B" ></a></h3>
<p>이 섹션은 프로토콜/런타임 오류에 속하는 것으로, 인증 오류는 아니다. 인증 오류들은 프로토콜에 명시된다.</p>
<ul class="text">
<li>정해진 에러 코드가 없음; 단지 구조화되지 않은 오류 텍스트.</li>
<li>잘못된 인수로 GET 요청을 한 경우, 유효한 openid.return_to URL 이 있다면, Identity 제공자는 openid.mode=error, openid.error=Error+Text 를 붙여서 User-Agent 를 해당 URL로 이동시켜야 한다(SHALL).</li>
<li>잘못된 인수로 GET 요청을 한 경우, 유효한 openid.return_to URL이 없다면, Identity 제공자는 임의의 content-type 과 에러 메시지와 함께 "400 Bad Request" 를 반환하여야 한다(SHALL).</li>
<li>인수 없이 GET 요청을 한 경우, Identity 제공자는 200 text/html 응답에 "This is an OpenID server endpoint. For more information, see http://openid.net/" 라는 에러 메시지를 보여주어야 한다(SHALL).</li>
<li>잘못된 인수 혹은 인수 없이 POST 요청을 한 경우, Identity 제공자는 400 Bad Request 응답 코드와 함께 "error"가 유일한 키이고 값으로 에러 문장이 들어간 Key-Value 응답 포맷을 반환해야 한다(SHALL). 이 경우에서, Identity 제공자는 임의의 키들을 추가할 수도 있다.</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Appendix C. Key-Value Format<a id="anchor32" ></a><a id="rfc.section.C" ></a></h3>
<p>Lines of:</p>
<ul class="text">
<li>어떤 키: 어떤 값</li>
<li>콜론(: )앞 뒤에 공백이 있어서는 안된다(MUST NOT)</li>
<li>Newline 문자는 반드시 유닉스-형식으로, ASCII 문자 10("\n") 만 이어야 한다(MUST).</li>
<li>Newline 은 라인들 사이는 물론 각 라인의 끝에 위치해야 한다(MUST BE).</li>
<li>MIME 타입은 명시하지 않았으나, text/plain 을 권고한다(RECOMMENED).</li>
<li>문자열 인코딩은 반드시 UTF-8 이어야 한다(MUST).</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Appendix D. Limits<a id="limits" ></a><a id="rfc.section.D" ></a></h3>
<ul class="text">
<li>Identifier URL: 최대 255 바이트</li>
<li>Identity 제공자의 URL: Consumer가 추가한 URL 인수까지 합해 최대 2047 바이트. 원본 endpoint URL 자체는 이보다 작게 유지되어야 한다(SHOULD).</li>
<li>return_to URL: IdP가 추가한 URL 인수까지 합해 최대 2047 바이트. return_to URL 자체는 이보다 작게 유지되어야 한다(SHOULD).</li>
<li>assoc_handle: 255 문자 이하, ASCII 코드 33-126 사이(포함해서)의 문자들로만 구성됨(즉, 출력 가능한 비공백 문자들).</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Appendix E. Misc<a id="anchor33" ></a><a id="rfc.section.E" ></a></h3>
<ul class="text">
<li>시간은 반드시 w3c 포맷을 따르며, "Z"로 표시되고, UTC 시간대에 있어야만 한다. 예를 들면, 2005-05-15T17:11:51Z</li>
</ul>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>6. Normative References<a id="rfc.references1" ></a></h3>
<table width="99%">
<tbody>
<tr>
<td class="author-text"><a id="RFC2119" >[RFC2119]</a></td>
<td class="author-text">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels.”</td>
</tr>
<tr>
<td class="author-text"><a id="RFC2396" >[RFC2396]</a></td>
<td class="author-text">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax.”</td>
</tr>
<tr>
<td class="author-text"><a id="RFC2631" >[RFC2631]</a></td>
<td class="author-text">Rescorla, E., “Diffie-Hellman Key Agreement Method.”</td>
</tr>
</tbody>
</table>
<hr />
<table class="bug">
<tbody>
<tr>
<td class="bug"><a href="http://openid.co.kr/specs/openid-authentication-1_1.html#toc" class="link2">TOC</a></td>
</tr>
</tbody>
</table>
<h3>Authors' Addresses<a id="rfc.authors" ></a></h3>
<table width="99%">
<tbody>
<tr>
<td class="author-text"></td>
<td class="author-text">David Recordon</td>
</tr>
<tr>
<td class="author">Email:</td>
<td class="author-text"><a>drecordon@verisign.com</a></td>
</tr>
<tr>
<td></td>
<td></td>
</tr>
<tr>
<td class="author-text"></td>
<td class="author-text">Brad Fitzpatrick</td>
</tr>
<tr>
<td class="author">Email:</td>
<td class="author-text"><a>brad@danga.com</a></td>
</tr>
</tbody>
</table>
<p> </p>
<p> </p>
http://openidkr.myid.net/http://jhaana117.myid.net/1849