검수요청.png검수요청.png

분산아이디 인증

위키원
Asadal (토론 | 기여)님의 2020년 8월 25일 (화) 20:00 판 (Asadal님이 DID Auth 문서를 분산아이디 인증 문서로 이동했습니다)
이동: 둘러보기, 검색

DID Auth 또는 DID Authentication는 여러 가지 방법으로 사용되었으며 현재 제대로 정의되어 있지 않다. DID Auth를 웹브라우저, 모바일 장치 및 기타 에이전트와 같은 다양한 구성요소의 도움을 받아 아이디 보유자분산아이디를 통제하고 있음을 신뢰할 수 있는 당사자에게 증명하는 의식으로 정의한다.

개요

여러 가지 방법으로 사용되었으며 현재 제대로 정의되어 있지 않다. DID Auth를 웹브라우저, 모바일 장치 및 기타 에이전트와 같은 다양한 구성요소의 도움을 받아 아이디 보유자가 분산아이디를 통제하고 있음을 신뢰할 수 있는 당사자에게 증명하는 의식으로 정의한다. 이는 DID 문서의 '인증' 개체에 지정된 메커니즘을 사용하여 분산아이디에 대한 제어를 입증하는 것을 의미한다. 이 작업은 다양한 데이터 형식, 프로토콜 및 흐름을 사용하여 수행될 수 있다. DID Auth에는 상호 인증된 통신 채널을 구축하고 웹사이트 및 응용 프로그램에 대해 인증하는 기능이 포함된다. 권한 부여, 확인 가능한 자격 증명 및 기능은 DID Auth를 기반으로 구축된다. 다른 인증 방법과 마찬가지로 DID Auth는 신뢰할 수 있는 당사자가 아이디 보유자의 DID를 인증하는 질문-응답 주기에 의존한다. 이 주기 동안 아이디 보유자는 인증 방지 메커니즘의 실행을 통해 DID 기록 작성 중에 생성 및 배포된 인증 자료에 대한 제어를 시연한다.[1]

특징

관련 개념

  • 인증(Authentication) : 아이디 보유자가 검증인(또는 서비스 공급자)에게 아이디 보유자가 해당 DID와 관련된 DID Document(DID 문서)에 설명된 메커니즘을 사용하여 DID를 제어한다는 것을 증명하는 행위이다.
  • 권한(Authorization) : DID 자체 또는 다른 컨텍스트에서의 작업을 포함하여 특정 작업을 수행하기 위해 아이디 보유자의 권한과 그 권한을 설정하는 프로세스이다.
  • 분산아이디(Decentralized Identifier) : 분산 원장 기술 또는 분산 네트워크의 다른 형태에 등록되어 있기 때문에 중앙화된 등록 기관을 필요로하지 않는 전 세계적으로 고유한 식별자이다.
  • DID 문서(DID Document) : 개인이나 조직이 인증에 사용할 수 있는, 즉 DID 제어권을 증명할 수 있는 공개키 및 익명의 생체 인식과 같은 인증 수단을 포함하여 DID를 설명하는 메타데이터가 포함된 구조화된 문서이다. DID 문서에는 엔티티를 설명하는 다른 속성이나 주장이 포함될 수도 있다.
  • DID 기록(DID Record) : DID와 관련된 DID 문서의 결합이다.
  • 아이디 보유자(Identity Owner) : DID를 생성한 개인, 조직 또는 사물로, 이들은 DID 문서의 대상인 DID로 식별되며 DID를 갱신하거나 취소할 수 있는 최종 권한을 가진다.
  • 신뢰 당사자(Relying Party) : DID Auth 프로토콜을 사용하여 신원 보유자를 인증하는 개인, 조직 또는 사물이다. 다른 사양에서는 'verifier'라고도 한다.
  • 검증 가능한 증명(Verifiable Credentials) : 변조 방지가 가능하고 저작자가 암호화로 검증될 수 있는 주제에 대해 발행자가 작성한 진술인 하나 이상의 클레임 세트 변조 방지가 있고 암호로 가능한 발행인이 생성한 하나 이상의 주장 집이다. 또한 검증 가능한 증명서는 검증 가능한 주장으로 기재되어 있다. 줄여서 VC라고 표기한다.[2]

DID Auth와 검증가능한 자격증명

