> 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 프로토콜의 많은 작업은 사용자 Ethereum 계정의 서명이 포함된 권한 부여를 요구하거나 그로부터 이점을 얻습니다. 예를 들면: 1. 다음의 새 버전을 업로드 [엔터티](https://github.com/decentraland/docs/tree/main/content/entities.md) 사용자가 소유한 것(예: 프로필). 2. 제3자 서비스에 자신을 인증합니다. 3. 대리인이 자신을 대신해 행동하도록 승인합니다. 이러한 작업을 수행하려면, 사용자와 대리인은 자신의 의도를 설명하는 payload에 서명하고 생성해야 합니다 *인증 체인*. ## 소개 인증 체인은 일련의 검증 단계들을 묶으며, 각 단계는 이전 단계의 성공적인 검증에 의존합니다. 제한된 작업이 수행되려면 검증자가 모든 단계를 유효하다고 판단해야 합니다. 모든 체인은 사용자 식별로 시작하고, 요청된 작업을 나타내는 서명된 payload로 끝납니다. 따라서 가장 작은 체인은 다음을 나타내는 두 요소로 구성됩니다: ```md 1. 권한 주체는 Ethereum 계정 입니다 2. payload는 이며, 에 의해 승인됩니다 ``` 이 기본 체인은 서명의 공개 키가 주소와 일치하는지 검증하여 평가할 수 있습니다. 이 경우 이는 일반 서명과 동일합니다. 사용자가 대리인이 자신을 대신해 행동하도록 승인할 때, 중간 단계가 체인에 나타납니다. 예를 들어, 단일 위임이 있는 체인은 다음을 나타냅니다: ```md 1. 권한 주체는 Ethereum 계정 입니다 2. 대리인은 이며, 에 의해 까지 승인됩니다 3. payload는 이며, 에 의해 승인됩니다 ``` 대리인이 자신의 대리인을 승인하면 체인은 더 길어집니다. 즉, 승인은 추이적입니다. {% hint style="info" %} 인증 체인은 HTTPS에서 사용되는 TLS 인증서 체인에 비유할 수 있으며, 사용자는 루트 권한에 해당합니다. {% endhint %} 이 단일 대리인 체인은 Decentraland에서 사용되는 가장 일반적인 승인 형태입니다. 사용자는 World Explorer용 키에 승인하여 Ethereum 계정으로 모든 개별 작업에 서명할 필요를 없애기 때문입니다. ### 체인 구성하기 인증 체인의 각 단계에는 세 가지 정보가 포함됩니다: a `유형`, a `페이로드` 그리고 이에 대응하는 `서명`. | 필드 | 값 | | ------ | ----------------------------------------------- | | `유형` | 유형의 이름([아래 참조](#types)). | | `페이로드` | 유형에 따라 달라지는 문자열. | | `서명` | 다음의 16진수 인코딩된 Ethereum 서명 `페이로드`다음으로 시작하는 `0x`. | {% hint style="info" %} 인증 체인의 가장 일반적인 직렬화 형식은 JSON 배열이므로, 아래 예시는 그 형식으로 제시됩니다. 다음을 참조하세요 [체인 전송](#transmitting) 에서 더 자세히 확인하세요. {% endhint %} ### 첫 번째 단계: 식별 원래 권한 주체(즉, 사용자)를 식별하는 첫 번째 단계는 다음 조건을 충족해야 합니다: 1. 그 `유형` 이 [`SIGNER`](#SIGNER) 2. 그 `페이로드` 는 인코딩된 Ethereum 계정입니다. 3. 그 `서명` 는 비어 있습니다. 예를 들면: ```json // 모든 인증 체인의 첫 번째 단계: { "type": "SIGNER", "payload": "0xdB055877e6c13b6A6B25aBcAA29B393777dD0a73", "signature": "" } ``` 두 번째 단계는 하나의 `서명` 이 계정에서 온 `페이로드`. ### 중간 단계: 위임 대리인이 사용자를 대신해 행동할 때, 각 대리인마다 체인의 중간에 항목이 추가됩니다. 이러한 단계의 조건은 다음과 같습니다: 1. 유형은 [`ECDSA_EPHEMERAL`](#ECDSA_EPHEMERAL) 2. 그 `페이로드` 는 특별히 구성된 텍스트입니다(아래 참조). 그 `페이로드` 사람(지갑 UI를 사용할 때)과 프로그램(구성하고 검증할 때) 모두가 이를 다뤄야 하므로, 읽기 쉽고 파싱하기 쉽도록 설계되었습니다. 대소문자를 구분하는 일반 텍스트 3줄이 정확히 포함됩니다: ```md 임시 주소: 만료: ``` 예를 들면, 이것은 World Explorer가 로그인 중 사용자 승인을 위해 임시 대리인 키를 생성할 때 사용하는 일반적인 payload입니다: ``` Decentraland 로그인 임시 주소: 0xBB9aDF0183b1742196A4Aa55622D5838f4f483a7 만료: 2023-02-25T13:00:19.730Z ``` 다음에 유의하세요: 1. 그 `임시 주소` 블록체인에 자금이 있는 실제 Ethereum 계정일 필요는 없습니다. 이 필드는 임시 공개 키만 나타낼 수 있습니다. 2. 그 `만료` 는 직렬화된 datetime 형식의 [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", // payload는 원본 ID 문자열입니다: "payload": "bafkreicfbg7ybpuoslkcf6x2vfnvzl5vwgqtb2pnheqiut2i4sgpblicqi", // 서명은 이전 단계의 계정(사용자 또는 대리인)에 의해 생성됩니다: "signature": "0x7e71dbbab..." } ``` 이 마지막 서명도 유효하면 작업을 진행할 수 있습니다. ### 체인 전송 위에서 언급했듯이, 인증 체인의 가장 일반적인 직렬화 형식은 JSON 배열입니다. 이것이 권장되는 방식입니다. 그러나 프로토콜이 이를 강제하지는 않습니다. 개발자는 특정 사용 사례에 더 편리하다면 YAML, CSV 파일, 최적화된 이진 형식 또는 구분된 필드를 가진 단순 문자열 같은 대체 직렬화 방식을 사용할 수 있습니다. 프로토콜 자체 내에서의 대체 직렬화 예시는 다음에서 찾을 수 있습니다: [`SignedFetch`](https://github.com/decentraland/docs/tree/main/runtime/modules/signed_fetch.md) 모듈에서 볼 수 있으며, 이 모듈은 JSON 배열 대신 HTTP 헤더의 시퀀스를 사용합니다. ### 만료일 선택하기 대리인 키의 유효 기간을 선택할 때는 상충 관계가 있습니다: 만료 기간이 짧을수록 보안은 높아지지만, 만료 기간이 길수록 사용자 경험은 좋아집니다(대리인을 사람이 상호작용하여 갱신해야 하는 빈도가 낮아지기 때문입니다). 유효 기간을 어떻게 정할지에 대한 보편적인 전략은 없습니다. 참고로 Foundation의 World Explorer는 자신의 대리인 키에 대해 한 달 동안의 승인을 요청합니다. {% hint style="info" %} 임시 키는 절대로 자금을 보유하거나 디지털 자산을 전송할 수 있는 능력을 가져서는 안 됩니다. 임시 키가 유출되어도 재정 손실로 이어지지 않는다면 최종 사용자는 훨씬 더 안전합니다. {% endhint %} ## 형식화 다음은 관련 프로세스에 대한 더 형식적이고 정확한 정의입니다. 인증 체인을 성공적으로 처리하려면 다음 지침을 따르세요. ### 생성 사용자를 위한 인증 체인을 구성하는 클라이언트는 다음 단계를 따릅니다: 1. 식별 단계를 추가합니다: 1. 다음을 설정합니다: `유형` 로 `SIGNER`. 2. 다음을 설정합니다: `페이로드` 사용자의 Ethereum 주소로 3. 다음을 설정합니다: `서명` 빈 문자열로 2. 위임 단계를 추가합니다: 1. 기존 대리인 개인 키를 생성하거나 사용합니다(상호작용이 필요할 수 있음). 2. 해당 공개 키에서 파생된 대리인 Ethereum 주소를 계산합니다. 3. 다음을 설정합니다: `유형` 로 `ECDSA_EPHEMERAL`. 4. 다음을 설정합니다: `만료` 를 미래 날짜로 5. 다음을 선택합니다: `목적` 을 이 키에 대해 6. 다음을 설정합니다: `페이로드` 을 정확히 다음 형식으로 ```md 임시 주소: 만료: ``` 7. 다음을 설정합니다: `서명` 필드를 `페이로드` 이전 키(사용자 또는 대리인)의 서명으로 8. 후속 모든 대리인에 대해 반복합니다. 3. 작업 승인 단계를 추가합니다: 1. 다음을 설정합니다: `유형` 유효한 값으로([아래 참조](#types)) 2. 다음을 설정합니다: `페이로드` 유형별 값(예: 엔터티 ID)으로 3. 다음을 설정합니다: `서명` 필드를 `페이로드` 이전 키(사용자 또는 대리인)의 서명으로 4. 인증 체인을 검증자에게 전송합니다. ### 검증 검증을 구현하는 콘텐츠 서버와 제3자 서비스는 다음 단계를 따릅니다: 1. 식별을 검증합니다: 1. 다음을 확인하세요 `유형` 이 `SIGNER`. 2. 다음을 확인하세요 `페이로드` 는 사용자의 Ethereum 주소입니다. 3. 다음을 확인하세요 `서명` 는 빈 문자열입니다. 2. 대리인을 검증합니다: 1. 다음을 확인하세요 `유형` 이 `ECDSA_EPHEMERAL`. 2. 다음을 확인하세요 `페이로드` 는 이 형식이며, 다음 필드를 추출합니다: ```md 임시 주소: 만료: ``` 3. 다음을 확인하세요 `날짜` 는 여전히 미래입니다. 4. 다음을 확인하세요 `목적` 는 귀하의 서비스에서 지원됩니다. 5. 다음을 확인하세요 `서명` 는 주어진 `페이로드` 및 이전 공개 키 6. 후속 모든 대리인에 대해 반복합니다. 3. 작업 승인을 검증합니다: 1. 다음을 확인하세요 `유형` 는 유효한 값입니다([아래 참조](#types)). 2. 다음을 확인하세요 `페이로드` 는 이 ...에 대해 유효합니다 `유형`. 3. 다음을 확인하세요 `서명` 는 주어진 `페이로드` 및 이전 공개 키 4. 인증 체인을 수락합니다. ### 표준 작업 유형 및 목적 그 `유형` 및 `페이로드` 식별 및 위임에 대한 값은 표준이며 위에서 설명한 대로 검증해야 하지만, 클라이언트와 서비스는 어떤 작업에 대해서도 합의할 수 있습니다 `유형`, 그리고 그 `페이로드` 구조와, 또한 ...를 설정할 수 있습니다 `목적` 그들이 유효하다고 간주하는 대리인 키에 대한 프로토콜은 세 가지 표준 유형과 하나의 표준 목적을 정의합니다: **타입 `SIGNER`** **반드시** 초기 `유형` 체인에서 ...이어야 하며, `페이로드` 는 사용자의 Ethereum 주소이고 `서명` 는 빈 문자열입니다. **타입 `ECDSA_EPHEMERAL`** **반드시** 이어야 합니다 `유형` 체인의 중간 단계에 대해, ...이며, `페이로드` 는 위에서 설명한 형식입니다. **타입 `ECDSA_SIGNED_ENTITY`** 최종 `유형` 엔터티 배포 승인을 위한 체인에서 ...이며, `페이로드` 는 사용자가 소유한 엔터티의 ID입니다. **목적 `Decentraland 로그인`** 일반적인 `목적` World Explorer의 경우, 월드에 로그인할 때와 대리인 키를 갱신할 때 모두 서명되는 --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.