I am creating an asset back security which is a pool of securitised loans. The abs will be fungible as it can be divided up and sold off in smaller units. This supports the basic scenario of securitisation which allows the holder of the asset to then have a balanced portion of loans for risk and return purposes.
The requirement I am struggling with is the ability to be able to verify that the underlying loans and from legitimate issuers and other characteristics without revealing the loans details. Is it possible to achieve this? I believe the only view is of the data for the abs contract but the underlying loans are not accessible. If this is possible, how would privacy be preserved on those loans?
The way I would think about this is each underlying asset (loan) is also issued on ledger by their respective borrowers and sent to the party that is creating the CDO (let's call it that for now).
Issue the CDO on ledger containing with the underlying loans as part of its state. Write the contract in such a way that it allows for the CDO to be divided up and traded.
The above is sufficient to support the first requirement.
The second requirement, to allow for verification that the underlying loans are from legitimate issues and other characteristics while hiding other characteristics can be achieved in multiple ways.
I don't think the creator of the CDO could obfuscate characteristics from the loans they receive as this would also require re-issuance of the loan by the CDO creator to break the link between the original loan issuance. This is so that walking the chain wouldn't reveal the hidden characteristics and you wouldn't be able to verify the original issuer.
The original issuance of the underlying loans could either have the hidden characteristics stored off-ledger or could make use or a trusted oracle that would only reveal them according to some defined set of rules.
Alternatively, the loan issuers could use symmetric keys to encrypt the characteristics to be kept hidden and so keep them as part of the state. The loan issuers could share the keys only when required. A hash of the entire state including the hidden characteristics could be attached to the state and could be used to achieve the same thing, with the issuer only revealing the characteristics when requested (and the hash proving they have not been changed)
This way the underlying loans are accessible from the CDO during each transaction and Verify can be run on the CDO which would reach into the attached underlying loans and run Verify on them too.
Related
I'm currently tying to make a CordApp That will be used for DVP, but I'm having trouble understanding some key concepts. For instance, I understand that Contracts apply to one type of state in particular. What I don't really get is if the contract validation logic should apply to only that state object or all the states that will be in the given transaction.
The typical example would be the issuance of a sell order :
The input of a transaction the state of the stock account of the issuer and the outputs are the sell Order and the modified stock account.
Basically my question is were do I do checks like : I don't sell more than I own, the sum of the number of stocks in the sell order and what is left in the account is equal to what was initially in the account, ... ?
I have followed the Corda tutorials but I'm still not clear on that logic.
It boils down to the Orchestration Layer (flows or APIs, what the user intends to do) vs the Ledger layer (what the user can do. IE - guaranteed shared logic).
Contract code absolutely must be adhered to, so in your case not being able to sell more than you own would be part of the explicit contract.
The CMN guide here helped me conceptualise.
Flows are better described as business logic, so anything can be achieved within a flow as long as it adheres to the contract.
A security consideration: Anybody may create a flow, and they are equally able to use any Asset (and thus it's state) within their third-party flow.
It is the relevant contract that ensures that your asset is used for the purpose you imagine, and that it isn't used malevolently.
I'm really confused as how to handle GDPR. I recently made a web for a client that is just a page with some info and a contact form. This contact form just sends an email to an adress with the users name, email, subject and message. Nothing is stored within the site. Do I need to include anything regarding the GDPR to make it compliant if I'm not storing anything or does the fact that an email is sent to my inbox count as storing data?
To be more specific that TermsFeed's answer, you're asking about article 6 of GDPR; In this case you can reasonably maintain that the processing is necessary "necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract". At the point of submission the data subject is fully in control of whether they choose to give you their information or not. It would however be a good idea to say on the form that the information they provide will not be used for any other purpose (and ideally how long it will be kept for, and where, etc), because anything strictly outside the purpose of the enquiry would indeed require consent.
Consent is normally applied to optional things – for example opting-in to marketing emails while buying something – where the additional processing is not a requirement for the primary purpose of the data collection. Consent should not be used unnecessarily because unlike the other bases for processing, it can be withdrawn unilaterally at any point by the data subject.
Another factor is that you are acting as a data processor; your client is the data controller and they have asked you to process this data on their behalf. In this situation, you are required to comply with data protection regulations applicable to processors (TLS, physical location etc, and you should have a data processing agreement in place with your client to make this clear), but the data is fundamentally not yours. The data subject has a relationship with the controller, not you as processor, so it's your client that really needs to be careful with their terms and behaviour. Not keeping any data on your servers is a very good idea; you can't lose control of data you don't have.
If the data you are handling is at all sensitive, you should conduct a data protection impact assessment (DPIA) and/or privacy impact assessment (PIA; essentially the same, but also looking at higher levels), something which sounds ominous and bureaucratic, but is actually quite straightforward and often quite an interesting exercise - CNIL (the French data protection office) has an excellent PIA app that walks you through the process.
It depends more on how you use that information rather than how you store it. Consent is just one of the legal basis that you can rely on to collect personal data under GDPR.
In Corda, an OwnableState must specify an AbstractParty as an owner. There are two types of AbstractParty:
Party, with a well-known identity
AnonymousParty, identified solely by public key
If I create a CompositeKey to own the OwnableState, who then will store it in their vault as part of FinalityFlow?
At the moment nobody will unless lower level APIs are used.
The vault needs more work to fully understand multi-sig states, e.g. with cash, we need a way to select coins that we're participants of.
It's quite an advanced feature because composite keys have so many use cases. This is typical in the blockchain space, Bitcoin supported CHECKMULTISIG outputs in the protocol long before wallets that knew how to use them existed. And when wallets did start to appear, they had different code and features for different use cases. E.g. using multisig/composite keys for more secure wallets is different to using them to do dispute mediation protocols.
At least with flows we have a straightforward way to implement support - we can make flows that understand composite keys and either have the certs linking the components to real parties, or know who they are some other way, and then go gather the signatures automatically.
I would like to ask your help and suggestion about below use case what are related to our new business case, a CorDapp which will be used to manage software license usage and management.
Does Corda has a pre-defined structure or approach to define the parent and child relationship between different states, for example, one contract state(main contract) has two child contract states(two types of license contracts)
If we want to track the license usage on blockchain, is that a good direction to ownable state for licenses? Our current thought is Party A(License Provider) and Party B(License consumer) has one agreed contract that Party A will provide Party B 100 licenses to be used, but charge will only happen after one license is activated by Party B. So from Corda’s backend process, Party A will issue 100 licenses initially which owner is PartyA, and this shared fact will be initialized as a transaction and will be added to both party’s ledger. Then periodically license usage data will be extracted from Party A’s system and updated the ledger by initializing a transaction, we will use “Move” flow to transfer the license state’s amount and owner. For example, if Party B activated 40 licenses, then Party A’s license state amount will become to 60, and there is another new state which owner is Party B and amount is 40. I thought I should use ownable state for this use case after reading some Corda documentation about linear state and ownable state, but not sure whether my understanding is correct
What is the best practice from Corda about how to design a dynamical contract terms which can be used in smart contract(verify menthod conditions). For example, in the initial version of license management process, two types of licenses and their price will be defined as contract terms, and we plan to define them as the state’s properties(meta data). If later there are one new type need to be added, how should we best handle this situation. Is there any dynamical approach to define the state’s properties/meta data? Our ideal approach is initially there is no any terms defined(no license type pre-defined), and allow user to add different type of license with their price information dynamically on UI, then these dynamically defined contract terms will be stored in CorDapp and can be used in later phase, and this approach can be easily to be “copied” to different providers. Is this possible to do?
Very interesting use case and scenarios. We have not formalized best practices for parent child states in api wrappers, but you can treat the collection of states using the same relational database model as long as your transactions also keep pointers updated.
Our thinking for state representation covers 3 hierarchical scenarios:
1 - portfolio of assets - like an etf or index grouping multiple assets. This can be moved as a new portfolio asset representing a tether to the existing asset data or a grouping function
2 - asset itself - this is a linear state that has a life cycle of events that influence it. Think of this like the company ref data behind the equity
3 - fungible asset representation - cash flow fungible staye that can reference the asset's linear id - think of issued shares for the equity
In this case, the 2 & 3 scenarios have the ref data to fungible state relationship. The fungible state can store the reference to the asset's linear ID and the asset can store an array of owners of the equity. Depending on your queries, you can also store another relational table for mapping different foreign and primary keys. The careful part is taking into account this logic linking when executing transactions that change issuance or ownership
For the standard Ethereum factory pattern, cordapps can be broken up into multiple functions. For example, the obligation cordapp uses the corda-finance-1.0.jar package to share different library functions and definitions on self issuing cash and cash properties.
Coming back to the asset example, we have an interest rate swap example cordapp that has contract code defining the known fields in a standard irs ISDA contract. From this template, you can deploy any irs type of state by defining the field properties like maturity date and interest rate.
I imagine the license use case can create similar fields for types for how the business logic or contract code would see it evolve. This also brings to light a tool gap for wrapping a workflow management tool or interface above the corda fundamentals.
We have a system we're designing which has to hold data for people globally, including countries with very strict data protection policies, specifically where data about its citizens must physically reside that country.
Now we could engineer a mechanism for silo-ing/querying the data where it must be pulled from a particular location but as the system will be azure based, we were hoping that cosmosDB's partitioning feature might be an option.
Based on the information available to date for partitioning, it seems like it's possible to assign a location-specific partition for some data but it's not very clear. Any search for partitioning in general goes on about high availability and low latency - good things - but not what I'm looking for.
To this end, can location-specific data be assigned in cosmosDB as part of its feature set or is this something that has to be engineered on top?
For data sovereignty, you must engineer a data access layer across multiple Cosmos DB accounts. Cosmos DB by default will replicate your data across all regions within your account (which is not what you need).
While not specifically for this scenario, you can see a description of how to build such a layer here: https://learn.microsoft.com/en-us/azure/cosmos-db/multi-region-writers