Ch 2 - VC & VP

1. intro

DID, DID document가 ID의 구성 요소중 식별자와 인증 수단이었다면,

 

VC (Verifiable Credential), VP(Verifiable Presentation)는 주민 등록증, 자격증 등

 

사용자가 실제로 제시할 ID data들을 의미한다.

 

holder는 Issuer에게서 VC를 발급받으면 이를 바로 verifier에게 제출하지 않고,

 

이를 적절히 가공한 (필요한 속성만을 추출한) 후, holder 자신의 서명을 추가한 VP를 제출한다.

 

Verifier는 받은 VP를 issuer, holder 각각에 대해 검증한다. (issuer의 서명, holder의 서명)

 

VC, VP 모두 앞에서 공부한 DID, DID document와 비슷하다.

 

2. VC (verifiable Cerdential) - model

issuer에게서 holder에게 발급된 신원증명이다. 신분증, 자격증, 증명서 등 여러 가지 속성이 VC에 포함된다.

 

VC는 Credential metadata, Claim(s), Proof(s)로 구성되는데, 각 구성요소의 역할을 살펴보자.

 

2.1 Credential metadata

VC의 issuer(누가 발행했는지), Credential subject(누구에게 발행되었는지), 만료일, 폐기 방법 등

 

VC의 메타데이터가 들어가 있다.

 

2.2 Claim(s)

subject에 ID 속성 정보가 Subject-Property-Value 방식으로 들어있다. 솔리디티의 매핑와 비슷한 구조인데,

 

매핑으로 치면 매핑 이름 - 속성 - 값 이라고 생각하면 된다.

 

만약 내 학점증명서라면 ('내 이름' - '학점' - '3.5')의 구조일 것이다.

 

만약 학위 증명서처럼 VC에 지도 교수등 복수의 사람에 대한 정보가 필요한 경우, 여러 개의 subject가 있을 수 있다.

 

이 경우 내가(subject) 그 사람(value : 김교수)과 어떤 관계인지 (property : 지도 교수)를 Claim을 표현할 수 있다.

 

심지어 value도 다시 (subject - property - value) 형태인 것도 가능하다. (김교수 - 직위 - 정교수)

 

2.3 Proof(s)

VC에 대한 진위 검증에 필요한 값이 포함된다. Verifier가 이 값을 보고 VC의 issuer가 위조되지 않았는지 검증한다.

 

서명 알고리즘, 서명 생성자, 서명 검증방법, 서명이 포함된다.

 

위의 학위증명서의 issuer 조작 여부를 검증하고 싶다면 김교수 혹은 학교의 서명이 필요할 것이다.

 

3. VC 구성 요소

VC도 DID document와 비슷한 요소들을 가지고 있는데,

 

@context, id, type, issuer, issuanceDate, expirationDate, credentialSubject, proof 등이 들어있다.

 

3.1 @context

DID document와 마찬가지로, 통신 참여자 간 정확한 통신을 위해 데이터 형식을 정의한다.

 

하나만 사용할 필요는 없고 직접 만든걸 혼용해도 되지만,

 

공식 @Context가 사용되었다면 이게 가장 첫 번째로 와야한다.

 

/*  VC - @Context 예시  */

{
    "@context" : [
        "https://www.w3.org/2018/credentials/v1", // 공식 문서의 context 사용
        "https://www.example.edu/context" // 커스터마이징 context 사용
    ],
    ...
}

 

예시의 VC는 두 가지 @Context를 사용했는데, 하나는 공식 @context (반드시 첫 번째로 와야한다.),

 

두 번째는 직접 커스터마이즈 했을 경우 커스터마이즈 @Context 정보가 잇는 uri이다.

 

3.2 type

예시에는 "type"이 2개 있는데, 첫 번째로 depth 1의 type은 어떤 데이터들이 VC에 들어갈지를 지정한다.

 

이 또한 공식적으로 제공되는 구조를 사용할 수도 있고, 자체 제작한 데이터 구조를 사용해도 되지만,

 

공식적인 구조를 사용하려면 그걸 배열의 첫 번째에 두어야 한다.

 

다음 예시에서 VerifiableCredential, KoreaUniversityCredentials 2개의 값을 배열로 가지고 있는데,

 

첫 번째 element인 VerifiableCredential은 공식 콘텍스트 내에 정의된 VC 기본 데이터 구조를 따르겠다는 것을 의미하며,

 

