From 00760fdc8dfb83027e3881cd84d493c5135ea84b Mon Sep 17 00:00:00 2001 From: backslash47 Date: Mon, 23 Apr 2018 13:10:08 +0200 Subject: [PATCH 01/12] Create OEP for Verification of ONT ID ownership --- OEP-Y.mediawiki | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 OEP-Y.mediawiki diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki new file mode 100644 index 0000000..48a38c6 --- /dev/null +++ b/OEP-Y.mediawiki @@ -0,0 +1,40 @@ +
+  OEP: 
+  Title: Verification of ONT ID ownership in web environment
+  Author: Matus Zamborsky
+  Type: Informational
+  Status: Draft
+  Created: 2018-04-23
+
+ +==Abstract== + +A method is proposed for online verification of ONT ID ownership. Trust anchors or other entities can use this method for identity authentication. +This method is based on the same cryptographic principles as is used during caller identification in smartcontract execution. + + +==Motivation== + +The motivation is critical for OEPs that want to change the ONT protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the OEP solves. OEP submissions without sufficient motivation may be rejected outright. + +==Specification== + +The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current ONT platforms. + +==Rationale== + +The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. + +The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. + +==Backwards Compatibility== + +All OEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The OEP must explain how the author proposes to deal with these incompatibilities. OEP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +==Test Cases== + +Test cases for an implementation are mandatory for OEPs that are affecting consensus changes. Other OEPs can choose to include links to test cases if applicable. + +==Implementation== + +The implementations must be completed before any OEP is given status "Final", but it need not be completed before the OEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. From 4744fd22015cb2e96b123a55a31c0855bec05a94 Mon Sep 17 00:00:00 2001 From: backslash47 Date: Mon, 23 Apr 2018 14:23:50 +0200 Subject: [PATCH 02/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index 48a38c6..0b5f83f 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -1,7 +1,7 @@ 
   OEP: 
   Title: Verification of ONT ID ownership in web environment
-  Author: Matus Zamborsky
+  Author: Matus Zamborsky 
   Type: Informational
   Status: Draft
   Created: 2018-04-23
@@ -10,31 +10,26 @@
 ==Abstract==
 
 A method is proposed for online verification of ONT ID ownership. Trust anchors or other entities can use this method for identity authentication. 
-This method is based on the same cryptographic principles as is used during caller identification in smartcontract execution.
-
+This method is based on the same cryptographic principles as is used during caller identification in smart-contract execution.
 
 ==Motivation==
 
-The motivation is critical for OEPs that want to change the ONT protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the OEP solves. OEP submissions without sufficient motivation may be rejected outright.
+Currently there is no recommended or established way of ONT ID ownership verification in web environment. Main motivation is to guide implementators of services interacting with ONT ID identity to use common principles and to prevent implementations which are not secure. 
 
 ==Specification==
 
-The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current ONT platforms.
-
-==Rationale==
+This proposal makes use of the following functions and definitions:
 
-The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
+*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
 
-The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
 
-==Backwards Compatibility==
 
-All OEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The OEP must explain how the author proposes to deal with these incompatibilities. OEP submissions without a sufficient backwards compatibility treatise may be rejected outright.
+The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current ONT platforms.
 
-==Test Cases==
+==Rationale==
 
-Test cases for an implementation are mandatory for OEPs that are affecting consensus changes. Other OEPs can choose to include links to test cases if applicable.
+'''''User story:''' As a Service Provider, I need to check if the requester is really who he claims to be, before providing the service.''
 
-==Implementation==
+or more specifically
 
-The implementations must be completed before any OEP is given status "Final", but it need not be completed before the OEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
+'''''User story:''' As a Trust Anchor who would like to issue a verificable claim, I need to check if the requester is really who he claims to be.''

From 0c0554a6ec35c21e045ec8bfaf83073c8db3cc7b Mon Sep 17 00:00:00 2001
From: backslash47 
Date: Mon, 23 Apr 2018 15:44:29 +0200
Subject: [PATCH 03/12] Update OEP-Y.mediawiki

---
 OEP-Y.mediawiki | 70 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 68 insertions(+), 2 deletions(-)

diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki
index 0b5f83f..7b719e7 100644
--- a/OEP-Y.mediawiki
+++ b/OEP-Y.mediawiki
@@ -10,7 +10,7 @@
 ==Abstract==
 
 A method is proposed for online verification of ONT ID ownership. Trust anchors or other entities can use this method for identity authentication. 
-This method is based on the same cryptographic principles as is used during caller identification in smart-contract execution.
+This method is based on the same cryptographic principles as is used during caller identification in Smart contract execution.
 
 ==Motivation==
 
@@ -20,11 +20,77 @@ Currently there is no recommended or established way of ONT ID ownership verific
 
 This proposal makes use of the following functions and definitions:
 
+*'''Requester''', an user wanting to prove ONT ID ownership.
+*'''Service provider (SeP)''', a provider of some service (e.g.: issuing veryfiable claim).
+*'''Signature''', a cryptographic signature of unsigned data using one of the supported cryptographic schemes.
 *'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
+*'''DDO''', an ONT ID Description Object, describing the current state of ONT ID with its claims and used public keys.
+*'''Signature schema''', a concrete selection of signing algorithm used.
+*'''Signature schema byte''', an one byte representation of Signature schema used.
 
+===General verification process===
+#Requester signs and sends a Request to Service provider.
+#SeP extracts Signature from Request.
+#SeP validates the Signature.
+#SeP retrieves DDO corresponding to supplied ONT ID using ONT ID Smart contract.
+#SeP checks if the DDO contains public key used in Signature.
 
+===Signing and sending Request===
+Request sent to Service provider should be in JSON format and needs to contain OntId attribute and can contain any other arbitrary attributes:
 
-The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current ONT platforms.
+
+{
+  "id": "7c756d2c-0630-4aa1-86e1-87a6921a5241",
+  "data1": "...",
+  "data2": "...",
+  "OntId": "did:ont:TWbWxyRQaxsG3saSZaUt6pHTghgta4qWBA",
+  ...,
+}
+

+
+Signature is generated using similar algorithm as Transaction signing in Ontology blockchain, therefore Private and Public key pair is used:
+
+# '''RequestHash''' = SHA256(SHA256(StringifiedJSONRequest))
+# '''SignedHash''' = Sign(SHA256(RequestHash, Privatekey))
+
+Result Signature is embedded into Request object:
+
+
+{
+  "id": "7c756d2c-0630-4aa1-86e1-87a6921a5241",
+  "data1": "...",
+  "data2": "...",
+  "OntId": "did:ont:TWbWxyRQaxsG3saSZaUt6pHTghgta4qWBA",
+  ...,
+  "Signature": {
+    "PubKeys": [
+      PublicKey
+    ],
+    "SigData": [
+      SignatureSchemaByte + SignedHash
+    ]
+  },
+}
+

+
+The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema.
+
+
+===Extracting and validating of Signature===
+
+
+===Supported signature schemes===
+*'''SHA224withECDSA''' = 0,
+*'''SHA256withECDSA''' = 1,
+*'''SHA384withECDSA''' = 2,
+*'''SHA512withECDSA''' = 3,
+*'''SHA3_224withECDSA''' = 4,
+*'''SHA3_256withECDSA''' = 5,
+*'''SHA3_384withECDSA''' = 6,
+*'''SHA3_512withECDSA''' = 7,
+*'''RIPEMD160withECDSA''' = 8,
+*'''SM3withSM2''' = 9,
+*'''SHA512withEDDS''' = 10,
 
 ==Rationale==
 

From 9d4b42a94607cff94f08cb8f1fc8b4f125910aa2 Mon Sep 17 00:00:00 2001
From: backslash47 
Date: Mon, 23 Apr 2018 16:00:22 +0200
Subject: [PATCH 04/12] Update OEP-Y.mediawiki

---
 OEP-Y.mediawiki | 30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki
index 7b719e7..a436c0b 100644
--- a/OEP-Y.mediawiki
+++ b/OEP-Y.mediawiki
@@ -30,7 +30,6 @@ This proposal makes use of the following functions and definitions:
 
 ===General verification process===
 #Requester signs and sends a Request to Service provider.
-#SeP extracts Signature from Request.
 #SeP validates the Signature.
 #SeP retrieves DDO corresponding to supplied ONT ID using ONT ID Smart contract.
 #SeP checks if the DDO contains public key used in Signature.
@@ -51,7 +50,7 @@ Request sent to Service provider should be in JSON format and needs to contain O
 Signature is generated using similar algorithm as Transaction signing in Ontology blockchain, therefore Private and Public key pair is used:
 
 # '''RequestHash''' = SHA256(SHA256(StringifiedJSONRequest))
-# '''SignedHash''' = Sign(SHA256(RequestHash, Privatekey))
+# '''SignedHash''' = Sign(SHA256(RequestHash, PrivateKey))
 
 Result Signature is embedded into Request object:
 
@@ -63,12 +62,8 @@ Result Signature is embedded into Request object:
   "OntId": "did:ont:TWbWxyRQaxsG3saSZaUt6pHTghgta4qWBA",
   ...,
   "Signature": {
-    "PubKeys": [
-      PublicKey
-    ],
-    "SigData": [
-      SignatureSchemaByte + SignedHash
-    ]
+    "PubKey": PublicKey,
+    "SigData": SignatureSchemaByte + SignedHash
   },
 }
