From b3e32815109365219a6adcb86b9174ee669e101f Mon Sep 17 00:00:00 2001 From: "Minho.Yoo" Date: Mon, 1 Jun 2020 20:40:58 +0900 Subject: [PATCH] =?UTF-8?q?=EB=B2=88=EC=97=AD=EB=90=9C=20=EB=82=B4?= =?UTF-8?q?=EC=9A=A9=20PR=20=EC=83=9D=EC=84=B1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- index.html | 202 +++++++++++++++++++++++------------------------------ 1 file changed, 86 insertions(+), 116 deletions(-) diff --git a/index.html b/index.html index c42465c60..c9270c265 100644 --- a/index.html +++ b/index.html @@ -2177,115 +2177,95 @@

확장성

-

Semantic Interoperability

+

의미론적 상호운용성

- This specification ensures that "plain" JSON and JSON-LD syntaxes are - semantically compatible without requiring JSON implementations to use a JSON-LD - processor. To achieve this, the specification imposes the following additional - requirements on both syntaxes: + 본 규격은 JSON-LD 프로세서를 사용하기 위한 JSON 구현의 필요 없이 + 전통적인 JSON 과 JSON-LD의 문법이 의미적으로 호환되도록 보장한다. + 이를 달성하기 위해서, 규격은 다음의 추가적인 요구사항을 양쪽 모두의 문법에 부과한다.

- A human-readable document describing the expected order of values for the - @context property is expected to be published by any - implementer seeking interoperability. A machine-readable description - (that is, a normal JSON-LD Context document) is expected to be published - at the URL specified in the @context property by - JSON-LD implementers seeking interoperability. + @context 속성의 기대되는 값 순서를 기술하는, + 사람이 읽을 수 있는 문서는 상호운용성을 추구하는 구현자에 의하여 게시되어야 한다. + 기계가 읽을 수 있는 설명(즉, 일반 JSON-LD 컨텍스트 문서)는 + 상호 운용성을 추구하는 JSON-LD 구현자가 @context 속성에 지정된 URL에 게시해야 한다.

- The requirements above guarantee semantic interoperability between JSON and - JSON-LD for terms defined by the @context mechanism. While JSON-LD - processors will use the specific mechanism provided and can verify that all - terms are correctly specified, JSON-based processors implicitly accept the same - set of terms without testing that they are correct. In other words, the context - in which the data exchange happens is explicitly stated for both JSON and - JSON-LD by using the same mechanism. With respect to JSON-based processors, this - is achieved in a lightweight manner, without having to use JSON-LD processing - libraries. + 위의 요구사항은 @context 메커니즘에 의해 정의된 term에 대해 + JSON과 JSON-LD 간의 의미론적 상호운용성을 보장한다. + JSON-LD 프로세서가 특정 메커니즘을 사용하여 모든 term이 올바르게 지정되었는지 확인할 수 있는 반면, + JSON 기반 프로세서는 term들이 올바르게 지정되었는지 확인하는 테스트 없이 암시적으로 동일한 term들의 집합을 수용한다. + 즉, 데이터 교환이 발생하는 컨텍스트는 동일한 메커니즘을 사용하여 JSON과 JSON-LD 모두에서 명시적으로 선언된다. + 이것이 JSON 기반 프로세서에서는 JSON-LD 처리 라이브러리를 사용할 필요없이 간단한 방식으로 달성된다.

-
-

Data Schemas

+
+

데이터 스키마

- Data schemas are useful when enforcing a specific structure on a given - collection of data. There are at least two types of data schemas that this - specification considers: + 데이터 스키마는 주어진 데이터 컬렉션에 특정 구조를 적용할 때 유용하다. + 이 규격에서는 고려하는 데이터 스키마 유형은 최소 두 가지가 있다.

  • - Data verification schemas, which are used to verify that the structure - and contents of a verifiable credential conform to a published schema. + 데이터 검증 스키마는 검증가능한 크리덴셜의 구조와 내용이 게시된 스키마를 따르는지 검증하는 데 사용된다.
  • - Data encoding schemas, which are used to map the contents of a - verifiable credential to an alternative representation format, such as a - binary format used in a zero-knowledge proof. + 데이터 인코딩 스키마는 검증가능한 크리덴셜을 대체 표현 형식으로 맵핑하는데 사용된다. + 이 때 대체 표현 형식이란 영지식 증명에서 사용되는 이진 형식 같은 것을 의미한다.

