General relationship manager
Entities
The GRM describes entities and relationships. Entities may take many forms.
The Global Relationship Manager
In the GRM every object in your interconnected world is represented by GUIDs (Globally Unique Id's)
The GUIDs represent other entities and/or someones relationship with those entities.
The relationship GUID has a representation in the cloud which defines the relationship. Essentially anyone can create these GUIDs and upload them, and anyone can then using other GUIDs to associate functions and data they would like the relationship GUID to support.
At the top level we have kind of core relationships
For example the record button on a particular PVR remote would have a GUID and against that GUID a generic guid with a meaning of "get IR code" would be associated. Since this PVR remote is not actually itself connected to the IOT the actual IR code would also be recorded in the cloud.
In other relationships the GUID for a method would be a method that interrogated an actually connected device, or your personal cloud data.
The GUID may be absolutely explicit. e.g. if a new API came along for "Get Contents List" it would be represented by a new GUID.
The above table could be a bit ambiguous on where the GUIDs reside, in the case of our AV receiver record button for example, we certainly don't want our GRM enabled remote control to be accessing the global cloud each time you press record, plainly data would be cached, but here is the point, the data is not so much cached as copied. It would become a GUID on the device evolved with a key saying where the data originated.
This ties in with the flexibility of the system GUIDs are all about the semantics they contain, something using those semantics may refer to that GUID directly, it may copy the semantics and keep a reference to the originating GUID so that it can follow updates, or it may choose its own entirely new path.
In the cloud database of GUIDs, each GUID entity has list of GUID->value pairs which can take the following form
This is an almost free form database where language translation is inherent and where as every key is itself a GUID the keys link to information on what the keys mean. Plainly when drilling down the software looking at the GUID database will start off pre-primed with a level of GUID knowledge such as the GUID of a country. Note that even at country level we are using a GUID, this is because the database is entirely free form. A translation table might not be between languages, it might be between dialects.
Where the system is not free form is that by insisting all keys are themselves GUIDs, and by insisting that a valid primitive GUID entry must contain a DEFINITION-TEXT keys, the system is self documenting.
RSA keys
Every entity that can relate to another entity in a contractual fashion may have its own GUID and RSA keypair. With the IOT this becomes a potential serial number and audit trail of device ownership. If the entity does not have its own RSA pair it may relate via an owners key pair. Note that how relationships are made might be even looser than that, this is a semantic model where each side of a relationship request endeavours via exploring the GUID to seek a level of understanding. One would expect agreement types to follow something like the SSH system:
SSH can be configured to utilize a variety of different symmetrical cipher systems, including AES, Blowfish, 3DES, CAST128, and Arcfour. The server and client can both decide on a list of their supported ciphers, ordered by preference. The first option from the client's list that is available on the server is used as the cipher algorithm in both directions.
Basically a system where the application receiving the request is fussy about the security level. It is worth noting that all relationship requests are owner signed and that the owner is themselves ratified by a signing authority.
The role of the IPP
An IPP is a trusted by the user body that has both of copy of the global cloud and also the users cloud data. The copy of the global cloud has features similar to that of the bitcoin blockchain. In the global cloud databases that have signed/immutable data must never have core data under a GUID altered. With bitcoin it relies on no one organizational having the power to out compute and hence out vote on transactions in the blockchain.
The IPP is a little like a vastly extended LASTPASS, something that not only stores notes and access keys, but also organizes your world into hierarchies or entities and relationships.
Databases within the IPP stay within the IPP, apart from such data as relationships allow. One core relationship here is that of backup. The chances are you would have an application on your main PC backing up your IPP data, and also you would authorize a relationship with a secondary IPP as well.
This underlines the point that our lives are now mapped out by devices, data and relationships. The IPP would for example be the archive of all of your emails. This archiving role is an important element of the functionality of the IPP. Your data is YOUR DATA and you want to own and control it. But the IPP is not best suited for data access. Take for example a skype chat, Skype is an optimized and polished frontend to a chat, and it would be nonsensical for Skype to pull chat data from IPP's, however it should push the chat to your IPP, and if for any reason the chat parties got fed up with Skype, they should be able to switch to say facebook messager and authorize messager with the GUID of the chat at which point messenger would pull the chat from the IPP's.
This changes the role of facebook, twitter, skype etc. These organizations continue to operate, but they no longer own us, they get our interaction because they offer the best experience. In this model there is no reason why given a chat GUID why I should not be chatting on Skype because I like skype, but the other party is on messenger. This might not be quite as responsive as the IPP's would be acting as intermediary, but the whole model makes this sort of interoperability far simpler.
A Secure Model?
In the model used every entity is by and large signed by a private RSA key and linked to the public key used, which is in turn linked to an authority for that key. This is roughly the equivalent of SSL certificate, except the signing authority is an IPP Internet privacy provider. Where does this leave us in terms of security against fraudulent attempts to form a relationship? Say we receive a request for a payment to "Nationwide Bank" the name of this entity would have to have been signed by the IPP. e.g. it would need a rogue IPP for this to happen and the system will need means of reporting and tracking incidents in the common cloud. This rogue request would also not contain a GUID referring to any current relationship you have with the bank, which would set off alarm bells. Requests would also work via the micropayment system making mass spamming of rogue requests more difficult, last but not least a relationship request that asks for payment would only be validated if it contained at least some tokens properly identified the receiver.
What this type of model does not prevent is all type of rogue marketing and extortion.But even there it can help. For example a common ploy at the moment is the one off special offer with the large recurring monthly fee in the small print. In a relationship request there is no small print, the full financial details would be present in the relationship request, and this type of request would be a three way request involving your bank which would now have full details on what could be withdrawn. So your application in approving this relationship would be showing in large letters the real nature of what you would be signing up to.
As alluded to with IPP the common cloud database could also be used to report issues and your relationship application could check for reports.
The Relationship model and the user interface
A relationship model means that your rights in respect of a relationship may be mediated by other relationships, for such a model to work for the user in terms of an understandable model manipulated by a simple use interface then a user interface will have two basic modes of looking at a relationship.
A good example of this would be a joint mortgage endowment policy, this is a relationship between an endowment entity owned by a building society and an entity referring to a couple, it might well be down to the building society whether the couple entity is a new one or the couples standard entity if it qualifies.
But some actions on an endowment policy such as setting up payment via direct debit would be open to the individual rather than the couple.
As such in a user interface opening a bank's direct debit entity would pull in the status/possibility of that direct debit without cluttering the screen with the relationship chain.
The key point is that the relationship as to what can and can’t be done is simple from a user point of view, the relationship entity of a couple or an endowment might well be quite complex, but that complexity does not hit the screen that the user sees unless they zoom in on the relationship. As a rule the user wants to do something between two entities and is or is not allowed to do so based on relationships, but those relationships are only visible if the user needs to explore why they can or cannot do something.
An inheritance model
Consider a dimmable lightbulb, this could expose several GUIDs describing its methods.
The principle is that systems accessing the lightbulb can do useful things even if they don't know about the subclasses. So for example if you have given a power company a relationship that allows it to turn off devices in preparation for a powercut, then their controller only needs very basic abilities, as you move up the scale you might eventually reach the point where a manufacturing has specific software the does very special things with a device such as setup functions, but below that any household controller with a reasonable understanding of core GUIDs can deal with any system that supports those GUIDS.
GUIDS
A GUID is a globally unique identifier. In the case of the GRM GUIDs have two typical parts.
A GUID of where the data can be found, its ORIGIN. e.g. which IPP and personal space is it on, or is it in the cloud. This is actually a left to right series of ORIGIN GUIDs. So for example if we are dealing with a chat between individuals, each IPP would store both sides of the chat, but record the other persons IPP location as well. This both speeds up access and creates a secure recorded chat. The left most location is the local copy, the rightmost location is the origin.
The actual GUID which also contains the GUID of the signing authority. All static GUIDs are signed by a trusted authority which will only sign the same GUID once. This does not preclude a rogue GUID, but it secures the model in that once you have established a relationship with a set of GUIDs, the GUIDs cannot be changed.
At this moment I am thinking the signatures ignore the first GUID part, so as to allow data to migrate without invalidating signed relationships. This might be an option based on the signingGUID.
GUID spaces
GUID data lives in multiple databases according to purpose and hence calling APIs will need to know which database to ask for. This has the effect of:
predefining a level of security. e.g. if you go to the "STATIC" section you know whatever is there for a GUID must always be the same once signed, and your device can cache sand verify signatures.
By having sections such as STATIC/DYNAMIC/IOT/SOCIAL the IPP can optimize technology around those databases.
Note that the database names won't be text strings STATIC etc, they will themselves be GUID keys into a GLOBAL segment that describes the properties of the database.
database is simply a word that fits here, the technology used is entirely up to the IPP.
GUIDs fall into at least a number classes with clearly distinguishable formats.
GUID break down
Let's break down a RATIFIED tag layer by layer so we can understand what an IPP would do with the tag on seeing this for the first time. The PREVIOUS_3_PAYSLIPS_MAIN_EMPLOYER_3DA_30DR is a GUID and its label whilst descriptive is ignored. The meaning is derived from the keys within the GUID. For brevity I have not included the keys that will generally be present. So we will deal with them first. Note that within a GUID "_" is used to delimit parts of the key that are also keys "-" is used to delimit words within a key. Those words may also be keys in their own right. Please remember this is only a naming convention the GUID does not imply any meaning at all.
Common keys
Common keys breakdown
Note that these keys themselves with have the Common Key parts
ORIGIN
DEFINITION-TEXT
LABEL_DATA-TYPE
LABEL-TEXT
LANGUAGE-CODE-MAP-TEXT
LANGUAGE-CODE-MAP-TEXT_LANGUAGE-CODE-MAP-TEXT
LABEL-TEXT_LANGUAGE-CODE-MAP-TEXT
LABEL-TEXT_COUNTRY-CODE-MAP-TEXT-FORMAT-RULES
PRECEDENCE-GUID-LIST
GUID-LIST
KEY-VALUE_CONTAINER
KEYVALUE-CONTAINER_LANGUAGE-CODE-MAP-TEXT-TEXT
PRECEDENCE-LIST_LANGUAGE-CODE-MAP-TEXT
LANGUAGE-CODE-AND-CHARACTER-ENCODING-MAP-RULES
LANGUAGE-CODE-AND-CHARACTER-ENCODING-MAP-RULES_LANGUAGE-CODE-MAP-TEXT
CAPITALISE-FIRST-LETTER-OF-EVERY-WORD
JAVASCRIPT-SCRIPT
CAPITALISE-FIRST-LETTER-OF-EVERY-WORD_JAVASCRIPT_SCRIPT
SINGULAR-VALUE_JAVASCRIPT-SCRIPT_TYPE1
SINGULAR-VALUE_JAVASCRIPT-SCRIPT_TYPE1-LANGUAGE-CODE-MAP-TEXT
SCRIPT-MAP
SCRIPT-MAP_LANGUAGE-CODE-MAP-TEXT
READ-ACCESS-REQUEST-DURATION
Note that this key will not be used on its own. A READ-ACCESS_REQUEST will also be part of a relationship GUID
TEMPORARY-DURATION
PREVIOUS-INCLUSIVE-COUNT-3
PREVIOUS-INCLUSIVE-COUNT
PREVIOUS-INCLUSIVE-COUNT_TEXT_COUNTRY_MAP
3-DAY-READ-ACCESS_REQUEST
This is just an example, there would be a lot of these keys in the core cloud available
PREVIOUS_3_PAYSLIPS_MAIN_EMPLOYER_3DA_30DR
This is a STATIC entity. It is important to note that a lot of the definition of this entry could be done in other ways. For example we have placed DESCRIPTION_AUDIO and DESCRIPTION_TEXT as top level items, there could just as well be a top level item called DESCRIPTION with DESCRIPTION_AUDIO and DESCRIPTION_TEXT as sub-items, or perhaps a top level item called DYNAMIC for all mutable sub-items. An application seeing a GUID is expected to understand enough of the core definitions to make sense of any format of the GUID.
So long as our IPP can make sense of some of the terms it can respond intelligently. If it does not know what MAIN_EMPLOYER means it just asks you about all payslips when asking you if you want to share the items. Note that PREVIOUS_3_PAYSLIPS_MAIN_EMPLOYER_3DA_30DR will itself be wrapped in relationship request GUID specifying the parties involved.
TEMPORARY-DURATION
HELP_AUDIO
HELP_AUDIO_LABEL_AUDIO
HELP_AUDIO_LABEL_AUDIO_COUNTRY-CODE-MAP
Audio help on the audio help label
COUNTRY-CODE_UK->HELP_AUDIO_LABEL_AUDIOFILES_UK
COUNTRY-CODE_UK_HELP_AUDIO_LABEL_AUDIO_MP3
READ-ACCESS-REQUEST_SINGULAR-ENTITY_PAYSLIP
PAYSLIP-FIND-PREVIOUS
This is getting to the heart of the GRM, have we actually got a payslip in our IPP?
PAYSLIP-FIND_FIND_HINTS
These are hints that can help the GRM explore data sources for items. Items are going to fall into categories.
Items outside of the IPP in non GRM format that we can nonetheless search for and present as candidates and extract some useful information from. e.g. an email has a date.
Items that are outside of the GRM and in non GRM format but which the user can set up say an email rule to reference or copy into their IPP.
Items in GRM format.
REQUESTED
SINGULAR-ENTITY
SINGULAR-OPERATION
This is a core semantic expected to be universally understood as identifying the core entity in a GUID. SINGLULAR- will have a parent that will provide context. e.g. SINGULAR_OPERATION or SINGULAR_ENTITY.
SINGULAR-DERIVED-VALUE
This is a core semantic expected to be universally understood as identifying the core operation in a GUID.
GUID data segments
The data GUID for a GUID has three segments.
The GRM format is intended as a repository of all kinds of information include "chat" type data. In a chat each sent message will be a GUID and hence if it is edited then it will have a superseded by GUID in the meta data, there will also be a GUID for the whole chat and a GUID for the chat state which will have a list of the message GUIDs and again will be being constantly superseded as the chat goes on. This is plainly quite verbose, but this is intended to be a secure system.
Core Keys
The Agreement Model
This is fundamental to the GRM a relationship between two of more GUIDs is defined as follows in the core data:
Agreements would generally be held by the IPP, and as part of auditing it would ensure knowledge of an agreement is held by the owning parties meta data.
The permissions model
The agreement type GUID contains the permissions as a list of permission GUIDs. What these permissions are is extremely flexible. They might refer to anything at all, the key point is that the agreement has established the right. for example the GUID might be the GUID of "Get Contents list" mentioned earlier. That call would basically accept an encrypted protocol that would contain "whose asking and by what agreement". In practical terms I would imagine devices on the IOT of things would heavily cache authorization data as they could not possibly verify agreements on each access.
Discovery and access
One of the core operations is for devices to discover each others existence, to this end they can contain discover ability and access keys
Discovery keys
Note that there are only three discovery states. This is deemed very important. If we want people to engage with a relationship manager, it has to be simple and manageable, and free of nasty surprises. I run phpbb2 and phpbb3 forums systems, the permissions system on phpbb2 was quite simplistic but still gave some people problems, in phpbb3 the complexity was ramped up and I doubt 1 in 10 forum administrators has a clue how to work the permissions system.
It should be noted that all GUID entities operate in the same way. e.g.
Permissions keys
As alluded to permission are free form. But there would be common ones
Identity and Aliases
A real human owner would mostly never directly own any entity but would own entities under the guise of aliases and would at any point in time be logged into the system as an alias or as multiple aliases at the same time. Each alias can be given a relationship with another alias. As such by default whilst as "owner" I can discover and control devices in all my aliases whereever I am logged in, but information will not be shared. For example I might under my browser history at work want to share that history between my work chrome and firefox browsers, I might want the same at home. But with those permissions work and home histories would remain separate unless I specifically set up a relationship.
An alias is I think Identical in functionality with a trustzone. For example if you have two houses, you might have a home alias, that then itself owns a trustzone for each house. In each house is a thermostat controller that wants to discover the thermostats in only its own house.
Micropayments
Micro payments fall easily out of an IPP model. The individual has a micro credit account with their trusted IPP, and it is important to remember that IPPs are accredited bodies signed off by a higher authority. All payments are routed via IPPs and IPPs like interbank transfers just settle the differences at the end of the day. Hence no small payments actually occur in reality.
Micropayments and Spam
We have already established that IPPs would be a good repository for email, by extension if emails were received by IPPs, it would be an opportunity to extract a micropayment from the sender, make a special case of email micropayments as an internet tax and there is no incentive to send or receive spam messages. Spam only works because sending spam is free, and ISPs are not bothered by compromised customers sending spam,an IPP seeing a customers micropayment account being drained by email fees (even at .01p an email) would be economically forced to take care of the customer.
A Note on the Semantic Dictionary
I think I can hear someone objecting that GRM is asking everything in the world to have the capacity to understand a massive dictionary.
This is not the case for a number of reasons.
Many devices can be entirely passive. For example a home control application connect to an IR emitter will want to know how to relate to each piece of IR controlled kit you have and have activity entities such as "myWATCH-BLURAY" that knows what devices to turn on. For this to work there is no need to involve the actual devices at all. Though of course a device with the sentience to tell us it had turned on would be even better.
This is not a complete dictionary, the eight parts of English are apparently nouns, pronouns, verbs, adjectives, adverbs, conjunctions, prepositions, and interjections. We don't have all of these things, and I think its only the verbs that need to be really understood by an application or device.
Devices are only going to need to understand the small subset that might apply to them. Say we have got a GRM connected bluray player. It would want to have a list of the GUIDs of each of its possible commands, and would want the ability to echo back to a received command that it had done it, actually that’s kind of a bad example as a bluray player on the GRM would not be being controlled by IR but by sending it GRM requests.
This is not the language of Shakespeare, the primitives that require understanding will surely be in the realms of 3 digits, and it is mostly our IPPs GRM application that needs to understand most things.
Listen, and understand. The GRM is out there. It doesn't have adjectives. It doesn't care about nouns. It doesn't have adverbs, or prepositions or conjunctions. All it is, is an unrelenting set of verbs, that will never stop.
The API
There are liable to be protocols developed for the API. But essentially the API is as follows:
Essentially each API call is a conversation in which the IPP or object being called may respond not with an answer but with a call of its own until a conclusion is reached.Much of this conversation may be about breaking down the GUID of the call into what it actually means by reading the primitives. Once that is understood the same call might need less conversation because the called object might have cached the meaning. At some level of course the called object must know something. At the very basic level there will be a GET-GUID-ENTITY GUID a called object would need to know in order to even ask about the meaning of other GUID's.
There is a DNS like element here, if you recall GUIDS are split into an ORIGIN part and general GUID part. When a called object needs to understand a GUID it may actually be asking its caller for the meaning, it may go to the IPP, or it may go to some general cloud GNS type service.
How does this work in terms of security? this being the GRM the answer is to some degree however the heck you want it to! But for example a device might make an API request to the IPP, which would then respond with a AND-WHO-THE-HELL-ARE-YOU guid, which would then need to be responded to with an entity security RSA signed by the authority. From that point on the called object provides an authorizing GUID that may be geared to just that conversation or for a session or even longer.
There is likely to be a "telnet" like negotiation on some of these things, a WILL,WON'T, DO, DON'T conversation about how the sides can talk. Perhaps the first call is over https and then the sides establish that they can talk a different protocol.
How is all this passed around and with what protocols?
Once again the keyword is evolution, you have to start somewhere and I would envisage that the starting point is a REST API over https passing POST data in JSON format. But at the start of the conversation the requesting entity may pass a GUID saying what protocols it can use, or conversely the called application may respond with suggested protocols. If a device is in the IOT and we want to communicate with it, we will contact the public cloud with its GUID to find out how to talk to it.
Once we have that bootstrap of the JSON format of a set of guids and entities things are free to evolve.
GRM in the browser
I think a lot of this would be done in "divs". e.g.
<div class="ipp-request" id="guid">
EntityJSON
</div>
This would be inert, but the browser would have an extension supplied by the IPP or as part of the browsers code that you would key to your IPP. This extension would see the DIV and respond accordingly.
GRM JSON
"guidofcaller": {
"core":[core entity]
"meta":[meta data]
"system:":[system data]
}
Bandwidth
With the advent of Netflix streaming 4K video a verbose conversation with long GUIDs is hardly a big bandwidth issue. However the GRM can easily economize on bandwidth. One class of GUID will be translated GUIDs. In this format the chatting devices agree on a list of translations. In that context for a lot of devices the GUID instruction may reduce to 2 bytes.
Evolution
Evolution is inherent in the SUPERSEDES model, a model that goes all the way down to the API. One important aspect of this is the ability of items in the internet of things to evolve. This ties in with the somewhat interesting question that when you have an internet connected device, just how much is it talking to the manufacture? I'd like to think in a GRM model there would become an agreement relationship that made this a contract, but in one way or another devices would like to report back at least some things. One core thing that would be reported, is any GUIDs that were passed to the devices API that the API failed to understand. So for example if a manufacturer gets a lot of reports that its devices are being asked to SWITCH-TO-STANDBY-MODE they can see what the request means by looking at the DEFINITION-TEXT and realize that.
Eek I'm a Fridge this means nothing sensible to me, but maybe I should be able to respond with a REASON code of some description.
Yes I should be able to do this.
I'm a simple motion sensor, part of an alarm system. The suggestion of STANDBY is suspect and I need my limited firmware memory for things I might need to understand. So I will not upgrade to know about this request.
GRM and AI
Does it take artificial intelligence to process a GRM conversation? Emphatically NO. Conversations are not like people talking, they are constructed to be understood clearly and this is aided by the SINGULAR guids that act to identify the most important part of each sentence.
There is though an underlying scope for AI within the GRM, here we have a collection of entities and relationships between people and things, people and people, things and things, companies and people, companies and things that can hold independent conversations.
On the midst of this is your IPP able given the permission to survey your world... bank account high... do you want to transfer some money to savings? warning mobile bill unusually high... Your schedule says you are at home at the weekend and the weathers good, may a BBQ?
Your IPP can be your personal assistant.
User Stories
Mortgage Application
In the current world I receive a letter asking for print outs of three payslips, and business and personal bank statement. This is a palaver and hardly secure from the building societies point of view.
In the GRM world. I receive an email, and three rows of choices pop-up. The first row asks me to confirm access to the payslips which are listed on the right, the second for access to the personal bank statements, the third row is stuck a little and asks me to choose which account to share. All three rows state that they are asking for access for 7 days. A few clicks and I'm done.
So what is going on behind the scenes?
I see the request without any security worries because I already have a relationship with the building society and the security signing of the request has been verified as valid.
Since I have provided the GUID of my employer and current account already, my IPP has gone and found the pertinent information. The request GUID is quite explicit about what it wants.
I had not provided enough information on the business account, Hence I am presented with accounts that might be what is wanted and have to make that choice myself.
Since all the GUID for these entities are signed by the bank and my employer, there is no question of fraudulent data being provided. I also have an explicit contract that my data will only be accessed within 7 days, with a side note that non pertinent information will not be retained for more than 30 days.
Thermostat
I have installed a new intelligent thermostat. It is "discovered" as a new entity when I login. It immediately shows up as an Icon along side three container entities.
Martin
Household
Kids Household
The first two are entities that will tend to exist for everyone, "Kids Household" is a container I have chosen to create for just the kids. e.g. Martin is myself, household has myself and partner as owners. I make the kids users of "Kids household".
I drag the themostat icon into all three containers and click done. But I am not finished.
I go to the Kids Household and edit the thermostat. I can drill into it and see it has a "Set Temperature" entity. This Entity already happens to have a VALID_RANGE entity that limits what temperatures can be set. I want to limit what the kids can set and so I edit that entity. When I try to do that I am asked "Do you want to edit the operation of the Thermostat for everyone or just for Kids Household"? I choose to alter it just for kids Household.
Behind the Scenes a few things have happened:
The thermostat entity has an I-WANT-TO-BELONG entity, that suggests what containers it would like to be in.
We have created a mythermostat Entity which is an entity that is a COPIED-INSTANCE-OF=>thermostatguid. This means our IPP has copied all the semantics of the thermostat keeping note of the source GUID. We now have in our space a thermostat we can change for ourselves.
mythermostat is then referenced by entities we create in each of our containers.
In the Kids Household container we gain another entity INHERITED-INSTANCE-OF->mythermostat which just contains the modified VALID_RANGE entity.
As a householder I am none to aware unless I choose to be of the actual mechanics. I don't see terms such as VALID_RANGE I will see readable labels and descriptions. However this is all about PRIMATIVES and devices, it is our household control system that reads the entities associated with a thermostat and adds then to its GUI for the household. If the thermostat had no VALID_RANGE concept I could go down to a programmers level and add one myself.
Supermarket
Your signed verified purchase list can be shared with your IPP automatically as you pay via the relationship between your payment method and your IPP. This is of course both useful and valuable information. No more need to keep receipts for electrical goods, and should you choose to allow your IPP to use this information to profile you perhaps as part of an anonyminised group it could earn you commission. It will also give you automatic ability to profile your own spending to help you budget.
Household Guest
When you visit someone, they accept your request to be a household guess.
When you access something in the household, something like this happens.
"Hi I'm provably Tom via a https type connection, and here is the relationship that allows me access"
The appliance then asks the middleware if that is valid, and then probably does set up a temporary relationship that means it can cut out the middleman for a while.
When you leave, the householder either removes you, are allows your access to timeout. The middleware should have recorded a list of accesses and can sent a revocation code to used appliances.
The OK google issue
How do you allow "ok google" to active the google voice system without google being able to listen to everything said. GRM makes this relatively easy, there is a certified app that does not spy on you, but simply polls for "okay google" this app has a relationship with the browser and a relationship with the microphone and can mediate a connection when it detects "ok google".
LikeBe the first to like this
No labels
Write a comment…
Basic 4 way web site authentication
This is the model for a user visiting a domain, the domain and being validated by the IPPs for both the domain and the user, so both sides know the relationship.
The model depends on a trust relationship between the IPPs.
The authentication between the user and the IPP and between the Domain and the IPP are not described, as that is entirely for the IPP to define and would be different between devices.
At this point communication can carry on over https without further authorisation or additional encryption.
Comments
Post a Comment