> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/contributor/contributor-ko/authentication/authchain.md). # 인증 체인 Decentraland 프로토콜의 많은 작업은 사용자의 이더리움 계정의 서명으로 인가받아야 하거나, 인가를 통해 이점을 얻습니다. 예를 들면: 1. 새 버전 업로드 [엔티티](https://github.com/decentraland/docs/blob/main/content/entities.md) 소유한 것(예: 프로필). 2. 제3자 서비스에 자신을 인증합니다. 3. 대리인이 자신을 대신해 행동하도록 승인합니다. 이러한 작업을 수행하려면, 사용자와 대리인은 자신의 의도를 설명하는 페이로드에 서명하고 하나의 *인증 체인*. ## 소개 인증 체인은 일련의 검증 단계를 캡슐화하며, 각 단계는 이전 단계의 성공적인 검증에 의존합니다. 모든 제한된 작업이 수행되려면 검증자는 모든 단계를 유효하다고 간주해야 합니다. 모든 체인은 사용자 식별로 시작하여, 요청된 작업을 나타내는 서명된 페이로드로 끝납니다. 따라서 가장 작은 체인은 다음을 나타내는 두 요소를 포함합니다: ```md 1. 권한 보유자는 이더리움 계정 입니다 2. 페이로드는 이며, 의 승인을 받았습니다 ``` 이 기본 체인은 서명의 공개 키가 주소와 일치하는지 검증하여 평가할 수 있습니다. 이 경우, 일반 서명과 동일합니다. 사용자가 대리인의 대리 행동을 승인할 때, 중간 단계가 체인에 나타납니다. 예를 들어, 단일 위임이 있는 체인은 다음을 나타냅니다: ```md 1. 권한 보유자는 이더리움 계정 입니다 2. 대리인은 이며, 에 의해 까지 승인되었습니다 3. 페이로드는 이며, 의 승인을 받았습니다 ``` 대리인이 자신의 대리인을 승인하면 체인은 더 길어집니다. 다시 말해, 승인은 전이적입니다. {% hint style="info" %} 인증 체인은 HTTPS에 사용되는 TLS 인증서 체인과 유사하다고 생각할 수 있으며, 사용자는 루트 권한 기관에 해당합니다. {% endhint %} 이 단일 대리인 체인은 Decentraland에서 사용되는 가장 일반적인 승인 형태입니다. 사용자는 자신의 World Explorer용 키를 승인하여 이더리움 계정으로 개별 작업마다 서명해야 하는 번거로움을 피합니다. ### 체인 구성하기 인증 체인의 각 단계에는 세 가지 정보가 포함됩니다: 하나의 `유형`, 하나의 `페이로드` 및 이에 대응하는 `서명`. | 필드 | 값 | | ------ | ----------------------------------------------- | | `유형` | 유형의 이름([아래 참조](#types)). | | `페이로드` | 유형에 따라 달라지는 문자열. | | `서명` | 다음에 대한 Hex 인코딩된 이더리움 서명 `페이로드`, 다음으로 시작하는 `0x`. | {% hint style="info" %} 인증 체인의 가장 일반적인 직렬화 형식이 JSON 배열이므로, 아래 예시는 그 형식으로 제시됩니다. 참조 [체인 전송하기](#transmitting) 에서 자세한 내용을 확인하세요. {% endhint %} ### 첫 번째 단계: 식별 원래 권한 보유자(즉, 사용자)를 식별하는 첫 번째 단계는 다음 조건을 충족해야 합니다: 1. 이 `유형` 가 [`SIGNER`](#SIGNER) 2. 이 `페이로드` 는 인코딩된 이더리움 계정입니다. 3. 이 `서명` 는 비어 있습니다. 예를 들면: ```json // 모든 인증 체인의 첫 단계: { "type": "SIGNER", "payload": "0xdB055877e6c13b6A6B25aBcAA29B393777dD0a73", "signature": "" } ``` 두 번째 단계는 하나의 `서명` 이 계정에서 나온 `페이로드`. ### 중간 단계: 위임 대리인이 사용자를 대신해 행동할 때, 대리인 각각에 대해 체인의 중간에 항목이 추가됩니다. 이러한 단계의 조건은 다음과 같습니다: 1. 유형은 [`ECDSA_EPHEMERAL`](#ECDSA_EPHEMERAL) 2. 이 `페이로드` 는 특별히 구성된 텍스트입니다(아래 참조). 이 `페이로드` 는 읽기 쉽고 파싱하기 쉽도록 설계되었습니다. 인간(지갑 UI를 사용할 때)과 프로그램(작성하고 검증할 때) 모두 이를 다루어야 하기 때문입니다. 대소문자를 구분하는 일반 텍스트가 정확히 3줄 포함됩니다: ```md 임시 주소: 만료: ``` 예를 들어, 이는 World Explorers가 로그인할 때 사용자에게 승인받을 임시 대리인 키를 생성할 때 사용하는 전형적인 페이로드입니다: ``` Decentraland 로그인 임시 주소: 0xBB9aDF0183b1742196A4Aa55622D5838f4f483a7 만료: 2023-02-25T13:00:19.730Z ``` 다음에 유의하세요: 1. 이 `임시 주소` 블록체인에서 자금이 있는 실제 이더리움 계정일 필요는 없습니다. 이 필드는 임시 공개 키만 나타낼 수 있습니다. 2. 이 `만료` 는 다음 형식으로 직렬화된 날짜시간입니다: [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) 형식입니다. UTC일 필요는 없습니다. 3. 이 만료일 때문에, 대리인 키는 주기적으로 사용자로부터 새 서명으로 갱신되어야 합니다. {% hint style="info" %} 모든 갱신마다 새 키를 생성하는 것이 표준 관행이며(따라서 이름이 `ECDSA_EPHEMERAL`). {% endhint %} 설명을 위해 값을 줄인 예시 위임 단계: ```json { "type": "ECDSA_EPHEMERAL", "payload": "Decentraland Login\n임시 주소: 0xBBa7...\n만료: 2021-01-25T...", "signature": "0x1370a4120a7cb0d2f6e4a5..." } ``` 다음 단계는 또 다른 위임이든 최종 승인 단계이든, 이 대리인의 키에서 나온 서명을 포함합니다. ### 마지막 단계: 승인 후에 `SIGNER` 가 지정되고 모든 `ECDSA_EPHEMERAL` 중간 서명 체인을 검증하여 대리인 키가 유효하다고 확인되면, 마지막 단계는 승인되어야 하는 실제 작업입니다. 이 `페이로드` 는 `유형` 의존합니다. 예를 들어, 사용자가 콘텐츠 서버에 새 프로필(또는 자신이 소유한 엔티티)을 업로드하는 경우, 마지막 요소는 다음 형식을 갖습니다: ```json { // 유형은 `payload`가 엔티티 ID임을 나타냅니다(세부 내용은 Content 섹션 참조): "type": "ECDSA_SIGNED_ENTITY", // 페이로드는 원시 ID 문자열입니다: "payload": "bafkreicfbg7ybpuoslkcf6x2vfnvzl5vwgqtb2pnheqiut2i4sgpblicqi", // 서명은 이전 단계의 계정(사용자 또는 대리인)이 생성합니다: "signature": "0x7e71dbbab..." } ``` 이 마지막 서명도 유효하면, 작업을 진행할 수 있습니다. ### 체인 전송하기 앞서 언급했듯이, 인증 체인의 가장 일반적인 직렬화 형식은 JSON 배열입니다. 이것이 권장되는 접근 방식입니다. 그러나 프로토콜은 이를 강제하지 않습니다. YAML, CSV 파일, 최적화된 바이너리 형식 또는 구분된 필드가 있는 간단한 문자열처럼 특정 사용 사례에 더 편리하다면 개발자는 대체 직렬화 전략을 사용할 수 있습니다. 프로토콜 자체에서 대체 직렬화의 예는 [`SignedFetch`](https://github.com/decentraland/docs/blob/main/runtime/modules/signed_fetch.md) 모듈에서 찾을 수 있으며, 여기서는 JSON 배열 대신 HTTP 헤더의 시퀀스를 사용합니다. ### 만료일 선택하기 대리인 키의 유효 기간을 선택할 때는 절충이 있습니다. 만료가 짧을수록 보안은 향상되지만, 만료가 길수록 사용자 경험은 좋아집니다(대리인은 사람의 상호작용을 통해 덜 자주 갱신하면 되기 때문입니다). 유효 시간 창을 어떻게 정할지에 대한 보편적인 전략은 없습니다. 참고로 재단의 World Explorer는 대리인 키에 대해 한 달 동안의 승인을 요청합니다. {% hint style="info" %} 임시 키는 절대로 자금을 보유하거나 디지털 자산을 전송할 능력을 가져서는 안 됩니다. 임시 키가 유출되더라도 금전적 손실로 이어지지 않는 것이 최종 사용자에게 훨씬 더 안전합니다. {% endhint %} ## 정형화 다음은 관련 프로세스에 대한 보다 형식적이고 정확한 정의입니다. 인증 체인을 성공적으로 처리하려면 이 지침을 따르세요. ### 생성 사용자를 위한 인증 체인을 작성하는 클라이언트는 다음 단계를 따릅니다: 1. 식별 단계를 추가합니다: 1. 다음을 `유형` 를 `SIGNER`. 2. 다음을 `페이로드` 사용자의 이더리움 주소로 설정합니다. 3. 다음을 `서명` 빈 문자열로 설정합니다. 2. 위임 단계를 추가합니다: 1. 기존 대리인 개인 키를 생성하거나 사용합니다(상호작용이 필요할 수 있음). 2. 대응하는 공개 키에서 파생된 대리인 이더리움 주소를 계산합니다. 3. 다음을 `유형` 를 `ECDSA_EPHEMERAL`. 4. 다음을 `만료` 를 미래의 날짜로 설정합니다. 5. 선택합니다 `목적` 을 이 키에 대해. 6. 다음을 `페이로드` 을 다음의 정확한 형식으로: ```md 임시 주소: 만료: ``` 7. 다음을 `서명` 필드를 `페이로드` 이전 키(사용자 또는 대리인)의 서명으로. 8. 모든 후속 대리인에 대해 반복합니다. 3. 작업 승인 단계를 추가합니다: 1. 다음을 `유형` 을 유효한 값으로([아래 참조](#types)) 2. 다음을 `페이로드` 을 유형별 값(예: 엔티티 ID)으로. 3. 다음을 `서명` 필드를 `페이로드` 이전 키(사용자 또는 대리인)의 서명으로. 4. 인증 체인을 검증자에게 보냅니다. ### 검증 검증을 구현하는 콘텐츠 서버와 제3자 서비스는 다음 단계를 따릅니다: 1. 식별 검증: 1. 확인하세요 `유형` 가 `SIGNER`. 2. 확인하세요 `페이로드` 는 사용자의 이더리움 주소입니다. 3. 확인하세요 `서명` 는 빈 문자열입니다. 2. 대리인 검증: 1. 확인하세요 `유형` 가 `ECDSA_EPHEMERAL`. 2. 확인하세요 `페이로드` 는 다음 형식이며 필드를 추출합니다: ```md 임시 주소: 만료: ``` 3. 확인하세요 `날짜` 가 아직 미래입니다. 4. 확인하세요 `목적` 는 귀하의 서비스에서 지원됩니다. 5. 확인하세요 `서명` 는 주어진 `페이로드` 및 이전 공개 키에 대해 유효합니다. 6. 모든 후속 대리인에 대해 반복합니다. 3. 작업 승인 검증: 1. 확인하세요 `유형` 는 유효한 값([아래 참조](#types)). 2. 확인하세요 `페이로드` 은 이 `유형`. 3. 확인하세요 `서명` 는 주어진 `페이로드` 및 이전 공개 키에 대해 유효합니다. 4. 인증 체인을 수락합니다. ### 표준 작업 유형 및 목적 이 `유형` 및 `페이로드` 식별 및 위임을 위한 값은 표준이며 위에서 설명한 대로 검증해야 하지만, 클라이언트와 서비스는 어떤 작업 `유형`, 그리고 그 `페이로드` 구조는 물론 `목적` 에 대해 자신들이 유효하다고 간주하는 프로토콜은 세 가지 표준 유형과 하나의 표준 목적을 정의합니다: **유형 `SIGNER`** **반드시** 초기 `유형` 체인의 `페이로드` 는 사용자의 이더리움 주소이며 `서명` 는 빈 문자열입니다. **유형 `ECDSA_EPHEMERAL`** **반드시** 이어야 합니다 `유형` 체인의 중간 단계에 대한 `페이로드` 는 위에서 설명한 형식입니다. **유형 `ECDSA_SIGNED_ENTITY`** 마지막 `유형` 는 엔티티 배포 승인을 위한 체인에서 `페이로드` 는 사용자가 소유한 엔티티의 ID입니다. **목적 `Decentraland 로그인`** 일반적인 `목적` World Explorers용으로, 월드에 로그인할 때와 대리인 키를 갱신할 때 모두 서명됩니다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.decentraland.org/contributor/contributor-ko/authentication/authchain.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.