Who contacts the Global Registry?

[fbeierle]

The Graph Connector serves as a address book/contact list.

The interface is defined here: https://github.com/reTHINK-project/core-framework/blob/master/docs/specs/runtime/runtime-apis.md

Open points are: * implementation of Bloom filters; maybe use https://github.com/jasondavies/bloomfilter.js * internal data format of graph data

Your feedback is welcome. Edit: I will open another issue regarding the Graph Connector. So far, we only discussed who will contact the Global Registry here. Edit end.

Also, I have a question: Is there any part of the Runtime so far that communicates with the Global Registry?

[pchainho]

I was not aware of this interface. I understood the Domain Registry was the one interfacing with the Global Registry, @rjflp ?

[fbeierle]

In order to call someone who's GUID is stored in the Graph Connector, we need to contact the Global Registry to resolve the GUID to that user's Domain Registr(y/ies).

[pchainho]

I understand that but can't this be done through a Domain Registry to minimize the number of protostubs deployed in the runtime?

The runtime instantiation is triggered by some Hyperty associated to a certain domain which will use its domain's protostub to register in the domain's registry. This protostub could be shared to perform queries through users' GUID even if they belong to other domains.

Actually I thought users' queries would be supported by the Discovery and I'm missing the dynamic view of the Graph Connector to better understand its usability: could you provide some UML MSCs describing the main data flows between the Graph Connector and other elements? This would really help clarify the Graph Connector role in the Hyperty Runtime.

[fbeierle]

Discovery cannot substitute looking up a user by her GUID. Users might choose not to be discoverable and there can be several Discovery services holding data about different people.

You are right that the domain/CSP could interface with the Global Registry to look up users. However, when moving/adding/removing domains, the user needs to contact the Global Registry directly.

Here is a UML sequence diagram:

[sbecot]

The first or second solution may be a question of tuning, but I still don't understand why moving/adding/removing necessitates to contact directly the Global registry. An indirection is still possible no?

[fbeierle]

The GUID is based on the user's public key. The user's record in the Global Registry contains information about her current Domain Registries. Updating her entry in the Global Registry, the user needs to sign her record with her private key. Would the user let some service provider handle this, she would have to give out her private key. Doing this, the user is no longer in control of her data.

Maybe @sgoendoer can say more regarding this topic.

[sbecot]

As far as I understand, the Global registry should be updated by the Domain registry, not by the user. This has to be clarified.

[sgoendoer]

The Global Registry and/or CSP MUST NOT / SHOULD NOT know the user's private key. Hence, the Domain Registry cannot update the Global Registry. Anyhow, If wanted, a user can create (i.e. sign) a data package to be published in the GlobalRegistry and forward it to the DomainRegistry, which then simply uploads it to the GlobalRegistry.

[sbecot]

The Global Registry and/or CSP MUST NOT / SHOULD NOT know the user's private key

Fully agree.

Hence, the Domain Registry cannot update the Global Registry.

Why not? That's what you state just below:

Anyhow, If wanted, a user can create (i.e. sign) a data package to be published in the GlobalRegistry and forward it to the DomainRegistry, which then simply uploads it to the GlobalRegistry.

[sgoendoer]

Of course this could be done this way, but I don't think it's mandatory that it is used this way. Is there a special requirement that would propose to use such a solution?

One advantage would be that when we are restricting the (write) access to the Global Registry to just the (CSP-run) Domain Registry servers, we don't really need to worry about malicious write requests from arbitrary attackers.

[rjflp]

@fbeierle Regarding the UML Sequence diagram, I would prefer the first alternative: it keeps complexity in the end devices (easier to update); provides more privacy.

@sbecot @sgoendoer I believe that the Global Registry should be contacted directly for the following reasons:

• It is independent from the Domain Registry.
• One can use several Domain Registry simultaneously (for several CSP). Which one would we use to update the Global Registry?
• The Global Registry contains what is basically the list of CSPs being used by the user. Why would we ask one CSP to update this list? There may be privacy and even sabotage concerns.
• The Global Registry is update using a private key. This must remain private.
• Future changes/updates to the Global Registry would be more difficult to perform if this required both the runtime/hyperty and the Domain Registries to also be updated.