@@ -76,8 +71,21 @@ Result Signature is embedded into Request object: The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema. -===Extracting and validating of Signature=== +===Validating of Signature=== +Validation of signature will ensure, that the Request was not forged and nobody tampered with the Request: +#Remove Signature attribute from the Request +#'''RequestHash''' = SHA256(SHA256(StringifiedJSONRequest)) +#'''Result''' = ValidateSignature(SHA256(RequestHash), Signature.PubKey) + +The '''ValidateSignature''' method should implement specific cryptographic algorithm for signature validation corresponding to selected Signature schema. + +===Retrieving DDO and proving the identity=== +Service provider needs to use one of the SDKs for communicating with Ontology network to retrieve DDO for ONT ID specified in the request. + +After successfully retrieving DDO from blockchain, SeP checks PublicKeys array and try to find PublicKey which was used in the Request. + +If the Public key is present, the Service provider has authenticated the Requester and verified that he is owner of the ONT ID. ===Supported signature schemes=== *'''SHA224withECDSA''' = 0, @@ -94,8 +102,8 @@ The '''Sign''' method should implement specific cryptographic algorithm correspo ==Rationale== -'''''User story:''' As a Service Provider, I need to check if the requester is really who he claims to be, before providing the service.'' +'''''User story:''' As a Service Provider, I need to check if the Requester is really who he claims to be, before providing the service.'' or more specifically -'''''User story:''' As a Trust Anchor who would like to issue a verificable claim, I need to check if the requester is really who he claims to be.'' +'''''User story:''' As a Trust Anchor who would like to issue a verificable claim, I need to check if the Requester is really who he claims to be.'' From 7ec182202f18c5372e850d49e521479eb59de968 Mon Sep 17 00:00:00 2001 From: backslash47 Date: Mon, 23 Apr 2018 16:01:38 +0200 Subject: [PATCH 05/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 2 ++ 1 file changed, 2 insertions(+) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index a436c0b..763f2b4 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -87,6 +87,8 @@ After successfully retrieving DDO from blockchain, SeP checks PublicKeys array a If the Public key is present, the Service provider has authenticated the Requester and verified that he is owner of the ONT ID. +If the Public key is not present or no DDO is returned, then the identity is not verified and SeP should not proceed. + ===Supported signature schemes=== *'''SHA224withECDSA''' = 0, *'''SHA256withECDSA''' = 1, From 615dde9ae8c938f2a9db06a4c327a43d6fdad229 Mon Sep 17 00:00:00 2001 From: backslash47 Date: Wed, 25 Apr 2018 10:20:53 +0200 Subject: [PATCH 06/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index 763f2b4..3a2c2b6 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -27,6 +27,11 @@ This proposal makes use of the following functions and definitions: *'''DDO''', an ONT ID Description Object, describing the current state of ONT ID with its claims and used public keys. *'''Signature schema''', a concrete selection of signing algorithm used. *'''Signature schema byte''', an one byte representation of Signature schema used. +*'''Key type''', a type of key (ECDSA, SM2, EDDSA). +*'''Key type byte''', an one byte representation of Key type used. +*'''Curve type''', a specific elliptic curve used (e.g.: secp256r1(P256)). +*'''Cerve type byte''', an one byte representation of Curve type used. +*'''Operation ||''', a string concatenation operation. ===General verification process=== #Requester signs and sends a Request to Service provider. @@ -47,10 +52,10 @@ Request sent to Service provider should be in JSON format and needs to contain O } -Signature is generated using similar algorithm as Transaction signing in Ontology blockchain, therefore Private and Public key pair is used: +Signature is generated with asymetric cryptography using elliptic curves, therefore Private and Public key pair is used: -# '''RequestHash''' = SHA256(SHA256(StringifiedJSONRequest)) -# '''SignedHash''' = Sign(SHA256(RequestHash, PrivateKey)) +# '''RequestHash''' = SHA256(StringifiedJSONRequest)) +# '''SignedHash''' = Sign(RequestHash, PrivateKey) Result Signature is embedded into Request object: @@ -63,20 +68,20 @@ Result Signature is embedded into Request object: ..., "Signature": { "PubKey": PublicKey, - "SigData": SignatureSchemaByte + SignedHash + "Algorithm": SignatureSchemaByte + "SigData": KeyTypeByte || CurveTypeByte || SignedHash }, } -The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema. - +The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema, key type and specified curve. ===Validating of Signature=== Validation of signature will ensure, that the Request was not forged and nobody tampered with the Request: #Remove Signature attribute from the Request -#'''RequestHash''' = SHA256(SHA256(StringifiedJSONRequest)) -#'''Result''' = ValidateSignature(SHA256(RequestHash), Signature.PubKey) +#'''RequestHash''' = SHA256(StringifiedJSONRequest) +#'''Result''' = ValidateSignature(RequestHash, Signature.PubKey) The '''ValidateSignature''' method should implement specific cryptographic algorithm for signature validation corresponding to selected Signature schema. From 2e83429083e1b5ddf5522a99da54502bb817373d Mon Sep 17 00:00:00 2001 From: backslash47 Date: Wed, 25 Apr 2018 10:36:27 +0200 Subject: [PATCH 07/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index 3a2c2b6..a1373ca 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -30,7 +30,7 @@ This proposal makes use of the following functions and definitions: *'''Key type''', a type of key (ECDSA, SM2, EDDSA). *'''Key type byte''', an one byte representation of Key type used. *'''Curve type''', a specific elliptic curve used (e.g.: secp256r1(P256)). -*'''Cerve type byte''', an one byte representation of Curve type used. +*'''Curve type byte''', an one byte representation of Curve type used. *'''Operation ||''', a string concatenation operation. ===General verification process=== @@ -67,9 +67,9 @@ Result Signature is embedded into Request object: "OntId": "did:ont:TWbWxyRQaxsG3saSZaUt6pHTghgta4qWBA", ..., "Signature": { - "PubKey": PublicKey, + "PubKey": KeyTypeByte || CurveTypeByte || PublicKey, "Algorithm": SignatureSchemaByte - "SigData": KeyTypeByte || CurveTypeByte || SignedHash + "SigData": SignedHash }, } From 12e4da089e603633694186e0ee7e1e09656e0fa2 Mon Sep 17 00:00:00 2001 From: backslash47 Date: Wed, 25 Apr 2018 10:43:57 +0200 Subject: [PATCH 08/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index a1373ca..516cd7c 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -2,7 +2,7 @@ OEP: Title: Verification of ONT ID ownership in web environment Author: Matus Zamborsky - Type: Informational + Type: Standard Status: Draft Created: 2018-04-23 @@ -114,3 +114,10 @@ If the Public key is not present or no DDO is returned, then the identity is not or more specifically '''''User story:''' As a Trust Anchor who would like to issue a verificable claim, I need to check if the Requester is really who he claims to be.'' + +==Test Cases== +backslash47/ontology-ts-sdk - https://github.com/backslash47/ontology-ts-sdk/blob/oep-verify-impl/test/webRequest.test.ts + +==Implementation== + +backslash47/ontology-ts-sdk - https://github.com/backslash47/ontology-ts-sdk/blob/oep-verify-impl/src/web/webRequest.ts From 787d7b3be2597ef42c74440b984f22d0d845ea6c Mon Sep 17 00:00:00 2001 From: backslash47 Date: Fri, 27 Apr 2018 15:18:13 +0200 Subject: [PATCH 09/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 70 ++++++++++++++++++++++--------------------------- 1 file changed, 31 insertions(+), 39 deletions(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index 516cd7c..92a9aba 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -10,7 +10,7 @@ ==Abstract== A method is proposed for online verification of ONT ID ownership. Trust anchors or other entities can use this method for identity authentication. -This method is based on the same cryptographic principles as is used during caller identification in Smart contract execution. +This method is based on the same cryptographic principles as is used during claim verification. ==Motivation== @@ -24,35 +24,30 @@ This proposal makes use of the following functions and definitions: *'''Service provider (SeP)''', a provider of some service (e.g.: issuing veryfiable claim). *'''Signature''', a cryptographic signature of unsigned data using one of the supported cryptographic schemes. *'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash. -*'''DDO''', an ONT ID Description Object, describing the current state of ONT ID with its claims and used public keys. +*'''Base64''', a well-known byte array encoding scheme used to encode arbitrary byte array into string. *'''Signature schema''', a concrete selection of signing algorithm used. -*'''Signature schema byte''', an one byte representation of Signature schema used. -*'''Key type''', a type of key (ECDSA, SM2, EDDSA). -*'''Key type byte''', an one byte representation of Key type used. -*'''Curve type''', a specific elliptic curve used (e.g.: secp256r1(P256)). -*'''Curve type byte''', an one byte representation of Curve type used. -*'''Operation ||''', a string concatenation operation. +*'''PublicKeyId''', the ID of a signature public key. ===General verification process=== #Requester signs and sends a Request to Service provider. -#SeP validates the Signature. -#SeP retrieves DDO corresponding to supplied ONT ID using ONT ID Smart contract. -#SeP checks if the DDO contains public key used in Signature. +#SeP requests status of declared public key from blockchain. +#SeP validates if the key is not revoked and verifies the signature. ===Signing and sending Request=== -Request sent to Service provider should be in JSON format and needs to contain OntId attribute and can contain any other arbitrary attributes: +Request sent to Service provider should be in JSON format and needs to contain Signature and can contain any other arbitrary attributes which are the also subject of signing. + +Unsigned request: 
 {
   "id": "7c756d2c-0630-4aa1-86e1-87a6921a5241",
   "data1": "...",
   "data2": "...",
-  "OntId": "did:ont:TWbWxyRQaxsG3saSZaUt6pHTghgta4qWBA",
   ...,
 }
