2편: SD-JWT 를 이해하기 위한 첫걸음: Issuer / Holder / Verifier Concept 이해하기
들어가기에 앞서
1편: JWT 에 이은 새로운 혁신, SD-JWT (selective disclosure)
요즘 저는 sd-jwt 라는 주제에 대해 공부하고 있습니다. sd-jwt 에 대해 공부하기 위해서는 자연스럽게 자기주권신원, VC, VP, Issuer / Holder / Verifier Concept에 대한 지식도 함께 동반되어야 합니다. 하지만 저는 처음 이런 것들을 공부할 때 용어가 너무 생소하고 어렵다고 생각됐습니다.
VC / VP (두둥탁..)
알파벳 두글자만 틱 하고 있는 것이 저에겐 너무 불친절하다고 느껴졌습니다. 공부를 진행하면서 나만의 용어로 재정의를 해서 사람들에게 개념을 아주 쉽게 인식 시켜주고 싶다는 생각을 했어요. 분명 나와 같은 답답함을 느끼는 사람들이 있을거라 생각했거든요. 여러 블로그 글들을 보며 글을 작성하는 이유가 내가 이만큼 잘한다! 라는 것을 뽐내기 위함이 아닌 모두를 이해시키기 위한 글을 작성하는 것이 목표가 되어야 한다는 생각이 들었습니다.
Issuer / Holder / Verifier
Concept에 대해서 설명해볼게요.
이슈? 홀더? 베리파이어...?
이게 뭐죠? 하나도 모르겠으니까 일단 던져버립시다.
학교 / 나 / 과외플랫폼
시나리오
나는 S대에 재학하는 학생입니다. 용돈이 부족해서 과외 플랫폼을 통해 과외를 구하기로 했습니다.
Issuer: 신원정보를 발급하는 발행자
과외플랫폼을 통해 과외를 진행하려면 무엇이 필요할까요? 바로 내가 S대에 다니고 있다는 것을 증명해줄 대학 증명서가 필요합니다. 그럼 이 증명서를 누가 발급해줄까요? 대학교(Issuer) 입니다.
Issuer? 증명서를 발급해주는 사람!
🎉 Issuer 에 대한 용어를 알아냈습니다.
Holder: 자격증명(신원정보)를 소유한 사람
이 발급한 증명서를 누가 가지고 있을까요? 바로 '나' 입니다. 발급해놓고 땅바닥에 그냥 버릴일은 없을 테니까요. 발급된 증명서는 내가 가지고 있게 됩니다.
Holder 는 발급된 증명서를 가지고 있는사람, 바로 나(Holder)입니다.
🎉 Holder에 대한 용어를 알아냈습니다.
Verifier: 자격증명(신원정보) 검증자
나는 발급이 완료된 증명서를 과외 플랫폼에게 제출해야겠죠?
나는 과외 플랫폼에게 증명서를 제출하고, 과외플랫폼은 그 증명서가 진짜인지 조작된 증명서인지 검증합니다.
Verifier 는 발급된 증명서를 검증하는 과외 플랫폼이 되겠네요.
🎉 Verifier 대한 용어를 알아냈습니다.
VC (Verifiable Credential) / VP (Veriable Presentation)
이 과정에서 학교가 발급한 증명서를 VC, 과외 플랫폼에게 보내는 것을 VP 라고 이해하면 쉽습니다. 그럼 VC,VP. 증명서가 두개가 되겠죠? 해당 컨셉에서는 받은 학교에게 증명서(VC)를 요리조리 바꿔서 새로운 증명서(VP)를 짜잔! 하고 만듭니다. 그 증명서를 과외 플랫폼에게 제출합니다.
학교를 통해 VC라는 증명서를 발급받았습니다. 하지만, 과외 플렛폼에 보낼 땐 VC의 정보 중 필요한 정보만 추려서 플렛폼에 전송하고 싶어서 필요한 정보만 담은 증명서를 만들어 제출했습니다. 이것들을 우리는 쉽게 VC, VP라고 부르는 것이죠!
📜 시나리오
🏫 : 증명서 발급했어 !! 이 증명서는 VC라고 해. 너 줄게‼️
🚶♂️: VC를 받았어. 난 여기서 제출하고 싶은 정보만 제출할래. VC 정보를 가공해서 새로운 증명서를 만들어야겠다. (뚝딱뚝딱..) 새 증명서 완성~ 나는 얘를 VP라고 할게. (제출)
📲 : VP 이게 진짜 맞는거지? 검증해야겠다…!
네, 이런 컨셉입니다.. !
다시 그림을 볼까요? 이제는 이슈어,홀더,베리파이어 용어가 좀 눈에 들어오시나요?
VC VP도 그저 검증된 자격증일 뿐이었네요.
이 전체적인 컨셉에 대해 이해하셨다면 이제 sd-jwt로 넘어 갈 수 있습니다.
vc/vp같은 증명서를 만드는 일은 마법이 아니에요. 해리포터 주문처럼 주문만 외면 짜잔하고 만들어지는 것이 아니라는 뜻입니다!
우리는 개발자니까 이걸 개발해야 해요. ..근데 어떻게?
언제나 그렇듯 우리에게는 라이브러리가 있습니다.
우리가 0부터 1까지 sd-jwt 를 구현하면 참 좋겠죠. 하지만 우리는 사실상 기술을 연구하는 사람이 아니라, 사용해서 제품을 만들어내야 하는 사람이에요. 하지만 jwt를 간편히 만들어주는 라이브러리가 있듯이 우리에게도 sd-jwt 라이브러리가 있습니다.
여기까지 오셨다면 sd-jwt 라이브러리를 사용해서 VC/VP를 만드는 것이 어렵지 않아요.
sd-jwt 와 jwt의 가장 큰 차이점은 뭘까?
하고 생각해봤을때,
JWT: 클라이언트 <-> 서버
SD-JWT: 이슈어-> 나 ->검증자
주로 JWT는 클라이언트와 서버와 통신하지만 SD-JWT는 이렇게 세명의 등장인물로 인해 시나리오로 이루어져요. 이에 대한 이해도가 기반이 되어야 비로소 SD-JWT를 이해 할수 있을 것입니다. 하지만 이 컨셉을 이해한다? 그 다음 스텝은 너무너무 쉬울 것입니다.
번외
" Verifier 검증시 과외플랫폼은 그 증명서가 진짜인지 조작된 증명서인지 검증합니다. "
에 대한 답변은 댓글에 있습니다. 궁금하신분들은 추가적으로 읽어보시길 바랍니다.
그리고 이 글도 읽어보세요.:)
질문 많이 부탁드립니다!
9개의 댓글
글이 술술 읽히네요 ! 잘 읽었습니다 ㅎㅎ
궁금한점이 있는데
"Verifier 검증시 과외플랫폼은 그 증명서가 진짜인지 조작된 증명서인지 검증합니다."
여기서 과외 플랫폼은 이 증명서가 조작되었는지 어떻게 판단할까요 ?
그건 이슈어에게 다시 확인을 받아야 하는게 아닐까? 라고 생각해보았습니다!
리브리버님의 질문입니다.
" Verifier 검증시 과외플랫폼은 그 증명서가 진짜인지 조작된 증명서인지 검증합니다. "
Q. 과외 플랫폼은 이 증명서가 조작되었는지 어떻게 판단할까요 ? 그건 이슈어에게 다시 확인을 받아야 하는게 아닐까? 라고 생각해보았습니다!
A. 과외 플랫폼은 대학교(이슈어)에게 확인받지 않고, 홀더가 건넨 VP안에 있는 정보만으로 검증할 수 있습니다.
Q. 검증을 해야 하는데 어떻게 대학교(이슈어)한테 안물어보고 검증하나요?
A. 이 이유는 바로 VC, VP(인증서)를 만드는데 DID를 사용하기 때문입니다. 이것을 전문용어로 SSI (자기주권신원) 이라고 합니다. SSI라는 용어가 나와도 당황해하지 않으셔도 됩니다! 아주 쉽게 풀어 말하면’ 내 정보는 내가 통제할래~’ 라는 컨셉입니다.
Q. DID는 무엇인가요?
A. 그냥 대학교가 누구인지, 내가 누구인지, 등 누군가를 식별하기 위한 ID입니다. 혼란을 방지하기 위해 이 컨셉에서는 ID를 DID라고 지칭합니다. DID를 만든 이유가 이슈어에게 물어보지 않고 검증하기 위해서 입니다. 검증 절차를 서술해보겠습니다.
- 발급된 VP안에는 이미 이슈어의 DID가 존재합니다.
- DID를 통해 DID Docs를 가져옵니다. ( DID Docs 를 가져오는 함수를 resolver라고 하는데요, 우리가 아는 fetch와 같은 요청을 하는 함수라고 생각하면 됩니다. 요청을 날리는 함수 용어가 resolver 함수인 것 뿐이에요.)
- resolver함수를 실행시키면 DID docs를 획득할 수 있습니다. docs라는 용어가 '어떠한 문서' 라고 생각될 수 있어서 헷갈릴 수 있지만, 사실 이 docs는 그냥 did 정보 모음 객체라고 생각하면 됩니다.
- 해당 DID Docs 안에는 Public Key 가 존재합니다. docs 안에서 해당 Public Key를 얻습니다.
- 서명을 Public key 로 검증합니다, 발급한 당사자인 대학교(이슈어)는 이 사실을 모릅니다!
Q.왜 Public key 를 가져와서 검증하나요? public 은 공개된 키인데, 누구나 검증 가능하면 보안에 안좋은 것 아닌가요?
A. sd-jwt 컨셉에서는 비대칭키 (public, private key) 를 사용해서 검증을 합니다. 실제 sd-jwt라이브러리도 비대칭키 형식을 사용해 내부 구현이 이루어져있습니다. 그렇다면 비대칭키를 사용하는 이유는 무엇일까요? 바로 주요 목적은 '이사람으로 부터 발급된 것이 정확한 것인가" 를 입증하기 위함입니다.
이것이 SSI를 구성하는 기술입니다.
Q. ID면 ID지! 굳이 DID란 용어를 붙인 이유가 뭘까요?
A. 바로 용어가 명확해야 사람들이 오해를 하지 않기 떄문입니다. '식별을 한다' 라는 개념 자체는 ID와 동일하지만 DID를 구성하는데에는 또 다른 표준이 있습니다. 이렇기 때문에 DID라는 ID를 지칭하는 용어로 구분지은 것입니다. DID Docs, resolver 함수도 마찬가지입니다.
앞서 말했던 SSI ("내 정보는 내가 통제할래~") 에 대한 컨셉, 여기서 다시 짚고 넘어갈 수 있습니다.
- 선택적으로 원하는 정보를 드러낼 수 있다.
블로그의 1-2편 내용은 1번에 초점을 맞추어 작성된 글입니다. sd-jwt 라이브러리 컨셉과도 동일합니다.
2.Issuer가 발급한 정보를 Issuer에게 확인받지 않고 검증할 수 있다.
입니다.
사실 1번만큼 2번도 굉장히 중요 개념입니다.
블로그글 1편과 2편은 쉬운 이해를 돕기 위해 작성된 글인데요, 리브리버님이 남겨주신 댓글은 해당 컨셉을 이해하기 위한 가장 중요한 질문이라는 생각이 듭니다. 질문을 해주셔서 진심으로 감사드립니다.
너무 멋진글이네요! 만드신 사이트도 너무 재밌고 이해도 잘되요.