[sbecot]

Good arguments, but not completely convincing.

It is independent from the Domain Registry.

It is, but indeed, it refers to reachability in the CSPs/Domain registries.

One can use several Domain Registry simultaneously (for several CSP). Which one would we use to update the Global Registry?

The domain which is updated should notify the Global registry, of course not the entire list.

The Global Registry contains what is basically the list of CSPs being used by the user. Why would we ask one CSP to update this list? There may be privacy and even sabotage concerns.

A CSP won't update a list but it's current status only. No privacy concern here.

The Global Registry is update using a private key.

I missed this point. We have to go further in the data present in both registries.

Future changes/updates to the Global Registry would be more difficult to perform if this required both the runtime/hyperty and the Domain Registries to also be updated.

Agree, that's why I thought that only Domain registry would update Global registry. That would allow to have much less potential clients: lower the risk of attacks if a limited set of clients can update them, and limit the number of updates.

[fbeierle]

One can use several Domain Registry simultaneously (for several CSP). Which one would we use to update the Global Registry?

Any of the Domain Registry could be used.

The Global Registry contains what is basically the list of CSPs being used by the user. Why would we ask one CSP to update this list? There may be privacy and even sabotage concerns.

I think, privacy should not be a concern because the Global Registry is public and does only contain the user's public key and her list of domain registries. Sabotage should not be possible if the record is signed on the user's device with the user's private key. If a Domain Registry refuses to update to the Global Registry or if a Domain Registry is suddenly offline permanently, any other Domain Registry can be used to make the update, as long as the user has her private key.

[rjflp]

It is, but indeed, it refers to reachability in the CSPs/Domain registries.

Not sure what you mean. Reachability information, which is updated often, is only present in the Domain registries.

The domain which is updated should notify the Global registry, of course not the entire list.

The Global Registry is only updated when the user subscribes/unsubscribes a new service. It contains the mapping from a GUID to the domain specific addresses for each of the services used by that user. This mapping is a single entry, signed with the private key. Although it would be possible, we are currently assuming that there are no "partial updates", only full replacement of a list of services with a new list. The Global Registry is a Distributed Hash Table. It maps from a GUID (key) to an entry (value).

The Global Registry is updated using a private key.

I missed this point. We have to go further in the data present in both registries.

All the autentication of the Global Registry is based on a public/private key pair. Writes are performed using the same private key, which must be kept private.

Agree, that's why I thought that only Domain registry would update Global registry. That would allow to have much less potential clients: lower the risk of attacks if a limited set of clients can update them, and limit the number of updates.

Event though they are part of the Registry service, the Global and the Domain registries are independent entities. No need to create an artificial dependency.

[sgoendoer]

A CSP cannot update only a part of the data in the global registry as the data is signed as a whole, e.g. as a JWT.

What data is present in what registry has (partly) been partly discussed here: https://github.com/reTHINK-project/architecture/issues/55 Anyhow, this was before the split between global and domain registry. Anyhow, I am sure we discussed this at some later point in more detail but i cannot find the issue as of now :(

For Global Registry, data would include (not limited to this though)

• GUID
• publicKey
• salt
• timestamp of last change
• list of userIDs (i.e. pointers to domain registries)
• signature

I opened up new issues in the registry repositories for this

[sbecot]

Got the point. Although this is not very flexible.

[KCorre]

A few things:

By signing an entry pointing to a domain in the GReg the user recognize a relation with a CSP. If a resource is present at this domain (userIDs) the CSP recognize a relation with the user.

• What would be the consequences of say Alice with GUID GUID_A and uID uID_A with relation (GUID_A, uID_A) and then another user Bob with GUID_B which would create a relation in the Global Registry (GUID_B, uID_A)? Would Bob impersonate Alice? Note that if the GUID_A would appear in uID_A this would be impossible but it would also forbid Alice from changing GUID and keeping the same uID.

As I explained in Aveiro there is nothing to distinguish from a userIDs to another type of data such as non CSP-userID or even a URL. So it would be possible for the user to register any kind of other "userIDs" in the Global Registry. For instance relations with an IdP, or a public key, ... This is something possible not something I'm asking. Which for me is fine. I think it's opening new possibilities that we should think of.