두 번째 element인 KoreaUniversityCredentials는 자체 제작한 콘텍스트를 따르겠다는 것을 의미한다.

 

(공식 콘텍스트 VerifiableCredential이 첫 번째 element로 온 것을 유의할 것)

 

{
    // ...중략
    "type" : ["VerifiableCredential", "KoreaUniversityCredentials"],
    // ... 중략
    "proof" : {
        "type" : "RsaSignature2018",
        "created" : "2020-01-01",
        "creator" : "Korea University",
        "verificationMethod" : "https://example.edu/issuers/keys/1",
        "jws" : "eyJbhadfdfgddsfg..."
    }
}

 

마찬가지로 "proof" 객체 내의 depth 2 "type"은 RsaSiganture2018 방식에 따라

 

검증 데이터를 생성하겠다는 것을 의미한다.

 

3.3 id

DID id처럼 VC의 식별자이다. did uri, http uri를 사용할 수 있다.

 

3.4 issuer

VC 발행인/발행 기관을 의미하는데, 보통 발행 기관의 DID id가 있고, 추가적으로 발행인 정보가 있을 때도 있다.

/*  issuer 예시  */

{
    // ...중략
    "issuer" : {
        "id" : "did:sov:ABCD",
        "name" : "Korea University"
    }
    // ...중략
}

 

3.5 issuanceDate & expirationDate

issuanceDate는 VC가 효력을 가지기 시작한 시간, expirationDate는 만료시간을 의미한다.

 

RFC3339에 정의된 방식에 따라 표기한다.

 

/*  issuanceDate, expirationDate 예시  */

{
    // ...중략
    "issuanceDate" : "2025-01-01T00:00:00Z",
    "expirationDate" : "2030-12-31T23:59:59Z"
}

 

3.6 credentialStatus

현재 VC가 유효한지를 검증하기 위한 항목이다.

 

해당 정보를 확인할 수 있는 url이 적힌 id와 검증 방식을 알려주는 type이 있다.

 

/*  credentialStauts 예시  */

{
    // ...중략
    "credentialStatus" : {
        "id" : "https://revoklist.com/status",
        // VC의 유효성을 확인할 수 있는 url
        "type" : "credList2020"
        // VC 상태 검증 방식
    }
}

 

3.7 credentialSubject

VC가 가르키는 사람(보통 holder)의 신원 정보의 내용이 여기있다. 내 정보가 실제로 들어있는 곳이다.

 

/*  credentialSubject  */

{
    // ...중략
    "credentialSubject" : {
        "id" : "did:sov:1234",
        "degree" : {
            "name" : "Korea University",
            "major" : "chemistry",
            "gpa" : "3.5"
        }
    }
    // ...중략
}

 

2.2에서 설명한것처럼 subject는 여러 명이 올 수 있는데, 이 경우 배열로 객체들을 넣어주면 된다.

 

/*  credentialSubject - subject가 복수일 경우  */

{
    // ...중략
    "credentialSubject" : [
    {
        "id" : "did:sov:1234",
        "name" : "lsj",
        "degree" : {
            "name" : "Korea University",
            "major" : "chemistry",
            "gpa" : "3.5"
        },
        "advisor": {
            "id" : "did:sov:ASDF",
            "name" : "Professor Choi"
        }
    },
    {
        "id" : "did:sov:ASDF",
        "name" : "Professor Choi",
        "student" : {
            "id" : "did:sov:1234",
            "name" : "lsj"
        }
    }
    ]
}

 

3.8 proof

VC를 검증하는데 관련된 proof가 존재한다.

 

이는 holder가 verifier가 신원 인증을 진행할 때

 

정말 이를 신뢰할 수 있는지 확인하기 위해 검사하는 issuer의 서명정보가 담겨있다.

 

/*  proof */

{
    // ...중략
    "proof" : {
        "type" : "RsaSignature2018",
        "created" : "2020-01-01T:20:00:00Z",
        "creator" : "Korea University",
        "verificationMethod" : "https://portal.korea/issuers/keys/1",
        // 서명을 검증할 수 있는 값이 위치하는 url
        "jws" : "해당 VC 서명값"
    }
}

 

subject와 마찬가지로 여러 개의 proof를 가져와 배열형태로 값을 주는 것도 가능하다.

 

3.9 기타

이 외에도 VC에 몇 가지 유용한 기능을 사용할 수 있는데,

 

대표적으로 이용약관 (Terms of Use)가 있다.

 

