Open rjflp opened 7 years ago
I'm not sure that a human friendly identifier is necessary, I think that's what have been implemented but this is to discuss. For example publication on the Global Registry is done with the GUID and a private Key. This mechanism could also be used for the Discovery Service, as long as you provide such publication mechanism. The question of the rethink framework is important too, as you could of course be registered in the discovery service without any "rethink compatible" account. The question could be "who manages the administration of the user data?". If the discovery service provides an API, any service could provide administration means (associated to the service account). The you just click on a button to publish your data, the GUID and private key could be enough. This is actually the case for the Greg. This would also allow to avoid many different step that would not be very clear for the user who may not see the difference between global reg and discovery service. In both cases he has to pubish his data.
@sbecot The Greg only allows queries by GUID. This is not something that is easily shared outside of a computer. It is not practical to provide over the phone, etc.
The Discovery Service bridges this gap, by enabling queries using other parameters, such as name, email, phone number, etc, from the profile that the user builds in the Discovery Service.
So, I guess that the answer to "who manages the administration of the user data?" is, at least from a profile point of view, the Discovery Service. User requires an account with the Discovery Service before we can be "discoverable" in rethink.
The use case is, you go to a site for the first time, that site provides an app that uses the rethink framework. You download the app and framework and use it for the first time. You use an IdP you already have, the runtime will assist you with the creation of a GUID, but what about the Discovery Service? Will you be told to go to another site, and create an account, by copy pasting GUID and some of that data? Would it be better for the runtime to help you with this?
This is not a technical issue so much as an usability issue.
@rjflp I fully agree with you. If I continue your scenario, when your site have created the GUID, I agree that you shouldn't go on another site. The current site can assist you to publish also your data on the discovery service. We can even imagin that the user is not aware of the difference. That supports the idea not to have a specific account on the discovery service, but use the same kind of mechanism than for the GReg. The fact that the runtime does it is not exactly important. Any kind of application can do this, but of course if you used one to do it, it is simpler to always use the same.
I think that building an API and UserInterface to replicate the account creation process already available on the Discovery Service Website is a waste of resources. Furthermore, it would have to be constantly updated. A good solution could be for the account creation page on the Discovery Service to accept the GUID as an input. From the runtime, we would direct the user to something like: https://discovery.rethink.eu/creatAccount?guid=ab098cd87ed798df7098a
And the user would fill in the rest of the missing information.
@ingofriese What do you think?
@rjflp what @sbecot meant is that if Discovery service provides an API similar to the one from GlobalRegisrty (in this case it is a simple HTTP PUT with some JWT dataset) we could include its call in the application used to publish the GUID into the GReg (for instance an address book app)
@ingofriese any thoughts?
Giiven that an account on the Discovery Service is required for the user to be found using human friendly identifiers (such as email address), every user needs an account there.
Users would be exposed to the rethink framework the first time they use a rethink app (by entering a website?). In order to bootstrap the process, it would be much simpler if the runtime could assist the user with the creation of an account on the discovery service. Can the protostub loader referred in issue #4 provide this functionality?