• For instance by registering its userIDs identities (IdPs) a user would prove that the identity he is using for authentication is also linked to the GUID.

Finally, the signature in the global registry enforce two protections. A protection againt deleting attack which ensure the availability of data in the global registry. Secondly a protection against attack adding new entries.

[sgoendoer]

This is in fact a valid point. Very similar to registering a domain sebastian.org and let it point to the IP address of felix.com. One could address this issue by letting the DReg sign the "claim" of a GUID being associated with an UserID. Both signature and claim could be published in the GReg. Furthermore, the DReg could check if GUID and UserID are matching.

[fbeierle]

What would be the consequences of say Alice with GUID GUID_A and uID uID_A with relation (GUID_A, uID_A) and then another user Bob with GUID_B which would create a relation in the Global Registry (GUID_B, uID_A)? Would Bob impersonate Alice? Note that if the GUID_A would appear in uID_A this would be impossible but it would also forbid Alice from changing GUID and keeping the same uID.

Bob would not be able to impersonate Alice. Someone contacting "Bob" with GUID_B would just reach Alice. Placing a call, Bob would make it difficult for the called to call him back, as under GUID_B, he would just reach Alice. I think, this is analogous to setting up an email address bob@something.com and forwarding it to Alice's Inbox.

[KCorre]

Ok thanks

[fbeierle]

I want to try to summarize the arguments that are left after the discussion about who contacts the Global Registry:

The Global Registry needs to be contacted to:

• put initial record
• update record (change of domain registries)
• delete record
• lookup GUIDs

The proposed solutions are: 1) Let the Runtime handle the contact 2) Let any Domain Registry handle the contact (with the user signing the record on her device)

Advantages of solution 1:

• Privacy advantage if user queries Global Registry directly, Domain Registry then remains oblivious to the user's search queries
• No dependency between Global and Domain Registry

Advantages of solution 2:

• Limit the number of external service providers that the runtime has to contact
• Have less clients update the Global Registry

I am unsure about Ricardo's @rjflp point about future changes/updates.

Did I miss any open arguments?

@reTHINK-project/wp4

[KCorre]

Some remarks:

• The GUIDs lookup is not the same type of interactions as a create/update/delete operation.
• As we should provide an open interface to do these operations both solutions should be possible on the same implementations.

About solution1

• The privacy advantages is limited because after the registry lookup, the user would probably start a call using its CSP. The CSP is the same entity as the Domain Registry and in the end learn who the user is calling.
• No dependency between global and domain (ok but see solution 2)

About soluton 2

• Altough its limiting the number of external services. Its in fact only removing ONE service. The DHT Global Registry. Not that much of an overhead.
• I am not sure the number of clients may be an issue. In the end you are checking the validity of the private key signature. So that would mean there is as much clients as in solution 1.
• Global and Domain registry are still independant as the key is still owned by the user.

On the other hand, if a CSP or whatever service want to provide a GUID creation service where they would know (by construction) the private key of their user. What's stopping them? What would be the problem? If a user delegate the management of its identity to a third party it's is decision and I don't see why it would be bad or even how we could stop that. As long as other user can still manage thei own private key by themselves we would still have reached our goal. It would be similar to the way Bitcoin wallet are handled.

[fbeierle]

Thank you for your reply. I have the feeling we don't have any strong arguments for either side. Still, as I understand your last paragraph, with solution 1, we would probably have more flexibility: Solution 2 could still be realized by any CSP, offering something like GUID-as-a-Service and Global-Registry-Contact-as-a-Service. Do you agree or did I misinterpret?

[KCorre]

I agree. If there is a function on the runtime to push something on the global registry, option 2 could still be realised by not calling the function and having the CSP do it. If there is no such function on the runtime then another implementation could add it later but it would be probably more difficult and we would be missing something in our demonstrator.

[sbecot]

So if I understand well, it's solution 1 + 2. This solution has to be reported in the D4.1 update to have a clear view, and then issue will be closed.