-Signature is generated with asymetric cryptography using elliptic curves, therefore Private and Public key pair is used: +Signature is generated using asymetric cryptography, therefore corresponding Private and Public key pair is used: # '''RequestHash''' = SHA256(StringifiedJSONRequest)) # '''SignedHash''' = Sign(RequestHash, PrivateKey) @@ -64,48 +59,45 @@ Result Signature is embedded into Request object: "id": "7c756d2c-0630-4aa1-86e1-87a6921a5241", "data1": "...", "data2": "...", - "OntId": "did:ont:TWbWxyRQaxsG3saSZaUt6pHTghgta4qWBA", ..., "Signature": { - "PubKey": KeyTypeByte || CurveTypeByte || PublicKey, - "Algorithm": SignatureSchemaByte - "SigData": SignedHash + "PublicKeyId": "did:ont:TRAtosUZHNSiLhzBdHacyxMX4Bg3cjWy3r#keys-1", + "Format": "pgp", + "Value": SignedHash, + "Algorithm": "SHA256withECDSA" }, } -The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema, key type and specified curve. +The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema and encode the resulting value in Base64 encoding. ===Validating of Signature=== -Validation of signature will ensure, that the Request was not forged and nobody tampered with the Request: +Validation of signature will ensure, that the Request was not forged and nobody tampered with the Request. + +First Service provider needs to use one of the SDKs for communicating with Ontology blockchain to retrieve Public key status for declared Public key and check if it is not revoked. Then it should validate the signature: #Remove Signature attribute from the Request #'''RequestHash''' = SHA256(StringifiedJSONRequest) -#'''Result''' = ValidateSignature(RequestHash, Signature.PubKey) +#'''Result''' = ValidateSignature(RequestHash, Signature, PublicKey) The '''ValidateSignature''' method should implement specific cryptographic algorithm for signature validation corresponding to selected Signature schema. -===Retrieving DDO and proving the identity=== -Service provider needs to use one of the SDKs for communicating with Ontology network to retrieve DDO for ONT ID specified in the request. - -After successfully retrieving DDO from blockchain, SeP checks PublicKeys array and try to find PublicKey which was used in the Request. - -If the Public key is present, the Service provider has authenticated the Requester and verified that he is owner of the ONT ID. +If the signature is valid, the Service provider has authenticated the Requester and verified that he is owner of the ONT ID. -If the Public key is not present or no DDO is returned, then the identity is not verified and SeP should not proceed. +If the signature is not valid, the Service provider is not able to retrieve Public key status, or the status is revoked, then the identity is not verified and SeP should not proceed. ===Supported signature schemes=== -*'''SHA224withECDSA''' = 0, -*'''SHA256withECDSA''' = 1, -*'''SHA384withECDSA''' = 2, -*'''SHA512withECDSA''' = 3, -*'''SHA3_224withECDSA''' = 4, -*'''SHA3_256withECDSA''' = 5, -*'''SHA3_384withECDSA''' = 6, -*'''SHA3_512withECDSA''' = 7, -*'''RIPEMD160withECDSA''' = 8, -*'''SM3withSM2''' = 9, -*'''SHA512withEDDS''' = 10, +*'''SHA224withECDSA''', +*'''SHA256withECDSA''', +*'''SHA384withECDSA''', +*'''SHA512withECDSA''', +*'''SHA3_224withECDSA''', +*'''SHA3_256withECDSA''', +*'''SHA3_384withECDSA''', +*'''SHA3_512withECDSA''', +*'''RIPEMD160withECDSA''', +*'''SM3withSM2''', +*'''SHA512withEDDS''' ==Rationale== From ef1f5e84a33aef51187a7bdc2ab9069df0f69bae Mon Sep 17 00:00:00 2001 From: backslash47 Date: Fri, 27 Apr 2018 15:19:13 +0200 Subject: [PATCH 10/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index 92a9aba..e5f141d 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -20,7 +20,7 @@ Currently there is no recommended or established way of ONT ID ownership verific This proposal makes use of the following functions and definitions: -*'''Requester''', an user wanting to prove ONT ID ownership. +*'''Requester''', an user wanting to prove his ONT ID ownership. *'''Service provider (SeP)''', a provider of some service (e.g.: issuing veryfiable claim). *'''Signature''', a cryptographic signature of unsigned data using one of the supported cryptographic schemes. *'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash. From 1197a1f22cc40ef36c57633f587dcd70f9c77689 Mon Sep 17 00:00:00 2001 From: backslash47 Date: Fri, 27 Apr 2018 15:23:00 +0200 Subject: [PATCH 11/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index e5f141d..8feb582 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -82,9 +82,9 @@ First Service provider needs to use one of the SDKs for communicating with Ontol The '''ValidateSignature''' method should implement specific cryptographic algorithm for signature validation corresponding to selected Signature schema. -If the signature is valid, the Service provider has authenticated the Requester and verified that he is owner of the ONT ID. +If the signature is valid, the Service provider has authenticated the Requester and verified that he is the owner of the ONT ID. -If the signature is not valid, the Service provider is not able to retrieve Public key status, or the status is revoked, then the identity is not verified and SeP should not proceed. +If the signature is not valid or the Service provider is not able to retrieve Public key status or the status is revoked, then the identity is not verified and SeP should not proceed. ===Supported signature schemes=== *'''SHA224withECDSA''', From 84958ce48e578e25132ac621e2f2b69ac3d1cc1c Mon Sep 17 00:00:00 2001 From: backslash47 Date: Fri, 27 Apr 2018 15:44:45 +0200 Subject: [PATCH 12/12] Update OEP-Y.mediawiki --- OEP-Y.mediawiki | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/OEP-Y.mediawiki b/OEP-Y.mediawiki index 8feb582..d45d3ca 100644 --- a/OEP-Y.mediawiki +++ b/OEP-Y.mediawiki @@ -22,11 +22,12 @@ This proposal makes use of the following functions and definitions: *'''Requester''', an user wanting to prove his ONT ID ownership. *'''Service provider (SeP)''', a provider of some service (e.g.: issuing veryfiable claim). -*'''Signature''', a cryptographic signature of unsigned data using one of the supported cryptographic schemes. -*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash. +*'''Signature''', a cryptographic signature of unsigned data using one of the supported signature schemas. *'''Base64''', a well-known byte array encoding scheme used to encode arbitrary byte array into string. -*'''Signature schema''', a concrete selection of signing algorithm used. +*'''Signature schema''', a concrete selection of hashing function and signing algorithm used. *'''PublicKeyId''', the ID of a signature public key. +*'''GetPublicKeyStatus''', a method of ONT ID smart contract to retrieve the public key and its status by id. +*'''Stringify''', a deterministic algorithm for encoding a JSON object as a single string. The algorithm needs to be implemented on both Requester and SeP end in the same manner, so it produces the same result for the same input. ===General verification process=== #Requester signs and sends a Request to Service provider. @@ -49,8 +50,7 @@ Unsigned request: Signature is generated using asymetric cryptography, therefore corresponding Private and Public key pair is used: -# '''RequestHash''' = SHA256(StringifiedJSONRequest)) -# '''SignedHash''' = Sign(RequestHash, PrivateKey) +# '''SignedHash''' = Sign(Stringify(Request), PrivateKey) Result Signature is embedded into Request object: @@ -71,14 +71,16 @@ Result Signature is embedded into Request object: The '''Sign''' method should implement specific cryptographic algorithm corresponding to selected Signature schema and encode the resulting value in Base64 encoding. +===Requesting status of declared Public Key=== +Service provider will preferably use one of the SDKs for communicating with Ontology blockchain to retrieve Public key status for declared Public key and check if it is not revoked. + +#'''Status''' = GetPublicKeyStatus(Signature.PublicKeyId) + ===Validating of Signature=== Validation of signature will ensure, that the Request was not forged and nobody tampered with the Request. -First Service provider needs to use one of the SDKs for communicating with Ontology blockchain to retrieve Public key status for declared Public key and check if it is not revoked. Then it should validate the signature: - #Remove Signature attribute from the Request -#'''RequestHash''' = SHA256(StringifiedJSONRequest) -#'''Result''' = ValidateSignature(RequestHash, Signature, PublicKey) +#'''Result''' = ValidateSignature(Stringify(Request), Signature, PublicKey) The '''ValidateSignature''' method should implement specific cryptographic algorithm for signature validation corresponding to selected Signature schema. @@ -86,7 +88,7 @@ If the signature is valid, the Service provider has authenticated the Requester If the signature is not valid or the Service provider is not able to retrieve Public key status or the status is revoked, then the identity is not verified and SeP should not proceed. -===Supported signature schemes=== +===Supported signature schemas=== *'''SHA224withECDSA''', *'''SHA256withECDSA''', *'''SHA384withECDSA''',