DID Auth은 DID에 대한 제어를 증명하는 것이지만 DID와 관련된 검증가능한 자격증명 교환은 DID Auth와 관련이 있다. DID Auth와 검증가능한 자격증명 간의 관계는 다음과 같은 몇 가지 개념적인 방법으로 생각할 수 있다. DID Auth 및 검증가능한 자격증명 교환은 별개이다. 두 당사자 사이의 상호작용을 시작할 때, 그들은 인증(상호 또는 한 방향으로만)을 해야 한다. 이 작업이 완료되면 검증가능한 자격증명 교환 프로토콜을 실행하여 양 당사자가 서로에 대해 자세히 알아보고 승인 결정을 내릴 수 있다. 검증가능한 자격증명 교환은 DID Auth에 대한 확장이다. 이 접근 방식에서는 식별자에 대한 제어 증명과 검증가능한 자격증명 소유 증명이 밀접하게 관련되어 있으며, 단일 프로토콜이 두 가지 목적으로 모두 사용된다. 검증 가능한 인증 정보는 프로토콜의 '선택적 필드'이다. 식별자에 대한 전용으로 제어하기 위해 빈 확인 가능한 자격 증명 집합이 교환된다. DID Auth는 다음과 같은 특정 유형의 검증가능한 자격증명이다. DID Auth는 상상할 수 있는 가장 사소한 검증가능한 자격증명, 즉 '나는 나다'라고 적힌 자가 발급된 검증가능한 자격증명의 교환으로 생각할 수 있다. 이러한 관점에서 DID Auth와 기타 검증가능한 자격증명 교환 간의 분리는 모호하며, 두 가지 모두 단일 범용 프로토콜의 일부이다.

DID 레코드 생성

DID Auth에는 DID 레코드 생성 중에 생성된 인증 자료가 필요하다. DID 사양에 명시된대로 DID Auth를 준수하는 DID 레코드를 생성하는 단계는 다음과 같다. 1) 관련 DID 메소드 사양에 지정된대로 NEW_DID를 생성한다. 2) 관련 DID 메소드 사양에 지정된대로 NEW_DID_DOCUMENT를 생성한다. id 속성을 NEW_DID (DID 제목) 값으로 설정한다. 3) 증명 메커니즘 배열에서 하나 이상의 인증 유형을 선택한다. NEW_DID_DOCUMENT type의 authentication 개체에 속성을 기록한다. 4) NEW_DID 인증 중에 나중에 사용할 인증 자료를 생성한다. 인증 유형은 증명 메커니즘에 대한 인증 자료를 생성하는 방법을 결정한다. 5) 인증 자료를 직접 또는 파생 자료로 NEW_DID_DOCUMENT에 저장하고 아이디 보유자가 저장할 수 있도록 통신하고 저장한다. 선택한 증명 메커니즘이 비대칭 키를 기반으로 하는 경우 NEW_DID_DOCUMENT의 인증자료 publickey는 DID 문서의 개체에 기록된다.

* DID 문서의 예제 authentication및 publicKey개체
{
        "@context": "https://w3id.org/did/v1",
        "id": "did:example:123456789abcdefghi",
        "authentication": [{
                "type": "RsaSignatureAuthentication2018",
                "publicKey": "did:example:123456789abcdefghi#keys-1"
        }, {
                "type": "Ed25519SignatureAuthentication2018",
                "publicKey": "did:example:123456789abcdefghi#keys-2"
        }],
         "publicKey": [{
                "id": "did:example:123456789abcdefghi#keys-1",
                "type": "RsaVerificationKey2018",
                "owner": "did:example:123456789abcdefghi",
                "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
         }, {
                "id": "did:example:123456789abcdefghi#keys-2",
                "type": "Ed25519VerificationKey2018",
                "owner": "did:example:123456789abcdefghi",
                "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
         }]
}

DID Auth는 아이디 보유자와 신뢰 당사자간에 문제와 응답을 교환하기 위해 다른 전송을 사용할 수 있다. 이러한 전송 중 하나는 DID Auth 서비스 엔드 포인트에 대한 HTTP POST 호출을 사용한다. 이 서비스 엔드 포인트는 DID 문서에서 찾을 수 있다.

* DID 문서의 예제 DID Auth 서비스 엔드 포인트
{
        "@context": "https://w3id.org/did/v1",
        "id": "did:example:123456789abcdefghi",
        "service": {
                "type": "DidAuthService",
                "serviceEndpoint": "https://auth.example.com/did:example:123456789abcdefg"
        }
}

DID 인증

다른 인증 방법과 마찬가지로 DID Auth는 신뢰 당사자가 아이디 보유자 의 DID를 인증 하는 시도-응답주기에 의존한다. 이 주기 동안 아이디 보유자 는 인증 증명 메커니즘의 실행을 통해 DID 레코드 생성 중에 생성 및 배포 된 인증 자료의 제어를 보여준다. 방법 정체성 보유자 또는 에이전트 만남 인증 요청뿐만 아니라, 도전의 포맷은, 상황에 따라 달라질 수 있다. 예를 들어 웹 사이트에서 "DID 인증으로 로그인"버튼이나 큐알코드를 발견 할 수 있다. 또는 API 호출의 경우 신뢰 당사자 가 인증을 요청하여 요청에 응답 할 수 있다(401 Unauthorized DID Auth가 HTTP 이외의 많은 사용 사례를 다루지 만 HTTP 응답은 전형적인 예이다).