- It is important to understand that data schemas serve a different purpose from - the @context property, which neither enforces data structure or - data syntax, nor enables the definition of arbitrary encodings to alternate - representation formats. + 데이터 스키마는 @context와는 다른 용도로 사용된다는 것을 이해해야 한다. + @context 속성은 데이터 구조나 데이터 구문을 강요하지도 않고 + 임의의 인코딩 정의를 대체 표현 형식으로 변환하게 할 수도 없다.

- This specification defines the following property for the expression of a - data schema: + 이 규격은 데이터 스키마 표현을 위해 다음 속성을 정의한다.

credentialSchema
- The value of the credentialSchema property MUST be one or - more data schemas that provide verifiers with enough information to - determine if the provided data conforms to the provided schema. Each - credentialSchema MUST specify its type (for example, - JsonSchemaValidator2018), and an id property - that MUST be a URI identifying the schema file. The precise contents of - each data schema is determined by the specific type definition. + credentialSchema 속성의 값은 + 제공된 데이터가 제공된 스키마와 일치하는지 판별하기에 충분한 정보를 검증자에게 제공하는 + 하나 이상의 데이터 스키마여야 한다. + 각각의 credentialSchema은 그것의 타입을 지정해야 한다(예: JsonSchemaValidator2018). + credentialSchema의 id 속성은 스키마 파일을 식별할 수 있는 URI여야 한다. + 각 데이터 스키마의 정확한 내용은 구체적인 타입 정의에 의해 결정된다.

- The credentialSchema property provides an opportunity to - annotate type definitions or lock them to specific versions of the vocabulary. - Authors of verifiable credentials can include a static version of their - vocabulary using credentialSchema that is locked to some content - integrity protection mechanism. The credentialSchema - property also makes it possible to perform syntactic checking on the - credential and to use verification mechanisms such as JSON Schema - [[JSON-SCHEMA-2018]] validation. + credentialSchema 속성은 타입 정의에 주석을 달거나 특정 버전의 용어에 고정할 수 있게 한다. + 검증가능한 크리덴셜의 작성자는 일부 콘텐츠 무결성 보호 메커니즘에 고정된 credentialSchema을 사용하여 + 정적 버전의 용어를 포함할 수 있다. + credentialSchema 속성을 사용하면 크리덴셜에 대해 구문 검사를 수행하고 + JSON 스키마 [[JSON-SCHEMA-2018]] 유효성 검사와 같은 검증 메커니즘을 사용할 수 있다.

