FW: Document "After-the-fact mandate changes" ready for external review
|
Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Hi Clive, all,
The document “After-the-fact mandate changes” was discussed in detail in the Hyperledger Identity working group. There were ten participants, including a person from Hyperledger Indy. There were some discussions about solution directions and potential implementation issues. The general feedback was that the document was well written and clear. No further changes were made. Let us now formally close the document, that is, PDF it, add it to the Wiki list, and formally share it with the Architecture and Identity working groups. OK? Best regards, Oskar From:
hyperledger-requirements-wg-bounces@... <hyperledger-requirements-wg-bounces@...>
on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...> Sent: Wednesday, July 5, 2017 12:57 AM
To: Boulton, Clive Cc: hyperledger-requirements-wg@... Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review
Hi Clive, all,
I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows.
Requirement 1: A user (“anchor”) shall be able to sign over its authorization over a smart contract to another user (“guardian”) after the fact. 1a: The original user (“anchor”) loses its authorization over the smart contract. 1b: The original user (“anchor”) maintains its authorization over the smart contract. Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”). Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (“anchor”) to another user (“guardian”) in a single action. Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (“anchor”) user. Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys. Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain. Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction. Requirement 8: The solution to requirements 1-4 may be programmable.
Following your suggestion, I shall share the document also with hyperledger-arch-wg@... and hyperledger-identity-wg@....
As always, reviews, comments and suggestions remain very welcome!
Best regards,
Oskar
From: Deventer, M.O. (Oskar) van
Hi Aaron,
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.
I am not sure how your comment relates to the subject of my document. My document is about “after-the-fact mandate changes”. Here either the authorized user (“anchor”) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (“guardian”).
Oskar
From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,
From: clive boulton <clive.boulton@...>
Hi Aaron,
Do you know any mandated cases?
What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated.
Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments.
-Clive.
---------- Forwarded message ---------- The minutes from [last] Monday's Requirements Working Group bi-weekly are here: https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017
Our next meeting July 10 - 1pm EST / 10am PST -Clive
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. |
|||||||||||||||||
|
|
|||||||||||||||||
|
Mark Parzygnat <markparz@...>
Hi Everyone, Hi Clive, all, From: hyperledger-requirements-wg-bounces@... <hyperledger-requirements-wg-bounces@...> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Sent: Wednesday, July 5, 2017 12:57 AM To: Boulton, Clive Cc: hyperledger-requirements-wg@... Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review Hi Clive, all,
I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows.
Requirement 1: A user (“anchor”) shall be able to sign over its authorization over a smart contract to another user (“guardian”) after the fact. 1a: The original user (“anchor”) loses its authorization over the smart contract. 1b: The original user (“anchor”) maintains its authorization over the smart contract. Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”). Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (“anchor”) to another user (“guardian”) in a single action. Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (“anchor”) user. Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys. Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain. Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction. Requirement 8: The solution to requirements 1-4 may be programmable.
Following your suggestion, I shall share the document also with hyperledger-arch-wg@... and hyperledger-identity-wg@....
As always, reviews, comments and suggestions remain very welcome!
Best regards,
Oskar
From: Deventer, M.O. (Oskar) van
Hi Aaron,
Oskar
From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,
From: clive boulton <clive.boulton@...> Sent: Monday, July 3, 2017 3:41:25 PM To: Aaron Benningfield Cc: Deventer, M.O. (Oskar) van Subject: Fwd: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
Hi Aaron,
Do you know any mandated cases?
What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated.
Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments.
-Clive.
---------- Forwarded message ---------- The minutes from [last] Monday's Requirements Working Group bi-weekly are here: https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017
“After-the-fact mandate changes”
Our next meeting July 10 - 1pm EST / 10am PST -Clive
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
|
|||||||||||||||||
|
|
|||||||||||||||||
|
Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Hi Mark,
De document was developed by me in collaboration with several others. It is likely to become an agreed document from the RequirementsWG very soon. The purpose of the document is input to IdentityWG, ArchitectureWG and (possibly indirectly) to Hyperledger projects, which includes Hyperledger Fabric.
I am not sure how I should read this statement. If Hyperledger Fabric does already intrinsically support the full set of requirements, then that is great. If not, then there is potential work for contributors to that project.
Does this make sense?
Best regards,
Oskar
From: Mark Parzygnat [mailto:markparz@...]
Sent: Wednesday, 19 July, 2017 19:33 To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...> Cc: Boulton, Clive <clive.boulton@...>; hyperledger-requirements-wg@...; hyperledger-requirements-wg-bounces@... Subject: Re: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review
Hi Everyone,
From:
hyperledger-requirements-wg-bounces@... <hyperledger-requirements-wg-bounces@...> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...> Hi Clive, all, I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows. Requirement 1: A user (“anchor”) shall be able to sign over its authorization over a smart contract to another user (“guardian”) after the fact. 1a: The original user (“anchor”) loses its authorization over the smart contract. 1b: The original user (“anchor”) maintains its authorization over the smart contract. Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”). Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (“anchor”) to another user (“guardian”) in a single action. Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (“anchor”) user. Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys. Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain. Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction. Requirement 8: The solution to requirements 1-4 may be programmable. Following your suggestion, I shall share the document also with hyperledger-arch-wg@... and hyperledger-identity-wg@.... As always, reviews, comments and suggestions remain very welcome! Best regards, Oskar From: Deventer, M.O. (Oskar) van Hi Aaron,
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.
I am not sure how your comment relates to the subject of my document. My document is about “after-the-fact mandate changes”. Here either the authorized user (“anchor”) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (“guardian”). Oskar From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,
Hi Aaron, Do you know any mandated cases? What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated. Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments. -Clive. ---------- Forwarded message ---------- The minutes from [last] Monday's Requirements Working Group bi-weekly are here: https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017
“After-the-fact mandate changes” Our next meeting July 10 - 1pm EST / 10am PST -Clive This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete
the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
|
|||||||||||||||||
|
|
|||||||||||||||||
|
Mark Parzygnat <markparz@...>
Hi Oskar, Hi Mark, De document was developed by me in collaboration with several others. It is likely to become an agreed document from the RequirementsWG very soon. The purpose of the document is input to IdentityWG, ArchitectureWG and (possibly indirectly) to Hyperledger projects, which includes Hyperledger Fabric.
Does this make sense? Best regards, Oskar
From: Mark Parzygnat [mailto:markparz@...]
Sent: Wednesday, 19 July, 2017 19:33 To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...> Cc: Boulton, Clive <clive.boulton@...>; hyperledger-requirements-wg@...; hyperledger-requirements-wg-bounces@... Subject: Re: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review Hi Everyone, Hi Clive, all,
Sent: Wednesday, July 5, 2017 12:57 AM To: Boulton, Clive Cc: hyperledger-requirements-wg@... Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review Hi Clive, all, I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows. Requirement 1: A user (“anchor”) shall be able to sign over its authorization over a smart contract to another user (“guardian”) after the fact. 1a: The original user (“anchor”) loses its authorization over the smart contract. 1b: The original user (“anchor”) maintains its authorization over the smart contract. Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”). Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (“anchor”) to another user (“guardian”) in a single action. Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (“anchor”) user. Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys. Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain. Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction. Requirement 8: The solution to requirements 1-4 may be programmable. Following your suggestion, I shall share the document also with hyperledger-arch-wg@... and hyperledger-identity-wg@.... As always, reviews, comments and suggestions remain very welcome! Best regards, Oskar From: Deventer, M.O. (Oskar) van Hi Aaron,
Oskar From: Aaron Benningfield [mailto:aaron.b.benningfield@...] What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about, From: clive boulton <clive.boulton@...> Sent: Monday, July 3, 2017 3:41:25 PM To: Aaron Benningfield Cc: Deventer, M.O. (Oskar) van Subject: Fwd: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th Hi Aaron, Do you know any mandated cases? What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated. Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments. -Clive. ---------- Forwarded message ---------- The minutes from [last] Monday's Requirements Working Group bi-weekly are here: https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017
“After-the-fact mandate changes” Our next meeting July 10 - 1pm EST / 10am PST -Clive This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
|
|||||||||||||||||
|
|
|||||||||||||||||
|
Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Hi Mark,
This question can only be answered based on well formulated requirements. The RequirementsWG has worked on these for the last two months. Initial feedback suggests that there are Hyperledger projects that do not support this set of requirements. Moreover, the support may be difficult for some of them without major architectural changes.
The purpose of the RequirementsWG is to figure out what features are needed. (The fact that a feature is missing does not imply that there is a market need, more likely the opposite.)
So we should spell out the associated use case and requirements, correct? (By the way, I am particularly interested in inter-project use cases and requirements.)
Best regards,
Oskar
From: Mark Parzygnat [mailto:markparz@...]
Sent: Thursday, 20 July, 2017 16:30 To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...> Cc: hyperledger-requirements-wg@... Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review
Hi Oskar,
I am not sure how I should read this statement. If Hyperledger Fabric does already intrinsically support the full set of requirements, then that is great. If not, then there is potential work for contributors to that project.
Hi Everyone,
From:
hyperledger-requirements-wg-bounces@... <hyperledger-requirements-wg-bounces@...> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...> Hi Clive, all, I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows. Requirement 1: A user (“anchor”) shall be able to sign over its authorization over a smart contract to another user (“guardian”) after the fact. 1a: The original user (“anchor”) loses its authorization over the smart contract. 1b: The original user (“anchor”) maintains its authorization over the smart contract. Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”). Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (“anchor”) to another user (“guardian”) in a single action. Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (“anchor”) user. Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys. Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain. Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction. Requirement 8: The solution to requirements 1-4 may be programmable. Following your suggestion, I shall share the document also with hyperledger-arch-wg@... and hyperledger-identity-wg@.... As always, reviews, comments and suggestions remain very welcome! Best regards, Oskar From: Deventer, M.O. (Oskar) van Hi Aaron,
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.
I am not sure how your comment relates to the subject of my document. My document is about “after-the-fact mandate changes”. Here either the authorized user (“anchor”) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (“guardian”). Oskar From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,
Hi Aaron, Do you know any mandated cases? What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated. Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments. -Clive. ---------- Forwarded message ---------- The minutes from [last] Monday's Requirements Working Group bi-weekly are here: https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017
“After-the-fact mandate changes” Our next meeting July 10 - 1pm EST / 10am PST -Clive This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete
the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
|
|||||||||||||||||
|
|
|||||||||||||||||
"Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact mandate changes" was discussed in detail in the Hyperled
"Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in collaboration with several others. It is likely to becom