DID 인증 아키텍처

분산아이디인증 아키텍처는 Challenge(요청), Response(회신), Transports(전송)에 근거하여 구성할 수 있다. 아키텍처 구성시 참고사항은, 1) 요청 시점에서 Relying Party(Service Provider)의 분산아이디를 알고 있는지 여부, 2) 분산아이디인증 요청의 전송 메커니즘, 3) 인증자료의 저장위치, 4) 분산아이디인증 응답의 전송 메커니즘이다. 사용 사례를 보자면 아래와 같다.[3]

  • 사례 1
1) 신뢰 당사자의 웹 페이지는 신원 보유자의 웹 브라우저에 QR코드(요청 포함)를 표시한다.
2) 신원 보유자의 모바일 앱은 신원 보유자의 웹 브라우저에서 QR코드(요청 포함)를 스캔한다.
3) 신원 보유자의 모바일 앱은 신뢰 당사자의 웹 서버에 HTTP POST(회신 포함)를 보낸다.
4) 신뢰 당사자의 웹 서버는 신뢰 당사자의 웹 페이지를 통해 HTTP GET(회신 포함)으로 폴링된다.
  • 사례 2
1) 신뢰 당사자의 모바일 웹 페이지는 딥링크(요청 포함)를 통해 아이디 보유자의 모바일 앱으로 리디렉션된다.
2) 아이디 보유자의 모바일 앱은 신뢰 당사자의 웹 서버에 대한 응답과 함께 리턴 링크를 연다.
3) 신뢰 당사자의 웹 서버가 신뢰 당사자의 모바일 웹 페이지를 업데이트한다.
  • 사례 3
1) 신뢰 당사자 웹 페이지에는 신뢰 당사자 웹 서버를 호출하는 링크 또는 버튼이 있다.
2) 신뢰 당사자의 웹 서버는 자격 증명 보유자의 분산아이디인증 서비스에 HTTP POST(요청 포함)를 보낸다.
3) 신원 보유자의 분산아이디인증 서비스는 신원 보유자의 모바일 앱에 푸시 알림(요청 포함)을 보낸다.
4) 아이디 보유자의 모바일 앱은 신뢰 당사자의 웹 서버에 HTTP POST(회신 포함)를 보낸다.
  • 사례 4
1) 신뢰 당사자가 웹 페이지에는 신뢰 당사자 웹 서버를 호출하는 링크 또는 버튼이 있다.
2) 신뢰 당사자의 웹 서버는 자격 증명 보유자의 분산아이디인증 서비스에 HTTP POST(요청 포함)를 보낸다.
3) 신원 보유자의 분산아이디인증 서비스는 신원 보유자의 모바일 앱에 푸시 알림(요청 포함)을 보낸다.
4) 신원 보유자의 모바일 앱은 신원 보유자의 분산아이디인증 서비스에 HTTP POST(회신 포함)를 보낸다.
5) 아이디 보유자의 분산아이디인증 서비스는 신뢰 당사자의 웹 서버에 HTTP POST(회신 포함)를 보낸다.
6) 신뢰 당사자의 웹서버는 신뢰 당사자의 웹 페이지에 의해 HTTP GET(회신 포함)으로 폴링된다.
  • 사례 5
1) 신뢰 당사자 웹 페이지에는 신뢰 당사자 웹 서버를 호출하는 링크 또는 버튼이 있다.
2) 신뢰 당사자의 웹 서버는 자격 증명 보유자의 웹 브라우저에 요청이 있는 HTTP 리디렉션을 보낸다.
3) 신원 보유자의 웹 브라우저는 요청된 신원 보유자의 분산아이디인증 웹 페이지로 HTTP 리디렉션을 따른다.
4) 신원 보유자의 분산아이디인증 웹 페이지는 신원 보유자의 모바일 앱 또는 다른 장치와 선택적으로 상호 작용한다.
5) 아이디 보유자의 분산아이디인증 웹 페이지는 HTTP 응답을 따라 신뢰 당사자의 웹 서버로 이동한다.
6) 신뢰 당사자의 웹 서버가 신뢰 당사자의 웹 페이지를 업데이트한다.

각주

  1. shannona, 〈Introduction to DID Auth〉, 《GitHub》, 2018-07-31
  2. 베니, 〈(DID 기술 분석) DID Auth-2〉, 《미디엄》, 2019-07-30
  3. 베니, 〈(DID 기술 분석)DID Auth-1〉, 《미디엄》, 2019-07-29

참고자료

같이 보기


  검수요청.png검수요청.png 이 분산아이디 인증 문서는 블록체인 기술에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.