- 
+      
 {
   "@context": [
     "https://www.w3.org/2018/credentials/v1",
@@ -2311,16 +2291,14 @@ 
Data Schemas

         

 
       

-        In the example above, the issuer is specifying a
-        credentialSchema, which points to a [[?JSON-SCHEMA-2018]] file that
-        can be used by a verifier to determine if the
-        verifiable credential is well formed.
+        위의 예에서 발급자는 credentialSchema를 지정하고 있는데, 
+        해당 credentialSchema는 검증가능한 크리덴셜이 제대로 구성되어 있는지 확인할 수 있도록 
+        검증자가 사용할 수 있는 [[?JSON-SCHEMA-2018]] 파일을 가리킨다. 
       

 
       

-        For information about linkages to JSON Schema [[JSON-SCHEMA-2018]] or other
-        optional verification mechanisms, see the Verifiable Credentials
-        Implementation Guidelines [[VC-IMP-GUIDE]] document.
+        JSON 스키마 [[JSON-SCHEMA-2018]] 또는 기타 검증 메커니즘에 대한 링크 정보는 
+        검증가능한 크리덴셜 구현 가이드라인 [[VC-IMP-GUIDE]] 문서를 참조.
       

 
       

@@ -2328,10 +2306,14 @@ 
Data Schemas

         as those used to perform zero-knowledge proofs. For more information on using
         the credentialSchema property with zero-knowledge proofs,
         see Section .
+
+        데이터 스키마를 사용하여 영지식 증명을 수행하는 데 사용되는 것과 같은 다른 이진 형식에 대한 맵핑을 지정할 수도 있다. 
+        영지식 증명으로 credentialSchema 속성을 사용하는 것에 대한 자세한 정보는 
+        섹션 을 참조.
       

 
       
+        title="영지식 유효성 검사을 위한 credentialSchema 속성 사용">
 {
   "@context": [
     "https://www.w3.org/2018/credentials/v1",
@@ -2357,66 +2339,55 @@ 
Data Schemas

         

 
       

-        In the example above, the issuer is specifying a
-        credentialSchema pointing to a zero-knowledge packed binary data
-        format that is capable of transforming the input data into a format, which can
-        then be used by a verifier to determine if the proof provided with the
-        verifiable credential is valid.
+        위의 예에서 발급자는 영지식 증명용으로 패키징된 이진 데이터 형식을 가리키는 credentialSchema를 지정한다. 
+        이 이진 데이터 형식은 입력 데이터를 검증자가 이용할 수 있는 형식으로 변환할 수 있는데, 
+        검증자는 변환된 데이터 형식을 이용하여 검증가능한 크리덴셜과 함께 제공된 증명의 유효성을 확인할 수 있다.
-
-

Refreshing

+
+

리프레싱

- It is useful for systems to enable the manual or automatic refresh of an - expired verifiable credential. For more information about expired - verifiable credentials, see Section . This - specification defines a refreshService property, which - enables an issuer to include a link to a refresh service. + 만료된 검증가능한 크리덴셜을 수동 또는 자동으로 리프레시할 수 있게 하는 것은 시스템에 유용하다. + 만료된 검증가능한 크리덴셜에 대한 더 자세한 정보는 + 섹션 에서 기술한다. + 이 규격은 발급자가 리프레시 서비스에 대한 링크를 포함할 수 있도록 refreshService 속성을 정의한다.

- The issuer can include the refresh service as an element inside the - verifiable credential if it is intended for either the verifier or - the holder (or both), or inside the verifiable presentation if it - is intended for the holder only. In the latter case, this enables the - holder to refresh the verifiable credential before creating a - verifiable presentation to share with a verifier. In the former - case, including the refresh service inside the verifiable credential - enables either the holder or the verifier to perform future - updates of the credential. + 만약 검증가능한 크리덴셜이 검증자나 보유자(또는 둘 다)를 위한 용도라면, + 발급자는 검증가능한 크리덴셜 내부의 요소로서 리프레시 서비스를 포함시킬 수 있고, + 보유자만을 위한 경우라면 검증가능한 프레젠테이션 내부의 요소로서 포함시킬 수 있다. + 후자의 경우, 검증자와 공유할 검증가능한 프레젠테이션을 생성하기 전에 + 보유자는 검증가능한 크리덴셜을 리프레시 할 수 있다. + 전자의 경우 검증가능한 크리덴셜 안에 리프레시 서비스를 포함시키면, + 보유자나 검증자가 크리덴셜의 향후 업데이트를 수행할 수 있다.

- The refresh service is only expected to be used when either the - credential has expired or the issuer does not publish - credential status information. Issuers are advised not to put the - refreshService property in a verifiable credential - that does not contain public information or whose refresh service is not - protected in some way. + 리프레시 서비스는 크리덴셜이 만료되었거나 + 발급자가 크리덴셜 상태 정보를 게시하지 않은 경우에만 사용되어야 한다. + 공개된 정보를 포함하지 않거나 리프레시 서비스가 어떤 식으로든 보호되지 않는 검증 가능한 크리덴셜에 + refreshService 속성을 넣는 것은 발급자에게 권장되지 않는다.

- Placing a refreshService property in a - verifiable credential so that it is available to verifiers can - remove control and consent from the holder and allow the - verifiable credential to be issued directly to the verifier, - thereby bypassing the holder. + 검증자가 사용할 수 있도록 refreshService 속성을 검증가능한 크리덴셜 안에 배치하면 + 보유자가 제어와 동의를 할 수 없게 되고 검증가능한 크리덴셜이 + 직접적으로 검증자에게 발행되어 보유자를 우회하게 된다.

refreshService
- The value of the refreshService property MUST be one or - more refresh services that provides enough information to the recipient's - software such that the recipient can refresh the verifiable credential. - Each refreshService value MUST specify its type (for - example, ManualRefreshService2018) and its id, which - is the URL of the service. The precise content of each refresh service is - determined by the specific refreshService type definition. + refreshService 속성의 값은 수신자가 검증가능한 크리덴셜을 리프레시할 수 있도록 + 수신자의 소프트웨어에 충분한 정보를 제공하는 하나 이상의 리프레시 서비스여야 한다. + 각각의 refreshService 값은 타입(예: ManualRefreshService2018)과 + 서비스의 URI인 id를 지정해야 한다. + 각 리프레시 서비스의 자세한 내용은 특정 refreshService의 타입 정의에 의해 결정된다.
- 
+      
 {
   "@context": [
     "https://www.w3.org/2018/credentials/v1",
@@ -2442,9 +2413,8 @@ 
Refreshing

         

 
       

-        In the example above, the issuer specifies a manual
-        refreshService that can be used by directing the holder or
-        the verifier to https://example.edu/refresh/3732.
+        위의 예에서 발급자는 보유자 또는 검증자를 
+        https://example.edu/refresh/3732로 디렉팅하는데 사용될 수 있는 수동 refreshService를 지정한다.