Document "After-the-fact mandate changes" ready for external review


Aaron Benningfield <aaron.b.benningfield@...>
 

Ok, I see what I have been doing wrong (comments not being displayed in Google Docs). See the link below


https://docs.google.com/document/d/1RecabhCuL7v-VTIcGTNpqPryodseAzvfs4TZzHANyrE/edit?usp=sharing




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
Sent: Wednesday, 05 July, 2017 09:43
To: Aaron Benningfield <aaron.b.benningfield@...>
Cc: clive boulton <clive.boulton@...>
Subject: RE: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

 

Hi Aaron,

 

  • My comments did not make it in Oskar's Document for what ever reason

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.

 

  • 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.

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@...]
Sent: Wednesday, 05 July, 2017 02:18
To: clive boulton <
clive.boulton@...>; Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Subject: Re: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

 

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 ----------
From: clive boulton <
clive.boulton@...>
Date: Mon, Jul 3, 2017 at 3:21 PM
Subject: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
To: Hyperledger Requirements <
hyperledger-requirements-wg@...>

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


Domain experts please review the use case: 

 

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 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
Sent: Wednesday, 05 July, 2017 09:43
To: Aaron Benningfield <aaron.b.benningfield@...>
Cc: clive boulton <clive.boulton@...>
Subject: RE: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

 

Hi Aaron,

 

  • My comments did not make it in Oskar's Document for what ever reason

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.

 

  • 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.

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@...]
Sent: Wednesday, 05 July, 2017 02:18
To: clive boulton <
clive.boulton@...>; Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Subject: Re: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

 

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 ----------
From: clive boulton <
clive.boulton@...>
Date: Mon, Jul 3, 2017 at 3:21 PM
Subject: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
To: Hyperledger Requirements <
hyperledger-requirements-wg@...>

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


Domain experts please review the use case: 

 

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.