다음을 통해 공유

FAQ(질문과 대답)

  • 아티클

이 페이지에는 확인 가능한 자격 증명 및 탈중앙화 ID에 대한 일반적인 질문과 대답이 포함되어 있습니다. 질문은 다음 섹션으로 구성됩니다.

기본 사항

DID란?

DID(탈중앙화 식별자)는 리소스에 대한 액세스를 보호하고, 자격 증명을 서명 및 확인하고, 애플리케이션 데이터 교환을 용이하게 하는데 사용할 수 있는 고유한 식별자입니다. 기존 사용자 이름 및 이메일 주소와 달리 DID 자체(개인, 디바이스 또는 회사)를 소유하고 제어합니다. DID는 외부 조직 또는 신뢰할 수 있는 매개체와는 독립적으로 존재합니다. W3C 탈중앙화 식별자 사양에서 DID를 자세히 설명합니다.

DID가 필요한 이유는 무엇인가요?

디지털 신뢰를 사용하려면 기본적으로 참가자가 자신의 ID를 소유하고 제어해야 하며 ID는 식별자에서 시작됩니다. 일별 대규모 시스템 위반 및 중앙 집중식 식별자 허니팟에 대한 공격이 만연한 시대에서 ID의 탈중앙화는 소비자와 비즈니스에게 중요한 보안 니즈로 자리잡고 있습니다. ID를 소유하고 제어하는 개인은 확인 가능한 데이터와 증명을 교환할 수 있습니다. 분산 자격 증명 환경을 사용하면 현재 수동 및 인건비 집약적인 많은 비즈니스 프로세스를 자동화할 수 있습니다.

확인 가능한 자격 증명이란?

자격 증명은 일상 생활의 일부입니다. 운전 면허증은 자동차를 운전할 수 있다는 것을 어설션하는 데 사용됩니다. 대학 학위는 교육 수준을 입증하는 데 사용될 수 있으며 정부 발급 여권을 통해 국가와 지역 간 여행이 가능합니다. 확인 가능한 자격 증명은 암호화된 보안, 개인 정보 보호, 컴퓨터 확인 가능한 방식으로 웹에서 이러한 종류의 자격 증명을 표현하는 메커니즘을 제공합니다. W3C가 확인 가능한 자격 증명 사양에서 확인 가능한 자격 증명을 자세히 설명합니다.

개념적 질문

사용자가 휴대폰을 분실하면 어떻게 되나요? ID를 복구할 수 있나요?

여러 가지 방법으로 사용자에게 복구 메커니즘을 제공할 수 있으며, 각 방법에는 고유한 장단점이 있습니다. Microsoft는 현재 사용자의 개인 정보 및 자체 독립성을 존중하면서 편의성과 보안을 제공하는 옵션을 평가하고 복구 방법을 디자인하고 있습니다.

사용자가 발급자 또는 검증 도구에서 요청을 신뢰하려면 어떻게 해야 하나요? DID가 진짜 조직의 DID인지 어떻게 알 수 있나요?

이미 알려진 기존 시스템인 도메인 이름에 DID를 연결하기 위해 Decentralized Identity Foundation의 잘 알려진 DID 구성 사양을 구현했습니다. Microsoft Entra Verified ID를 사용하여 만들어진 각 DID에는 DID 문서에 인코딩된 루트 도메인 이름을 포함하는 옵션이 있습니다. 자세한 내용은 분산 식별자에 도메인 연결 문서를 참조하세요.

확인된 ID의 확인 가능한 자격 증명에 대한 크기 제한은 무엇인가요?

  • 발급 요청의 경우 - 1MB
  • 확인 가능한 자격 증명의 사진 - 1MB
  • 수신 없이 콜백 결과 10MB

라이선싱 요구 사항은 무엇인가요?

확인 가능한 자격 증명을 발급하기 위한 특별한 라이선스 요구 사항은 없습니다.

Microsoft Entra Verified ID 서비스를 재설정하려면 어떻게 해야 하나요?

다시 설정하려면 Microsoft Entra 확인된 ID 서비스를 옵트아웃했다가 다시 옵트인해야 합니다. 기존의 확인 가능한 자격 증명 구성이 다시 설정되고 테넌트는 발급 및 프레젠테이션 중에 사용할 새 DID를 가져옵니다.

  1. 옵트아웃 지침을 따릅니다.
  2. Microsoft Entra Verified ID 배포 단계를 수행하여 서비스를 다시 구성합니다.
    1. 확인된 ID를 수동으로 설정하는 경우 Azure Key Vault 위치를 동일하거나 가장 가까운 지역에 선택합니다. 이렇게 하면 성능 및 대기 시간 문제가 방지됩니다.
  3. 확인 가능한 자격 증명 서비스 설정을 완료합니다. 자격 증명을 다시 만들어야 합니다.
    1. 테넌트를 발급자로 구성해야 하는 경우 스토리지 계정을 유럽 지역에 있는 확인 가능한 자격 증명 서비스로 사용하는 것이 좋습니다.
    2. 또한 테넌트가 이제 새 DID를 보유하고 있으므로 새 자격 증명을 발급해야 합니다.