verifier가 VC를 검증 후 이를 저장하는 것을 금지한다던가 하는 정책을 추가할 수 있다.

 

/*  Terms of use  */

{
    // ...중략
    
    "termsOfUse" : [{
        "type" : "IssuerPolicy" // issuer가 정하는 이용 약관
        "id" : "http://portal.edu/termsofUse",
        "profile" : "http://portal.edu/profiles/credentials",
        "prohibition" : [{ // 금지사항 지정
            "assigner" : "https://portal.edu/issuers/14",
            "assignee" : "AllVerifiers",
            "target" : "did:sov:1234",
            "action" : ["Archival"] // 해당 action들을 금지한다.
        }]
    }]
    
    // ...중략
}

 

evidence 항목엔 verifier가 첨고할 수 있는 추가적인 정보를 입력할 수 있는데

 

예를 들어 issuer가 holder에게 VC를 줄 때 어떤 정보를 근거로 내줬는지를 기록할수 있다.

 

4. VP (verifiable Presentation) - model

holder는 VC를 verifier에게 직접 제출하지 않고 VP로 가공해 제출한다.

 

이는 VP를 제출하는 사람이 정말 본인이 맞는지를 확인하기 위함이다.

 

VC가 정말 holder가 자격을 가졌는지를 확인시켜준다면,

 

VP는 자격을 가진 다른 holder의 VC를 다른 사람이 도용한 것인지를 확인한다.

 

VC와 비슷하게, VP는 presentation metadata, Verifiable Credential, proof로 구성된다.

4.1 Presentation Metadata

해당 데이터가 VP라는 것을 알려주는 type, 이용 약관, evidence등 VP 검증에 참고할 데이터가 들어있다. 

 

4.2 Verifiable Credential(s)

holder가 verifier에게서 요구받은 정보들을 가진 VC들을 골라 여기에 담는다.

 

VC에 포함된 proof 항목으로 이 VC의 진위를 판별할 것이다.

 

4.3 proof(s)

VP의 proof에는 holder의 서명이 들어간다. VP 제출자가 정말 holder 본인이 맞는지 확인하는데 이용한다.

 

5. VC 폐기

면허가 정지되었거나 퇴사, 자퇴 등으로 인해 VC를 폐기해야 할 때도 있는데,

 

verifier도 이런 폐기 여부를 확인할 수 있어야 한다.

 

바꿔말하면 holder는 자신의 VC가 폐기되지 않았음을 verifier에게 입증해야한다.

 

그 방법이야 여러 가지 있지만 이 글에선 Hyperledger indy에서 사용하는 방식을 알아보자.

 

 

VC를 폐기하기 위해선 Tails file, Accumulator, Witness 총 세 가지 구성 요소가 필요하다.

 

- Tails file은 issuer가 발행할 VC에 해당하는 인수 목록을 모아둔 것이다.

 

  > issuer는 미리 몇 개의 VC를 발행할지 정해둔 뒤에 그 수만큼의 VC 인수가 저장된 Tails file을 생성한다.

 

 

- Accumulator는 이렇게 생성된 Tails file중 발행된 VC의 인수들만을 사용해 연산한 연산의 결괏값이다.

 

  > 이후, holder에게 VC를 발행 혹은 폐기할 때, 이 VC에 대한 인자값을 함께 주고, accumulator를 업데이트한다.

 

  > verifier는 이 Accumulator에 접근해, VC의 폐기 여부를 확인할 수 있다.

 

  (Accumulator는 블록체인 상에 저장된다.)

 

 

- Witness는 아직 발행하지 않은 VC의 인수값들만을 사용한 연산의 결괏값이다.

 

- Revocation registry는 블록체인 상에 저장되는 VC 폐기 기록이다.

 

 

만약 VC가 폐기되었으면 이를 제외하고 다시 연산을 실행해 Accumulator 값을 업데이트한다.

 

이를 REVOC_REG_ENTRY tx라고 한다.

 

 

이 개념을 머리에 넣고 폐기 검증 메커니즘을 요약하자면

 

1. holder가 proof와 함께 폐기 여부를 검증할 Proof of non-revocation을 생성한다.

 

1-1. Proof of non-revocation에는 Witness값이 포함되어 있는데, 이는 Tails file, 폐기 기록을 이용해 구한다.

 

2. holder가 이를 verifier에게 전달하고 이를 검증해 폐기되지 않았음을 확인한다.