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 Verified ID 서비스를 옵트아웃했다가 다시 옵트아웃해야 합니다. 기존의 확인 가능한 자격 증명 구성이 다시 설정되고 테넌트는 발급 및 프레젠테이션 중에 사용할 새 DID를 가져옵니다.
- 옵트아웃 지침을 따릅니다.
- Microsoft Entra Verified ID 배포 단계를 수행하여 서비스를 다시 구성합니다.
- 확인된 ID를 수동으로 설정하는 경우 Azure Key Vault 위치를 동일하거나 가장 가까운 지역에 선택합니다. 동일한 지역을 선택하면 성능 및 대기 시간 문제가 방지됩니다.
- 확인 가능한 자격 증명 서비스 설정을 완료합니다. 자격 증명을 다시 만들어야 합니다.
- 또한 테넌트가 이제 새 DID를 보유하고 있으므로 새 자격 증명을 발급해야 합니다.
Microsoft Entra 테넌트의 지역을 확인하려면 어떻게 해야 하나요?
Azure Portal에서 Microsoft Entra Verified ID 배포에 사용하는 구독에 대한 Microsoft Entra ID로 이동합니다.
관리에서 속성을 선택합니다.
국가 또는 지역에 대한 값을 참조하세요. 값이 유럽의 국가 또는 지역인 경우 Microsoft Entra Verified ID 서비스는 유럽에 설정됩니다.
Microsoft Entra 확인된 ID는 DID 메서드로 ION을 지원하나요?
확인된 ID는 2023년 12월까지 미리 보기에서 DID:ION 메서드를 지원했으며 그 이후에는 중단되었습니다.
did:ion에서 did:web으로 어떻게 이동하나요?
did:web
에서 did:ion
으로 이동하려면 관리 API를 통해 다음 단계를 따릅니다. 권한을 변경하려면 모든 자격 증명을 재발급해야 합니다.
기존 did:ion 자격 증명 정의 내보내기
-
did:ion
권한의 경우 포털을 사용하여 기존 자격 증명의 모든 표시 및 규칙 정의를 복사합니다. - 권한이 두 개 이상인 경우
did:ion
권한이 기본 권한이 아닌 경우 관리 API를 사용해야 합니다. 확인된 ID 테넌트에서 관리 API를 사용하여 연결하고 권한을 나열하여did:ion
권한에 대한 권한 ID를 가져옵니다. 그런 다음 계약 목록 API를 사용하여 계약을 내보내고 결과를 파일에 저장하여 다시 만들 수 있습니다.
새로운 did:web 권한 만들기
-
온보딩 API를 사용하여 새
did:web
권한을 만듭니다. 또는 테넌트에 did:ion 기관 하나만 있는 경우 서비스 옵트아웃을 수행한 다음, 확인된 ID 구성으로 다시 시작하는 옵트인 작업을 수행할 수도 있습니다. 이 경우 빠른 설정과 수동 설정 중에서 선택할 수 있습니다. - 관리 API를 사용하여 did:web 권한을 설정하는 경우 DID 문서 생성을 호출하여 DID 문서를 생성하고 잘 알려진 문서 생성을 호출한 다음 해당 잘 알려진 경로에 JSON 파일을 업로드합니다.
자격 증명 정의 다시 만들기
새 did:web
권한을 만들 때 자격 증명 정의를 다시 만들어야 합니다. 선택을 취소하고 다시 온보딩한 경우 포털을 통해 이를 수행할 수 있으며, 계약을 다시 만들려면 계약 만들기 API를 사용해야 합니다.
기존 애플리케이션 업데이트
- 새
did:web authority
를 사용하려면 기존 애플리케이션(발급자/검증자 앱)을 업데이트합니다. 발급 앱의 경우 자격 증명 매니페스트 URL도 업데이트합니다. - 새로운 did:web 기관에서 테스트 발급 및 확인 흐름이 이루어집니다. 테스트가 성공하면 did:ion 권한 삭제를 위한 다음 단계로 진행합니다.
did:ion 권한 삭제
옵트아웃하고 다시 등록하지 않은 경우 이전 did:ion
권한을 제거해야 합니다. did:ion 권한을 삭제하려면 권한 삭제 API를 사용합니다.
Microsoft Entra Verified ID 서비스를 재구성하는 경우 내 DID를 내 도메인에 다시 연결해야 하나요?
예, 서비스를 재구성한 후 테넌트는 검증 가능한 자격 증명을 발급하고 확인하기 위해 새로운 DID를 사용합니다. 도메인과 새 DID를 연결해야 합니다.
Microsoft에 "이전 DID"를 검색하도록 요청할 수 있나요?
아니요, 이 시점에서 서비스를 옵트아웃한 후에는 테넌트의 DID를 유지할 수 없습니다.
ngrok를 사용할 수 없습니다. 어떻게 해야 하나요?
샘플 배포 및 실행을 위한 자습서에서 ngrok
도구를 애플리케이션 프록시로 사용하는 방법을 설명합니다. 경우에 따라 이 도구는 회사 네트워크에서 IT 관리자가 사용하지 못하도록 차단할 수도 있습니다. 다른 대안은 샘플을 Azure App Service에 배포하고 이를 클라우드에서 실행하는 것입니다. 다음 링크는 해당 샘플을 Azure App Service에 배포하는 데 도움이 됩니다. 무료 가격 책정 계층은 샘플을 호스팅하는 데 충분합니다. 각 자습서에서 먼저 Azure App Service 인스턴스를 만들고, 이미 앱이 있으므로 앱 만들기를 건너뛰고 자습서를 계속하여 배포해야 합니다.
- Dotnet - App Service에 게시
- Node - App Service에 배포
- Java - App Service에 배포합니다. Azure App Service에 대한 maven 플러그 인을 샘플에 추가해야 합니다.
- Python - Visual Studio Code를 사용하여 배포
사용 중인 샘플의 언어에 관계없이 Azure AppService 호스트 이름 https://something.azurewebsites.net
이 공용 엔드포인트로 사용됩니다. 작동하도록 추가 항목을 구성할 필요가 없습니다. 코드 또는 구성을 변경할 경우 샘플을 Azure AppServices에 다시 배포해야 합니다. 문제 해결/디버깅은 콘솔 창에 대한 추적으로 오류가 표시되는 로컬 컴퓨터에서 샘플을 실행하는 것만큼 쉽지는 않지만 로그 스트림을 사용하여 거의 동일한 작업을 수행할 수 있습니다.
콜백 이벤트에 대한 네트워크 강화
요청 서비스 API는 신뢰 당사자 애플리케이션에서 제공하는 URL에 대한 콜백을 사용합니다. 콜백을 받으려면 확인된 ID 시스템에서 이 URL에 연결할 수 있어야 합니다. 콜백은 Microsoft Entra 테넌트와 동일한 지역의 Azure 인프라에서 제공됩니다. 네트워크를 강화해야 하는 경우 두 가지 옵션이 있습니다.
- Azure Firewall 서비스 태그 AzureCloud를사용합니다.
- 게시된 CIDR 범위를 사용하여 방화벽을 구성합니다. AzureCloud를 사용해야 합니다.Microsoft Entra 테넌트가 배포된 지역과 일치하여 방화벽을 구성하여 요청 서비스 API에서 콜백 트래픽을 통해 허용합니다. 예를 들어 테넌트가 EU에 있는 경우 AzureCloud에서 모든 CIDR 범위를 선택해야 합니다.방화벽 구성에 대한 northeurope, .westeurope 등
QR 코드 검사
설명서에서 지침 scan the QR code
은 달리 명시되지 않은 한 Microsoft Authenticator 모바일 앱으로 검색하는 것을 참조합니다.
모바일의 카메라 앱으로 QR 코드를 스캔한 다음, Microsoft Authenticator를 시작합니다. 이렇게 하려면 Microsoft Authenticator에 대한 openid-vc://
프로토콜 처리기를 등록해야 합니다. 다른 모바일 앱이 등록되어 있으면 Authenticator가 열리지 않습니다.
Android 휴대폰에서 QR 코드를 검사하는 알려진 문제는 다음과 같습니다.
- Android 9 및 이전 버전에서는 카메라 앱으로 QR 코드를 검사하는 작업이 작동하지 않으며 Microsoft Authenticator 앱을 사용하여 스캔하는 것 외에는 다른 해결 방법이 없습니다.
- 회사 및 개인 프로필이 모두 있는 Android 휴대폰에서 각 프로필에는 Microsoft Authenticator 앱의 자체 인스턴스가 있습니다. 회사 프로필의 Authenticator 앱에 자격 증명이 있고 개인 프로필의 카메라 앱을 사용하여 QR 코드를 스캔하려고 하면 개인 Authenticator 앱이 열립니다. 자격 증명이 개인 프로필이 아니라 회사 프로필에 있기 때문에 오류가 발생합니다. "이 확인된 ID를 추가하고 다시 시도해야 합니다."라는 오류 메시지가 표시됩니다.