Microsoft Entra 테넌트의 지역을 확인하려면 어떻게 해야 하나요?

  1. Azure Portal에서 Microsoft Entra Verified ID 배포에 사용하는 구독에 대한 Microsoft Entra ID로 이동합니다.
  2. 관리에서 속성 선택 설정 삭제 및 옵트아웃
  3. 국가 또는 지역에 대한 값을 참조하세요. 값이 유럽의 국가 또는 지역인 경우 Microsoft Entra Verified ID 서비스는 유럽에 설정됩니다.

Microsoft Entra 확인된 ID는 DID 메서드로 ION을 지원하나요?

확인된 ID는 2023년 12월까지 미리 보기에서 DID:ION 메서드를 지원했으며 그 이후에는 중단되었습니다.

did:ion에서 did:web으로 어떻게 이동하나요?

did:ion에서 did:web으로 이동하려면 관리 API를 통해 다음 단계를 따릅니다. 권한을 변경하려면 모든 자격 증명을 재발급해야 합니다.

기존 did:ion 자격 증명 정의 내보내기

  1. did:ion 권한의 경우 포털을 사용하여 기존 자격 증명의 모든 표시 및 규칙 정의를 복사합니다.
  2. 권한이 두 개 이상인 경우 did:ion 권한이 기본 권한이 아닌 경우 관리 API를 사용해야 합니다. 확인된 ID 테넌트에서 관리 API를 사용하여 연결하고 권한을 나열하여 did:ion 권한에 대한 권한 ID를 가져옵니다. 그런 다음 계약 목록 API를 사용하여 계약을 내보내고 결과를 파일에 저장하여 다시 만들 수 있습니다.

새로운 did:web 권한 만들기

  1. 온보딩 API를 사용하여 새 did:web 권한을 만듭니다. 또는 테넌트에 did:ion 권한이 하나만 있는 경우 서비스 옵트아웃을 수행한 후 옵트인 작업을 수행하여 확인된 ID 구성으로 다시 시작할 수도 있습니다. 이 경우 빠른 설정과 수동 설정 중에서 선택할 수 있습니다.
  2. 관리 API를 사용하여 did:web 권한을 설정하는 경우 DID 문서 생성을 호출하여 DID 문서를 생성하고 잘 알려진 문서 생성을 호출한 다음 해당 잘 알려진 경로에 JSON 파일을 업로드합니다.

자격 증명 정의 다시 만들기

새 did:web 권한을 만든 후 자격 증명 정의를 다시 만들어야 합니다. 선택을 취소하고 다시 온보딩한 경우 포털을 통해 이를 수행할 수 있으며, 계약을 다시 만들려면 계약 만들기 API를 사용해야 합니다.

기존 애플리케이션 업데이트

  1. 새 did:web authority를 사용하려면 기존 애플리케이션(발급자/검증자 앱)을 업데이트합니다. 발급 앱의 경우 자격 증명 매니페스트 URL도 업데이트합니다.
  2. 새로운 did:web 기관에서 테스트 발급 및 확인 흐름이 이루어집니다. 테스트가 성공하면 did:ion 권한 삭제를 위한 다음 단계로 진행합니다.

did:ion 권한 삭제

옵트아웃하지 않고 다시 온보딩하지 않은 경우 이전 did:ion 권한을 제거해야 합니다. did:ion 권한을 삭제하려면 권한 삭제 API를 사용합니다.

예, 서비스를 재구성한 후 테넌트는 검증 가능한 자격 증명을 발급하고 확인하기 위해 새로운 DID를 사용합니다. 도메인과 새 DID를 연결해야 합니다.

Microsoft에 "이전 DID"를 검색하도록 요청할 수 있나요?

아니요, 현재로서는 서비스를 거부한 후 테넌트의 DID를 유지할 수 없습니다.

ngrok를 사용할 수 없습니다. 어떻게 해야 하나요?

샘플 배포 및 실행을 위한 자습서에서 ngrok 도구를 애플리케이션 프록시로 사용하는 방법을 설명합니다. 경우에 따라 이 도구는 회사 네트워크에서 IT 관리자가 사용하지 못하도록 차단할 수도 있습니다. 다른 대안은 샘플을 Azure App Service에 배포하고 이를 클라우드에서 실행하는 것입니다. 다음 링크는 해당 샘플을 Azure App Service에 배포하는 데 도움이 됩니다. 무료 가격 책정 계층은 샘플을 호스팅하는 데 충분합니다. 각 자습서에서 먼저 Azure App Service 인스턴스를 만들고, 이미 앱이 있으므로 앱 만들기를 건너뛰고 자습서를 계속하여 배포해야 합니다.

사용 중인 샘플의 언어에 관계없이 Azure AppService 호스트 이름 https://something.azurewebsites.net이 공용 엔드포인트로 사용됩니다. 작동하도록 추가 항목을 구성할 필요가 없습니다. 코드 또는 구성을 변경할 경우 샘플을 Azure AppServices에 다시 배포해야 합니다. 문제 해결/디버깅은 콘솔 창에 대한 추적으로 오류가 표시되는 로컬 컴퓨터에서 샘플을 실행하는 것만큼 쉽지는 않지만 로그 스트림을 사용하여 거의 동일한 작업을 수행할 수 있습니다.

다음 단계